Plugin Author
Me
(@cyberws)
It works on Nginx as we use Nginx at my company and this plugin is in use.
Several things can cause this and since I don’t know your setup:
1) Have you double checked the full path?
2) Things like SELinux can block writing to files. I have seen this before.
3) PHP itself can be configured to not allow writing to files outside the base directory. I have seen this before.
Do you control the environment? IE: VPS, cloud, or dedicated server
Thanks so much for the very prompt response. Really above and beyond…
1) Have you double checked the full path?
I’m not sure — I placed the blank redirectit.php file in the site root folder — is that where it should be?
2) Things like SELinux can block writing to files. I have seen this before.
3) PHP itself can be configured to not allow writing to files outside the base directory. I have seen this before.
I just ran a quick test and could write to files via php in the root directory.
This is our own server, so we do have complete access.
Plugin Author
Me
(@cyberws)
It sounds like the full path to the redirectit.php isn’t setup correctly. This does matter and has to be correct or you get a failure.
If you don’t know the full path:
1) Copy the php code below to a new file and name it say getpath.php
2) Upload it to your server in the directory that has redirectit.php (unless you created the file with something like vi and it is already there).
3) Now visit getpath.php in your browser and get the information.
4) Place that information in the “Settings” then “Absolute Path To Redirect File:” area and click on “Save“.
5) Try writing to the file and hopefully it should work if the permissions are set to 666 or 777.
DELETE THE getpath.php FILE REGARDLESS!
<?php
echo getcwd();
?>
Curiouser and Curiouser…
I’ve confirmed the path is correct, but the redirect file is still not being written.
I tried writing to the file from a test php file, and it worked successfully.
Again, thanks for your help!
Plugin Author
Me
(@cyberws)
Okay, curious.
1) Did you run the test under the same account (website) so the same user was used?
2) Are you using Nginx with PHP-FPM?
3) Did you double check that the file name in the “Settings” area matches the file you created? I know it sounds silly but I have actually inverted letters or numbers and it has taken awhile to realize it.
(again, thanks, I really appreciate it!)
1. Yes, I did the writing through a php script from the browser. I’ve confirmed the file permissions and ownership are the same as other wordpress-writeable files on the server
2. Yes, it looks like we’re running php-fpm (I used php_sapi_name() and it returned “fpm-fcgi”)
3. Not silly at all — I’ve done this many (OK, many, many) times myself. Because I have done it so often, I just copy and pasted the names between the two locations (FTP connection and plugin settings) to be sure they matched.
Plugin Author
Me
(@cyberws)
Then my guess is your PHP environment is setup to not allow fwrite along with possibly fopen using the “disable_functions” setting in your php.ini.
In your test script which function did you use to write to a file?
I am thinking it is time to check the error log file.
Plugin Author
Me
(@cyberws)
I should add how are you running PHP-FPM for the site? As another user from the site (site: site1 but PHP-FPM: nobody) or are both running as same user?
If the latter is the case you can try chmodding redirectit.php to 755 and try updating file.
I’m just using a standard fopen (w+) and fwrite to test writing a file. I’ve made sure the permissions and ownership of the files match.
I’ve checked, double-checked and triple-checked the path and file name (it’s the same path name as revealed by a phpinfo call in the same directory).
I deactivated the writeable-check in the plugin, and then tried rebuilding the file — the error log reports:
[15-Oct-2015 19:15:21 UTC] PHP Warning: fopen(): Filename cannot be empty in [path removed…] /wp-content/plugins/cleverwise-redirect-it/ria.php on line 153
I’m also noticing that changes to the settings are not saved when we click the “Save” button. It sounds like maybe there is a database problem behind all of this.
OK, an update…
I went into the plugin (ria.php) and hard-coded the path and file name to the redirect file, and that enabled the plugin to write to the data file.
However, I noticed that the key redirect options were not stored in the options table in the database (the only one there was the redirect_version option). I tried manually populating the options (using the list apparent in the plugin code), but the plugin is still not working (I probably missed an option, or entered an incorrect value).
SO, it seems the problem has to do with saving the plugin options to the database. There have not been problems with any other plugins on the site (and it’s a plugin-heavy site).
Sorry, I should clarify… With the hardcoded path/filename, and the manually-entered options, the admin side of the plugin seems to work (we can add redirects, and they appear in the redirectit.php data file), but the redirect addresses don’t actually work.
Plugin Author
Me
(@cyberws)
That is really odd as WordPress should create that entry automatically when clicking on “Save”. There should be an entry called just “redirect_it” and once you update the file another called “redirect_it_updates“.
I do agree that based on your findings it seems to be a database issue. So you only see “redirect_it_version“?
I uninstalled, and reinstalled the plugin, and the redirect_id_updates item now appears in the options table.
Unfortunately, it contains a serialized value with just two keys, “redirect_db_update,” and “redirect_file_update” — each value is a timestamp. I’ve tried making and changing settings in the admin panel without luck. The changes are not saved to the database. There aren’t any errors reported by PHP.
It really just seems like there is something wrong with our WP installation — but we’re running a bunch of different plugins, and this is the only one with a problem.
I guess my next step is to change themes, deactivate some plugins and look for a conflict. Do you have any suggestions of what to look for?
Plugin Author
Me
(@cyberws)
You have come up with a really odd error.
The plugin should created three db entries:
“redirect_it” holds the “Settings” information
“redirect_it_version” is version of the redirect it plugin
“redirect_it_updates” is the last time stamp of the redirect it file write out
It is possible there is a conflict with another plugin. I don’t know of any but with nearly 30,000 published plugins plus countless private ones it is possible.
If you really want to use this plugin and do the work then here is how I would approach this:
1) Setup another WP install on this same server (so the environment is the same). Obviously use another domain or just a subdomain. You should keep the stock theme of WP.
2) Now install this plugin and see if it works. If it does obviously it isn’t the plugin (at least directly) or your environment.
3) Now you have a choice. You can try your theme OR plugins but do each one at a time. After installing a new plugin or theme update the settings in redirect it. It doesn’t matter if the settings are bogus you just want to see if it writes to the database. So the path could be “1”, then “2”, then “3”. You again just need to see if changes are really saved.
Now all this is some work but you’ll more than likely find the issue unless your WP install is just corrupted some how. It isn’t a bad idea to have a test WP install anyway. Of course your call here but that is how I would do it. I have several test WP environments on several setups, OSes, and servers; from CentOS to Solaris, Apache to Nginx, PHP 5.3 to PHP 5.6, etc.
I may have figured it out…
I think the primary problem was that the firewall plugin we are using was blocking the proper saving of the settings — I set the firewall to ignore administrators, and that took care of that. At the same time, we were receiving the error that the absolute path to the redirectit.php file was incorrect (even though I confirmed it several times). I changed it to “../” and it saved. So to repeat, I turned off the firewall, and tried a different path to the file, and we are now able to build the redirect file.
Redirection is not yet working, but at least we’ve gotten this far.
