kelson
Forum Replies Created
-
Forum: Plugins
In reply to: [ActivityPub] Moving an ActivityPub-enable blog to another domainGot it. Thanks for clarifying it!
I’ll let you know if I run into any glitches now that I know what to expect.
Forum: Plugins
In reply to: [ActivityPub] Moving an ActivityPub-enable blog to another domainI understand ActivityPub followers migration. I’ve had a dozen Fediverse accounts on as many pieces of software over the years and migrated them as I consolidated. That’s not the part I’m concerned about.
My concern is this scenario:
- Old server federates a post publicly.
- New server is set up with the new domain.
- New server has copies of all the same posts, but with new URLs, so none of them have actually been federated yet.
- Will the new server understand that those posts haven’t actually been federated, or will it think they have been?
Forum: Plugins
In reply to: [ActivityPub] Moving an ActivityPub-enable blog to another domainA real move to a new domain.
My understanding is that I need to:
- Set up a new copy of the blog at the new domain
- Get the new blog fully configured (replace paths and URLs, update the permalinks, all the stuff in the WordPress Migration docs.)
- Issue the ActivityPub move from the old location of the blog
- Do whatever cleanup I want on the old copy. Eventually I plan to just 301 the whole thing to the new site. I see there’s a wp-cli command to self-destruct the activitypub, which would probably be a good idea to run on the old site after the Move is done.
My main question is how step 2 interacts with the ActivityPub setup on the new site. Is there anything special I need to do to make sure it doesn’t still think it’s blog@oldsite somewhere in there? Will it think it a post has been federated already because it was previously federated by the old site? Stuff like that.
Thanks!
Forum: Plugins
In reply to: [ActivityPub] Images no longer attached to Fediverse view of postI suppose that makes sense. It’s just annoying that something that used to work OK was ripped out in favor of something that doesn’t work at all on my setup.
Between this and the 6.0 release requiring WP 6.5, would it be accurate for me to assume the plugin just isn’t going to work right on WP forks going forward?
Forum: Plugins
In reply to: [WP Super Cache] No longer compatible with ClassicPress?I was going to test this today, but I see it’s back to requiring 6.6 with no explanation.
Edit: I see there was an issue with older PHP versions. Was there actually a problem with the older WordPress versions too?
Would it be helpful for me to manually install 2.0 on my ClassicPress site to confirm that it works there with a more recent PHP? If it does, would it be feasible to bump the PHP version instead of the WP version, or would the WP plugin update system still try to install the newer release on sites with older PHP setups?
- This reply was modified 1 year, 4 months ago by 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.
Forum: Plugins
In reply to: [WP Super Cache] “Rewrite rules must be updated” message on WordPress 4.9I’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.
Forum: Plugins
In reply to: [WP Super Cache] Need helpThat’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.
Forum: Fixing WordPress
In reply to: XML-RPC services disabledAha! 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.
Forum: Fixing WordPress
In reply to: XML-RPC services disabledI’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.
Forum: Plugins
In reply to: [6Scan Security] 6Scan claiming unserialize vulnerability on WP 3.6.1Thanks, it’s http://www.hyperborea.org/journal/
Forum: Plugins
In reply to: [Threads] Threads breaks tag management in WordPress 3.6Thanks 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.