Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Medium Medium
    • Resolution: Unresolved
    • Affects Version/s: 2012.1, 2012.2, 4.7.0-dev
    • Fix Version/s: None
    • Component/s: Legacy > Extensions
    • Labels:
      None

      Description

      See issue 19107 and pull request: https://github.com/ezsystems/ezwt/issues/9

      It seems extension load ordering changed after 2011.12 - with the results most apparent in some ini parameters defined in one extension and changed in another one getting different values.
      For one project I am doing, I had to resort to disable automatic loading and set it to manual

        Issue Links

          Activity

          Hide
          Jean-François Müller added a comment -

          I can confirm that for ActiveAccessExtensions[]. It's even not directly the extension ordering, it's more the ordering from parsing/overriding ini files. That changed from "bottom - up" to "top - down", which is inconsistent with other parsing, e.g. design templates. Those are still overridden from "bottom - up".

          For multisite configurations, where all extensions are activeted on siteaccess level it's now unusable. We had to revert to 2011.12... 2012.1 seems to be broken...

          Show
          Jean-François Müller added a comment - I can confirm that for ActiveAccessExtensions[]. It's even not directly the extension ordering, it's more the ordering from parsing/overriding ini files. That changed from "bottom - up" to "top - down", which is inconsistent with other parsing, e.g. design templates. Those are still overridden from "bottom - up". For multisite configurations, where all extensions are activeted on siteaccess level it's now unusable. We had to revert to 2011.12... 2012.1 seems to be broken...
          Hide
          Gaetano Giunta (Inactive) added a comment -

          I confirm that it is not related to extension load ordering, which is correct, but to settings loading.
          Still open in 5.1-rc1...

          Show
          Gaetano Giunta (Inactive) added a comment - I confirm that it is not related to extension load ordering, which is correct, but to settings loading. Still open in 5.1-rc1...
          Hide
          Gaetano Giunta (Inactive) added a comment -

          Seems like a one-liner could fix it:

          foreach ( array_reverse( $activeExtensions ) as $activeExtension ), on line 209 of ezextension.php

          The strange thing is that that line has been there since 2010...

          Show
          Gaetano Giunta (Inactive) added a comment - Seems like a one-liner could fix it: foreach ( array_reverse( $activeExtensions ) as $activeExtension ), on line 209 of ezextension.php The strange thing is that that line has been there since 2010...
          Hide
          André Rømcke added a comment -
          Show
          André Rømcke added a comment - Wasn't this fixed in https://github.com/ezsystems/ezpublish-legacy/commit/bfebd92 ?
          Hide
          Gaetano Giunta (Inactive) added a comment -

          Apparently not.

          Looking at the code, it makes sense that "prepending" extensions dirs to the ini search path in the order they are loaded will end up with later extensions having their settings actually loaded first.

          I am not sure which usecase was fixed by https://github.com/ezsystems/ezpublish-legacy/commit/bfebd92, possibly some with scope mixed along with ext. priorities?. Maybe we should make sure we have test cases covering all possibilities (array value, array add, array reset and scope vs. ext. load order)...

          Show
          Gaetano Giunta (Inactive) added a comment - Apparently not. Looking at the code, it makes sense that "prepending" extensions dirs to the ini search path in the order they are loaded will end up with later extensions having their settings actually loaded first. I am not sure which usecase was fixed by https://github.com/ezsystems/ezpublish-legacy/commit/bfebd92 , possibly some with scope mixed along with ext. priorities?. Maybe we should make sure we have test cases covering all possibilities (array value, array add, array reset and scope vs. ext. load order)...
          Hide
          Gaetano Giunta (Inactive) added a comment - - edited

          Note that instead of using array_reverse() in ezextension, we might just call ezini::appendOverrideDir(), but there's a catch:
          if ezini::appendOverrideDir() is called and the extension's inis are already loaded, they are not pushed at the end of the array, while they are pushed at first position when they are already loaded and prependOverrideDir() is called.
          Also it seems appendOverrideDir() is never used, at least in a standard eZ install...

          Show
          Gaetano Giunta (Inactive) added a comment - - edited Note that instead of using array_reverse() in ezextension, we might just call ezini::appendOverrideDir(), but there's a catch: if ezini::appendOverrideDir() is called and the extension's inis are already loaded, they are not pushed at the end of the array, while they are pushed at first position when they are already loaded and prependOverrideDir() is called. Also it seems appendOverrideDir() is never used, at least in a standard eZ install...
          Hide
          Gaetano Giunta (Inactive) added a comment -

          ps: if we use "extends" tag to make an extension load BEFORE another, we can work around the issue.
          But then in backoffice the origin of settings is displayed wrong (maybe another bug?)

          Show
          Gaetano Giunta (Inactive) added a comment - ps: if we use "extends" tag to make an extension load BEFORE another, we can work around the issue. But then in backoffice the origin of settings is displayed wrong (maybe another bug?)
          Hide
          Gaetano Giunta (Inactive) added a comment - - edited

          Seems like I found as well the source of the problem for backoffice sometimes getting wrong the source location of a setting - for array settings: at line 777 of ezini

                      if ( preg_match("#^([\w_*@-]+)\\[\\]$#", $line, $valueArray ) )
                      {
                          $varName = trim( $valueArray[1] );
           
                          if ( $placement )
                          {
                              if ( isset( $this->BlockValuesPlacement[$currentBlock][$varName] ) &&
                                   !is_array( $this->BlockValuesPlacement[$currentBlock][$varName] ) )
                              {
                                  //eZDebug::writeError( "Wrong operation on the ini setting array '$varName'", __METHOD__ );
                                  //continue;
                              }
           
                              //$this->BlockValuesPlacement[$currentBlock][$varName][] = $file;
                              $this->BlockValuesPlacement[$currentBlock][$varName] = array( $file );
                          }
                          else
                          {
          

          Show
          Gaetano Giunta (Inactive) added a comment - - edited Seems like I found as well the source of the problem for backoffice sometimes getting wrong the source location of a setting - for array settings: at line 777 of ezini if ( preg_match("#^([\w_*@-]+)\\[\\]$#", $line, $valueArray ) ) { $varName = trim( $valueArray[1] );   if ( $placement ) { if ( isset( $this->BlockValuesPlacement[$currentBlock][$varName] ) && !is_array( $this->BlockValuesPlacement[$currentBlock][$varName] ) ) { //eZDebug::writeError( "Wrong operation on the ini setting array '$varName'", __METHOD__ ); //continue; }   //$this->BlockValuesPlacement[$currentBlock][$varName][] = $file; $this->BlockValuesPlacement[$currentBlock][$varName] = array( $file ); } else {

            People

            • Assignee:
              unknown
              Reporter:
              Gaetano Giunta
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: