Diagnostics: Archive reports outputs as application/json
-
I had an issue related to https://www.ads-software.com/support/topic/archive-process-cant-work/ ; reports had not been archived for months.
When using the “Archive reports” button, the same errors as reported in the post linked above occurred, so I added the following snippet to
wp-config.phpas advised:if ( ! defined( 'MATOMO_SUPPORT_ASYNC_ARCHIVING' ) ) { define( 'MATOMO_SUPPORT_ASYNC_ARCHIVING', false ); }At this point, instead of errors, the browser is outputting what seems to be raw HTML when using the “Archive reports” button (which reloads the page at https://sub.domain.tld/wp-admin/admin.php?page=matomo-systemreport&tab=troubleshooting).
Looking into the response headers in the browser’s network inspector gave me a clue:Content-Type: application/json; charset=utf-8It seems that https://sub.domain.tld/wp-admin/admin.php?page=matomo-systemreport&tab=troubleshooting is reloaded as JSON after executing the operations behind the “Archive reports” button.
I looked for
application/jsonin the code base, and added the following at the start ofJson::sendHeaderJSON()to get more information:$e = new \Exception; print_r( $e->getTraceAsString() );Sure enough, I could find the output of this code in the raw HTML, confirming
Json::sendHeaderJSON()is called when using the “Archive reports” button.Changing
application/jsontotext/htmlas a confirmation test inJson::sendHeaderJSON()results in the page being displayed correctly. It seems this method should not be called when using the “Archive reports” button, or at least that the output should be built differently.Resulting stack trace:
#0 wp-content/plugins/matomo/app/plugins/API/Renderer/Json.php(80): Piwik\DataTable\Renderer\Json::sendHeaderJSON() #1 wp-content/plugins/matomo/app/core/API/ResponseBuilder.php(242): Piwik\Plugins\API\Renderer\Json->sendHeader() #2 wp-content/plugins/matomo/app/core/API/ResponseBuilder.php(89): Piwik\API\ResponseBuilder->sendHeaderIfEnabled() #3 wp-content/plugins/matomo/app/core/API/Request.php(272): Piwik\API\ResponseBuilder->getResponse() #4 wp-content/plugins/matomo/app/core/Context.php(28): Piwik\API\Request->Piwik\API\{closure}() #5 wp-content/plugins/matomo/app/core/API/Request.php(273): Piwik\Context::executeWithQueryParameters() #6 wp-content/plugins/matomo/plugins/WordPress/WordPress.php(236): Piwik\API\Request->process() #7 wp-content/plugins/matomo/app/core/Access.php(661): Piwik\Plugins\WordPress\WordPress->Piwik\Plugins\WordPress\{closure}() #8 wp-content/plugins/matomo/plugins/WordPress/WordPress.php(238): Piwik\Access::doAsSuperUser() #9 [internal function]: Piwik\Plugins\WordPress\WordPress->onSendHttpRequestBy() #10 wp-content/plugins/matomo/app/core/EventDispatcher.php(141): call_user_func_array() #11 wp-content/plugins/matomo/app/core/Piwik.php(845): Piwik\EventDispatcher->postEvent() #12 wp-content/plugins/matomo/app/core/Http.php(318): Piwik\Piwik::postEvent() #13 wp-content/plugins/matomo/app/core/CliMulti.php(412): Piwik\Http::sendHttpRequestBy() #14 wp-content/plugins/matomo/app/core/CliMulti.php(189): Piwik\CliMulti->executeNotAsyncHttp() #15 wp-content/plugins/matomo/app/core/CliMulti.php(172): Piwik\CliMulti->executeUrlCommand() #16 wp-content/plugins/matomo/app/core/CliMulti.php(448): Piwik\CliMulti->start() #17 wp-content/plugins/matomo/app/core/CliMulti.php(117): Piwik\CliMulti->requestUrls() #18 wp-content/plugins/matomo/app/core/CronArchive.php(468): Piwik\CliMulti->request() #19 wp-content/plugins/matomo/app/core/CronArchive.php(390): Piwik\CronArchive->launchArchivingFor() #20 wp-content/plugins/matomo/app/core/CronArchive.php(263): Piwik\CronArchive->run() #21 wp-content/plugins/matomo/app/core/Access.php(661): Piwik\CronArchive->Piwik\{closure}() #22 wp-content/plugins/matomo/app/core/CronArchive.php(269): Piwik\Access::doAsSuperUser() #23 wp-content/plugins/matomo/classes/WpMatomo/ScheduledTasks.php(332): Piwik\CronArchive->main() #24 wp-content/plugins/matomo/classes/WpMatomo/Admin/SystemReport.php(157): WpMatomo\ScheduledTasks->archive() #25 wp-content/plugins/matomo/classes/WpMatomo/Admin/SystemReport.php(222): WpMatomo\Admin\SystemReport->execute_troubleshoot_if_needed() #26 wp-includes/class-wp-hook.php(307): WpMatomo\Admin\SystemReport->show() #27 wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters() #28 wp-includes/plugin.php(476): WP_Hook->do_action() #29 wp-admin/admin.php(259): do_action() #30 {main}The same raw output issue occurs without
MATOMO_SUPPORT_ASYNC_ARCHIVINGbeing defined whenWP_DEBUGis defined.
If none of them is defined, the faulty behavior reported in https://www.ads-software.com/support/topic/archive-process-cant-work/ occurs.Please advise.
-
More research, and a possible clue for a way to fix the issue.
When
WP_DEBUGis active, clicking the “Archive reports” button setssupportsAsynctofalseinPiwik\Plugins\WordPress\WordPress::supportsAsync().This down the execution stack triggers
Piwik\Plugins\WordPress\WordPress::onSendHttpRequestBy(), and specifically this block:if ((strpos($url, 'module=API&method=API.get') !== false && strpos($url, '&trigger=archivephp') !== false && Url::isValidHost(parse_url($url, PHP_URL_HOST))) || (strpos($url, 'module=API&method=CoreAdminHome.archiveReports') !== false && strpos($url, '&trigger=archivephp') !== false && Url::isValidHost(parse_url($url, PHP_URL_HOST))) ) { // archiving query... we avoid issueing an http request for many reasons... // eg user might be using self signed certificate and request fails // eg http requests may not be allowed // eg because the WP user wouldn't be logged in the auth wouldn't work // etc. \Piwik\Access::doAsSuperUser(function () use ($url, &$response) { WordPress::$is_archiving = true; // refs #118 because there is no actual user when archiving there is also no token etc $urlQuery = parse_url($url, PHP_URL_QUERY); $request = new Request($urlQuery, array('serialize' => 1)); $response = $request->process(); WordPress::$is_archiving = false; }); $status = 200; return; }The notable part is this:
$urlQuery = parse_url($url, PHP_URL_QUERY); $request = new Request($urlQuery, array('serialize' => 1)); $response = $request->process();In my case, the
$urlQueryvalue is:module=API&method=CoreAdminHome.archiveReports&idSite=1&period=month&date=2022-08-01&format=json&trigger=archivephp&Note the presence of
format=json; this is assigned to aPiwik\API\Requestobject, then used in thePiwik\API\Request::process()method, which first uses the$urlQueryvalue to set the output format, and then instantiates aPiwik\API\ResponseBuilderobject. ThePiwik\API\ResponseBuilder::getResponse()method is then called, and it contains:$this->sendHeaderIfEnabled();This is where the JSON output come from.
A way to avoid that (and here, I am unsure of the side effects it may cause, because I am unaware of all the cases in which this block is executed) would be to use
format=originalin$urlQuery, and usewp_json_encode()on the$responsevariable to bypass sending the content type headers.Here is an example of rewrite for the block mentioned above in
Piwik\Plugins\WordPress\WordPress::onSendHttpRequestBy(see my added comments in all caps):if ((strpos($url, 'module=API&method=API.get') !== false && strpos($url, '&trigger=archivephp') !== false && Url::isValidHost(parse_url($url, PHP_URL_HOST))) || (strpos($url, 'module=API&method=CoreAdminHome.archiveReports') !== false && strpos($url, '&trigger=archivephp') !== false && Url::isValidHost(parse_url($url, PHP_URL_HOST))) ) { // archiving query... we avoid issueing an http request for many reasons... // eg user might be using self signed certificate and request fails // eg http requests may not be allowed // eg because the WP user wouldn't be logged in the auth wouldn't work // etc. \Piwik\Access::doAsSuperUser(function () use ($url, &$response) { WordPress::$is_archiving = true; // refs #118 because there is no actual user when archiving there is also no token etc /** FORCING THE FORMAT TO ORIGINAL TO AVOID SENDING HEADERS **/ $urlQuery = str_replace( 'format=json', 'format=original', parse_url($url, PHP_URL_QUERY) ); $request = new Request($urlQuery); /** APPLYING ORIGINALLY INTENDED JSON FORMAT ON THE RESPONSE **/ $response = wp_json_encode( $request->process() ); WordPress::$is_archiving = false; }); $status = 200; return; }I guess that your normal configuration when you try to archive your blog data is without the constants defined and with woocommerce enabled, right?
If you mean in production environment, then that’s right:
WP_DEBUGandMATOMO_SUPPORT_ASYNC_ARCHIVINGare set tofalse.
I briefly had to useMATOMO_SUPPORT_ASYNC_ARCHIVINGin production at some point due to incompatibility with a third party (a plugin – legitimately – doing awp_safe_redirectin aninitaction ; thankfully they did provide a filter for me to work around matomo and awkwardly check the value of$GLOBALS['matomo_is_archive_request'], but it’s something I’ll probably raise as a separate issue).
At this stage, these constants are not defined in production ; it does not make it much less of an issue though because the staging environment we extensively use does use these constants.Do you have an error in this case when running manually the archiving process? I can’t see this case in your explanation.
There is no such issue in production environment at this stage. Only with
WP_DEBUGorMATOMO_SUPPORT_ASYNC_ARCHIVINGin staging, both of which having the same influence onPiwik\Plugins\WordPress\WordPress::supportsAsync().
- The topic ‘Diagnostics: Archive reports outputs as application/json’ is closed to new replies.
