kelson

Strange. I even tried installing on two other blogs that didn’t have it installed and deactivated every plugin except this and the classic editor, but could never get it to show the manual URL entry or existing URLs. I could get the log box to show up (empty), and the syndicate to list of services with checkboxes, but I couldn’t get any of them to show the URL boxes.

I’m seeing this again after upgrading to 1.6.0 today. I haven’t been seeing it for a while. This is on WordPress 4.9.5.

That’s the way the plugin works: The first time someone hits the page, it’s generated by WordPress and can take time to run, and the plugin caches it. Every time after, until the cache is cleared (which typically happens automatically when you edit or add posts, but can be done manually), it will use the cached copy and run much faster.

So to test the cache load time, you should load the page at least three times: The second and third time should both be much faster than the first.

FYI, on sites using Open Sans (ex with the TwentyTwelve theme), this also causes a delay in rendering the site text, as the browser tries to load the broken URL first before falling back to the URL specified in the theme stylesheet. Applying the fix takes care of the invisible text problem as well.

I don’t care nearly as much about the extra 404 as I do about my text being visible immediately instead of after a several second delay.

Aha! Good catch. The new Wordfence Options page has an option way down at the bottom under “Other Options” — “Disable XML-RPC for DDoS protection.” Unchecking that lets the mobile app back in on my sites.

I’m unable to connect to any of my self-hosted blogs with the Android WordPress client today, after upgrading to WP 3.8.2 yesterday (though to be fair, a lot has been going on the last two days). Trying to refresh posts or comments gives me a “…couldn’t be refreshed at this time” error.

Thanks, it’s https://www.hyperborea.org/journal/

Thanks for taking a look, but I guess I wasn’t clear on the circumstance: If I deactivate Term Management Tools, but leave Threads active, I still get an error when deleting tags.

If I delete tags one at a time with the delete link, I just get the red generic error warning. If I select several tags and bulk delete them, I get an actual PHP error page listing the full error for each tag I’m deleting.

Just to be sure, I’ve deactivated every plugin on my site except for Threads, and I still get an error in wp-content/plugins/threads/lib/cf-tax-post-binding/cf-tax-post-binding.php line 454 when I delete tags. If I turn the rest of them back on, and turn Threads off, the error doesn’t fire.

The same thing happens on another blog on the same system that I didn’t have Threads on before. I installed it, and the errors started appearing on tag deletion – same line, same file.

In fact, I created a new, empty blog and just installed Threads on it, nothing else, created a few tags and deleted them…and got the same error.

Warning: Could not find post for term “2” in taxonomy “post_tag” in /home/kvibber/wptest.hyperborea.org/wp-content/plugins/threads/lib/cf-tax-post-binding/cf-tax-post-binding.php on line 454

FWIW, it’s PHP 5.4.11 through FastCGI on Apache, though the error persists if I switch to PHP 5.3.13. DreamHost, specifically.

I ran into this with my blogs too. It looks like WPSEO is replacing wp_title so that your theme can fill it in normally, but the themes are outputting wp_title followed by the blog name. So WPSEO adds the site name title, and then the theme adds it again.

Force rewrite seems to wipe the theme’s <title> tag entirely and build a new one in wp_head.

There’s an importer that will copy over all your individual post info from AIO to Yoast. I did it a couple of days ago on two much longer (thousands of posts) blogs. I only really used the meta descriptions, so I’m not sure what else it does and doesn’t transfer, but those all came through just fine.

More info: https://yoast.com/all-in-one-seo-pack-migration/

Thanks, I appreciate it.

If it helps to track it down, this is PHP 5.2.17 (not my choice, it’s what the host offers if I want to use XCache) on Apache using FastCGI as the interface.

I’m not sure this is directly related to 3.5. I ran into the same problem (at least the Facebook one) a few weeks ago while still on 3.4. At the time I figured it was a temporary glitch at Mailchimp, because it seemed to fix itself, but now I’m not so sure.

Did you recently add or upgrade Jetpack? There have been a number of problems where it’s conflicted with other plugins.

In particular, I had to disable a couple of features recently added to Jetpack that conflicted with ShareThis. Now that I think about it, it was around the same time I had the problem with Social. It could be that the same features are interfering with both plugins, and the fix for the ShareThis conflict — disabling the Sharing and Publicize features in Jetpack — took care of both of them.

Based on the info in another thread, I tried disabling both the Sharing and Publicize features, and ShareThis appears on my individual posts again.

Thanks for the link – loganscott’s patch on that thread worked for me.

@loganscott: This solution worked for me too, thanks!