-
Notifications
You must be signed in to change notification settings - Fork 117
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
RFC Add elemental to the installer recipe #1025
Comments
I very strongly disagree with this. |
I should hope not. Any evidence to support this claim/assumption? In my experience, developing sites with Elemental quickly becomes an exercise in working around various ehrm 'issues'(?) as soon as you want anything out of the ordinary. |
Even though we used Elemental for nearly all our site builds and built quite a complex and rich boilerplate around it with what we commonly needed, I also think it should NOT be the default. I would support making it as easy as possible to install and provide sane defaults like what is described in the RFC, but having it opt-in, not opt-out. It reminds me of the CWP recipe where it was initially thought everyone would want the defaults like news page, events holders, footer holder page types etc., but they hardly ever worked for the majority of the projects our clients wanted, so it was more about having a way how to remove/hide all that and keep the bare minimum required. |
I use elemental a lot but also have doubts it would be a good default. "elemental friction" like #945, #738, inline editing is hardly usable cos of to many things & fields that do not work, moving blocks to another page is not possible out of the box, virtual-element cannot be used for form-elements, handling around versioning & archive -> restoring an element is an exercise in pain cos probable an element has no title but you cannot make title a required field, anchor-linking is also not well supported, etc. The elemental experience ATM has too many rough edges to be default. |
Sounds like we're not ready for this one yet. Closing. |
This module is the defacto way to add content to pages these days. It should be added to the installer recipe, either directly or as part of recipe-cms.
Note that it wouldn't make any sense to include this in the recipe without adding some default config - so we would need to agree on what the appropriate default config would be. I've listed two options here - if anyone can think of a different option I'll happily add it to this description for discussion.
Possible options:
Add a new page type
I don't personally like this option but I can see arguments for it.
$ElementalArea
we would need a separate template file for this page type explicitly - which would likely be deleted in all projects because it won't go with the markup for the rest of their bespoke themeApply
ElementalPageExtension
toPage
orSiteTree
by defaultThis is my preferred option.
ignored_classes
config array to explicitly not apply this to redirector and virtual pages$ElementalArea
(which imo is something we should do anyway)The text was updated successfully, but these errors were encountered: