BuddyDev

Search

[Resolved] Possible conflict with LiteSpeed Cache plugin and Xprofile Custom Field Types.


  • Participant
    Level: Master
    Posts: 399
    calu on #26145

    Hi Brajesh, Happy Diwali to you!

    I am experiencing a conflict with LiteSpeed Cache plugin and BuddyPress Xprofile Custom Field Types.

    With LiteSpeed activated, users can’t change their profile fields. I don’t know if I should address this isse to your or LiteSpeed,
    but you might wanna check this out, to confirm the conflict, when the light festival is over, thanks

    Regards
    Carsten


  • Participant
    Level: Master
    Posts: 399
    calu on #26146

    My apologies, this topic was posted under the wrong category, should have been plugins


  • Participant
    Level: Master
    Posts: 213
    Mike (DesignServe) on #26147

    Hi Brajesh (Happy Diwali!) and Carsten,

    I also use Litespeed cache and I’ve been thinking that a recent Litespeed update might be the reason that my Member Types checkboxes in the Xprofile Field don’t persist. Brajesh and I have been discussing this and he thought it related to caching. My users have to log out and back in for their saved data to be shown correctly. Try that, change a setting in the profile and then log out and back in, see if the setting has been saved.

    In the toolbar menu, Litespeed option, caching can be turned off for individual pages. I’m thinking of turning it off in the Profiles. I haven’t wanted to do that yet until I have sufficient time to be rigorous about testing. Because my site is a Multisite I have to take a lot of care over setting the Litespeed cookies correctly per sub-site, so testing is not quick. I only have very basic Litespeed caching in place at the moment, nothing fancy.

    However, I think Brajesh is correct and I think we will have to do some experiments with Litespeed settings. There are a lot of settings as you’ll know!

    I’ll monitor this thread and join in if I have any useful results to share.

    Best wishes,
    Mike


  • Participant
    Level: Master
    Posts: 399
    calu on #26148

    Hi Mike, thanks for sharing this information, always nice to know when an issue is general, and not only in your set up.
    No doubt the issue with LiteSpeed is cache related, so the solution must be to get the settings right, eventually by contacting LiteSpeed. The issue is very persistent, even after clearing the cache it persists. I will experiment with some settings, and follow this thread, and hopefully a solution comes up.

    Best
    Carsten


  • Keymaster
    (BuddyDev Team)
    Posts: 12763
    Brajesh Singh on #26152

    Hi Mike,
    Happy Diwali 🙂
    Thank you for the help here.

    Hi Carsten,
    The issue is not related to us. AS it is due to new update of the caching plugin, Please contact their support.

    Regards
    Brajesh


  • Participant
    Level: Master
    Posts: 399
    calu on #26158

    Hi Brajesh, thanks, I expected it to be a cache issue, and I will contact LiteSpeed as mentioned.

    Regards
    Carsten


  • Participant
    Level: Master
    Posts: 213
    Mike (DesignServe) on #26165

    Both,

    Adding this for people who are not familiar with Litespeed. If set up correctly, Litespeed caches pages, objects, widgets etc for individually logged-in users directly on the server’s disk (which will undoubtedly be an SSD). It is one of its best features and makes it the fastest cache around in my opinion. Simplistically, you have to specifically buy hosting with Litespeed’s system because it replaces the Apache system.

    For now I’m using the following to exclude some sections from the Litespeed cache.

    In the Litespeed plugin > Settings > [4] Excludes > Do not cache URLs

    
    members/
    members/*
    forum/
    forum/*
    activity/
    activity/*
    

    When you enter these every letter you type is delayed because Litespeed is detecting what you type. Be patient.

    ‘members’ are the two slugs you need in particular because that will exclude the users profiles.

    Litespeed will then cache the logged-in member individually except when they (or visitors) are visiting a subset of those slugs. This is better than not caching your logged-in users everywhere.

    Of course, you have to have the Litespeed cookie set up for your WordPress installation for Litespeed to know who is logged in or not. However, the method above will exclude the slug and its children from caching whether the cookie is set correctly or not. therefore, it is a ‘simple’ method.

    An alternative is to start to focus-in on the logged-in user and refresh parts of their cache on a short interval. However, if you do that there will always be a delay for a user changing a profile setting. I think that even a delay of a minute would be confusing for the user, you would have to set up a cron to run every minute and they would have to wait a minute to see the results.

    I hope that helps for now and I’ll report back if I get further with it.

    Best wishes,
    Mike

    • This reply was modified 2 weeks, 1 day ago by  Mike (DesignServe). Reason: Corrected one of the slugs and added more explanation

  • Participant
    Level: Master
    Posts: 213
    Mike (DesignServe) on #26167

    PS going to a deeper slug won’t work for profile editing.

    Trying members/me/profile/edit/group/1/ for example, the individual user would be cached because “me” will be replaced by the username thus (for user called designserve) – members/designserve/profile/edit/group/1/


  • Participant
    Level: Master
    Posts: 213
    Mike (DesignServe) on #26168

    PPS moreover, you could just use members/* and then your members directory (members/) will continue to be cached.


  • Participant
    Level: Master
    Posts: 213
    Mike (DesignServe) on #26169

    Apologies, I need to add this for completeness.

    After doing the above you will need to do the following:

    – purge all in Litespeed (from the Litespeed top menu in the backend)
    – purge Cloudflare from the same menu, if you use Cloudflare
    – purge all again.

    This is due to some buddypress issues with user avatars that are probably being flagged as warnings in your debug logs. It’s some programming in buddypress that is beyond my expertise.

You must be logged in to reply to this topic.

This topic is: resolved
Subscribe