Thread Starter
temp5
(@temp5)
Ok, it seems the “Ai1ec_Abstract_Query”-class that manages the request uri had some issues extracting the request_type and so the type was always set to “standard”, which means: html-rendering.
So I wrote a workaround that checks the request uri for “request_type=json” and sets the type corresponding to the result.
Maybe not the nicest solution, but everything seems to work now!
Best regards,
temp5
temp5: Can I get someone from Time.ly to contact you regarding that fix? I’d like to see if we can get that sorted so that it’s fixed in future versions (even if the fix is different to yours).
Thread Starter
temp5
(@temp5)
Of course you can! But I really don’t know if my solution will be of any assistance for them, because it really is a quick and dirty fix and was done in the old 1.10.11 and it seems that there are many other reasons that can lead to this behavior.
Best regards,
temp5
Hello temp5!
I am having the same problem of eternal loading, and its not a plugin conflict.
Is there any chance you think I’d be able to use your fix? I know some html/css but no ajax or javascript.
Would you be able to describe to me what to do?
Thank you,
Claire
Thread Starter
temp5
(@temp5)
Hello pearl-grey,
as I said: the fix is really quick and dirty and I don’t know if it will of any assistance for you, but of course I will try to help you (remember: I did this in version 1.10.11):
Add the following:
if (strpos($_SERVER['REQUEST_URI'], "request_type=json") !== false)
$type = "json";
after line 918 (“$type = $this->request->get( 'request_type' );“) in file
wp-content/plugins/all-in-one-event-calendar/app/controller/class-ai1ec-app-controller.php
and after line 188 (“$type = $request->get( 'request_type' );“) in file wp-content/plugins/all-in-one-event-calendar/app/controller/class-ai1ec-calendar-controller.php .
This really isn’t a neat solution, but it does the trick for me and hopefully for you.
If you have any questions feel free to ask!
Best regards,
temp5
Upgrade to v2.0.13 – having this issue. Not sure why it is marked [resolved] here in the support forum. Clearly it has not been.
and yes – I have disabled all plugins and reverted to twenty eleven, so the canned response is not appropriate.
Thread Starter
temp5
(@temp5)
I marked this thread as “resolved” because the workaround I posted before your post did the trick for me.
The main problem with this issue is, that it only occurs to a bunch of people and under special circumstances, that, I think, the devs don’t know – because otherwise they would have fixed it already.
Have you tried my workaround?
Hi temp5 –
I am trying to get v2.0.13 working. unfortunately, your workaround does not apply.
I have found that applying a string filter in .htaccess to prevent malicious XSS string attacks breaks the navigation within ai1ec (even after denying permission to phone home during initial setup <taps foot />) – there is a hook in there somewhere that hasn’t been properly terminated.
Thread Starter
temp5
(@temp5)
Oh, sorry, I read over the fact that you use v2.
I really can’t say much about your suggestion – maybe you are on the right track, but maybe you found a complete other problem.
In my opinion the best bet to solve this “forever loading”-issue is to check the process where the parameters are extracted from the request uri.
Best regards,
temp5
