ADeweyan

A quick and easy solution that worked for me was to temporarily disable JavaScript.

I was having the problem where the second password field was not displaying, but the form was being rejected because the passwords didn’t match. I disabled JavaScript in the browser (usually in the security settings), reloaded the page, created the user without a problem, and then re-enabled JavaScript.

This may not work with all the different errors, but it’s the easiest fix I’ve seen when it works.

Just chiming in to report that deactivating W3 Total Cache worked for me. I deactivated it, logged into the Admin, which prompted me to update the database. After that, I was able to reactivate W3 Total Cache without any more problems.

To deactivate W3 Total Cache, I:

1. created a new folder in wp-contents (I named it “removed”, but it could be just about anything).

2. dragged the “w3-total-cache” folder out of the “plugins” folder and into this new “removed” folder

3. W3 Total Cache may have added some additional files directly in your wp-content folder (for my install, these were “advanced-cache.php,” “dp.php,” and “object-cache.php”) — I had to move these into the “removed” folder as well.

4. Then I could access the admin area.

5. When the database was updated, I moved the files/folder I had moved back into place.

6. Finally, I had to go to the Admin Plugins page and reactivate W3 Total Cache

Hey, I resolved the issue and wanted to get back with the solution, in case someone else runs into the problem.

You were absolutely right, the problem was with a conflict between the updates version of jquery, and a line of js code in the Divi theme (in custom.js). Updating the theme took care of the problem. Again, in case someone is looking for this… in this line: a[href*=#]:not([href=#])
the href values need to be in double-quotes, so a[href*=”#”]:not([href=”#”])

Excellent. Thanks. We originally had calendars on several pages, but now it’s just one page. I set that to the “Calendar Page” in the settings, and that seems to have solved the problem.

Just FYI, no, we don’t use the iThemes Security plugin.

Thanks again.

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.

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?

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.

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).

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.

(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.

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!

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.

Thanks MissBizzy — that did it for me.

I would add that the solution did not work while I had domains listed in the API Credentials. I had to select a Browser Credential without any specific domains, and it works.

Hey, just adding another report.

We’re having the same problem. The navigation menu (set through Appearance > Menu) appears fine on every page except the calendar list/grid page. It is displayed properly on the event detail page.

We’re using a custom template based on TwentyEleven. No changes have been made to the navigation menu code (except styles).

I’ve tried all the templates in the Events Settings > Template options.

We do have a handful of other plugins installed, but nothing that works with the menu or header. Also running WP 3.4.2.

You can view the problem here:
https://bsc.aecdev.com/?post_type=tribe_events