• Resolved lightchat

    (@lightchat)


    Hello Matomo team,

    Thank you for the great plugin!

    For the past few weeks, I’ve been noticing a persistent problem where the automatic archiving process triggers Fatal error logs in my debug.log file.

    I’m concerned that this might be affecting the accuracy of the website statistics for previous days. The website typically receives only 200-300 visitors per day, so it shouldn’t be an overloading case.

    1. System Report

      Available by the link.

      2. WordPress Cron Setup

        The default WP Cron is disabled (DISABLE_WP_CRON=true), but it’s called regularly via the server Cron and WP CLI every 10 minutes using the following command: wp cron event run --due-now --path=/home/web/domains/x/public_html >/dev/null 2>&1.

        The cron jobs for my theme and other plugins are functioning perfectly.

        3. PHP Memory Limit

          It’s set to 512MB.

          4. The primary error logs

            Warning archive_errors: 2024-04-26 08:10:03 ('Error unserializing the following response from ?module=API&method=CoreAdminHome.archiveReports&idSite=1&period=month&date=2024-04-01&format=json&trigger=archivephp: \' \'' '1 total errors during this script execution, please investigate and try and fix these errors.' => ScheduledTasks.php:351; class-wp-hook.php:322; class-wp-hook.php:348; plugin.php:565; Cron_Event_Command.php:364; Cron_Event_Command.php:286; CommandFactory.php:100; Subcommand.php:491; Runner.php:431; Runner.php:454; Runner.php:1269; LaunchRunner.php:28; bootstrap.php:83; wp-cli.php:32; boot-phar.php:20; wp:4;)

            Stacktrace from PHP:

            [26-Apr-2024 10:10:04 UTC] PHP Fatal error: Uncaught Exception: 1 total errors during this script execution, please investigate and try and fix these errors. in /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/CronArchive.php:474
            Stack trace: 0 /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/CronArchive.php(469): Piwik\CronArchive->logFatalError() 1 /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/CronArchive.php(227): Piwik\CronArchive->end() 2 /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/Access.php(568): Piwik\CronArchive->Piwik{closure}() 3 /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/CronArchive.php(231): Piwik\Access::doAsSuperUser() 4 /home/web/domains/x/public_html/wp-content/plugins/matomo/classes/WpMatomo/ScheduledTasks.php(338): Piwik\CronArchive->main() 5 /home/web/domains/x/public_html/wp-includes/class-wp-hook.php(322): WpMatomo\ScheduledTasks->archive() 6 /home/web/domains/xg/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() 7 /home/web/domains/x/public_html/wp-includes/plugin.php(565): WP_Hook->do_action() 8 phar:///usr/local/bin/wp/vendor/wp-cli/cron-command/src/Cron_Event_Command.php(364): do_action_ref_array() 9 phar:///usr/local/bin/wp/vendor/wp-cli/cron-command/src/Cron_Event_Command.php(286): Cron_Event_Command::run_event() 10 [internal function]: Cron_Event_Command->run() 11 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(100): call_user_func() 12 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher{closure}() 13 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(491): call_user_func() 14 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(431): WP_CLI\Dispatcher\Subcommand->invoke() 15 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(454): WP_CLI\Runner->run_command() 16 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1269): WP_CLI\Runner->run_command_and_exit() 17 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start() 18 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(83): WP_CLI\Bootstrap\LaunchRunner->process() 19 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap() 20 phar:///usr/local/bin/wp/php/boot-phar.php(20): include('…') 21 /usr/local/bin/wp(4): include('…') 22 {main}

            thrown in /home/web/domains/x/public_html/wp-content/plugins/matomo/app/core/CronArchive.php on line 474

            This error happens again and again, I even clear the logs periodically to make sure it’s still actual.

            5. Manual ‘archive’ reports issue

              Additionally, when attempting to manually run the archive process via Diagnostics -> Troubleshooting, I encounter the following error: “SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data.” Instead of the expected JSON response, the browser displays HTML.

              I tried adding ‘MATOMO_SUPPORT_ASYNC_ARCHIVING=false’ to the wp-config, but it didn’t help.

              6. Potential compatibility issue with WooCommerce

                I suspect a compatibility issue with WooCommerce. Switching to the default theme hasn’t resolved the issue, but deactivating all plugins does temporarily resolve the manual archive problem.

                Upon reactivating plugins one by one, I found that deactivating WooCommerce specifically resolves the issue. However, I couldn’t replicate this problem on a clean WordPress installation with just WooCommerce and Matomo installed.

                It’s possible that the issue is related to my current WooCommerce setup, maybe due to the use of the old WooCommerce Post storage method instead of the newer, or the other settings.

                I appreciate any insights or assistance you can provide in resolving this issue. Thank you for your attention to this matter.

                Regards,
                Maxim

              Viewing 5 replies - 1 through 5 (of 5 total)
              • Plugin Support dizzyatinnocraft

                (@dizzyatinnocraft)

                Hi @lightchat, thanks for the detailed report. Before I begin, if you are seeing statistics appear in the report, then the error you are seeing is likely happening after the statistics are archived successfully, or is something that doesn’t interfere with the statistics. Now, to further investigate the issue you’re facing:

                The Matomo archiving process creates reports for individual time periods by sending HTTP requests to a specific Matomo API method. From the system report you provided it looks like these requests are returning an incorrect response (HTML instead of a proper API response).

                To get more insight, can you try visiting this URL in a browser: https://yoursite.com/wp-content/plugins/matomo/app/index.php?module=API&method=CoreAdminHome.archiveReports&idSite=1&period=month&date=2024-04-01&format=json&trigger=archivephp (replace yoursite.com with the URL to your wordpress).

                You should see a JSON response with the text “WordPress_TokenAuthMissing” (this is expected). If you see a large HTML response, it might contain more details on the specific error.

                Also, if you haven’t already done so, you can add the following to your wp-config.php to possibly capture more details in wp-debug.log:

                define('MATOMO_DEBUG', true); // should be defined alongside WP_DEBUG and WP_DEBUG_LOG
                Thread Starter lightchat

                (@lightchat)

                Hi @dizzyatinnocraft,

                Thank you for the prompt response!

                Yeah, the report shows items from the past few days. It’s reassuring to know that it doesn’t affect them.

                I visited the URL, and it displayed the expected ‘WordPress_TokenAuthMissing’ error in the correct JSON content type.

                I checked the logs now, and saw the new record type in the logs:

                [26-Apr-2024 10:10:04 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 499712 bytes) in /home/web/domains/x/public_html/wp-content/plugins/matomo/app/vendor/matomo/doctrine-cache-fork/lib/Doctrine/Common/Cache/PhpFileCache.php on line 86

                I just realized that the WP CLI is probably using a different PHP configuration than the default nginx setup.

                By default, the PHP CLI doesn’t have a memory limit, but WP CLI ( wp --info) indicates that it’s using another php.ini file located at /usr/local/php81/lib/php.ini, which sets a 128MB memory limit. I’ve just adjusted it and cleared the logs.

                I’ll check later to see if this change has helped, and I’ll keep you posted.

                Thank you

                Plugin Support dizzyatinnocraft

                (@dizzyatinnocraft)

                @lightchat The memory setting could definitely be the cause (in fact I think you probably found the issue). Let us know if it works or if there’s anything else you need help with.

                Thread Starter lightchat

                (@lightchat)

                @dizzyatinnocraft It has been working without issues since the memory increased, so I mark it as resolved. Sorry for bothering you.


                Thank you so much for the support and keep up the great work!

                Plugin Support dizzyatinnocraft

                (@dizzyatinnocraft)

                No need to apologize, we appreciate all feedback, and greatly appreciate your detail and responsiveness. After all, we can’t make improvements if users don’t tell us about the problems they face.

              Viewing 5 replies - 1 through 5 (of 5 total)
              • The topic ‘Issue with Automatic Archiving’ is closed to new replies.