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

eZ REST API v1: all eZ log files except error.log are disabled unless DebugOutput=enabled

    XMLWordPrintable

    Details

      Description

      For any code accessed using the rest-api v1 controller (index_rest.php), all calls to eZDebug::writeWarning(), or Info, or Debug, will not produce any message in the log files, unless the DebugOutput setting is set to enabled, regardless of the value of the AlwaysLog setting.

      This practically means that the warning.log and brothers will only ever be available on developer's installations.

      This is unlike what happens for code executed when the main entry point is the default legacy controller index.php (or the eZ5 one): in that case the log files, as configured by AlwaysLog, are independent of DebugOutput (which controls just debug printed as part of the web pages).

      The result is that, in order to have the log files be written by exposed rest-api calls, one has to enable DebugOutput .

      Assuming that rest-api calls are accessed via the admin siteaccess, enabling DebugOutput has the side effect of showing debug info in the admin interface, which might not be desirable.
      And for contenstaging in particular, using the admin siteaccess is recommended, as it has access to all languages as well as to hidden content.

      A workaround might be to created a dedicated siteaccess to be used only for rest-api calls, but that is a lot of work, as the developer now needs to maintain a whole new set of config files, change proxy configs etc...

      It would be better to make the DebugOutput and AlwaysLog work separately even for index_rest.php.

      It seems that the problem lies in index_rest.php, around line 50: if ezpRestDebug::isDebugEnabled returns false, then ezpRestDebug::updateDebugSettings() never gets called, and in turn eZDebug::updateSettings() also does not get called.
      I think that just by removing the IF around the ezpRestDebug::updateDebugSettings call the symptoms will be fixed, and without having bad side effects (e.g. unless one explicitly enables Debug in rest.ini, the debug info will still not be part of the rest calls payload) - but that of course should be thoroughly tested, not to introduce regressions for EZP-18998 or EZP-19206

      Steps to reproduce:

      1. Created a new test content, an article with object_id 119;
      2. Edited /ezpublish_legacy/index_rest.php and added the following:

      eZDebug::writeDebug("Testing issue #013200.");
      eZDebug::writeError("Testing issue #013200.");
      eZDebug::writeNotice("Testing issue #013200.");
      eZDebug::writeWarning("Testing issue #013200.");
      

      3. Edited /ezpublish_legacy/settings/override/site.ini.append.php:

      [DebugSettings]
      DebugOutput=disabled
      AlwaysLog[]=debug
      AlwaysLog[]=notice
      AlwaysLog[]=strict
      AlwaysLog[]=warning
      

      ... and cleared cache;

      4. Called "http://53ezdemo.com/api/ezp/v1/content/object/119";
      5. This generated a new entry on error.log only. Should also have created entries on debug.log, notice.log and warning.log;
      6. Edited /ezpublish_legacy/settings/override/site.ini.append.php, set DebugOutput=enabled, and cleared cache;
      7. Calling "http://53ezdemo.com/api/ezp/v1/content/object/119" resulted in a new entry in error.log only, no new entries were created for the other log files;

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              gg Gaetano Giunta
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: