For future reference, please describe "this" in task summaries as we're not after clickbait here. :D

Might be simply fixing the owner of that file via chown?

As this code is entirely taken from an external library, it might be an upstream issue to be handled at https://github.com/smarty-php/smarty/blob/master/libs/sysplugins/smarty_template_compiled.php instead.

@Txantimedia Did you grant the folder permission as described here? Alternatively you could set $wgWidgetsCompileDir = "$IP/images/"; which is a directory accessible by the web server.

The directory is read and writeable by the webserver. Here's the relevant php code:

227         // compile locking
228         if (!$_template->source->handler->recompiled) {
229             if ($saved_timestamp = $_template->compiled->getTimeStamp()) {
230                 touch($_template->compiled->filepath);
231             }
232         }

I also checked that specific file, and it is owned by the webserver account and read/writeable.

I have looked at the waring message more closely and recognize it as a warning I get for years now. My logs are indeed full of this error message, however so far it never caused any wiki to completely fail.

A blanc page suggests a 500 which is afaik not caused by a PHP warning so I guess something else is causing the failure of your wiki.

I am not saying that this is not a painful issue.

My wiki isn't failing. It's working fine. This error was displayed on the home page, however, so it was problematic. I disabled warnings to get rid of it. I'll be happy to provide any information that is helpful to assist in tracking it down. It's merely a warning, not a fatal error.

Ah, sorry, somehow I thought that we are talking about fatalities softwarewise. However your report indeed does not support this theory. I has been a long day for me. So yeah, this is an annoying issue but my impression was the same of André that this may very well be an upstream issue.

I disabled warnings to get rid of it.

That's what you should do in production anyways. Only turn this on when your are actually working on the software but not in normal operations.

I have reproduced exactly the same error message in MW 1.31.1 with complementary Widget extension version in my local test environment today.

[error] [494a215dc4088aafe4920a40] /Mainpage ErrorException from line 230 of /extensions/Widgets/smarty/libs/sysplugins/smarty_template_compiled.php: PHP Warning: touch(): Utime failed: Permission denied

I can confirm that the compiled_templates is www:www 755 read/write/execute. BUT most the compiled.php in it belongs to root with 644. In my case, this is caused by runjob.php running under root permission., which create compiled.php files with root owner.

To solve this error, make sure you run all the mediawiki service (php/nginx/apache etc... threads) and cronjob from same user. delete all compiled php files in /Widgets/compiled_templates. then set /Widgets/compiled_templates to exactly same user with 755 (or more secure 700) permission.

I believe this is not a bug in Widget extension. We should close this task as resolved.

@Zoglun Thanks for the elaborate information. I added a link to your post here to the troubleshooting section of the extension's homepage.

Just noting that it seems like this would be resolved by solving T20914.

Indeed it sounds very much like it. :)