Thanks for the report. Both are warnings, not errors.
I just fixed the Doku_Event_Handler in b80ed4c2e184.

Added documentation to DokuWiki.org, closing as it seems to work fine.

Marking it as resolved as it works for me and nobody else complained...

Thank you, applied.

I applied this in 630eee463542. Any reason why you didn't translate the settings strings?

Thanks for the translated strings, I'll apply the changed files ASAP.

Please update to the latest version, this fixes the issue for me.

I can reproduce this if I set my client to your timezone. The server's timezone doesn't seem to have any influence on this. I'll investigate this during the next days.

OK, I'm currently installing a few test servers and clients with different timezone settings, however it's going to take some time.

Duplicate of T23

My first guess would be a timezone issue. Please give some more info:

This should be fixed now in rDAVCAL1e7c1b3b359f. It was a problem with how the SQL queries were built, the SQL library thought the question mark was a placeholder and expected more parameters

Then you most probably have a JavaScript error in one of your other PlugIns, because addInitEvent is not used by davcal. To speed up the time to track it down, disable JavaScript compression in DokuWiki. Check the error log again and you should get an idea what PlugIn it is from by looking around the erroneous line. Disable (or update?) the corresponding PlugIn and you should be good to go.

Yes, re-saving the configuration file has the exact same effect as touching the file.

Seems like the JavaScript did not reload. Try force-reloading the page and, if that doesn't help, cleaning DokuWiki's cache (for instance by re-saving the configuration file).

I added this in rUSQL77f7b713334c, rUSQL34606ff7539f and rUSQL5d207457c879

The need for this functionality actually arose yesterday when I discovered some problems with my setup. I'm going to implement this in one of the next releases, but I have yet to find a structured way to enter the configuration.

The iOS URL is displayed starting from rDAVCAL084e26cfa950. Limited testing is now being done on MacOS X El Capitan.

It seems to be a problem with autodiscovery and/or the sync URL.
I can get MacOS X 10.5 to sync when I paste the principal URL into Calendar. It then discovers all available calendars.
Using the .well-known approach, it doesn't detect anything.

This was fixed in rDAVCAL2d14bdd4dd3c

Yeah, Thunderbird uses the terms Attachment and web pages. I agree with you, though, I'm going to change the text. Thanks for the translation, updated in rDAVCAL8a73b69f4ffa. Closing the task now :)

Support for adding URL attachment was introduced in rDAVCAL40987d2c5f2a. Please test and report back!

This has been fixed in rDAVCALc1147cdcb5be

I just started looking into this: In order to support ThunderBird, I'll probably use the ATTACH property of the ICS spec. This one can be specified several times and it defaults to URI. Seems like a good fit.

I agree. I'll add a separate link field (first step, should be easy) and I'll also change the behaviour of the edit popup: When you click on an event, it will be displayed read-only, so that the URL is rendered. Only after clicking 'Edit', it will be read-write (if you have enough permission).

Yeah, sometimes, when you look closer to "simple" wishes, they become complicated :(

OK, now I understood your request :) You're speaking of creating links WITHIN an event, not within a page TO an event.

Thanks for the idea!
I'm not sure if I understood you correctly, however. What I could imagine is a syntax like

Initial support for RSS feed was added in rTL3139de083d8f: Add possibility to display entries of a pages as RSS feed.
This still lacks a button for subscribing to the feed and for enabling/disabling feed generation. Documentation is also missing.

Commit rUSQL6952eee1f647: Add PHPass class, as it's removed in ownCloud 8. Load it only if now includes the PasswordHash.php file if the PasswordHash() class is not found.