KirkM

WordPress 3.9 includes TinyMCE 4.0.* which is quite different internally than versions of TinyMCE in past editions of WordPress. This includes the TinyMCE APIs as well. Unless the plugin authors have rewritten the 9 plugins you use to be compatible with WordPress 3.9 and TinyMCE 4.0.* they probably won’t work. The best thing you can do at this point is to contact the authors of these plugins to see if they’re aware of this. If the plugin is still under development and hasn’t been abandoned, the author should already be working on an updated version.

It’s very important that users do this, especially users that don’t regularly “police” their plugins and themes to see if they actually are still under development (I don’t mean you specifically) as well as alerting plugin and theme authors who may not be aware of the changes in WordPress 3.9. They should but sometimes there’s the exception.

I agree, and it would be especially convenient to able to have the “Open link in a new window/tab” checkbox in the “Image Details” modal however, you can still click a linked image that’s been inserted into a post/page (which outlines it with the resize grabbers and adds the “Edit” and “Delete” icons) and then click the “Link” button in the editor tool bar and check the “Open link in a new window/tab” checkbox in that dialog box instead. It’s an extra couple of clicks but it works.

Well, never mind then. WordPress 3.8 was released and I was able to update to stable from nightly via my admin’s update, no problem.

Ah, that fixed it. Thanks for the quick fix, Stephen. Marking this resolved.

Yup, same problem here although it didn’t lock me out of the site. It just fails to activate. You might want to add the WordPress version you’re running to your initial post though. I just upgraded WP to 3.7.1 this morning along with BruteProtect to version 1.0b.

Oops, not the same problem. Created a new support ticket/post.

Todd Lahman – At least let me thank you for continuing to maintain the basic Spam Free WordPress plugin (I believe you are?) as it’s basic functions are all I need at the moment, especially the simple comment form protection which certainly beats the extremely annoying “captcha” method. Since my 7 year old WordPress powered site is still just a simple “blog” setup rather than than a full fledged CMS and not meant to be very popular (was never meant to be) I simply don’t need all the functions of “Simple Comments”. If I ever do I’ll be glad to pony up the dough for Simple Comments.

Many thanks, Sam. Always glad to work with a plugin author willing to take feedback and correct problems. And thanks as well for the shout out in the change log.

@david – Thanks for pointing out the Transient Cleaner plugin. I only use a few plugins but that one is a keeper. Beats trying to clean 100s of transients manually.

@aprillhamilton – I may have the same problem as you except the whole block you posted wasn’t removed, just the following…

RewriteEngine On
RewriteBase /

…which is basically the same as removing the whole block. My situation is bit different as I use the WP SuprCache plugin which also turns on Mod_rewrite (if I set it that way). Either way, if you want an easier way to add that particular block back in, just save your Permalink structure again via the WordPress Admin.

Just to say I did…

In your WP Admin, navigate to Settings/Permalinks, make absolutely sure your site’s permalink structure is still selected (it should be, if it isn’t then there’s a more serious problem) and hit the “Save changes” button. If you check the contents of your .htaccess file via FTP (or however) you should see Mod_rewrite block added back in.

Better WP Security should not ever touch the “Mod_rewrite” block at all in my opinion.

Hey Sam,

On that note, I’ve never known WordPress to “auto-clear” transients without user intervention so to speak so very glad to hear you’re going to add a cron job to do so. Many thanks!

Sam,

I edited my entry just as you replied (timing is everything?). Just one more question then? How are these entries cleared out? I’ve been using WordPress for years but not being a programmer I’m hardly aware of how everything works. Just asking.

And thanks for your quick reply.

Upgraded to version 2.0.3 a few days ago. Works fine in 3.5.1. I’ll test it out on my WP 3.6 beta 3 test site and see how it works there.

Many thanks for the update! I really don’t like the Jetpack version at all and Jetpack is too resource intensive overall for my taste.

I’ll mark this topic “Resolved” then.

@kitchin – Just to make sure I got this straight as I’m code impaired. ??

Line 605 and 606 originally:

$target_post = get_post($post_id);
		if (($post_id > 0) && !is_object($target_post))

So I want to change the two “$post_id” to “$_post_id”, yes? So it should read like this:

$target_post = get_post($_post_id);
		if (($_post_id > 0) && !is_object($target_post))

Do I have this right? (yeah, dumb question but I’m getting old–forgetting what I learned when I was a geek)

And it doesn’t function either if you noticed. That’s probably because version 5.0.5 is a paid-for only plugin. Version 3.2.1 was the last free version before it was sold to iThemes in the early summer of 2011. The update for the plugin never should have been shown in the WordPress admin plugins page in the first place.

Sorry this doesn’t help you but at least you know.

Sorry for the delay in replying. Things got busy for the last few days.

The problem turned out to be a conflict with the last two versions (3.9.7 and 3.9.8) of the Text Link Ads plugin for WordPress. After enabling WP Super Cache debugging and checking the resulting log, it showed that there was a “DONOTCACHE is defined” statement after every page viewed on my site as long as the TLA plugin was activated. Although I couldn’t actually find this exact statement in the options table in my site’s DB I’m pretty sure that’s where it was being added. It’s certainly not in the source code of any page/post on my site. Once the TLA plugin was deactivated and removed, WP Super Cache began working properly once more.

I’ve run both plugins side by side for nearly two years now without a problem but apparently when TLA jumped from version 3.5.1 directly to 3.9.7 the problem began. Unfortunately, 3.5.1 no longer works with the latest version of WordPress so I can’t do any compatibility tests. TLA support acknowledged the problem but offers no solution at the moment. They said they’d look into it though.

Since it’s more important to me to keep my site properly cached than having a steady source of packet change for coffee and donuts every month, the TLA plugin got booted. Thanks much for the help Donncha and bh_WP_fan. I’m marking this topic resolved.