statamic / ideas Goto Github PK

In v2, there's a mixed pattern of how you can close tags. For example, you can write:

{{ if condition }}
    // Code goes here
{{ endif }}

and

{{ if condition }}
    // Code goes here
{{ /if }}

But others like collection don't have that alias.

{{ collection from="blog" }}
    // Code goes here
{{ /collection }}

It's a personal preference (granted), but I'd love to be able to have a consistent alias that would enable users to close tags with the keyword end, as well as the /. E.g.

{{ collection from="blog" }}
    // Code goes here
{{ endcollection }}

Since we cannot predict features or changes, it would be nice to have some sort of way to communicate with users in the CP in a generic way.

eg.

• You need to do bla bla to your account on statamic.com
• Your version has a security issue
• We've updated the terms and conditions
• There's free pizza in the lobby

Structures are ordered alphabetically but it would improve the sidebar navigation if we could number order the listing to move Structures of higher importance (Pages) to the top of the list.

As users are still learning the new concepts introduced in V3, it would be help to reiterate the purpose and importance of Blueprint and Structures in the Create Collection wizard.

1. Could add the dashboard definition for the Blueprint field.

Blueprints define the custom fields used to create and store your content.

2. Same goes for the Structure field in the Routing step.

Structures establish the heirarchy of your pages and help you manage your site navigation.

3. It would also be useful to know which fields are required and which are optional. As I understand it, a Blueprint is required and a Structure is optional. Is that right?

When creating an Asset field in the field builder, users should be able to Create folder in the Asset field Settings and the Folder listing screens.

Settings:

Folder Listing:

On the publish form, it's difficult to distinguish between two Add set buttons. Could use "Add [field_name] Set" help text.

We can benchmark the number of times we reach out and hit the filesystem with fs_usage. There are different types of touches -- stat, lstat, read, write, etc. We should be able to limit these to once per type per request, and hopefully jack up some performance gains.

Logging the file system activity:

Run the following command and hit the system with a single request:

sudo fs_usage php-fpm -f filesys -w > ~/Desktop/fs_log.txt

And then we can pop that file open and find results for specific .yaml or .md files to see how many times they've been touched.

They will need to expose the params and arguments in the URL

Title shouldn't really need to be required. It could be generated based on other fields, defined on the collection level.

statamic/v2-hub#1920

Parts of the Assets manager might be a bit confusing, especially for a less savvy user.
(this might belong in the ideas repo)

• Create Container button is always visible. It might confuse or accidentally be clicked when a user wants to Create Folder (Folder vs Container...). Both those buttons are also very close to each other. Maybe the Create Container button doesn't need to be there once you're in a container.

• Folders are not selectable in either grid or list mode. Inconsistent with behaviour when clicking on files.

• Clicking on a file in list mode opens up the "Edit file" modal, but in grid mode it selects the file and allows easy multiple file selection. The same behaviour in both display modes would be more consistent. Maybe show a checkbox when hovering on a grid file preview to allow for selection (as in list mode), otherwise, click = edit file.

• resources/js/addonname.js
• webpack.mix.js compiling addonname.js into dist/js
• package.json with just enough to compile assets
• The ServiceProvider's should have a $scripts array pointing at addonname.js
• .gitignore with node_modules and vendor

Out of the box, Statamic 3 comes with a resources folder that contains a sass folder. I, like many others, don't use Sass/Scss. I use PostCSS. While it's trivial to delete that folder, it would be great if there was an ability to define a front end preset to use during the composer command.

I don't think this is possible cause it could break things, but I found myself wanting to do this many times in both v2 and v3. Often I'll find myself wanting to change a fieldset from a textarea fieldtype to a markdown fieldtype. To do this, you must delete and recreate the field.

Would be useful to add a "Change fieldset" action for similar fieldtypes. Perhaps show a warning if the data could produce an error.

If a user manually moves an asset but forgets to move the meta file with it, the new one will eventually get created which is fine, but the old one will just sit there forever.

In the command, after the meta files are generated, we could loop over all meta files and delete them if there's no corresponding asset.

Maybe the cleanup part could also be extracted to its own command.

It would be much better to just use the columns from a user's preferences to render a selector stack when linking an entry from a collection using the Relationship fieldtype. Right now, when we use <relationship-fieldtype> in one of our components or even a Bard toolbar button child component, we have to re-implement logic on what columns to show for what collections in that stack, after we already added that logic to our wrapping PolygonRelationship, even though it's right there in the user preferences.

Description

This is mildly annoying that i need to click into this dropdown to see all the rules.
It would be nice if i could start typing, and suggestions would appear.

Something akin to this:

I have found myself needing a "slug" field based on another field (not the title). Would be great if we could "attach" the slug to a text field.

When creating new fieldsets it would be useful to have an action to Duplicate Fieldset.

As explained in statamic/cms#74

It might be cool to include a trait in the addon service provider stub to auto-register fieldtypes/filters/tags/etc. for the user. If the trait is used, the service provider would loop through the appropriate folders, loop over the files, and auto-register everything. If it's too magical for a user, they can remove the use trait statement.

My thought is this... In Laravel, so many times I’ve developed a policy and forgot to register it, only to waste 5 minutes fumbling before realizing. I think I remember a tweet where Taylor said he was working on a convention to auto-register policies with models using a naming convention? That said, there are other things in Laravel that will always require registering, like middleware.

Pros: Make it easier for new users to develop for marketplace. Remove that extra mental step that some people might forget.

Cons: Development time? Any others?

😊

Dates step:
The wording on these options could be simplified. Some ideas:

Articles – Entries will be private until a date in the future.
Events – Entries will be private after a certain date.
No dates – Entries will not have any dates.

Order step:
I'd expect Alphabetical to default to ascending.

Content Model step:
Would be nice if Blueprints, Taxonomies, etc linked out to the page where you could create them. First thing I did when setting up a new site was create the collection and I hadn't set up anything from this step. Assume I could go back and link it later.

https://laravelshift.com/opinionated-laravel-way-shift

https://cl.ly/f02423698beb

Add instructions or action to create a sidebar set. This is a hidden but often used feature that should be clearly defined on the the fieldset builder.

Right now we support make:addon with statamic things...

It'd be cool to also generate with artisan things (ie. -c to generate a controller, -l to generate listener, etc), moving to proper addon location with proper namespace, etc.

Note: I have a half working git stash, if/when we choose to do this 👍

To reduce the number of clicks needed to Save your Blueprint, you could add a "Close All" or "Save Blueprint" action to quickly exit all Stacks and save the Blueprint.

When making a blueprint the section thingy is always small. It should default to big:

Also, it should remember what it was so I don't have to expand it every time I come to this screen.

We need a way to execute actions in the browser, i.e. write the code in JS.

Would be great to be able to limit file uploads to a container based on the file type. For example, allow uploading PDF files but nothing else to a certain container.

Just because it looks like a select, doesn't mean you shouldn't be able to edit stuff.

Make the items clickable and have them open in a stack like the non-select UI mode.

This applies to the taxonomy / taxonomies / terms field. Throwing this sentence in for search keyword juice :)

I've always thought that the group_by modifier should return the actual keys in a way you can loop through them like this:

      {{ collection:store_products as="types" }}
        {{ types group_by_with_keys="type" }}
          <ul>
          {{ groups }} <!-- this is each 'type'-->
            {{ group }} <!-- this will be the `id` of the type, so in your case you'll likely want to feed that into a relate tag -->
            {{ relate:group }}
              {{ title }}
            {{ if first }}<li><h1>{{ title }}</h1></li>{{ /if }}
            {{ item as="products" }}
              <ul>
              {{ products }}
                <li>{{ title }}</li>
              {{ /products }}
              </ul>
            {{ /item }}
        {{ /groups }}
      {{ /types }}
    {{ /collection...... }}

So I made one:

class GroupByWithKeysModifier extends Modifier
{
    /**
     * Modify a value
     *
     * @param mixed  $value    The value to be modified
     * @param array  $params   Any parameters used in the modifier
     * @param array  $context  Contextual values
     * @return mixed
     */
    public function index($value, $params, $context)
    {
        $group = [];

        $keyedItems = collect(Modify::value($value)->groupBy($params)->fetch())
            ->map(function ($item, $key) {
                return ['group' => $key, 'item' => $item];
            })->values()
            ->all();

        return Arr::set($group, 'groups', $keyedItems);
    }
}

Should I do a PR?

Things like EXIF, dimensions, etc.

It should be done on upload, queueable being a plus.

It will also need to be lazily loaded for assets that already exist.

I wonder if we should augment the data before inserting it into the search index so you can search on what you would expect as output. Thoughts, @jasonvarga?

Originally posted by @jackmcdade in statamic/cms#550 (comment)

Maybe It could be useful in a series of cases, for example to show automatically labels for fields instead of title (without click) or to show direct doc links in section or under particular fields type.

Could it make sense?

Description

This is mildly annoying that i need to click into this dropdown to see all the rules.
It would be nice if i could start typing, and suggestions would appear.

Something akin to this:

https://github.com/jwagner/smartcrop.js/

It would provide a smart crop point for images, better than the current 50-50 default.

Imagine having a company that has multiple locations. Each of those locations should be managed through their own site. Clear case of a multi site.

Let's assume we have a company with 3 locations/variations and 2 translations. This would create 6 different site versions, which would mean, if a user was to create or edit an entry, the user would see 5 other options to choose from for creating/editing the other translation as well.

But now, let's assume we could combine different sites to a group. Let's say location 1 (default lang) with location 1 (secondary lang). This would allow for having a clear separation between variations of a site and its translations. Now, a user would only see one option to choose from if the user was to edit/create an entry and wants to switch between the languages.

This feature would make statamic the most comprehensive CMS on the market for multi site support as it would allow to set up some really fine grained details.

Possibility to order the fields too. 😄

Fields that are only used in the column view, so you can show custom things.

As with Statamic V2... it's very important to know how many times a tag or category is being used.

It should be possible to make a route appear in only certain sites, or differently depending on the site.

There have been several times where it's very useful for a listener to check the old version to see if anything has changed (dirty).

Reason for this is that sometimes you have to update the data and therefore call $data->save(), which fires the events again. This creates an infinite loop.

I currently solve this by copying the core "save" code into my listener so the events aren't fired again.

Option would be able to call save with a "don't fire events" param? Or expose a deeper save method that is only in charge of saving and not firing events?

Any chance we could get that for v3?

It appears that fields with type: section are included in entry->data() and as a result, are saved in the entry with a null value. That shouldn't happen I'd say.

Yay! Congrats on v3 public beta, and sorry I've been out of the loop for a while.

I've been looking through the v3 docs on statamic.dev and - with my "I'm coming from another CMS" hat on, I feel like there's a lot of complicated, heavy, technical stuff to get through (Core concepts, templating/front end) before I actually find out how to use Statamic.

This is very much developer documentation, not user documentation.

This may be very deliberate. And it may be that you have a plan for user docs. And it may be that the "Screencasts" page which currently 404's will cater for this.

But I also wonder if another "path" to reading the docs should be made, one that enables people to get up and running more quickly so that they can check out Statamic without having to invest a heap of time in reading so much.

What do you think?

• Load user widget preferences if they exist
• GUI for user widget prefs?

Would be great if the intelligence tools could jump around the code, but it can't when the vars have no type hints. For example these:

    protected $stache;
    protected $paths;
    protected $uris;
    protected $uriQueue = [];
    protected $items;
    protected $loaded = false;
    protected $updated = false;
    protected $expired = false;
    protected $markUpdates = true;
    protected $files;

Would be great if $stache was type hinted so the reflection finder thingy worked in VS Code.

Obviously not urgent but a great nice to have for us folks trying to figure out how all this works.

The starting screen for Create Structure might be an opportunity to introduce the concepts of Collection and Navigation structures. It would help solidify the user's understanding of how Structures can be used, and would also reduce the amount of steps in the following Wizard flow.

This could be a useful pattern for other Create screens such choosing how Collections should be ordered.

We would like to be able to set the value of a field that's inside a Bard Set. Currently, those seem to not be represented in Vuex except for the ProseMirror JSON of the Bard field.

Our use case: We have a Set that has fields A and B, where A is of a custom field type. From A's Vue code we want to modify the value of the B field.

Our current workaround is to render B from within A, and save the values together as an object under A's handle. This has multiple drawbacks like non-standard padding in the UI around input fields and the B field not being represented in the blueprint.

The "Add Set" dropdown should only appear when there is more than one set. In the example below, I would expect a simple "Add Cover" action instead of the dropdown.