-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using >1 ElementalArea confuses content authors #758
Comments
Do you mean like this? You can see the above implementation in the Silverstripe demo Codebase is here: silverstripe/bambusa-installer |
Yeah, like that but make it OOTB functionality, part of the Elemental / SIlverstripe forms API. Cheers! |
I recommend to avoid having multiple elemental areas on a page. See #759 for more details. |
I'd support making the heading part of the area, being optional. |
My solution is to just use ElementalAreasExtension directly, and not the pages specific one, and then add the block headers manually. same as the demo solution actually.
|
For projects that have migrated to Elemental from other Blocks modules, CMS authors are used to seeing at-a-glance, which "Area" within a page, their block will be added to.
OOTB, I see no easy way to prepend a
HeadingField
or something similar before eachElementalArea
- in fact, AFAICT, the standard Silverstripe forms API doesn't work as expected: If I try to use$fields->insertBefore()
in an additionalDataExtension
subclass, the headings are added, but in a completely different spot in the CMS' UI.I had to resort to the folowing hackery to make it work (Unless of course I am missing something)
1). Subclass
ElementalPageExtension
(Which itself subclassesElementalAreasExtension
)2). Overlload
updateCMSFields()
and lightly modify as per the following:This shouldn't be too hard to configure as an opt-in using the Config system - that is as I said, unless I'm missing something.
The text was updated successfully, but these errors were encountered: