|
Omnishambles
|
May 15, 2019 at 9:05 am
Our customers are unable to buy tickets using their mobile phones – android and iPhone here https://theportsmouthdistillery.com/portsmouth-distillery-tours/ When they add a ticket and click on the ‘Register now’ button (we’ve renamed it to Book Now) they get the Nothing in Your Event Queue message. I’ve read the other posts from those who’ve had similar problems and thought it must be caching related and so added the key EE pages to the caching plugin exceptions, namely, registration-cancelled, thank you, transactions, registration-checkout and events but the problem continued. I raised a ticket with my hosting provider because I read that it could be a server side caching issue and they replied saying, ‘So this process appears to work in one browser but not the other, I suspect this down to the way the browser handles the script when passing details from one page to the next as opposed to a server-side caching issue.’ This is because they found it worked on a MacBook in Firefox but not in Safari – I found the same thing.
Any advice would be much appreciated.
|
|
Omnishambles
|
May 15, 2019 at 9:23 am
One more development that may be useful when you’re looking at this. Our hosting company has said, ‘I think it may be the https://theportsmouthdistillery.com/portsmouth-distillery-tours/ page that is being cached here and being detected as a mobile page somehow, maybe something to do with the Safari browser.
I’ve added /portsmouth-distillery-tours/ to the exclusions list and the calendar now loads correctly on Safari on my MacBook and allows the booking to advance to the registration stage.
I’m still getting the issue on the iPhone though, I’ve compared the two URLs and this looks to be the same format so I can’t see an obvious issue with the page although I suspect this is something to do with the way the plugin processes the URL/script on a mobile device.’
Thought this may be helpful.
|
|
Josh
|
May 15, 2019 at 10:21 am
Hi,
It’s OK if the page you linked to is cached, that’s just a calendar being displayed there.
The problem with caching is actually happening on the /registration-checkout/ page, where I also see “Nothing in your Event Queue”, even on Firefox.
https://slack-files.com/T02SY781D-FJQFHBJE4-18a2cbe6b0
So this is not a mobile-browser-only issue. What they’ll need to do is exclude the /registration-checkout/ page from caching, and also turn off object caching for the site.
|
|
Omnishambles
|
May 15, 2019 at 10:25 am
Thanks Josh. We did already add registration-checkout to the list of cache exclusions in the Stackcache plugin but is that not sufficient?
|
|
Josh
|
May 15, 2019 at 10:30 am
Correct. They also need to turn off object caching for the site.
|
|
Omnishambles
|
May 16, 2019 at 9:48 am
Hi Josh
Thanks for you advice earlier but unfortunately we still have the problem. I’ve had the following reply from my hosting company when I asked them to switch off object caching as well as per your suggestion. Their reply is set out below. Please advise.
Dear James,
Thanks for that. I’ve been speaking to our platform team and I can confirm that setting the exclusion for this page will stop object caching as well, there is no further server side caching once Stack Cache has been switched off/excluded for that page.
I’m not able to replicate the “Nothing in your Event Queue” message on any browser on my MacBook, only through Safari on my iPhone which does tend to indicate to me that it’s something within the way the scrip is handled specifically for that browser that is causing the issue,
To test the caching I’ve installed the ‘HTTP SPY’ plugin for Chrome and followed the process through and when I get to the /registration-checkout/ page the following is snippet from the headers that are produced showing there is no caching for the page as per the exclusion set:
GEThttps://theportsmouthdistillery.com/registration-checkout/?uts=1558020596#checkout
HTTP/1.1 200
1s 804 ms
185.151.28.158
Origin
https://theportsmouthdistillery.com
Upgrade-Insecure-Requests
1
Content-Type
application/x-www-form-urlencoded
User-Agent
Mozilla /5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36
Accept
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
status
200
date
Thu, 16 May 2019 15:29:58 GMT
content-type
text/html; charset=UTF-8
content-length
13899
server
Apache
x-powered-by
PHP/7.0.33
expires
Thu, 19 Nov 1981 08:52:00 GMT
cache-control
no-store, no-cache, must-revalidate
pragma
no-cache
link
; rel=”https://api.w.org/”, ; rel=shortlink
vary
Accept-Encoding
content-encoding
gzip
x-cache-status
MISS
x-backend-server
wordpress_backend/wp6.hosting.stackcp.net
|
|
Josh
|
May 16, 2019 at 10:03 am
I’m sorry for their reply, it’s not helpful. It’s simply not the case that this is a mobile-only issue, as I’ve shown you it’s also an issue with Firefox too.
The important thing is the WordPress transients need to be set in the _options table. If their server infrastructure is storing the transients in memory instead, that needs to change to the _options table.
|
|
Omnishambles
|
May 16, 2019 at 10:49 am
Thanks Josh. Hopefully they will resolve this now.
|
|
Omnishambles
|
May 17, 2019 at 4:40 am
Hi again Josh
I’ve just had this response (below) from the hosts and wonder if I need to add any more pages to the stack cache exclusion list currently I have excluded?
I have excluded the following:
^/registration-cancelled/
–
^/thank-you/
–
^/transactions/
–
^/registration-checkout/
–
^/events/
–
^/portsmouth-distillery-tours/
–
+
The message from eco is below….
Dear James,
Thanks for your reply. The /registration-checkout/ page is listed in the exclusions table and is not being cached at the moment, the above entry from the HTTP SPY plugin confirms this is the case.
I’ve tested the tour booking through a number of browsers on two separate networks, standard residential connections, and I’m not seeing any error at all when using a laptop and desktop on both WIndows and MacOS. Firefox and Firefox Developer both allow for orders to be placed when used on a desktop/laptop.
The only time I get this issue is when using a browser on my iPhone, this has been tested on Safari, Firefox and Chrome.
Having discussed with our platform team they have confirmed that setting the exclusion will stop object caching. Either this issue is caused by a page that is not set in the exclusions being cached or this points to caching not being the issue in this case.
|
|
Tony
|
May 17, 2019 at 6:41 am
Hi there,
Nothing in your event queue is almost exclusive to caching and if it works when logged in but then not when logged out, it again points to caching. It can also happen if something clears the user’s session on each request (we’ve seen that happen on another server before now).
Your events pages are still shown as cached, for example, this page:
https://theportsmouthdistillery.com/events/portsmouth-distillery-tour-7/
Shows in the headers that it is being cached:
https://monosnap.com/file/TcXmA5UBorCFWBlk6XZy2K8zSZg4dE
Note that I’m using my desktop to browse the site and get the Nothing in your event queue error on Chrome, so it’s not specific to any browser, nor a mobile-only issue.
You’ll need to contact your host and have them fix the caching issue so that the /events/ pages are excluded, the pages that MUST be excluded from cache are the EE critical pages (Listed in Event Espresso -> General Settings -> Critical pages) and the page with the ticket selector on where the user starts their registration. By default, that’s anything under /events/ but if you use the ticket selector shortcode elsewhere, those pages need to be excluded.
|
|
Omnishambles
|
May 17, 2019 at 9:37 am
Hi Tony
Thanks for the advice. I’ve switched stackcache to ‘disabled’ (although there is a note saying that it can’t be permanently disabled because it’s part of the hosting platform) and then I tested as you did for caching and I find that the cache does appear to have stopped and yet I’m still getting the ‘Nothing in your event queue message’. https://monosnap.com/file/pDx3xjE3qgKMvG3k9w3VQ2UQ3KctqX and https://monosnap.com/file/owsxcRkvLNIBlL4vSDmMMxQx041PzX
I have asked my hosting company again about the point that Josh made about transients being possibly stored in the server memory because they didn’t answer that directly although I don’t know if this is something that would be detectable from an Inspector tool.
Your continued patience with this is very much appreciated.
Please advise.
|
|
Josh
|
May 17, 2019 at 10:00 am
The presence of transients within the _options table isn’t something that can be detected from a browser or browser inspector tool. You can check for this if you have access to your site’s database, either through the control panel and/or a tool like phpMyAdmin. What you’ll look for is similar to what’s in this screenshot:
https://slack-files.com/T02SY781D-FJSC0NM1A-c7f13bc86b
if there is object caching on the site, then, unlike in the above screenshot, you won’t see any options prefixed with _transient_.
|
|
Omnishambles
|
May 17, 2019 at 11:03 am
Hi Josh
I do have access to the phpMyAdmin and I’ve had a look and here’s the screenshot of what I can see in the options table in there https://monosnap.com/file/nq2z3lvDhWTLoB8knVENkb7M12n9aD
There don’t appear to be any transients in there. I’m waiting for feedback from the hosts to confirm this. I still feel that you’re right on this about it being something to do with the hosting because we host another site with EE on a different hosting platform and we do not experience this issue. However, I am a bit surprised that having disabled the Stack Cache I’m still having an issue.
|
|
Josh
|
May 17, 2019 at 11:08 am
Our experience so far with sites that have object caching is it’s a different type of caching that works independent of page caching. In other words, you can deactivate page caching on pages, and even deactivate page caching on all pages, but you’ll still have issues if there’s object caching.
Here’s a link to a related topic where the same problem was resolved on a DreamPress hosted site:
https://eventespresso.com/topic/no-tickets-can-be-purchased/#post-290787
|
|
Omnishambles
|
May 17, 2019 at 11:33 am
Very happy for you to login and take a look. I’m guessing checking the ‘set as private rely’ will ensure that any details I add will not be on the publicly visible thread? I thought I should double check.
|
|
Josh
|
May 17, 2019 at 12:37 pm
Hi,
Thanks for the offer, but there’s likely nothing there for me to look at because at this point the object caching issue needs to get sorted out.
|
|
Omnishambles
|
May 20, 2019 at 7:38 am
Hi Josh
OK I’ve had some further information from my hosting company as follows in relation to the transients and object caching.
The listed pages are excluded from the cache with means there is no object caching with the tests we have run showing the page in question is not cached, as has been confirmed from your/your developer’s side in your previous reply.
Having checked with our platform team I can confirm that transients are likewise not cached on the server which have been the two suggestions from the developers so far.
Can you suggest the next step to try and finally resolve this issue?
Thanks
|
|
Josh
|
May 20, 2019 at 3:27 pm
You might consider moving the site to the other hosting platform (the one you’re using for the other site). It seems the hosting support doesn’t understand that there’s a problem with the transients not getting saved to the options table. You didn’t find transients in the options table, so unless they are there and you just did not find them, that means the transients are in memory which is a feature of object caching.
|
|
Omnishambles
|
May 20, 2019 at 4:10 pm
Hi Josh. Yes I already decided on 17th to get a copy set up at Dream Hosts – one you recommend and then this afternoon after the last response from my hosting company, I switched over the DNS and the copy site became the live site. The problem appears to have been miraculously and instantly solved. Hmm. I will be letting my previous hosting company know as it’s been a lot of time and trouble. One last quick question, will moving the site like I have done, have any impact on things like Stripe settings? I noticed that I see a message saying that ‘the payment method Stripe was automatically deactivated because it appears its associated Events Espresso Addon was recently deactivated …’ I checked the plugin page but it appears active and the Stripe settings suggest it’s connected. Any reason to doubt this?
Final question, the new hosts have applied a replacement SSL but on my browsers it’s showing with a warning even though I cleared by browser and flushed my DNS cache. It says that the Certificate Issuing Authority is invalid even though my new hosts say it looks fine to them. I know it’s an issue for them really but thought you may have encountered it in situations like this …?
Thanks for all your help and patience with this.
|
|
Josh
|
May 20, 2019 at 5:23 pm
Hi,
With regards to the Stripe settings it sounds like the site’s “activated plugins” setting didn’t transfer over so the Stripe plugin may have been not activated for a moment. Since you’ve checked the settings and the Stripe settings say “Connected”, then Stripe is ready to go. The settings would not be displayed in Stripe was still deactivated. If you want make sure that Stripe is working you could start a registration then on the payment page select the payment method which will bring up the Stripe modal. If you see the Stripe modal that means Stripe is activated.
With regards to the SSL, I actually did encounter a situation like this with Dreamhost (it wasn’t a site with Event Espresso though). I opened a support ticket with Dreamhost support and they were able to fix it. If I remember correctly, they applied a fix to update the URL strings in the database and applied a fix to the .htaccess file.
If it helps, you could share this screenshot with them:
https://slack-files.com/T02SY781D-FJV4ETZMW-712c6df0cb
|
