smilf

Ran into this as well…after hitting lots of brickwalls with doublechecking the config file, renaming / hiding /deleting plugins, etc it was a PhP version problem.

Go to your Cpanel / PhP version control. Set the PhP version to the oldest (within reason if you have tons of choices) version available, like X.1 if X.4 is the current version. Doing that should re-establish your admin content. Then update your WPress version to make it current, and reset the PhP version to the initial setting (ie X.4).

Now, to apply ice to all that headbanging.

Well the .htaccess hack caused the following:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webadmin@//////./// and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

So I guess we won’t be using that to solve the issue.

We’ve had to set up over 1800 users (local association only wants its members to be able to view board minutes, budget, etc, but wants the flexibility WP provides for most postings and pages). When some admins try to add a user (new member) user.php ends up freezing for some connections (even after waiting 10 minutes for page to load).

We’re using the workarounds via phpMyAdmin and commenting out user.php list of users to try to improve responsiveness. Has anyone developed a plug-in, hack or rewrite of user.php to give admins better and more responsive control over users?

Will try the .htaccess hack. Ideas welcomed.

It’s not just you, but any iframe tag — the damage depends on where it appears in the page build. It is a known defect. The problem here is that WordPress tries to parse coding and tags. As a result, “<iframe src=’yadda yadda’ etc.></iframe> ” is converted to “<iframe src=’yadda yadda’ etc. />” and the rest of the page doesn’t load properly. The fix seems to be to turn off ‘rich text editing’ and insert: “< br /></iframe>”. I saw a suggestions of &nbsp; but the rich text editor saw through that ploy. Thereafter, as long as the iframe sizes are appropriate to layout they seem to play nice with the other elements.

It’s not just google, but any iframe tag — the damage depends on where it appears in the page build. It is a known defect. The problem here is that WordPress tries to parse coding and tags. As a result, “<iframe src=’yadda yadda’ etc.></iframe> ” is converted to “<iframe src=’yadda yadda’ etc. />” and the rest of the page doesn’t load properly. The fix seems to be to turn off ‘rich text editing’ and insert: “< br /></iframe>”. I saw a suggestions of &nbsp; but the rich text editor saw through that ploy. Thereafter, as long as the iframe sizes are appropriate to layout they seem to play nice with the other elements.