- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
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.
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(...))
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 29 2017
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
Oct 25 2017
Oct 19 2017
Oct 18 2017
Oct 12 2017
Jul 28 2017
Jun 30 2017
Jun 20 2017
Sure :)
Well, we're generating secret material, so I guess it's cryptography ;)
That's right, as davcal is tested and being developed with this version of sabredav (which is also patched to support PHP7). I'm not going to update for no good reason, feel free to provide a patch, though.
Thanks for the documentation, please feel free to add it to the Wiki at www.dokuwiki.org/plugin:davcal
Closing, since user_sql is on hold.
Thanks for your suggestion, I did not know that random_compat exists.
However, I still consider the implementation with uniqid as appropriate, because:
Jun 19 2017
Jun 2 2017
yes it works perfectly now. thanks !
May 30 2017
Could you check whether the latest update fixes your problem? The downside is a scrollbar that appears, at least for me.
Oh well: this doesn't happen in Chromium, only in Firefox!
Finally, I'm able to reproduce your problem, at least partially: It happens to me only in month view and only in the lower three rows of the calendar. It does not happen with an older version of davcal, so it might be either a regression or a bug in fullcalendar (which was updated due to a newer jQuery version in DokuWiki).
Is there anything that I should change ? every plugins look up-to-date.
May 24 2017
Hi,
I have only one calendar on the page.
I call it the easiest way possible: {{davcal>}}
OK, let's debug that a bit further:
May 23 2017
does someone have any idea about our problem ?
May 17 2017
here is what is on the server log:
[Tue May 16 14:13:15 2017] [error] [client ip adresse] client denied by server configuration: /usr/share/dokuwiki/data/security.png, referer: https://ourwebsite.fr/doku.php?id=clic:calendrierseeg&do=admin
May 16 2017
Hi,
in the developer tools, in console, nothing happens when I click on a day.
I have this :
"JQMIGRATE: Migrate is installed, version 3.0.0 jquery.php:20:440
Use of getPreventDefault() is deprecated. Use defaultPrevented instead."
it appears at the begining.
I have nothing added to the console when I click on a day or when I modify an events.
I'll look on the webserver log.
Hm, that sounds indeed a bit weird. Are there any error message in either the webserver log or the browser log? Could you open Developer Tools in Firefox or Chrome (F12 for both of them), click on a day and see if there is an error logged in the console?
Sometimes, also the installation of another, presumably unrelated, plugin trigger an error?