I gave it all up and installed another calendar but maybe the question is still interesting from a general perspective?
Same thing happening to me..
Ok it was easy to fix this issue – but of course this is not portable for upgrades, and IMO the author should reconsider the placement of the install and upgrade functions that do require access to wp-admin/ somewhere different than the ajax-event-calendar.php, or figure out some way to fix this conflict.
All I did was comment the lines in ajax-event-calendar.php which refer to the wp-admin location and it seems to have fixed it.
HTH
OOPs… sorry not quite that simple
Invoking the calendar page does
POST /wp-admin/admin-ajax.php
why is this necessary?
That is harder to control as that URL is formed coming through the include/function branches in wp3.5.1
I wonder if the author even reads these threads?
I believe the root of the problem is incorrect handling of ajax calls for the viewer facing side, which is described here:
http://codex.wordpress.org/AJAX_in_Plugins#Ajax_on_the_Viewer-Facing_Side
That document urges developers to create a separate ajaxurl value, and realize that ajax by default is executed in the admin context. This should be separated out so that non-logged in users (or any users execept a logged in admin) execute through a non-admin context/path in the application.
After digging deeper I see the Ajax routine is doing the POST of json data
e.g.
[,…]
0: {id:2, title:Saltwater Fly Tying Demo, start:2013-05-26 00:00:00, end:2013-05-26 00:00:00, allDay:1,…}
1: {id:3, title:Event Two, start:2013-05-27 00:00:00, end:2013-05-27 00:00:00, allDay:1, className:cat1,…}
which is how the calendar content gets rendered.
How difficult will it be to address this issue? It’s the best calendar I’ve installed and I would like it to work without touching the admin context.
Many thanks also for any corrections to the above.
