BuddyBoss Home – Web Support Forums General Requests and Feedback Please make Buddyboss cache complaint

Viewing 6 posts - 1 through 6 (of 6 total)
  • Question


    It would be really nice if Buddyboss were able to work with plugins that cache html, by using JavaScript and maybe a JSON api.

    Let's say:
    Anon enters my website. A static HTML page is served (maybe by WP Super Cache, with “make known users annonymous” option enabled), and this page loads the JavaScript api that verifies Anon is an annonymous user, so “nothing” happens.

    Alice enters my website. The same static HTML page is served. This time, the JavaScript api is able to detect Alice is a registred and logged in user (maybe because WP Super Cache does not cache urls containing ‘/bb-api' string); So JS api is able to show custom menu, custom avatar and custom stuff to Alice, by manipulating the DOM.

    I think this will be very useful and a resources saver, because it seems to me to be more efficient to just serve the same static cached HTML page to everyone and then take care of api cache optimization.

    What do you think?




    @mautematico do caching plugins have a standard we would be able to adhere to that would make this apply to any caching plugin? Any information pertaining to an standard would be greatly helpful.


    Actually, I'm quite confident the way I tried to describe before is the way WP Super Cache [0] works.

    1. Let's suppose the cache plugin will cache only HTML resources (i.e. only html outputs properly closed ‘</html>'), and then serve the same static HTML file to anyone who access example.org/example-post

    2. Let's suppose we have something like a JSON REST api [1] [2] (or we're able to create it just as needed). I think it can be even something more simple that that.
    If this json api is an external one (like Jetpack's), there should be no caching problems, since it won't be cached. If it's an internal one (example.org/wp-json/), there should be no caching problems, since api sends json data (not a valid HTML, so it won't be cached, as supposed on 1.).

    So Anon (not a logged in user) requests example.org/example-post. Our server sends (or generates and then send) a cached version of the requested post, in plain HTML.
    Once loaded, a JavaScript resource is executed and load_user_specifics() is called.

    So Alice (a registred, loggedin user) requests example.org/example-post, and our server sends a previously cached HTML file (the same served to Anon, if it's not expired). load_user_specifics() is called

    /*The POST part (send comments, post to the forum, update status, etc…) goes here.
    Since this part is already made by POST requests, I think there shouldn't be lots of pain on this part.

    a) makes POSTS request to the REST api, identifying the user via cookies or any other needed method.
    JSON data is obtained. Special case if user is Anon

    b) makes GET request to home-made JSON api.
    In this scenario, user identification is made directly by WordPress, by it's own methods.
    which could be as simple as a custom page template [3]
    JSON data is obtained. Special case if user is Anon

    then, let's manipulate the DOM to display user-specific data, such as display_name, gravatar, etc. Do nothing if user is Anon.

    Long story short:
    I think we can assume the cache plugin will serve the same HTML output to anyone, and we have a way to always serve specific resources (like /homemade-json/*) dynamically.

    What do you think?

    [0] WP Super Cache: https://wordpress.org/plugins/wp-super-cache/
    [1] WP API: https://wordpress.org/plugins/json-rest-api/
    [2] Jetpack json api: http://jetpack.me/support/json-api/
    [3] Example of a simple “json api”, using page templates: http://snipet.co.uk/SL



    @mautematico I understand what you are saying but are other themes doing this or is this something that we should be pressuring on BuddyPress since they are the foundation of the social experience.


    @tjchester, this stuff is over my head but I just paid WP Rocket to custom install their caching plugin when I couldn't get it to work. After two days they identified BuddyBoss Wall as the conflict. I'm disabling BuddyBoss Wall and I can get by without it considering that BuddyPress now has the “Favorite” function. But I'd love to resume use of BuddyBoss Wall if this issue can be resolved. Can I help in any way with information? I'm sure I can get information from the WP Rocket developer if it can help.




    @jgwolfenberger any additional info would help. Thanks!

Viewing 6 posts - 1 through 6 (of 6 total)
  • The question ‘Please make Buddyboss cache complaint’ is closed to new replies.