Nabha Cosley

Right you are, it works in Twenty-Ten even with the admin bar. Thanks, I’ll troubleshoot the theme.

Jeffrey, thanks for your response, and thanks for putting your energy into this plugin. I wasn’t using a caching plugin, but something goofy along those lines must have been happening. In any case, it works now. I hope to come back and try it again in the future.

Thanks for your sympathy. ??

And, an epilogue: the problem is gone, though I don’t know what fixed it.

The unexpected behavior of — turning into a em-dash (something that this plugin did) is still there, but unicode characters I put in myself are no longer being corrupted.

All’s well that ends well. I guess I can move on.

Thanks!

What I find interesting is that in the back-end — the Edit Page screen — everything looks like it should. So I don’t think any content changes have actually been made. (Phew! ?? )

“Intelligent” means that is replaces characters intelligently — taking into account things like context, etc.

Oh, I see — thanks, mebrand. So it is removing the tags, but wpautop puts them back in.

Yes, I came across the suggestion of using TinyMCE.init, as well, but didn’t see it in the plugin, and didn’t have time at the moment to figure out how to set it up. But I imagine that is the right way to fix it, as you say.

I’m having the same problem. It acts like wpautop is missing from the javascript rich text thing.

What’s interesting (to me) is that the
tags aren’t ACTUALLY being removed, at least from what I can tell. You can still use something like

wpautop( $term->description );

… to have it display correctly in your theme.

I completely agree that this is a great plugin. I’m sure this is just a small bug.

Oh, and of course $post->post_type==’page’ on line 530 has to change to $post_type==’page’, using the above code.

I also forgot to add my thanks to you for developing the plugin, and spending so much time with it. Among other things, it’s a real help in speeding development time for more complex things.

For other people who encounter this in the future:

When switching themes cured the problem, I found the cause: a missing wp_footer(); call just before </body></html> in one of my theme files.

Thanks, I was looking for exactly this solution. Would love to be able to do it without a hack!

Some emergency methods:

If you have direct access to your database, you can try this:
Quickly Disable All Plugins

Otherwise, delete (or rename) the plug-in folder, or empty the contents of the plugin file itself. I haven’t tried these things before, but I suspect they would work, as the offending code would be gone.

Good luck!

Hooray! Here’s what fixed this error for me:

We had WordPress 3.0 installed and Multisite enabled.

1. I was using an old wp-config.php setting, define( ‘VHOST’, false );, and that had to be changed to define( ‘SUBDOMAIN_INSTALL’, false );

2. Because it was on a test server, our dev site address had to be used (instead of our LIVE site address) in two places in the wp_options table and also in the (new) wp_blogs table.

That means our test database has to be slightly different from our live database.

For anyone interested:

I ended up fixing this on most of the copies of WordPress. It had to do with URL rewriting in at least one case — with the database actually not being there in another (sad, I know!) — but in a third, I have yet to figure it out.

The database is there and the settings are correct, but all WordPress pages return the error.

I also was able to fix this by activating per-site and not sitewide. (Inweb’s solution didn’t work for me, but it would have been nice!)

I’m using WordPress 3.0 and NexGen 1.5.0. Not many other plugins, and nothing of significant impact.

This is a fine solution, though. NexGen is a pretty incredible plugin, I have to say.

That is an excellent idea, one I’ll remember for other times, but I wasn’t able to fix it that way.

I tried optimizing, repairing, and finally, copying the entire database from the live site. (The live site does work.)

Edit: I used Navicat MySQL, which I highly recommend as a database front end if you can connect to your MySQL server remotely.

Hi Locke,

It’s not possible to point one subdomain (“www” being the subdomain) to two servers, but there may be other solutions:

• Make index.php do a remote include ( require_once(‘https://flavors.me&#8217;); ) of the flavors.me page — but this may not be possible with your host for security reasons
• Have the home page on a different subdomain as the rest of the site. Then you CAN use A records, or CNAME records (aliases) might be better, to point to flavors.me. The homepage of the wordpress subdomain can redirect to flavors.me…

There was another idea in my brain, but I lost it…

Hope that helps.