It seems that the previous commit accidentally broke the creation of new events by not defining a necessary variable in the client side JavaScript.

Problem fixed !

Sorry, something went wrong during branch merge (one function in helper.php appeared twice) and I didn't test it thoroughly enough. Should be fixed now.

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

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.

Updated and was still having the same issue. Created a new calendar and it is now working correctly. That is fine for me since I didn't have much in my calendar yet.
Thanks for the quick work.

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

OK. Thanks!

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.

I was thinking timezone issue also. My browser and server timezones are both America/New_York.
I had the default timezone set on the calendar. I tried using forcetimezone on the calendar and I set the timezone in settings to America/New_York but neither worked.
I don't see any timezone preferences set for the user.
I am new to davcal and installed the latest (2016-01-20) version today.
Thanks.

Duplicate of T23

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

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

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