Background updating with cron

[jaredatch]

Here is the work flow, that at least at the moment, seems like it would work.

When the counts are fetched via the function, the first thing we currently do is check the expiration time. If expired we update the counts, and proceed.

Instead a better solution would be, at least for larger sites, if expired we add the post ID to an option named ea_shared_count_expired and serve the expired counts. This option will be an array of all the expired counts. Then we have a cron job that runs at a specific frequency (filterable, default maybe 5 mins?) and checks if that option is empty. If its not, grab the IDs, update the counts for each one, then remove the ID from the array.

Probably might not be an idea to make this feature filterable (on or off be default I'm not sure).

[billerickson]

Is there any issue running update_option() multiple times on one pageload with the same option?

It might be better to have a global variable, $ea_share_count_expired, and if it's expired we add to the variable. Then on wp_footer we update_option if ! empty( $ea_share_count_expired )

[jaredatch]

I don't think update_option would be running multiple times on pageload, I figure we'd check in_array() before we bother to update anything :)

Edit: I guess you are referring to archive pages haha. That makes more sense now. Hmm, good question. I think one footer update would def be better otherwise I think it would trigger separate writes to database.

[jaredatch]

Probably will end up with something like https://github.com/dannyvankooten/wp-mail-in-background/blob/master/wp-mail-in-background.php

[jaredatch]

Another option worth looking at https://github.com/A5hleyRich/wp-background-processing

[billerickson]

At Pressnomics we decided to stick with our existing approach, except wait until the page has rendered to hit the API and refresh share counts.

While we could do it as cron, here were our main concerns:

1. Even though it won't happen when a user loads a page, searching for expired posts on a large site is still a very expensive meta query and could affect site performance.
2. The current solution only updates a post if the counts have expired AND a user is looking at the post. If we switched to cron, we would be updating the counts if they have expired, regardless of whether anyone looks at that post. On large sites with lots of old content, we could be updating posts that no one is looking at. This could drastically increase the number of API queries, pushing you to a higher paid SharedCount plan. It's also doing additional writes to the database that aren't necessary, negatively affecting performance.

The new plan is to add a global variable $easc_needs_updating (or something) that is an empty array. When rendering share counts, if that count has expired we will add the post ID to the array instead of fetching updated counts (so old counts are still displayed). After the page has loaded, if the array isn't empty we'll loop through it, calling to the API and updating the share counts.

[norcross]

perhaps also add something that'll fetch the counts when an admin is viewing a post on the admin side. or a manual button that says "update counts"

[billerickson]

We actually have a metabox for that now. When editing a post:

[norcross]

ahh. didn't see that on my end. carry on 😀