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

extension INI collisions, treat .append.php different from default INIs

    Details

      Description

      Take settings/design.ini
      There are settings like BackendCSSFileList[] that can be changed at the 3 settings/override, extension/settings and settings/siteaccess levels.

      However, take ezfind.ini
      There are settings like RawFilterList[] that CANNOT be overriden at the siteaccess level.

      There is ONLY an extension/settings (peer / entire site) and settings/override

      The alternative is to comment OUT the extension/settings like #RawFilterList[]
      and thus allow a siteaccess to re-initialize, but this is NOT ideal becuase then EVERY siteaccess must have it.

      PLEASE, identify ini files within an extension that do NOT have .append.php and consider then the same level as the default settings/*.ini default files.

      This would preserve the 3 levels of override using extensions INI files.

      Steps to reproduce

      Try and override an extension/settings INI value with a siteaccess... you cannot because an extension setting take precidence over a siteaccess one.

        Issue Links

          Activity

          Hide
          Gaetano Giunta added a comment -

          Nice to flag this bug as affecting every eZ version, every component...

          Apart from that, you can search both here and in the share.ez.no site for about a million discussions about what should be the best loading order / filesystem layout for inis.

          I'd vote for having by default siteaccesses having higher priority than extensions.

          Otoh your proposal does not solve ALL problems, is is a bit too specific and it adds yet more complexity to the system

          Show
          Gaetano Giunta added a comment - Nice to flag this bug as affecting every eZ version, every component... Apart from that, you can search both here and in the share.ez.no site for about a million discussions about what should be the best loading order / filesystem layout for inis. I'd vote for having by default siteaccesses having higher priority than extensions. Otoh your proposal does not solve ALL problems, is is a bit too specific and it adds yet more complexity to the system
          Hide
          David Sayre added a comment -

          It is not about the load order, it's about the inability to create an extension/settings/INI that starts a value, and then allow that ini value to be changed at the siteaccess level. If anyone can find an example of this please post the solution. My proposal is in-line with the standard /settings/siteaccess approach but not the new push to have extensions (and client sites) be self contained.

          Show
          David Sayre added a comment - It is not about the load order, it's about the inability to create an extension/settings/INI that starts a value, and then allow that ini value to be changed at the siteaccess level. If anyone can find an example of this please post the solution. My proposal is in-line with the standard /settings/siteaccess approach but not the new push to have extensions (and client sites) be self contained.

            People

            • Assignee:
              unknown
              Reporter:
              David Sayre
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: