statamic / ideas Goto Github PK
View Code? Open in Web Editor NEW💡Discussions on ideas and feature requests for Statamic
Home Page: https://statamic.dev
💡Discussions on ideas and feature requests for Statamic
Home Page: https://statamic.dev
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.
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?
😊
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.
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?
https://github.com/jwagner/smartcrop.js/
It would provide a smart crop point for images, better than the current 50-50
default.
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.
Blueprints define the custom fields used to create and store your content.
Structures establish the heirarchy of your pages and help you manage your site navigation.
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.
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.
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.
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.
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.
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 👍
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)
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.
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?
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.
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.
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?
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.
Fields that are only used in the column view, so you can show custom things.
resources/js/addonname.js
webpack.mix.js
compiling addonname.js into dist/jspackage.json
with just enough to compile assetsServiceProvider
's should have a $scripts
array pointing at addonname.js.gitignore
with node_modules
and vendor
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.
Title shouldn't really need to be required. It could be generated based on other fields, defined on the collection level.
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?
They will need to expose the params and arguments in the URL
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.
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.
As explained in statamic/cms#74
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.
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.
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 :)
We need a way to execute actions in the browser, i.e. write the code in JS.
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 }}
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.