Paddy Landau

@delyandelov — Perfect! That worked on all of my sites, thank you.

Thank you, @pdosev

I’ve implemented my suggestion in my .htaccess files, which should solve that problem.

This is a low-priority request, I would imagine.

@georgiganchev — Thank you, Georgi

I appreciate all the time and effort that you and your team put into the plugin.

@plamenm — Thank you. I do understand that this is a warning, but if the program is receiving an invalid argument, it could mean invalid execution.

I shall disregard this, but it’s the only the thing on any of my entire sites (WordPress, using various themes) that ever create php_errorlog. So, it’s a bit weird.

@georgiganchev — Thanks for your reply, Georgi.

This is really interesting.

Looking at the files in /wp-content/themes/Divi, I see that there was an automatic update 1:37:09 a.m.

The error was reported at 1:37:10 a.m.

So, the security plugin must have run at the same time as, or immediately after, the updates, indirectly leading to this error.

I hope that this answers your question.

By the way, the error is reported in php_errorlog in the account’s root folder.

• This reply was modified 3 years, 2 months ago by Paddy Landau.

@hristo-sg — Hristo, unfortunately it’s happened again!

It’s the test site this time. The site is always fully up-to-date (I have auto-update set on everything). Current version is 1.1.3.

[21-Jan-2022 01:37:10 UTC] PHP Warning:  Invalid argument supplied for foreach() in /home/customer/www/[redacted]/public_html/wp-content/plugins/sg-security/core/Activity_Log/Activity_Log_Themes.php on line 95

As always, let me know how I can help with diagnosis or testing.

Thank you

@hristo-sg — Thank you, Hristo!

@ignatggeorgiev — Thank you! Must I update SiteGround Security, or did you a different fix?

@ignatggeorgiev — It’s this one.

Let me know if I can do something to help.

Hi @stoyangeorgiev

This is to let you know that this still happens occasionally. It doesn’t happen as often as it used to, but it still happens every couple of weeks or so.

If I can do something to help you diagnose the problem, let me know.

@jetxpert, @hristo-sg

Nice resources, AeroStar, thank you.

Hristo, I’m not quite sure what holds you back. What I had in mind was this:

• SG Optimizer creates not only WebP but also AVIF files.
• To allow fallback, it uses the HTML <picture> element in the generated HTML code.

This way, there is support for browsers that support AVIF, support for browsers that support WebP but not AVIF, and support for browsers that support neither.

It would not only help SiteGround’s clients directly, but also it would help SiteGround itself as it would reduce bandwidth — as well as create happier customers! Not to mention that it’s another feather in SiteGround’s hat.

Everyone wins with this.

Syntax for <picture>

Example:

<picture>
  <source srcset="flowers.av1">
  <source srcset="flowers.webp">
  <img src="flowers.jpg" \>
</picture>

@stoyangeorgiev — That’s excellent, thank you!

@stoyangeorgiev — That’s a good question. I don’t know the answer.

All that happens is that I see this error in php_errorlog. The last one happened at 2:00 a.m. when I was asleep, so I have no idea what was going on at that time! Maybe an auto-update?

Because it’s so rare, I can’t tell when it will happen again. I’ll disable all auto-updates, and then check for the error every time when I manually update.

When I spot it again, I’ll post back here.

@stoyangeorgiev — I’ve been testing this, and it does seem to be to do with the 403 error!

So, that was entirely my fault.

Thank you for helping me to find the problem.

@stoyangeorgiev — Sorry, my mistake! I’ve fixed that.

It’s working today. Would the problem have been because of the 403 error?