Elements with templates housed within a theme throw error on CMS search

[thats4shaw]

I've got a number of namespaced element templates housed inside a theme folder - all works as expected on frontend however throws an error within a CMS search.

[User Warning] None of the following templates could be found: Array ( [0] => Company\Project\Elements\ElementPathway_Elements [1] => Company\Project\Elements\ElementPathway [2] => Company\Project\Elements\ElementPathway_Elements [3] => Company\Project\Elements\ElementPathway ) in themes "Array ( [0] => silverstripe/admin:cms-forms [1] => $default ) "

My element templates all live at themes/base/templates/Company/Project/Elements.

This my theme setup:

---
Name: mytheme
---
SilverStripe\View\SSViewer:
  themes:
    - '$public'
    - 'base'
    - '$default'

Module versions:

dnadesign/silverstripe-elemental 2.x-dev 75b4fff
silverstripe/admin 1.1.0
silverstripe/cms 4.1.0
silverstripe/framework 4.1.0  

In short looks like templates aren't making it to the $default theme. I understand generally most element templates will be housed in their own module but I would of thought we would need to allow for this more custom use case.

[blueo]

We've also got this problem (same module/framework versions), and our blocks are pretty custom so not worth making a module out of each one. Could just have it search in theme folders too? Or should we be providing a 'search result' representation of the block?

[phptek]

Same issue here with 4.1.0 and module v.2.x-dev (75b4fff5)

[NightJar]

Throughout history the CMS has traditionally explicitly unset themes. I've not looked into the process in SilverStripe 4, however I'm assuming at this point that it's still the same (unsets all themes except $default I guess, now that it's a list). This prevents e.g. custom form field templates from interfering with CMS functionality.

The issue here is that because elements are so free in defining what they contain, there is no way to search through them all uniformly. With page types there is always Title and Content as a common denominator, and this is what is searched. Elemental pages don't have Content anymore, so searching becomes a non-event (bad). In order to circumvent this limitation simply dumping the rendered output of all the elements into a 'content' to be searched helps get around this (good)... except when in the CMS there is no theme, so if a template exists only in a theme, it fails (bad again).

A work around while we think about a solution may be to abstract into a module (perhaps even app) and house templates for your elements there. That way they'll hopefully be covered as '$default' as opposed to 'theme' templates. But I'm not positive about this.

[thats4shaw]

I'm running 4.2.x-dev on my latest project so i've adopted the new recommend app structure and it that looks like it gets around it @NightJar.

[NightJar]

Neat, thanks for reporting back :)

I've found the issue. And good news; SS4 does have a theme in the CMS. This is both good and bad news.

Good: You can set templates via setting a theme (fallback) for the CMS. Bad: You can easily wreck your CMS experience. Ugly: To hold a developers hand through this would be ... complicated.

Fix

Short version

Give a little documentation, and what basically amounts to a "Don't screw it up" note. Not overly helpful, as it relies on developers trying to read up on how to fix issues they encounter (as everyone in this thread has). OR Write some kind of clear path to go down to avoid this issue, involving decorators and manipulating the admin theme list programmatically. This would be delivered on 'best guess' and would still essentially carry all the caveats of the first solution - the only difference is keeping a (moderately) clearer separation of concerns between Elemental and the CMS (theme).

Long version

This list holds the (totallity) of the admin themes.

    /**
     * Assign themes to use for cms
     *
     * @config
     * @var array
     */
    private static $admin_themes = [
        'silverstripe/admin:cms-forms',
        SSViewer::DEFAULT_THEME,
    ];

And these lines show how it is set (note UNINHERITED).

        // Assign default cms theme and replace user-specified themes
        SSViewer::set_themes(LeftAndMain::config()->uninherited('admin_themes'));

With this in mind We can add some documentation (preferably in at least two places; the greater docs along with an summarised yet large and loud statement in the readme) informing developers of this issue (site tree search in the CMS) and that this config value must be set in their project in order to work around it, along with listing the caveats of doing such (altering the defaults here via yaml will result in a merge, i.e. ['admin-forms', '$default', 'sweet-custom-elements', 'etc-elements'] - which to my understanding is wrong ('$default' should be last).

OR Add a decorator that lives in silverstripe-elemental and implements an onAfterInit that modifes this value (note it is global state - SSViewer::set_themes), reading extra themes to include in the CMS from a config setting residing in elemental. The only real advantage here is that it doesn't promote the wanton application of themes to the CMS by obscuring that fact behind an elemental specific configuration value - which also encourages the fact that it's an exception specific to elemental.

BOTH of these solutions would require clear docs around separating themes out to be listed, and that all custom element templates should be confined to their own theme, as so that any other page, or form field, or requirement of some sort is not pulled into the CMS and inadvertently destroys some functionality or suchlike (particularly in some insidious ways such as the nature of complex CSS which may not be completely obvious).

The downside of both is that they are essentially the same thing: Managing separate logic for defining a custom element and having it work normally everywhere, except in the CMS search which would require separate registration to be kept in sync with manual maintenance.

In the mean time

• There is a work-around in hosting templates within the project itself (as I'm aware many vendors already do, instead of managing separate themes & application logic).
• One can still explicitly set the config value SilverStripe\Admin\LeftAndMain.admin_themes given that they should have read this post and be aware of the caveats in order to do so.

[robbieaverill]

I think the solutions above are a little over complicated, we can simply nest the config manifest and apply the frontend themes around the area where we generate the element content.

[robbieaverill]

PR at https://github.com/dnadesign/silverstripe-elemental/pull/262

[NightJar]

Ideal, something I hadn't considered. That's why it's worthwhile asking the question!