Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-28506

Defining a frontend template overrides the backend content view

    Details

      Description

      Here is the configuration of the frontend template, I used to do in v1:

      ezpublish:
          system:
              default:
                  pagelayout: "@ezdesign/pagelayout.html.twig"
       
                  content_view:
                      full:
                          article:
                              template: "@ezdesign/full/article.html.twig"
                              match:
                                  Identifier\ContentType: [article]
      

      The problem is when I view an Article in the backend (admin siteaccess), the frontend template is used.
      default should not be used for admin interface.

      Note, I tried to use site_group (frontend siteaccess group) instead of default but it's not working.
      The only way to have the admin template and the frontend template is to use a siteacces (site instead of default). This is not great because you will have to define the same overrides for all the siteaccesses.

      I think admin siteaccess should also use ez-design-engine. It will be good for developers if they want to override a template in the admin interface.

        Activity

        Hide
        Bertrand Dunogier added a comment -

        We can't really qualify that as a bug. Default sets the behaviour for the entire app, and isn't really meant to be used "by default" (haha).

        But it is a regression of v2 from an integrator's perspective: until now, it was okay to use default as the scope of your settings. With the v2 release, this will break the backoffice without the integrator doing anything. Fortunately, it is a v2, meaning that we are allowed BC breaks. But since it touches to day-to-day integration, I think we must be pro-active on it.

        Our options, sorted:
        1. Document it: the site group, or siteaccess, should be used for frontend sites. Default is meant for extensions, as it sets the default behaviour of a feature for the entire system.
        2. Warn people, starting from v1: log a deprecation warning clearly explaining what must be changed
        3. On v2, think of ways to silently handle that. We could for instance detect view configurations on default, and change the scope to the site group. We could also warn more brutally during compilation. The main challenge here is to distinguish legitimate usage of default from misusages.
        4. Do a spike using the design engine & the @ezdesign operator for everything. The admin-ui would use an "admin" siteaccess. Default templates (fields, views, repository forms, etc) would be part of the "standard' design. Discussions with integrators have shown that this was a very, very popular aspect of the legacy's template system.

        Show
        Bertrand Dunogier added a comment - We can't really qualify that as a bug. Default sets the behaviour for the entire app, and isn't really meant to be used "by default" (haha). But it is a regression of v2 from an integrator's perspective: until now, it was okay to use default as the scope of your settings. With the v2 release, this will break the backoffice without the integrator doing anything. Fortunately, it is a v2, meaning that we are allowed BC breaks. But since it touches to day-to-day integration, I think we must be pro-active on it . Our options, sorted: 1. Document it: the site group, or siteaccess, should be used for frontend sites. Default is meant for extensions, as it sets the default behaviour of a feature for the entire system. 2. Warn people, starting from v1 : log a deprecation warning clearly explaining what must be changed 3. On v2, think of ways to silently handle that. We could for instance detect view configurations on default, and change the scope to the site group. We could also warn more brutally during compilation. The main challenge here is to distinguish legitimate usage of default from misusages. 4. Do a spike using the design engine & the @ezdesign  operator for everything. The admin-ui would use an "admin" siteaccess. Default templates (fields, views, repository forms, etc) would be part of the "standard' design. Discussions with integrators have shown that this was a very, very popular aspect of the legacy's template system.
        Hide
        Sylvain Guittard added a comment -

        Thanks Bertrand Dunogier for all the explanations.
        1. I totally agree with siteaccess_group and siteaccess. Problem is that siteaccess_group does not work. Maybe it's my local instance. It might be good to test it again
        2. warn people -> update the documentation
        4. I don't think we have time to do it before 2.0 release...
        What do you think Sławomir Uchto?

        Show
        Sylvain Guittard added a comment - Thanks Bertrand Dunogier for all the explanations. 1. I totally agree with siteaccess_group and siteaccess. Problem is that siteaccess_group does not work. Maybe it's my local instance. It might be good to test it again 2. warn people -> update the documentation 4. I don't think we have time to do it before 2.0 release... What do you think Sławomir Uchto ?
        Hide
        Sławomir Uchto added a comment - - edited

        Sylvain Guittard, Bertrand Dunogier: According to documentation: https://doc.ezplatform.com/en/1.12/guide/siteaccess/#scope it is a bug.

        Currently default has priority over everything else, and it's because of LocationView implementation (funny thing: deprecated since 2015.09): https://github.com/ezsystems/ezpublish-kernel/blob/cfe8d73146b6ab8dc3cc844ff4374ac18c31fbf1/eZ/Bundle/EzPublishCoreBundle/DependencyInjection/Configuration/Parser/LocationView.php#L21

        To fix it, and make default to work like fallback (instead of CSS-like !important), we should move ConfigResolver::SCOPE_DEFAULT to the bottom of this array merge (I will prepare a PR in ezpublish-kernel).

        Show
        Sławomir Uchto added a comment - - edited Sylvain Guittard , Bertrand Dunogier : According to documentation: https://doc.ezplatform.com/en/1.12/guide/siteaccess/#scope it is a bug. Currently default has priority over everything else, and it's because of LocationView implementation (funny thing: deprecated since 2015.09): https://github.com/ezsystems/ezpublish-kernel/blob/cfe8d73146b6ab8dc3cc844ff4374ac18c31fbf1/eZ/Bundle/EzPublishCoreBundle/DependencyInjection/Configuration/Parser/LocationView.php#L21 To fix it, and make default to work like fallback (instead of CSS-like !important ), we should move ConfigResolver::SCOPE_DEFAULT to the bottom of this array merge (I will prepare a PR in ezpublish-kernel ).
        Show
        Sławomir Uchto added a comment - PR: https://github.com/ezsystems/ezpublish-kernel/pull/2187
        Hide
        Sławomir Uchto added a comment -

        Merged.

        Show
        Sławomir Uchto added a comment - Merged.
        Hide
        Bertrand Dunogier added a comment -

        Wow, I did not see that one coming.

        The rest of the comments are still true. About not being able to inform people before the release, I mean, it is quite a severe issue. There are many regular cases where the settings will break the admin.

        The minimum is to at least clearly document it as part of the release notes & doc.

        Show
        Bertrand Dunogier added a comment - Wow, I did not see that one coming. The rest of the comments are still true. About not being able to inform people before the release, I mean, it is quite a severe issue. There are many regular cases where the settings will break the admin. The minimum is to at least clearly document it as part of the release notes & doc.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sylvain Guittard
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: