Forum Replies Created

Viewing 15 replies - 1 through 15 (of 49 total)
  • Thread Starter arypneta

    (@arypneta)

    Great, thanks! I’ll keep an eye out there for a resolution.

    Thread Starter arypneta

    (@arypneta)

    I don’t have a GitHub account currently, so it would be great if you could open the ticket for me. Thanks so much!

    Thread Starter arypneta

    (@arypneta)

    Great, thank you so much! That immediate fix appears to work.

    Thread Starter arypneta

    (@arypneta)

    Okay, perfect – thanks for the update!

    Thread Starter arypneta

    (@arypneta)

    Thanks for following up!

    1. We use our host’s caching (WP Engine). Looks like we have page cache, network cache (including what they call edge full page cache) and an object cache turned on through them. They have a button to clear all the caches on the website dashboard, which is what I’ve done before. I’ve never logged in directly to try clearing one at a time to see what happens. Next time I notice this issue, I can do that to see if one particular cache is the culprit. I just tried to test it by creating a new user, but they showed up immediately this time. I haven’t actually noticed (or been contacted by an editor) with issues since my last post, so maybe something else was interfering that’s now been resolved.

    2. About 510 users. It’s a multisite network and not all users are on all subsites. I think we’ve mostly been noticing the issue on the main site (which has about 475 users).

    3. Yes, we’ve mainly noticed it in the author box in the post editor. I think I may have also tried the author box from quick edit on the posts list screen at least once, but I can’t remember. We do use the block editor (since that linked Github issue mentions the classic editor).

    4. As far as I can tell, only clearing the cache seemed to work. But perhaps it’s because we didn’t wait long enough. At one point I added a new user, and they still hadn’t show up in the list at least 24 hours later (and then I cleared the cache and they showed up).

    Thread Starter arypneta

    (@arypneta)

    So, this is now happening with authors who have been on our site for years. They stop showing up in the co-authors box and I have to clear the cache to get them to show up. Any update on whether this is expected behavior or if you plan to fix it?

    Thread Starter arypneta

    (@arypneta)

    Okay, perfect – thanks so much!

    Thread Starter arypneta

    (@arypneta)

    After further research, it appears that another plugin we have is adjusting the HTTP callout to api.wordpress.org to get the themes and not returning the active_installs field. I will follow up with the other plugin.

    But in your code, it would be safest to handle it gracefully when the field doesn’t exist. If you use the empty function, that won’t give a warning if the field doesn’t exist: empty($theme->active_installs)

    Thread Starter arypneta

    (@arypneta)

    Great, thank you so much!

    Thread Starter arypneta

    (@arypneta)

    Okay, thanks, that makes sense!

    Thread Starter arypneta

    (@arypneta)

    Thanks for the suggestions, Matthias! I think the click listener will probably do what we want, so that’s helpful to know the right class name to target.

    Thread Starter arypneta

    (@arypneta)

    That looks great, thank you so much!

    Thread Starter arypneta

    (@arypneta)

    I can’t easily send a screenshot, but as far as I can tell there already are indexes on those fields:

    Keyname: PRIMARY on column: term_taxonomy_id
    Keyname: term_id_taxonomy on columns: term_id and taxonomy
    Keyname: taxonomy on column taxonomy

    But the Trac ticket is a good idea. I might search there too if there’s already one open.

    That would be great if you have an idea to get around it for this plugin though. Thanks so much for your help!

    Thread Starter arypneta

    (@arypneta)

    We have about 180 users, but we use Co-Authors Plus which adds an additional author taxonomy (about 200 separate entries).

    However, we have like 12,700 tags, so I could see that being part of the issue even though it’s not querying those directly. From the EXPLAIN ANALYZE query, it does seem like the issue is something with the taxonomy (if I’m reading it correctly, which it’s entirely possible I’m not). This particular author only has 95 posts and wp_term_taxonomy is indexed on the taxonomy field (and it’s filtering by taxonomy=”author”), so I wouldn’t think that the tags would necessarily affect this query, but maybe they are. It looks like it’s finding a ton of rows and I’m really not sure why….

    -> Limit: 5 row(s) (no early end due to SQL_CALC_FOUND_ROWS)  (actual time=554..554 rows=5 loops=1)
    -> Sort: wp_posts.post_date DESC (actual time=554..554 rows=95 loops=1)
    -> Filter: (
    max(if((wp_term_taxonomy.taxonomy = 'author'),if((wp_term_taxonomy.term_id = 1443),2,1),0)) <> 1) (actual time=123..554 rows=95 loops=1)
    -> Stream results (cost=98692 rows=23086) (actual time=123..554 rows=95 loops=1)
    -> Group aggregate: max(if((wp_term_taxonomy.taxonomy = 'author'),if((wp_term_taxonomy.term_id = 1443),2,1),0)) (cost=98692 rows=23086) (actual time=123..553 rows=95 loops=1)
    -> Filter: ((wp_posts.post_author = 38) or ((wp_term_taxonomy.term_id = 1443) and (wp_term_taxonomy.taxonomy = 'author'))) (cost=83190 rows=155022) (actual time=123..553 rows=1051 loops=1)
    -> Nested loop left join (cost=83190 rows=155022) (actual time=0.0749..531 rows=184775 loops=1)
    -> Nested loop left join (cost=28932 rows=155022) (actual time=0.0639..128 rows=184775 loops=1)
    -> Filter: ((wp_posts.post_type = 'post') and ((wp_posts.post_status = 'publish') or (wp_posts.post_status = 'acf-disabled'))) (cost=10400 rows=11563) (actual time=0.0513..29.6 rows=14549 loops=1)
    -> Index scan on wp_posts using PRIMARY (cost=10400 rows=23124) (actual time=0.0496..21.7 rows=29511 loops=1)
    -> Covering index lookup on tr1 using PRIMARY (object_id=wp_posts.ID) (cost=0.262 rows=13.4) (actual time=0.0035..0.00596 rows=12.7 loops=14549)
    -> Single-row index lookup on wp_term_taxonomy using PRIMARY (term_taxonomy_id=tr1.term_taxonomy_id) (cost=0.25 rows=1) (actual time=0.00194..0.00196 rows=1 loops=184775)

    The really weird thing is that we have sites with many more tags (including one with 1,000 more tags that is also using SSP) that don’t give us this error message. So, perhaps there’s some other plugin conflict.

    But anyway, the number of problems have been much reduced by the update, so this is probably fine for the time being.

Viewing 15 replies - 1 through 15 (of 49 total)