it works perfectly now, thanks !

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

you were right, the problem came from the plugin ACLauditor.

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.

We checked, there is no error on the server's log file.

not checked for the server's log file yet
but on Firefox I clicked on f12, reload the page and I have this error message:
"ReferenceError: addInitEvent is not defined"
js.php:24
js.php:24:108057

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

we tried that and we still have the problem.
to clean the DokuWiki's cache we did:
"touch conf/local.php" which is recommended by dokuwiki's help

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 :)

Seems to work perfect. Thanks a lot!

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.

Thanks again. I am looking foreward to it.

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).

I just checked owncloud. The Calendar app does not have a link. Calendar+ has one link as a seperate field. So it appears one seperate link is considered 'enough'.

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

You are right. wiki sytax would be useless on other clients. However the ICS url you refer to is just a link. I mean there is no label so you can see what it is where you will go to when you click on it (they could have done URL:"meeting notes":http://bladiebla). Or is that what they mean with 'xparam'?

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

Thanks for looking into this.

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