|
Tom Howard
|
December 11, 2014 at 7:10 pm
I have an event that in which the ticket selector wasn’t working. All other events were working fine. This specific event would just reload the same page with “?ee=process_ticket_selections” appended to the end of the URL.
After a few hours of searching and rebuilding the event line by line I realized the issue had to do with the colon (:) at the end of one sentence. I thought it might be that you couldn’t use a : at all but during further testing that proved incorrect. As it turns out, you can’t use the phrase “include:” anywhere in the content. I tried to even use “include:” but the editor rewrote it back to “include:” which caused the error again.
So, this is a bug that really needs to be fixed! It is darn near impossible to track down without spending a significant amount of time. And even then it makes no sense to most users. I had to change my content to “include…” and hope the client is ok with the text change.
Let me know if I’m missing something. Thanks!
|
|
Josh
|
December 11, 2014 at 8:07 pm
Hi Tom,
There might be something in your server’s mod_security rules that’s making this happen. I tried to reproduce the same issue on our demo site and the include: there doesn’t cause any errors.
|
|
Tom Howard
|
December 11, 2014 at 9:35 pm
hmmm I guess there could be another plugin causing the plugin as well. It doesn’t sound like a mod_security issue. More like a parsing issue with the content. But I guess I’ll have to dig a bit deeper then to figure this out. Thanks for testing on your end. I’ll let you know if I figure out where the conflict is. Thanks!
|
|
Tony
|
December 12, 2014 at 2:43 am
Hi Tom,
Just to note so dont end up on a wild goose chase, this has come up before and turned out to be mod_security rules around base64 encoded objects.
When you select tickets on the ticket selector it is encoded as a base64 object and passed to the next page for those values to be re-used, due to some fairly recent attacks (unrelated to EE4) a lot of hosts have added stricter rules around base64 encoded urls/objects.
For example Dreamhost would block base64 encoded objects if they contained certain phrases, this resulted in the same issue you are reporting.
GoDaddy seemingly randomly blocked base64 encoding but would not provide details on what they blocked, again this caused the same issue.
It is possible it is another cause but I would recommend also issuing a ticket with your host to investigate.
|
