Looking for feedback on SiteConfig assigned themes

[Damian Mooyman]

As a part of recent refactoring in the master branches of the core modules, we have now introduced the concept of nested themes. You can see the implementation of this feature at https://github.com/silverstripe/silverstripe-framework/pull/5804.

As this has been a reasonably major API change, there are a few parts of the CMS that no longer work the way they once did in 3.x, or at least the way one would expect.

One of these areas is the SiteConfig theme selector. Since theme management has become a lot more powerful and configurable, I'm not certain it makes much sense to offer a simple theme dropdown selector as the default mechanism. In fact, it raises the question as to whether theme management is really a content editor's role, or a web developer's role.

I have raised https://github.com/silverstripe/silverstripe-siteconfig/pull/31 as a concept for supporting simple theme selection interacting with a set of stacked themes, in an attempt to maintain existing behaviour.

However as an alternative, I would propose that we simply remove the theme selector from SiteConfig, and default to yml as the main configuration. Modules such as Subsites could still extend theme selection with their own behaviour, but it would no longer be an out of the box function.

How do others feel about this? Is CMS-theme selection an important enough feature to maintain, and if so, what form should this take?

I'm looking forward to your feedback. :)

Kind regards,

Damian Mooyman

[Daniel Hensby]

I would support dropping theme selection from SiteConfig

For all projects I've worked on we had a SiteConfigExtension to hide the dropdown.

[Richard Rudy]

I think this change speaks more towards the core market for SilverStripe. If SilverStripe is inteded to be a developer targetted framework moving forward removing the default theme selector makes sense. However, if the goal is to  build a much more robust theme ecosystem (like Wordpress) where the content editor is able to pick from a lot of themes and select the one they want, then a slector will be needed.

Judging by the projects I currently work on, I'm creating custom theme and implimenations. I only leave the simple theme on my dev server as a fallback for testing. I have a few projects using subsites, but even those have augmented the deafult theme selector for acusotm use cases.

My vote is to remove the selector, but as I said this is more a strategic decsion.

[Ralph Slooten]

We don't use the theme selection option either for any of our SS websites and, like Daniel said, tend to hide as it's not used anyway.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[mikenz]

If it disappeared from SiteConfig I wouldn't miss it. An I could close an open request from my testers to hide it in our installation :-)

- Mike

[Sam Minnée]

SilverStripe core isn't really designed for non-developers to pick up and run with independently. It's primary use-case is for web designer (or web team) is to be able to work with copywriters & digital marketers to build a tailored, quality site as a team.

In certain cases, the theme selector is beneficial, and SilverStripe can be built on to make a tool that lets non-developers spin up new sites. Additionally, I think that the modules that you get with silverstripe/installer should be helpful to a newcomer: it's a lot easier for an experienced developer to make their own composer.json than for a newcomer to know what they were supposed to have installed.

For that reason, I think that this feature should be shifted into its own module that is included in silverstripe/installer by default but isn't a dependency of silverstripe/cms.

I've raised an RFC here with a bit more detail on implementation: https://github.com/silverstripe/silverstripe-cms/issues/1552

To Damian, Paul, Chris, Hamish, and Ingo: I don't see this as a priority for our in-house dev work right now; we've got bigger fish to fry.

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Sam Minnée

CEO

SilverStripe Limited

[Roman]

Great work on the nested themes, I like it.

I'm also in favor of dropping the theme-selector. I've never used it in any project.
I guess it should be added to the subsites-module somehow. Since subsites are created/administrated within the CMS, it does make sense to have a theme-selector there… (as opposed to a single-website, where the developer installs the theme and adjusts the config file accordingly).

The available "themes" for the subsite module could also be configured via config-api instead (so that the developer can specify which "parts" form a theme?). Not sure how it would work in detail, as I don't fully understand how the nested themes work yet :)

@Mike: Just FYI: You can easily remove the theme-selector by creating a DataExtension for SiteConfig and add something like this to it:

public function updateCMSFields(FieldList $fields)
{
    $fields->removeByName('Theme');
}

- Roman

--

[Mark Muller]

Sam,

Adding it to a module that by default is installed via the zip download makes sense, I would hazard a guess those of us that use SS for each and every project, make no use of the theme dropdown, will more than likely be making extensive use of composer to do our installs and hopefully in my case sspak when I get my head around it for migrations.

The only caveat I see would be for a subsite/translatable site that might want to give the CMS authors a choice of template for each variation of the site maybe. As long as the module played nicely in those instances then I think its sensible to move it out of the core.

Mark