adrianww

Thank you very much for that – there’s useful additional info in there. I’m less concerned about it now that I know the nature of the bug.

OK, so having had the pleasure (!!) of trying to track down this problem for the last couple of days, I now have a better picture.

The reason that the install or update from the WordPress repository was failing was that the installation/update process on the affected sites was taking so long that it was hitting a PHP spawned process timeout while running. Why the install or update now seems to be so slow I don’t know – I’ve installed Matomo several times on various sites and it has been updating with no problems. It only seems to be since the last update that the installation/update process has become so slow that it runs up against process time limits.

(As an aside, something similar seems to be happening with the most recent update to Woocommerce too. Again, multiple sites on different hosting providers.)

Anyway, I don’t know whether it’s something in the install package itself or something in the way in which the WordPress repository is delivering it to the target sites. But, whichever it is, it means that installations or updates from the repository fail, while installations directly from an uploaded .zip file don’t.

Given that a .zip file which is downloaded manually from ww.wp.xz.cn then uploaded to the sites works fine, but the install/update from the WordPress repository runs so slowly as to cause these issues, is it possible that there is some kind of problem with the way in which the repository is delivering the plugin to the sites?

OK, been doing some more testing here.

The failed installations/updates seemed to be if using the WordPress repository. If I download the .zip file from Matomo and install the plugin that way, everything seems to work.

Having done that, I then uninstalled Matomo and reinstalled from the WP repository and this now worked as well.

Whether there was something funny going on with the connection between my sites and the repository or whether I was getting some kind of corrupted version of what was in the repository I don’t know but, hopefully, things seem to have resolved themselves.

I’ll leave this open for another 24-48 hours in case the issue reappears but if everything seems to be back on the level, I’ll mark it as resolved.

Maybe it’s just been one of those days…

Hi again,

Just thought I’d take a look at the code and see if I could spot where this is happening.

I think the culprit is around line 45 in the add_layout_to_list() function in class_rcno_reviews_get_templates.php in the admin/settings directory. When handling a local layout file, it uses:

$base_url = get_template_directory_uri() . '/rcno_templates/' . $file;

to set the base URL. This will end up generating a URL for an /rcno_templates/file in the parent/root theme directory. This works fine if there isn’t a child theme, but doesn’t work if a child theme is being used.

To test this out, I replaced the above line with:

$base_url = get_theme_file_uri('/rcno_templates/' . $file);

in the plugin installation on the site that we’re working on and it then picks up the file correctly even with a child theme installed and shows our screenshot.png in the Reviews->Settings->Templates panel.

Thanks again,

Adrian