|
pvosteen
|
November 17, 2018 at 1:35 am
I am updating the theme to one that uses (but does not RELY on) Gutenberg, and now may calendar will not work, just get a spinning disk (load error?).
I have display attendee limits set to “no” and disable categories set to “no”, I also have show_expired=”false” set.
calendar is (not) working on: greenbankobservatory.org/events/
Using …
Event Espresso version: 3.1.37.14.P
WordPress version: WP 4.9.8
PHP Version: 5.6.38
Server Software: Apache
|
|
pvosteen
|
November 19, 2018 at 6:34 am
Going back through previous Support Forum items, I did the following:
deleted the calendar shortcode and saved the page. Re-inserted the [ESPRESSO_CALENDAR] shortcode and saved the page. No change.
I was going to delete the plugin and reinstall it, but when I exported my calendar data, it came down in xls, not csv format (which is what EE3 needs to upload), and likewsie the format does not match the import data format from your “events.csv” file. So I’m kinda stuck, again.
|
|
Tony
|
November 19, 2018 at 6:44 am
Hi there,
There’s a 301 redirect on the ajax request from http to https, did you recently setup https on the site?
The request to pull in the calendar events is being blocked:
Access to XMLHttpRequest at 'https://{yourdomain.com}/wp-admin/admin-ajax.php?action=get_calendar_events&noheader=true&start_date=1540681200&end_date=1543708800&show_expired=false' (redirected from 'http://{yourdomain.com}/wp-admin/admin-ajax.php?action=get_calendar_events&noheader=true&start_date=1540681200&end_date=1543708800&show_expired=false') from origin '{yourdomain.com}' has been blocked by CORS policy: Request header field X-Requested-With is not allowed by Access-Control-Allow-Headers in preflight response.
Is switching themes the only change you’ve made since this started happening?
|
|
pvosteen
|
November 19, 2018 at 6:47 am
We have been running HTTPS for a while on our live server, but not on DEV (as it was internal)
Yes, switching the theme is the only thing I have done. The calendar was working before the theme switch, and it was also working on the development site where I tested the new theme …
|
|
pvosteen
|
November 19, 2018 at 7:10 am
Our network admin is looking into things … where did you find that log of the http -> https error?
|
|
Tony
|
November 19, 2018 at 7:19 am
I was going to delete the plugin and reinstall it, but when I exported my calendar data, it came down in xls, not csv format (which is what EE3 needs to upload), and likewsie the format does not match the import data format from your “events.csv” file.
Deleting the plugin does not remove any of the settings/events/data in your database, WordPress may show a notice that all data will be removed, but its actually just a poorly worded WordPress notice as it’s down to the plugin to remove the data on delete, EE (intentionally) does not.
So you can de-activate, delete and reinstall the plugin should you wish, but it wont actually fix the problem here.
Our network admin is looking into things … where did you find that log of the http -> https error?
Open Chrome dev tools and load the calendar, in the console you’ll see the error I mentioned.
In the network tab you can log the ajax request and the redirect.
|
|
pvosteen
|
November 19, 2018 at 7:28 am
huh. ok.
so do you have a recommendation?
|
|
Tony
|
November 19, 2018 at 8:18 am
huh. ok.
I’m not sure what this is in response to?
so do you have a recommendation?
There’s a couple of steps you’ll need to take to fix this.
First, you’ll need to stop loading jQuery from googleapis, it’s likely your theme is doing is for you, but it’s not a good idea, see:
https://pippinsplugins.com/why-loading-your-own-jquery-is-irresponsible/
It may also be done through a plugin, but as you mentioned this was working before the theme change, I’d say it’s the theme, look in the functions.php file for anything with ‘googleapis’.
The CORS issue I posted above can be fixed by loading the calendar page over HTTPS, right now you have both and if you load the HTTP version, the ajax request loads over HTTPS and is considered cross site so is rejected.
|
