I have a test multisite stripped down with no plugins except Post Indexer and Events+. The theme for each subsite involved in this issue is TwentyFifteen.
I set up a few test pages with the [eab_calendar network="yes"] shortcode, and I kept noticing 404 errors that would seem to resolve themselves, but I could not make sense of how or why. Finally, I did a detailed inventory of all the events and pages and I have uncovered the source of the issue.
There are 3 sites involved here: the main site of the multisite, and two subsites.
Each one has a test page, which contains the shortcode.
When the April calendar on any site is viewed (because that's where all the test events are, in April) you can see all the events from the Network (with one exception, a recurring event; more on that at the end of this issue).
However, some of them give a 404 error when clicked.
The events that 404 are different in each case, depending on which site is the "host" for the event and which site owns the page where the calendar shortcode is used. The 404 error is ultimately caused by the events slug of the site where the PAGE was created (as designated in Events >> Settings).
Whatever site the calendar shortcode PAGE lives on, that page's "events slug" is being incorporated into the URLs for the events that are hosted by other sites....except when the event lives on the /events subsite.
Here is the core scenario:
- If the calendar page is on the main site, all the events that are hosted by the subsite /nroc will 404, because the URL is rewritten to the main site's events slug.
- If the calendar page is on the /nroc subsite, all the events that are hosted by the main site will 404, because the URL is rewritten to the /nroc site's events slug.
- If the calendar page is on the /events subsite, all the events that are hosted on either the main site or the subsite /nroc will 404, because the URLs are rewritten to the /events site events slug.
However, here's the exception: events that are hosted on the /events subsite work perfectly every time....but for different reasons, depending on the site where the calendar page lives:
- If the calendar page is on the main site, the link is not rewritten. It is accurate (it contains the /events site event slug) and we get a successful link.
- If the calendar page is on the /nroc subsite, the link is rewritten so that it has the /nroc site's event slug; BUT it also gets a 301 redirect! So ultimately, we do end up on the correct page to see the event.
- If the calendar page is on the /events subsite, the link works fine. It does not have to be rewritten because we are on the same site where the event is hosted.
I have documented this in a Google spreadsheet, which I hope will make this even more clear. The spreadsheet includes all URLs for testing. Comments are open (and welcomed) on the spreadsheet:
There is also one other problem, probably unrelated to all of the above, but I'll mention it because it does show up in the spreadsheet: one test event is not showing up at all in the "network=yes" calendar scenario. It is an open, recurring event. That is the only difference I can see between that event and the others. The others are archived (and they displayed when "open"), and none of them are recurring. So the fact that this is a recurring event would seem to be the cause of it not displaying, but I haven't tested that theory beyond this cursory observation.
I am hopeful that this will help to either resolve a bug, or will shed light on something I have done wrong in my setup, so this can be resolved quickly.
Thank you in advance!