davcal is unmaintained, no further fixes will be implemented from my side.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 13 2020
Apr 20 2020
Finally, this should be fixed in rDAVCALe4bc2b1c0d4a53495d69bc0e916c5e70b3941ea2. Feel free to reopen if it doesn't work as intended.
Apr 14 2020
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
Jan 24 2020
Oct 12 2019
OK - it sounds feasible and would need to be done entirely in JavaScript. Unfortunately, at the moment, I don't really have the time to work on this.
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?
Jun 28 2019
Jun 17 2019
May 29 2019
May 28 2019
Apr 30 2019
Mar 20 2019
Mar 12 2019
Feb 5 2019
Jan 25 2019
Jan 23 2019
Jan 22 2019
Jan 21 2019
Jan 9 2019
Dec 17 2018
Nov 9 2018
Oct 25 2018
Oct 13 2018
Oct 11 2018
Oct 4 2018
Sep 27 2018
Aug 22 2018
Thanks for the report. I do not use Google calendar, so I never had the necessity to implement it (I only sync against Nextcloud).
May 3 2018
While this works in an action plugin when registering the DOKUWIKI_STARTED event, the configuration manager does not reflect the changes - IMHO this is misleading. It should be possible to save the changes using config plugin's config manager classes - I'll investigate that.
Apr 27 2018
$conf is global. You can change it from your plugin.
As far as I know, a plugin cannot overwrite core settings, only plugin settings. As these are core settings, those changes have to be made manually. However, even if it was possible to change the settings, I would prefer not to change settings automatically.
Apr 11 2018
Apr 5 2018
Mar 18 2018
Jan 30 2018
Jan 19 2018
Dec 6 2017
Nov 24 2017
Nov 22 2017
Nov 19 2017
Nov 17 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.