technabob

This is really annoying – it sure would be nice if there was a way to disable this. Can it be turned off on Yoast Pro?

After upgrading to the latest version of Yoast, I’m getting this error message:

DeleteDuplicateIndexables – Error executing ‘query’ with: INSERT INTO wp_yoast_migrations (version) VALUES (‘20200507054848’) Reason: Duplicate entry ‘20200507054848’ for key ‘idx_wp_yoast_migrations_version’

I had previously run the complete indexing job using WP-CLI (which took over 48 hours on my site with 60,000 posts and lots of attachments), and it had been successful. Do I have to run the whole indexing process again?

…and it’s finished. Even using the command line on a relatively fast 8-core dedicated virtual server, it took 47 hours to complete the index build for one of my websites. I sure hope I never have to do that again.

You need SSH access and have to follow the installation instructions here:
https://wp-cli.org/#installing

Then run the command
wp yoast index

From inside of the directory where your WordPress installation is located

For what it’s worth, I’m 18 hours into my 70,000 post site, and only at 44% on the indexing job. Fortunately, you can just leave the SSH terminal open in the background running, and it’ll eventually complete.

The only way I can get it to work is with the WP-CLI tool, and on a site with 30,000 posts it took about 14 hours. I imagine my site with 70,000 posts and 400,000+ objects is gonna take at least 24 hours on the command line.

Thanks for the tips, Adam. I’ll give these a whirl and see if it helps me get through all of these links eventually. At this point I’m only concerned with the YouTube embeds, and will probably set up a different pass down the road for HTML links.

So I’ve manually updated this file with my own YouTube API key, but there’s a 10,000 credit per day limit in this API now, and my site has over 35,000 videos in it – which is about 100,000 credits required to query for all of those. That said, is there any way to throttle the link checker to gradually check all of these over a longer period of time? I need to spread out the link checking over about 10 days to check them all.

To answer your question about the Automatic Full Cache Management, this is the code in the plugin that appears to be relevant to this…

        add_action('switch_theme', array('\CF\Hooks\AutomaticCache', 'switchWPTheme'));
        add_action('customize_save_after', array('\CF\Hooks\AutomaticCache', 'themeSaveButtonPressed'));

So basically, it looks like it clears the cache if you switch themes or save a theme change via the WordPress GUI. It won’t purge based on changes on the file system.

Haha. I could use one after all of that. Who knew that GMT and UTC could be different.

Easiest way to test if a server has the problem. In the shell run these two commands back to back:

TZ="UTC" date
TZ="GMT" date

If they’re different – bad juju.

SOLVED!

Turns out that WordPress interchangeably uses UTC and GMT in its code, and my server wasn’t returning UTC properly, due to a corruption of the timezone file for UTC under /usr/share/zoneinfo. I simply copied the GMT file to the UTC file, and the problem is solved.

Anyone on MediaTemple with this problem should check /usr/share/zoneinfo, and if the UTC and GMT files aren’t the same, you have the same issue.

When I compare the values in my two different servers, I notice that the site with the problem is recording GMT INCORRECTLY in the database:

For instance on the server with the problem:
post_date: 2016-08-04 00:01:00, post_date_gmt: 2016-08-04 01:01:00

And the server without the problem:
post_date: 2016-08-04 00:01:00, post_date_gmt: 2016-08-04 05:01:00

PHP seems to know the proper difference between GMT and CDT, but whatever is recording the post_date_gmt to the database doesn’t seem to.

I’m currently thinking it’s something in the get_gmt_from_date logic in /wp-includes/formatting.php, but that’s above my paygrade.

Nope. These are brand new posts, created on the new server. It’s a real headscratcher.

Thanks, George. I’m definitely not going to be cutting back on the number of categories I use, but would love to be able to set just a single section in the og tags for Facebook, since they’re the number one consumer of that data for us.

Thanks for the update. I’ll play around with it and see if the embedded video player at Facebook is worth using. There’s some value in NOT using it, because having just an image to represent the video drives more clicks to my sites instead of keeping people at Facebook.

FYI, I’m not going to touch the guids. When I dug in deeper, it appears that only some of the oldest DB entries are relative and the majority are absolute, so something must have changed in our environment that did that several years back. Regardless, wp_get_attachment_url now fetches all paths as absolute regardless of how they are stored in the DB.