We did a larger version upgrade recently and seems events are now can only be filtered by a maximum no. of groups for a widget embedded on one of our webpages. Is there documentation about this? Is there any workaround for this?
Thanks Gladys, and sorry to hear this is giving you trouble – it’s possible at a certain point the request that the widget makes to the calendar server might overspill some length limitations? We’ll stay tuned for an example we can check out, or you might try reproducing the extra-long case as a Saved Widget and seeing if that does the trick?
Hi Karl,
Thanks for looking into this. Here are some examples for the issue:
Hi Gladys,
Aha, yes, that would do it:
From the LiveWhale 2.20.0 release notes
Performance improvements: Blocked /live/ requests with a massive REST depth (more than fifty instances of /) which we’ve seen correspond to malicious and spam requests.
(As a note, we are adding more verbose error messages to blocked requests like this in our next release, so that would’ve helped illuminate this sooner.)
When we added the 50-slash limit to REST requests, we thought it was a good outer limit for day-to-day use (i.e., up to 25 REST search filters). But, the examples you shared go a bit beyond that, for example querying 1 widget id, 2 groups, 23 categories, and the 1 max= value. That’s where we start to overspill and trigger that REST blocker.
I’ll chat with the team to see if we can relax that restriction a bit – in the meantime, though, I wonder if some of these widgets could be optimized somehow?
For example, the request you sent that searches for all of these category/ values:
SFU Vancouver Campus
SFU Surrey Campus
SFU Burnaby Campus
Online
Off Campus
Undergraduate Students
Staff
Public
Prospective Students
Graduate Students
Faculty
Alumni
All Students
Thesis Defences
Services for Students
Seminars & Workshops
Lectures
Info Sessions
Dates & Deadlines
Conferences
Community Events
Campus Life
Arts & Culture
Am I wrong, or is that just all of your audience, campus, and event types?
I wonder if the UI where you’re having editors place widgets could be clarified to communicate that the default behavior is to Show All events (all categories, audiences, and campuses), and the filters are really only useful if you’re trying to show just select ones?
Alternately, if you don’t want a certain category, you can use &exclude_category= to remove a few, rather than including the whole list?
Hope this may help! Let me know if I can say more about this. A Saved Widget can have unlimited filters like I mentioned above, which would help work around this issue with the long query.
Karl
Ah, I see the 2nd case is just wanting to filter by 24 groups, so optimizing the Categories piece of the query won’t help. We’ll chat with the team about relaxing this bot-blocking behavior so it doesn’t accidentally capture this case. Using a Saved Widget would definitely work as a stop-gap until that fix is released; apologies for the inconvenience in the meantime!
Hi Karl,
Thanks for the suggestion. I have to discuss with our IT team if we can have some clarification on the default behavior on our UI.
In general, we let users to select their filters so they can display the events on their department’s website. At this point, we don’t know how many of this and what filters they are using. So saved widget may limit their flexibility to create the event list on their own and yet, we have to restrict them from messing around the style and html code we used in the widget.
Thanks Gladys – we’ll have an adjustment for this behavior in our next minor/patch release, and I believe Rachael mentioned in your conversation with email support that we have a workaround for your site in the short term. 
Glad we were able to get this resolved for you!