Lost/abadoned support topic

Hi @marcguay,

Sorry to see the above hadn’t worked out, I was sure after seeing your diagnostic it was a case of the FPM/FastCGI code not adding correctly upon optimization because the only thing missing was that auto_prepend_file was reporting no value in your PHP configuration. There didn’t seem to be other permission or connectivity issues after a second check.

Did you end up checking in with your host as I mentioned before? I see they have some documentation around adding directives inside .htaccess, which is not necessarily the usual solution for FPM/FastCGI – hence why I provided the .user.ini information – but is worth a try if they’re making the recommendation themselves. You’d add something like:

<IfModule mod_php.c>
  php_value auto_prepend_file "/var/www/website.com/public_html/wordfence-waf.php"
</IfModule>

It might also help to see if the output of phpinfo() still shows no value after trying that (like the example given on their site) before contacting them. The alternative may be that there’s a global override in php.ini that always sets it back to no value.

Thanks again and let me know how you get on,
Peter.

Thanks again for your help. I think there was a misunderstanding, auto_prepend_file in phpinfo() is correctly displaying the path to the wordfence-waf.php file. Regardless, I tried the htaccess approach and observed no change.

Curious, I see that auto_prepend_file is no valuein the Wordfence diagnostic report but when I add a file to my server which echos phpinfo() it is pointing to the WAF file. Any idea on what could explain this difference?

I tested echoing phpinfo() inside one of the theme’s template files and it also has the correct value for auto_prepend_file.

• This reply was modified 1 year, 3 months ago by MarcGuay.

Hi @marcguay,

This is certainly interesting as the host appears to be fine with .htaccess changes judging by their documentation, the phpinfo() seems to reflect the change, but the result of no_value as far as Wordfence is concerned suggests otherwise. We don’t see this often, so it’s not common for Wordfence to miss a correctly configured site.

When we’ve seen this before, it’s either been down to a second .htaccess somewhere in the site’s folder(s) that’s overriding the value or the host requires the change to be made from a panel or with root access. Certainly check both possibilities.

If you still can’t find the issue, would it be possible to send us a saved copy of the phpinfo() output along with another diagnostic from during the time that page is outputting a valid auto_prepend_file? Don’t forget to include your forum username with each email to wftest @ wordfence . com as usual.

Thanks,
Peter.

I searched and found no other .htaccess files that are trying to modify this variable. The user.ini modification is working for frontend pages (as I echoed phpinfo in a theme file and it recoginizes the auto_prepend_file value). However, I inspected the call that Wordfence makes to generate the diagnostic phpinfo output and saw that it is an admin-ajax call. So I echoed phpinfo inside the wp-admin/admin-ajax.php file and the value is not set. Can you think of a reason the user.ini instructions would be respected in theme files but not in admin-ajax?

Hi @marcguay, thanks for the extra information.

That was extremely helpful as it prompted me to search around for admin-ajax not detecting auto_prepend_file correctly and I found one other case deep in the archives that seems to match up with what you’re seeing.

In your diagnostic, $_SERVER['SCRIPT_FILENAME'] starts with // rather than /. This is an example on Stack Overflow, showing the incorrect way with an extra slash and correct way of setting SetHandler in Apache’s config for PHP-FPM: https://stackoverflow.com/questions/27226055/does-the-user-ini-file-work-for-subdirectories

It’s possible that the auto_prepend_file status works in a script that runs in the document root. The issue above causes .user.ini to only to work in the exact directory where it is located, and not in subdirectories like /wp-admin/. Naturally if you didn’t configure this or can’t correct it, you may have to mention it to your host.

Many thanks,
Peter.

That definitely seems to match the problem, thanks Peter!

No worries @marcguay. I’ll leave this topic open for now in case you need to add further information for our attention in the next few days.

Peter.