jlahm

I am having a similar problem. IT seems that on pages with a few conditional fields (1-3) it works fine. But on those pages with 4 or more conditional fields, it does no include those in the final email. I believe it was working with V2.23 of conditional fields, but not with V2.25 and up.

I have been trying to figure out a very similar problem with my home page. It has a login box that is changed to a “Welcome” message after the user logs in. I have managed to get it to work by changing 2 settings on the Cache tab. First, I set Cache Login Page to Off. Second, under Private Cached URIs I enter a single line of “/$”. This unfortunately means my home page isn’t publicly cached, but it seems like this combination works most consistently.

An update. I did not have the ExpiresByType text/html or ExpiresDefault set. Setting them to 0 had no effect and the problem continued.

However, I think I have resolved the problem. As I had noted before, deleting the PHPSESSID cookie or setting it to not be cached did fix the problem. But as you noted, that likely had side-effects. I was using PHP Sessions which is why the PHPSESSID cookie exited. I installed the WP Session Manager plugin which handles session information outside of the PHP session manager and changed my code to use it instead of PHP sessions. Everything is working nicely now.

Thanks again for your patience and your suggestions! Knock on wood I think things are good – for now… ?? I do greatly appreciate the prompt and helpful support I’ve always received from the A2 support staff.

As a quick follow-up, I now find that the login works and the WP admin bar, home page text and menus are changed once I marked the home page as “private cache”. But, now when I logout I have the opposite problem – I still see the logged-in version (with changed menus and text and the WP admin bar). Looking at the HTTP headers, it says “x-litespeed-cache: hit, private”. Clearing the browser’s cache does then allow me to see the proper non-logged-in version. However, I did find that if I tell LiteSpeed to not cache the cookie PHPSESSID then everything appears to work correctly.

Thanks for your patience!

Ah, the WP admin bar that I have hidden on site pages… ??

I went into the WP Dashboard in Chrome and enabled the WP Admin bar. In a separate Firefox browser, I then logged into the site’s home page as usual. The problem with the menu and content not being changed still occurred, and the WP admin bar was not visible. I went back to the WP Dashboard in Chrome and clicking on the Visit Site link to view the site’s home page. Here the WP admin bar did show up (which is interesting…), so I marked the home page as Private Cache. I then went back to the Firefox version and refreshed the home page and now things look great – the WP admin bar is present, the site’s menu is changed as expected, and the home page content is changed to reflect the logged-in user.

I hope this provides a clue, and a potential work-around for me by marking the page as private cache. Unfortunately, that means the home page isn’t cached for users until they visit the page.

I’m sorry Eric if I’m a little dense, but I can’t find that button or those options anywhere. When I go to the WP Dashboard and edit the home page (or any page), then the only LiteSpeed icon I see is in the top WP menubar and it says “LiteSpeed Cache Purge All”.

Now that was fast! Thank you.

D’oh! I see what I did. For some reason, I was setting the WP_SITEURL and WP_HOME defines in my wp-config.php file. So, a user using “www.sitename.com” was setting the WP_SITEURL define to include the www. Fixing that mistake of mine does allow WordPress to properly remove the www on my site and Plugin Organizer should work just fine.

Thanks for your patience. Error was entirely on my part!

So, if I understand you correctly, when I set the enabled/disabled plugins using the Plugin Organizer portion of the page edit dialog, it will only apply to those URLs entered by people that match my site’s settings? In my case, since I defined the Site URL without the “www.”, if someone comes to the site using “www.sitename.com” then Plugin Organizer will not match on this address and thus not make the changes I specified. Conversely, if I set my Site URL to “www.sitename.com”, users who entered “sitename.com” would not match either?

If this is correct, I assume that the “fix” is to add the appropriate entry in my .htaccess file to (in my case) remove the “www.” from the URL? The alternative is to define filters that match both forms of the URL.

If this is all correct, it might be worth highlighting this in the documentation.

Thanks for your help.

Great! Yes, I’ve seen the blog post and realize I can do it using a widget. So, I was planning to see if I can place a widget into a portion of the front page.

By wanting an example, I should have been more specific. The earlier reply suggested adding some code to the page to accomplish this. I was looking for an example of PHP code to accomplish this and thought it might be something others could benefit from (not just an old retired geek like me). ??

Thanks so much for your help! A2 support has been great – and patient – explaining things.

Yes, this explanation of using the “vary groups” helps a lot. I will look into it.

I believe a large part of my problem was me. ?? Understanding the difference between public versus private caching, ESI and vary groups is one thing, but knowing when and why to use them is another. I wanted to have some portion of the home page to contain a note like “Welcome John Doe”. It appears I can do that using either a private cache or by using ESI. The advantage of the private cache is that it is easy! But, it isn’t pre-populated and the user will benefit from the cache only for those pages that they revisit. The advantage of the ESI approach is that I can take advantage of a pre-populated public cache and simply replace a small portion with my “Welcome John Doe” text. The vary groups solves my problem of having two different menus, but does not allow me to put the custom text on the page. I hope all of that is correct!

I am leaning towards removing the custom text and using vary groups. One issue with the ESI approach is the lack of a good example. A previous A2 reply in this thread pointed me to an API document, but the commands he suggested I use weren’t in there. Having an example of “punching a hole” to display or hide a block of text would be really useful.

Thanks so much for the help! I am really impressed with the LiteSpeed plugin and the upcoming updates that have been mentioned elsewhere.

I think I may have confused things. The suggestions you made in your initial response apply nicely to my problem with embedded text on the page that changes based on the login status. I am also trying to see if this same approach would also work for the website’s main menu (which also varies based on login status). This is where I was wondering whether I had to define two WordPress menus and show one or the other based on public/private.

I hope that makes sense! Thanks so much for your help. I will take a look at the API documentation, although at first glance those items you specified (esi_url() and hook_tpl_esi()) are not mentioned.

Also, where might I find any documentation/examples for those two API calls?

That response was fast!

Will the approach using the API calls also work with my main menu (the admin bar isn’t an issue for me)? If so, I guess I would have two define two main menus – one for public user and one for private?

Nick: I’m so sorry! I can’t believe I went to the wrong plugin for support. What a doofus… ?? Thank you for your patient and courteous reply.

Jim