Skip to content
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

Closed
GuySartorelli opened this issue Nov 20, 2022 · 5 comments
Closed

RFC Add elemental to the installer recipe #1025

GuySartorelli opened this issue Nov 20, 2022 · 5 comments

Comments

@GuySartorelli
Copy link
Member

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.

  • We would need to add a new class for this page type
  • If we don't update the simple theme to output $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 theme
  • This means there are at least two files projects need to amend or remove to change the defaults
  • This would not automatically add elemental blocks anywhere they're not wanted
    • But it also presents a more confusing editing experience by default, where the default pages have hardcoded WYSIWYG field and only this one special page type has elemental blocks

Apply ElementalPageExtension to Page or SiteTree by default

This is my preferred option.

  • It gives a yml file with a (very basic) example of setting config for elemental blocks
    • Because this is in a recipe, the yml is added to the project, so developers can alter or remove it to their heart's content
    • New projects are more likely to update this file than create a new one if starting from scratch
    • New projects which have some boilerplate already set up will only have to delete this one yml file to remove to completely override the defaults
  • Gives all the benefits of elemental out of the box on first dev/build (i.e. sane defaults)
  • We would need some way to convert the default content into elements (there's already a task that does this, we just need to make that task run automatically after the first default records creation or something)
    • This is really the only complicated part, but honestly it's something that would be beneficial for this module anyway.
  • We can use the ignored_classes config array to explicitly not apply this to redirector and virtual pages
  • We would need to update the simple theme to include $ElementalArea (which imo is something we should do anyway)
@xini
Copy link

xini commented Nov 26, 2022

I very strongly disagree with this.
a) it presumes that every site uses elemental, which is very much not the case
b) there are so many flaws and issues with elemental that it simply can't be pushed as a defacto standard

@micschk
Copy link
Contributor

micschk commented Feb 15, 2023

This module is the defacto way to add content to pages these days

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.

@michalkleiner
Copy link
Contributor

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.

@lerni
Copy link

lerni commented Mar 3, 2023

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.

@GuySartorelli
Copy link
Member Author

Sounds like we're not ready for this one yet. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants