The DokuWiki DAVCal PlugIn adds calendaring functionality to DokuWiki enabling users to sync their calendars. It is based on fullcalendar and SabreDAV.
Feb 26 2020
OK. Thank you for your analysis. I will try it. Many thanks.
Thanks - DokuWiki thinks the request is a CSRF attack. The reason is that some requests are performed to your uppercase URL and some to your lowercase URL. I suppose that IIS invokes separate PHP instances for the different URLs and thus the security tokens do not match.
Then we need to go the more complicated route and I have to ask for more details:
Unfortunately, that's not possible. We are using DokuWiki in our Intranet. Access from outside isn't possible.
OK, then my theory is probably wrong :(
Sorry, I've forgotten to write that we are using IIS. You are right, DokuWiki and dokuwiki are separate folders – on UNIX systems. But using IIS on Windows Server, both names refer to the same directory. Therefore, we are able to use both styles. It works with all pages except pages using davcal.
Short answer: dokuwiki and DokuWiki are - usually - two separate folders and you should *never* mix them.
Feb 12 2020
Thanks for the patch, I'll review and apply it as soon as possible (there is another patch pending that arrived via E-Mail that needs some work as well).
Feb 10 2020
Oct 12 2019
If you want to give it a try, I'd be happy to give you some guidance. If not, it's going to take a while, I'm afraid.
Oct 11 2019
Yes, this is exactly what I meant.
Could you be a bit more specific with what you mean? What exactly should the setting prevent/disable/disallow?
Aug 22 2018
Nov 24 2017
Nov 15 2017
OK, I can see the problem with the datepicker in bureaucracy now. This seems to be a "feature" of the underlying fullcalendar.js library, though. I'll need to investigate that a bit further.
Thanks for your comment, much appreciated! It should be fixed now, would you mind having a look again?
Yes, I had the problem with 2017-02-19e and the current hg checkout of your plugin.
Thanks for the report. I cannot reproduce this on 2017-02-29e, the interface language of davcal follows DokuWiki's language for de, en, fr and nl. There is indeed a bug regarding datetimepicker which is always English (easy fix).
Of course this breaks the localization of the calendar view itself.
Nov 9 2017
Perfect now it works again :) I thought i made a mistake.
No problem, I introduced a nice regression - I should definitely do more regression testing before pushing updates!
Anyway, please try the latest update published just now. The problem was/is the "C:" in <C:calendar-data> which confused the XML parser - I fixed it in 447fc5d456c1.
I'm sorry to hesitate you again.
Today i was working on the dokuwiki and recognised, that the plugin still dont work.
After that i saw the update for webdav
I updated the webdav plugin but nothing changed.
Nov 8 2017
OK, I'm glad you got it working. I'm pushing an update anyway just now, since you discovered a bug with this broken XML tag.
It works now!
I updated davical from version 1.1.3 to 1.1.5 about backport package made a resync and now I see the data.
So I guess there where changes made for debian stretch.
Thanks for the quick response. Obvisily nothing changed i deleted brwoser cache etc.
Do you need access to my system?
OK, could you try the following:
In function clean_response (helper.php:1364), add as first line of the function:
$response = preg_replace('/xmlns[^=]*="[^"]*"/i', '', $response);
This might fix it, if not, we need to find another solution.
Thanks, that is the relevant part. The function clean_response messes the response up when davical is used (I only test against Sabre/DAV resp. NextCloud). It might take a bit until I come up with a solution, but I'll make that a high priority task.
This is helpful, although webdavclient doesn't seem to log the raw response. There seems to be an empty tag <''> which is closed by </multistatus> and that probably confuses simplexml_load_string().
Could you add the following line in helper.php on line 1126 (right before $response = $this->clean_response(...))
here is the output. do you need more?
Hm, seems to be related to davical. Unfortunately, I can't test this since I do not have a davical installation.
Please enable debug logging and force a sync. Then, you should be able to see some XML output in the debug log - be aware that your calendar data is included here!
Actual i found this at the apache error.log
What exactly are you trying to achieve? You want to synchronise your DokuWiki calendar to davical, right?
Did you configure WebDAV connections in the Admin section? If so, were you able to display the available calendars?
Oct 27 2017
I don't really understand your question. What I've understood is that a user should have read/write access to a calendar when he's logged in to DokuWiki. This is the exact behaviour. Put simply:
Oct 26 2017
Jul 28 2017
Jun 20 2017
Well, we're generating secret material, so I guess it's cryptography ;)