Problem with URLs and redirects in Events+

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:

https://goo.gl/0HnX4b

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!

  • Rupok

    Hi kalico

    Hope you had a wonderful day.

    I tried to regenerate the issue on my test site in the same procedure, but [eab_calendar network="yes"] is not working on my test site. So I'm asking my colleagues to retest this.

    In the mean time, can you please try making Events+ slug same for all sites (main site and subsite) and check the result? Please let us know the result. I'm looking forward to hear from you and resolve this issue as soon as possible.

    Have a nice day. Cheers!
    Rupok

  • kalico

    Rupok I just wanted to be clear that I would still like a reply about the risks of this "solution" before I implement it on a production site.

    I am a little uncertain whether the proposal to use the same slug on all sites was just a test, or if it was meant to actually solve the problem.

    Even though it "solves" the problem at face value, I am concerned about the problem it might create with the risk of duplicate event names and URLs across a multisite.

    For my own purposes, it can work (because the entire multisite serves a single company, and we can easily coordinate the event slugs to be identical across all subsites). However, this clearly would not be a viable solution for a multisite of non-related subsites -- which is a far more common scenario than mine.

    If you and the team believe this to be a bug, then I would prefer to wait for a fix rather than implementing a workaround that might end up causing more headaches down the road. So if you can let me know how this is being addressed by the developers, that would be very helpful.

    Thank you!

  • Kasia Swiderska

    Hello kalico,

    Duplicated slug names will cause you conflicts when you try to use them on single WordPress or on single subsite (for example if you have the same slug for page and category). But when slugs are the same on different subsite (each subsite has one page with the same name) then it should not cause any conflicts.
    But if you will see some strange behavior then please feel free to reopen this thread and we will investigate this more.

    kind regards,
    Kasia

  • kalico

    Hi Kasia Swiderska

    Just for the record, I'm referring to the Events slug -- under Events >> Settings where it says "Set your root slug here". Different than a page slug. But still, your explanation makes perfect sense. Now that I think about it, the default is /events on all subsites! Lots of users might not bother to change it. And if a bunch of non-related subsites all used the Events slug "events" it would need to work :slight_smile: You could never expect them all to use different slugs! :slight_smile:

    I still would like to know if this issue I discovered is being reported as a bug. Because even though it does make sense that it's OK to all use the same events slug, it's also not possible in most situations to *force* users to all use the same events slug.

    What I have discovered seems to prove that the option to use different slugs is broken. That is what I would like to hear back on, so I will keep this ticket open until that question is answered.

    Thanks for clarifying. :slight_smile:

  • kalico

    Learned one more thing. It does NOT work to name all your Events slugs "events" if you have a subsite named "events" :slight_smile:

    In that case, ALL events will 404.

    Earlier, I had changed all my event root slugs to "testevents" but of course that's not practical for production. When I changed the slugs to "events", everything broke again. So I changed the URL for my Events subsite to "testevents" and all the events URLs started working again.

  • Rupok

    Hi kalico

    Hope you had a wonderful day.

    I'm flagging our developer here as he can give you best idea regarding this. He can tell us better if this was designed like this or this is a bug.

    Please keep in mind, our developers work round the clock and they have to deal with lots of critical issues and other things. So it may take a little while for them to check this and provide a feedback.

    Have a nice day. Cheers!
    Rupok

  • Kasia Swiderska

    Hello kalico,

    I did some more testing on my multisite - and I'm able to confirm that different event slugs on each subsite are nor working and returning 404 error when reached from calendar (because for some reason calendar sets all slugs to be events and not taking real url for events). This is bug and I'm sending report to developer.

    Learned one more thing. It does NOT work to name all your Events slugs "events" if you have a subsite named "events"

    This one I could replicate partially - when I have subsite called events and on the main site slug is event then events on the main site are showing 404 error. Other subsites are showing correct event pages, but not the main site.
    So we should be able to "fix" this witch changing slug for the main site events... but we cant because calendar forces to use "events" as slugs :slight_frown:.
    I'm also adding this to the bug report.

    kind regards,
    Kasia

  • Ash

    Hello kalico

    If you have a subsite called events, then you must change the event slug from settings in main site.

    About the wrong url in calendar after changing events slug in main site, please go to lib/class_eab_calendar_helper.php line no 375 and add the following:

    if( is_multisite() ) switch_to_blog( $event_info['blog_id'] );

    Then in line 409 add (just after '':wink::

    if( is_multisite() ) restore_current_blog();

    The changes are added in next version, so no need to worry :slight_smile:

    Hope it helps :slight_smile: Please feel free to ask more question if you have any.

    Cheers
    Ash

  • kalico

    Hi Ash

    First I wanted to mention that I got a little confused on this one, because I'm not clear on where to actually put those new lines of code. Is it being added to the same line? before or after the existing code? My line numbers are a little wonky because of other fixes I've implemented, so I need a little more direction on placement.

    But then after I started fiddling with it, I realized I can't replicate the original situation anymore, because I've already got a viable workaround in place. The only way to test it is to undo my existing arrangement of events on subsites. It's really not a problem for me at this point, so I'm just going to leave it alone and wait for the new version.

    Thanks for providing this fix (and many others!!).

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.