statamic
Allows fieldsets to be loaded and saved from multiple locations
Edit: I have renamed this pull request and added functionality to allow loading and saving fieldsets from multiple locations and a fix for an issue regarding saving fieldsets in subdirectories.
Allows fieldsets to be loaded and saved from multiple locations
This is a larger edit to the FieldsetRepository to allow saving and loading from multiple fieldset locations. This allows for a modular approach for loading and saving fieldsets, for example:
ARTICLES:
Articles/resources/blueprints/collections/articles.yaml
Articles/resources/blueprints/collections/articles/default.yaml
Articles/resources/fieldsets/articles-details.yaml
PAGES:
Pages/resources/blueprints/collections/pages.yaml
Pages/resources/blueprints/collections/pages/default.yaml
Pages/resources/blueprints/collections/pages/sidebar-left.yaml
Pages/resources/blueprints/collections/pages/sidebar-right.yaml
Pages/resources/fieldsets/pages-details.yaml
It works by allowing either a single string path or an array of paths to be passed in to a new statamic.system.fieldsets_path config setting. This has been added to the default config but falls back to the original setting of resource_path('fieldsets') to preserve backwards compatibility. I have also left the original FieldsetRepository->directory() method in place, it returns the first entry from the array as the default fieldset directory.
Fieldsets are loaded / saved on a first come, first serve basis based on the supplied fieldsets_path array order, so original versions of fieldsets that might be loaded in by modules can be overridden and customised where required.
Note: I have only completed FieldsetRepository changes but would make similar changes to BlueprintRepository if my approach checks out. I have also created a separate FieldsetRepositoryArrayTest to handle the array specific test cases.
Allows saving a fieldset in a subdirectory
This is a small edit to allow fieldsets that are stored in subdirectories to be saved in their original location. The ability to read from a subdirectory was already implemented but upon saving they would revert to a flattened format.
// before
fields/sub-test.yaml -> fields.sub-test.yaml
// after
fields/sub-test.yaml -> fields/sub-test.yaml
Note: I have not modified the control panel to accommodate this. When attempting to save a path with / or . the user is still presented with an error message: May only contain letters, numbers, dashes and underscores.. I am assuming this was an intentional decision and just wanted to keep the pull request fairly low impact.
Please let me know if there are any issues with the approach i've taken, thanks for all your hard work!
Just on this point below:
Note: I have not modified the control panel to accommodate this. When attempting to save a path with
/or.the user is still presented with an error message:May only contain letters, numbers, dashes and underscores.. I am assuming this was an intentional decision and just wanted to keep the pull request fairly low impact.
I feel it would be useful to allow for selecting a path from the available fieldsets_paths when creating / saving within the UI. This would allow creation of new path / module specific Fieldsets.
I’ll add to this PR and will also duplicate changes to Blueprints as well.
Similar to mine, we likely need to combine: https://github.com/statamic/cms/pull/4673
Similar to mine, we likely need to combine: #4673
@edalzell love your work. Just having a look at your PR:
-
Am I correct in assuming that you don’t need to register the blueprints and fieldset paths via an AddonServiceProvider? They could theoretically be loaded from a regular service provider or the config?
-
Can blueprints / fieldsets theoretically be loaded in without a namespace?
It would ideal if we were able to drop in some extra paths similar to config/views.php:
'paths' => [
resource_path('views'),
app_path('views'),
],
It would mean that paths could be managed without the creation or requirement of an AddonServiceProvider.
@jasonvarga we call upon your guidance, how best to proceed on this?
Okay I made a right mess of things by pulling in latest changes from 3.3 branch but that should be good to go for Blueprints now.
Regarding this:
I feel it would be useful to allow for selecting a path from the available
fieldsets_pathswhen creating / saving within the UI. This would allow creation of new path / module specific Fieldsets.
I'll hold off on this for the time being to avoid doubling up on efforts with other PR.
Edit #12501923: Crisis averted, it was a stray union type
Would you be able to explain the use case that this feature solves? I can't quite see the benefits of increasing the code complexity here.
@jackmcdade gladly,
I have been in touch with you quite a bit about this issue over email. 'Tell me about premium support', conversation started on 7th April. but i'm happy to revise here. We have also talked about organising some time to troubleshoot the control panel but that is a conversation for another day.
We are medium sized Ed-tech company with several successful products across the industry. We have carved out our 'dream' modular content approach using Statamic after a significant investment in time (as in months). It’s worth stating that we will be purchasing a Statamic licence for each of our products.
As you can see in the attached screenshots, we have a collection of nested replicators, bard field types etc grouped into Sections, Columns and Blocks. Each of these fieldsets has been customised (via CSS only) to offer a fairly streamlined editing approach and we have things like an 'Advanced' toggle and a 'More' revealer (the small vertical strip next to each block) that keeps complex editing functionality hidden at most times but that means most fields have some element of condtionality.
We have a single repository for all our products and that monorepo is split into a series of “modules”. We share module level code (models, migrations, fieldsets, blueprints) between all our sites so functionality, a new content element or block, a new database action etc added to one product can be leveraged in another. These modules are all installed via composer etc.
It has been mentioned in the pull request having to combine this with another other pull request around the addition of Namespaces. That implementation would be problematic for us because we don’t use add-hons and having to use namespaces is an issue as well for a few reasons which I am happy to elaborate on if required. I would equate the approach we used more akin to adding additional path to views_path as opposed to registering view namespaces from within a service / add on provider and I see value in both.
As stated in my recent email about launching our sites, this really is the backbone of our entire modular content approach with Statamic. I understand the burden of maintenance in accepting the pull request but I have kept the imprint intentionally small. I'd also be happy for you to @ me on GitHub if there are any emerging issues for your other clients in the event that I can assist in some way.
Let me know if you would like any more details.
Cheers, Michael
Ya @jackmcdade, my use case is that I’d love to provide fieldsets from an addon without having to publish them, as those can’t easily be updated if their are changes. In my particular case, the Events addon should provide a file set that can be imported into blueprints.
Similar to mine, we likely need to combine: #4673
@edalzell love your work. Just having a look at your PR:
- Am I correct in assuming that you don’t need to register the blueprints and fieldset paths via an AddonServiceProvider? They could theoretically be loaded from a regular service provider or the config?
- Can blueprints / fieldsets theoretically be loaded in without a namespace?
It would ideal if we were able to drop in some extra paths similar to config/views.php:
'paths' => [ resource_path('views'), app_path('views'), ],It would mean that paths could be managed without the creation or requirement of an AddonServiceProvider.
@jasonvarga we call upon your guidance, how best to proceed on this?
Just want to re-iterate on this point above, I do feel like there is a use case for both.
It seems that this PR and #4673 are basically achieving the same goal.
This one is more centered around being able to provide additional paths where as the other one is about adding namespaces.
It would mean that paths could be managed without the creation or requirement of an AddonServiceProvider.
You could add Fieldset::addDirectory(...) to your AppServiceProvider to add additional paths. No need to create an entire addon.
Fieldset::addDirectory('/path/to/module_one', 'module_one');
Then you can use the fieldset like so:
-
handle: mybutton
field: 'module_one::buttons.somebutton'
-
import: 'module_one::buttons'
You asked this about Erin's PR:
Can blueprints / fieldsets theoretically be loaded in without a namespace?
You can't, but I think that's good. For your use case, your namespace would be module_one, for example.
Fieldsets are loaded / saved on a first come, first serve basis based on the supplied fieldsets_path array order
By using namespaces, there's no ambiguity. If you have two fieldsets named the same, you don't have to worry about the first come first serve issue. You'll know exactly which file it's referring to.
I feel it would be useful to allow for selecting a path from the available fieldsets_paths when creating / saving within the UI. This would allow creation of new path / module specific Fieldsets.
Erin's PR could be updated to allow you to select the namespace.
We very much appreciate the contribution but I'm going to close this PR and continue to work on the other, but we'll make sure that your modular approach is achievable there.
