davcal is unmaintained, no further fixes will be implemented from my side.

Finally, this should be fixed in rDAVCALe4bc2b1c0d4a53495d69bc0e916c5e70b3941ea2. Feel free to reopen if it doesn't work as intended.

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:

OK, then my theory is probably wrong :(

Short answer: dokuwiki and DokuWiki are - usually - two separate folders and you should *never* mix them.

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

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.

Could you be a bit more specific with what you mean? What exactly should the setting prevent/disable/disallow?

Thanks for the report. I do not use Google calendar, so I never had the necessity to implement it (I only sync against Nextcloud).

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.

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.

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?

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

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.

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.

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!

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?

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:

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:

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

OK, let's debug that a bit further:

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?

Seems that latest jQuery 3 code in DokuWiki broke fullcalendar, on which davcal is based. Probably, an update of fullCalendar can fix this.

Yeah, mine looks similar to yours. You can try to style the calendar output by modifying fullcalendar-2.4.0/fullcalendar.print.less (it's a standard CSS stylesheet).

Yes, please upload a screenshot of the differences. I just tried printing (Firefox 49.0.1) and IMHO it looks very nice! Day/Week view are more condensed in print, but that could be by design (fullcalendar's unmodified print stylesheet is applied).

Thanks for your comment.

A basic editor for events created within DokuWiki doesn't seem too difficult. However, making it compatible with events created and/or modified by other clients is the hard job.

Thanks for testing, I'll add it to the next release.
Did you also test password changing?

Could you please test if the latest development version works for you? Here is the direct link: https://www.aboehler.at/hg/user_sql/archive/e6a991d13870.tar.gz

Hm, my initial though was that it is impossible due to the way CRAM-MD5 works. However, it seems that someone wrote a library recently: https://github.com/hn/dovecot-misc/blob/master/dovecot_hmacmd5.php

Obviously, you do not have the PDO mySQL driver installed. That's a problem of your NAS, nothing I can do about.

If you read through the documentation, you will find the option "timezone" which should solve your problem.

OK, user_sql has just been released to the Nextcloud app store. Plus, I changed the way archive folders are created, so now it should also work with the release on OwnCloud's app store.

This issue includes a fix to the code and does not only involve disabling the app code checker.

I'm sorry, NC10 is, of course, supported and it works fine for me. However, I have not yet upgraded to 10.0.1, which you are probably running.

I never tried it with NC10, as soon as I upgrade, this problem will be fixed.

This would be a nice Admin Plugin...

you're welcome, I'm closing this...

By the way: If you go through the Joomla docs you'll notice that the column "activation" is meant for a completely different thing: It controls whether activation emails are to be sent!
You want the column "block" and, of course, need to check the "invert active value" box.

I went over your screenshot of the app configuration again and I think I found your problem: You must activate "Invert Active Value" (I did not bother entering the table for "User Active Column" in the first place)

I did not change the configuration of the sql server. I just created a new local user and selcted "Create database with same name and grant all permissions" in phpMyAdmin.

I just did a fresh installation of Debian Jessie, ownCloud 9.1.0, user_sql 2.3 and Joomla 3.6.2. Everything went without problems, my Joomla user is in the list and is able to login.

That's really strange. The log doesn't even include information about ownCloud trying to list the users from the user_sql backend.

Hm, looks quite fine to me.
Is this the only domain you serve ownCloud on? If yes, what happens if you duplicate your settings for domain "default"?

It seems that either saving or loading of the settings fails (you did click on "Save", right?).
Could you give some more info, please:

Thanks for the logs. Could you try clearing your browser cache and cookies and logging in again? Did you check from a different computer?

That's strange, I'm running on NextCloud 9 for quite some time now (actually, since its release).
I tested it on ownCloud 9.1 just yesterday and I did not notice any problems.

OK, I found the problem: It's the PHP7 update and an incompatibility with the version of Sabre/DAV I'm using for davcal. See the problem for ownCloud, I applied their patch: https://github.com/owncloudarchive/calendar/issues/1002

I'm currently testing a few things, it seems that OutlookCalDavSynchronizer requests only events within a certain time span. davcal does not report any events back, so it looks like a problem somewhere within davcal.

Did you use this one: https://sourceforge.net/projects/outlookcaldavsynchronizer/?

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

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.

Hm, I don't think this can be achieved easily. All rendering is done using jorgchart, I just created a wrapper for DokuWiki.

You need to know the name of the table as well as the columns that vBulletin uses to store its information. Unfortunately, vBulletin is not Open Source, thus I am not able to help you here.