[Plugin: BulletProof Security] Error Log Path Seen by Server is blank

Is your Web Host listed here? >>> https://www.ait-pro.com/aitpro-blog/3576/bulletproof-security-pro/custom-php-ini-faq/#web-hosts-list
If so, click on your Host’s link to go to specific custom php.ini setup instructions by Host. Also 10 new Web Hosts have not been added to the list yet. If you do not see your Web Host listed then please send an email to info[at]ait-pro[dot]com. We will be glad to log into your site and fix the issue.

Error Log Path Seen by Server: (BLANK) is usually either:

1. When you created your custom php.ini file the error_log = directive does not contain the path to your php error log file. Check your custom php.ini file to ensure the error_log = directive is not (BLANK).

2. The custom php.ini file was not created successfully or correctly for your particular specific Web Host.

3. Your Web Host does not allow you to create custom php.ini files.

General Help info is also contained in the Htaccess Protected Secure PHP Error Log Read Me help button, but this could be a Host specific issue.

Troubleshooting and Possible Problems
If you have done everything correctly then the Error Log Path Seen by Server: should display the same exact path that you see in the PHP Error Log Location Set To: window. BPS will display an error warning message if a valid path to your BPS PHP error log has not been added to your custom php.ini file by comparing the PHP Error Log Location Set To: path to the Error Log Path Seen by Server: path. If your custom php.ini file is not really being seen by your Web Host Server then you will see that the Error Log Path Seen by Server: path is either blank or you may see error_log or you may see a completely different folder path then the path in the PHP Error Log Location Set To: window. A custom php.ini help link is provided on the P-Security Help and FAQ page – General php.ini Info and Host Specific php.ini Information. This link contains specific custom php.ini set up steps by web host.

Regarding using the PHP Error Log test button. If your custom php.ini file is set up correctly then you would see that php error test logged in your php error log file. Since the custom php.ini file does not appear to be set up correctly the php error test will not be logged and only displayed to you.

Yes, its godaddy with basic hosting setup (shared hosting running on linux).

Honestly, the whole custom php ini portion of new install was sketchy. Its a simple wordpress website, yet the settings to install are like rocket launch sequence. All the install errors went away as I configured the p security, but I have a feeling the custom php ini wasnt setup right (but Im not sure). I tried to follow the link you supplied above plus video instructions as I went through install. To a new wordpress host, Im really not sure between a master php ini, custom php ini, nor where in the install they are located.

I will check what the error log has set tonight after work. If error log is not blank, then how do I procedd with fixing the custom php ini? Do I just redo the install steps for this section again (and it overwrites previous files)?

Thanks Ed.

Yep i have been told that i was nuts to even attempt something as insane as trying to automate something so arcane and cryptic that would work on 100’s of different web hosts. In any case, I will be glad to set up your custom php.ini file for you (I do custom php.ini setups all day long). I just need for you to create a temporary WordPress Admin login for me and send that login info to info[at]ait-pro[dot]com. Thanks

One of the most common custom php.ini issues with creating custom php.ini files for GoDaddy hosting is that the php.ini file is not named php5.ini when it is created with the Php.ini File Creator. GoDaddy is the only host that requires this.

During install I distinctly remember that godaddy required the php file to be named php5.ini. I thought I saved it that. So I browsed the directory, and what do I see…php.ini not php5.ini as I thought. I wasnt sure if bps would like this but I simply renamed it to php5.ini. I think I fixed it. Heres the results:
– php error at top is gone
– “php error log seen by server” is no longer blank and also matches what path was “set” to from default setup
– “test error log” now opens a new window with http 500 error “website cannot display page” instead of displaying the parse error like before. The parse error is now logged into the the text box on the p-security error log tab
– the “loaded configuration file” section of phpinfo viewer is displaying the same php5.ini path to file I renamed (not sure if this was correct before, I think not).
– now I see all php directives as saying (green values), where before a couple had (red values).

So, I will mark this resolved tomorrow, but I need to make sure that renaming the php.ini to correct name of php5.ini is ok. Any sort of restore issues that bps would see from file name being changed?

Yep I use GoDaddy Hosting and have done this same thing myself several times during testing. ?? There are 2 factors that made me decide not to try and detect the Host and automatically add the entire path including the php.ini or php5.ini file name in the path.

1. CloudFlare, PipeDNS, Private NameServers and other similar services hide or modify the Host DNS records so that you cannot tell the true Host anymore.

2. php.ini (php5.ini) creation is a one time setup and will probably never need to be done ever again.

Yes, manually renaming the php.ini file to php5.ini is fine and no it will not cause any problems in BPS Pro 5.1.7.2.

BPS Pro 5.1.8 (soon to be released) has Full Site AutoRestore and another new feature (not announced yet) that would require that you turn off AutoRestore when manually editing/renaming a Root file and then click the new Root files backup button before turning the AutoRestore Cron back on.

You could also have used the Php.ini File Creator and just created a new php5.ini based on your Master php.ini file and saved it to your Root directory. On GoDaddy “php.ini” file names are ONLY recognized/loaded by the Server if you are using a PHP4.x Version and php5.ini files are ONLY recognized/loaded by the Server if you are using the PHP5.x Version. So in other words, since you are using PHP5.x on GD then files named “php.ini” are completely ignored and ONLY the php5.ini file is recognized/loaded by your Server.

Ok, cool. I lucked out it was as easy as it was. I appreciate the help.

Since you brought up the full restore…I was going to create a new post asking what backup plugin bps current works with for backing up site. Backwpup and xcloner are the two that look like most popular. I think on your website, you mentioned xcloner. Is that what you suggest in current bps state? Then, are you saying next version of bps will have full site backup/restore capability so plugin like xcloner wont be necessary?

Either BackWPup or Xcloner are great choices.

Full Site AutoRestore does not take the place of doing regular backups. Full Site AutoRestore is designed to protect all of your website files against being modified and the new feature is designed to protect against a hacker file being uploaded to your website. Your content is all stored in your WordPress Database so regular DB backups would still be a normal backup routine to back up your content. In the future BPS Pro may also do a DB autorestore, but this has to be researched first to determine if this is a viable option for actual development.

Also I just wanted to point out that the whole AutoRestore approach is a countermeasure website security approach. BPS Pro already protects your website from direct attacks and Full Site AutoRestore is designed as a countermeasure security approach if your Host Server gets hacked. Since you cannot apply security directly to a Server then you can only add this form of countermeasure security to protect your individual website in the event that the Server itself is hacked.

Thanks for clearing up my confusion on the difference. Great service.