Skip to:
Content

BuddyPress.org

Opened 5 months ago

Last modified 5 weeks ago

#9076 new defect (bug)

Cache issue when trying to use get_post() with an existing directory page ID

Reported by: imath's profile imath Owned by:
Milestone: Up Next Priority: normal
Severity: normal Version: 12.0.0
Component: Members Keywords: has-patch has-unit-tests
Cc:

Description

This issue was reported on the BP Attachments' plugin support. But to me there's something weird we need to fix from BuddyPress.

See https://wordpress.org/support/topic/make-object-cache-friendly/

Change History (17)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


5 months ago

#2 @imath
5 months ago

  • Milestone changed from 12.2.0 to 12.3.0

#3 @imath
4 months ago

  • Milestone changed from 12.3.0 to 12.4.0

This ticket was mentioned in PR #246 on buddypress/buddypress by imath.


4 months ago
#4

  • Keywords has-patch has-unit-tests added

Introduce the BP_Component->set_queried_object() to set the BP queried object even for some failed object cache reason a post does not exist although it does!

Trac ticket: https://buddypress.trac.wordpress.org/ticket/9076

#5 @imath
4 months ago

@shawfactor I'm sorry I can't reproduce your issue, so I'm suggesting the above PR to try to avoid your notice error. Could you please test it to see if it solves your issue?

Thanks in advance for your help.

#6 @shawfactor
4 months ago

Yes I agree the issue seems to with buddypress and occurs for me without bp-attachments. Noting it was a fatal error r

I installed the patch 12 hours ago. I have run it on a test version of my multisite with redis object caching. There are no errors in my debug log and almost everything functions perfectly.

The only thing that does not seem to work are permalinks to the buddypress components. The permalinks in the menus now have a url or https://mysite.com/?post_type=buddypress&p=8179 and this is 404 not found when they are visited. Refreshing permalinks does not fix this. I imagibe this is simmply the case that the patch does not cover this scenario?

The actual underlying pages and components are all work fine e.g.https://mysite.com/members/ https://mysite.com/groups/ etc function perfectly.

Last edited 4 months ago by shawfactor (previous) (diff)

#7 @imath
4 months ago

Thanks for your feedback @shawfactor

Very strange, I doubt it has something to do with the patch, but just in case, what happens with these menu items if you remove the patch?

If menu links are still using plain URLs once you removed the patch, if you remove the menu items to add them back do menu links are still using the same plain links schema ?

Last edited 4 months ago by imath (previous) (diff)

#8 @shawfactor
4 months ago

@imath the menu issue is not caused by the patch, I have checked and it exists without the patch (the menus go back to using the pretty permalik).

It is just that the patch does not fix the issue.

#9 @shawfactor
4 months ago

I think I know what the issue is. The issue is actually with get_permalink as if I run that with the post_id of one of the buddypress pages in wp-admin I get the plain url.
AFAICT your patch runs on parse_query right?

Well that would explain the menu issue as the menu links must be generated before parse_query. It would also explain why if I run get_permalink on the body_class hook I get a pretty permalink.

#10 @imath
4 months ago

@shawfactor That's the issue for your specific set up. If you use a fresh WordPress install with only BuddyPress as the active plugin, here's what you get:

https://i.imgur.com/Cf6uC3X.png

This should always be the case by the way as the post_type_link is filtered by BuddyPress since 12.0, see:
https://github.com/buddypress/buddypress/blob/master/src/bp-core/bp-core-filters.php#L1363|L1385

Anyway this ticket was about a cache issue when BuddyPress was setting the queried object, and you confirmed the PR is fixing the issue. Thanks a lot.

I'll deal with post "guid" links from this ticket #9117

#11 @shawfactor
4 months ago

@imath I have identified the issue and it is an issue with buddypress 12. and its interaction with object caching on multisite when BP_ENABLE_MULTIBLOG is set to true. Basically the directory_pages cache seems to relfect that of the root blog .

This can be reproduced by running a clean install of buddypress 12.* on mutisite with BP_ENABLE_MULTIBLOG set to true and activating redis object caching. The issue exists. Incuding the fatal errors. It can be remedied by excuding the chache group bp_pages from object caching

I think you patch functioned more as a band aid for the underlying issue.

I have looked at the logic though and I cannot determine why the root blog is being picked up though. Any ideas?

Last edited 4 months ago by shawfactor (previous) (diff)

#12 @imath
4 months ago

  • Milestone changed from 12.4.0 to 14.0.0

Thanks, I'll need more time to test this very specific config (BP_ENABLE_MULTIBLOG). Thanks in advance for your understanding.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


3 months ago

#15 @espellcaste
7 weeks ago

In 13859:

Unit tests are run with Memcache or/and Redis in CI (Continuous Integration)

A new Github Action is added with a simple matrix to run our unit tests with object cache services, currently Memcache and Redis.

Props imath
See #9076
Fixes #9129
Closes https://github.com/buddypress/buddypress/pull/284

imath commented on PR #246:


6 weeks ago
#16

Wontfix, the issue is about the Multiblog config.

#17 @imath
5 weeks ago

  • Milestone changed from 14.0.0 to Up Next

We'll work on it during next development cycle.

Note: See TracTickets for help on using tickets.