r1baum
Forum Replies Created
-
Thank you for the update.
I can confirm, there are no warnings anymore with the current version.Best,
MaxForum: Plugins
In reply to: [WooCommerce PayPal Payments] Incorrect language in FirefoxThank you for your fast reply.
If i understand you correctly, it is a known but obscure problem that nobody can reproduce. See your screenshot.If it is a firefox edge case with a low probability i would be fine with it.
I will ask PayPal MTS and do some additional tests on our side.
Best
@bplaza Thank you!
That are good news!
Much appreciated!
UPDATE:
After searching for some hints to solve this problem i found out that more users have the same problem.
https://forum.matomo.org/t/uncaught-exception-matomo-core-cronarchive-php-599-got-invalid-response-from-api-request/42849/13A common thing is that the problems started with the upgrade to version 4.4.1
UPDATE:
Fixing the PHP warnings of 3rd party plugins did not resolve the issue.
Something else is causing this errors.Not sure if it is a coincidence but the last successful archive cron was just before we installed the Matomo update to 4.4.2 (from 4.3.1)
Looking into the Version history we skipped the update to 4.4.1
Was there a kind of database update included in 4.4.1 which 4.4.2 is expecting but we never had?Hi,
thank you for your feedback.
Running the archive process manually ends up in a timeout.
I think i missed the LOGS part of Matomo Analytics > Diagnostics the last time but there i see error messages like this:
archive_boot 2021-09-28 08:39:33 Matomo error: 8: Undefined index: REQUEST_METHOD in $abs_path/wp-content/plugins/pretty-link/app/controllers/PrliAppController.php:33 => bootstrap.php:56; bootstrap.php:85; PrliAppController.php:33; pretty-link.php:200; wp-settings.php:391; wp-config.php:39; wp-load.php:37; bootstrap.php:95; console:11;
WordPressI assume the archive process does not run in a webserver context and because of this all lazzy written plugins generate all kind of warnings / errors.
I fixed all of them manually and now i wait for the archiving processed to run again. I post an update if this did the trick.
Forum: Fixing WordPress
In reply to: Fatal Error in requests to “http(s)://DOMAIN/wp-includes/blocks/”Thank you for your feedback.
But coming back to /blocks/, is it save to block direct requests like
RewriteRule ^wp-includes/blocks/ - [F,L]without breaking any WP functionality?
- This reply was modified 4 years, 9 months ago by r1baum.
Hi,
i had the same error in our error_logs today.
What i see is that some kind of bot tried different urls and added ‘/wp-json/wp/v2/users/’ to the links. Which all resulted in the error above mentioned.
Did some testing and adding /wp-json/ to an existing link is enough.
e.g. https://mysite.com/category/wp-json/ -> 500 …Hope this helps.
Best!
Hi @tsteur ,
thank you for your feedback.
I observed it for a couple of days and i cannot see any errors regarding Matomo.
Views / Users / Sales are tracked as before the update.
Error logs are clean.I agree, running the update twice could be the reason.
I still would appreciate a kind of db structure test script (not only Matomo but more like WordPress, Matomo and Co.) to be able to recognize “unwanted” changes.
But i understand the complexity and priority.Best!