Failed to open stream: no such file or directory

Do you have the latest version installed?
There’s nothing like that on line 1490.

There are multiple check to see if the file exists, so I can only see this happening, if you purged your cache on FVM, but somehow your cache was still referring to those files.

Using a CDN is irrelevant here, because it’s trying to open the file from the local disk.
Do you have writing permissions on /nas/content/live/htdocs/wp-content/uploads/fvm/out/ ? Are FVM files actually being created there, when you check via sftp?

Hi Paul,

We don’t have the latest version but we have v2.3.2, which is almost the latest. Apparently there have been some significant changes since then. This is the code it’s referring to:

# register and enqueue minified file, consider excluding of mediatype “print” and inline css
if ($remove_print_mediatypes != 1 || ($remove_print_mediatypes == 1 && $header[$i][‘media’] != ‘print’)) {
if($force_inline_css != false) {
echo ‘<style type=”text/css” media=”‘.$header[$i][‘media’].'”>’.file_get_contents($file).'</style>’;
} else {

# move CSS to footer with loadCSS ?
if($loadcss != false) {
if($fvm_remove_css != true) {

# save to some sort of global and show it on the footer
$mt = $header[$i][‘media’];
echo ‘<link rel=”preload” href=”‘.$file_url.'” as=”style” media=”‘.$mt.'” onload=”this.onload=null;this.rel=\’stylesheet\'”>’;
echo ‘<noscript><link rel=”stylesheet” type=”text/css” media=”‘.$mt.'” href=”‘.$file_url.'”></noscript>’;
echo ‘<!–[if IE]><link rel=”stylesheet” type=”text/css” media=”‘.$mt.'” href=”‘.$file_url.'”><![endif]–>’;

/*
# alternative way
echo <<<EOF
<script type=”text/javascript”>var ldfvm$i=document.createElement(“link”);ldfvm$i.rel=”stylesheet”,ldfvm$i.type=”text/css”,ldfvm$i.media=”bogus”,ldfvm$i.href=”$file_url”,ldfvm$i.onload=function(){ldfvm$i.media=”$mt”},document.getElementsByTagName(“head”)[0].appendChild(ldfvm$i);</script>
EOF;
*/

}

Yes you are right – I realized afterwards that the CDN wouldn’t have anything to do with it since this is a backend error.

Yes, there are files going into fvm/out. And all around the plugin works – but when we noted the error in New Relic we were concerned because it might be an indication that at times, there are references to older files that have been deleted. And this did happen after clearing the FVM cache – but wondering why it didn’t detect that the file didn’t exist, and thus generate a new one?

And if this was the results of caching, why would there be a PHP error? Wouldn’t the client, in that case, be served a static version of that page, and thus no PHP errors should happen (as is the case with the CDN)?

Thanks,
Nathan

Hi Nathan,

If files are being created on fvm/out, there should be no problem, however what you report can happen for a few reasons.

There have been a few bug fixes on 2.3.3 and 2.3.4 as well as on 2.3.5 which is due to be released today or tomorrow… please try to update, as I don’t remember exactly, if this was something that may have been fixed (I remember adding some extra file checks at least).

Files on FVM are deleted in 2 ways.
a) Older than 45 days files are automatically deleted.
b) When you manually hit the purge button.

When you hit purge, it will physically delete the files on fvm/out in real time, however, depending on how many files you have there, it may take a couple of seconds to do it.

Although very small, there is a possibility that a request for the frontend started a few ms before or after you hit purge, thus it may fail to detect that the file is already gone, because it checked that the file was there but meanwhile, file was deleted “as we speak”. It’s very rare, but it could happen on high traffic sites especially.

The other possibility is if you use APC, Zend or some other OPCode cache on your server. And not only on PHP, but also on the web server side… for example, setting open_file_cache on Nginx, will even cache PHP code in RAM and run it without changes, even if those files are deleted from the disk. Likewise, if you have a NFS mounted disk with cache… I can see this happening. Not saying this is the reason though, but technically, it can happen for many reasons.

My suggestion would be to update first and test it out.

On the code above, the error would have come from file_get_contents on:

echo ‘<style type=”text/css” media=”‘.$header[$i][‘media’].'”>’.file_get_contents($file).'</style>’;

The thing is, just before there was a “if file exists” condition… so it was there a few ms ago, or at least, PHP reported it as file exists. I think I added some extra checks for this, but let me know if the error persists after updating.