ErrorException: Trying to access array offset on value of type bool

[flart]

Some weeks ago my rolling release distro delighted me with PHP7.4.
As I could find some hints that you already adopted some parts of your nice software to this php version I'd like to point out another issue which seems to be related to some "Backward Incompatible Changes" according to the php documentation. When trying to sync my database by vdirsyncer I'm faced with the above mentioned error. The log files says:

Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: ErrorException: Trying to access array offset on value of type bool in /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/CalDAV/Backend/PDO.php:797
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: Stack trace:
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #0 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/CalDAV/Backend/PDO.php(797): Baikal\Frameworkk::exception_error_handler()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #1 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/CalDAV/Calendar.php(359): Sabre\CalDAV\Backend\PDO->calendarQuery()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #2 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/CalDAV/Plugin.php(606): Sabre\CalDAV\Calendar->calendarQuery()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #3 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/CalDAV/Plugin.php(260): Sabre\CalDAV\Plugin->calendarQueryReport()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #4 /usr/share/nginx/html/baikal/vendor/sabre/event/lib/WildcardEmitterTrait.php(96): Sabre\CalDAV\Plugin->report()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #5 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/DAV/CorePlugin.php(720): Sabre\DAV\Server->emit()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #6 /usr/share/nginx/html/baikal/vendor/sabre/event/lib/WildcardEmitterTrait.php(96): Sabre\DAV\CorePlugin->httpRepor>
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #7 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/DAV/Server.php(464): Sabre\DAV\Server->emit()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #8 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/DAV/Server.php(241): Sabre\DAV\Server->invokeMethod()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #9 /usr/share/nginx/html/baikal/vendor/sabre/dav/lib/DAV/Server.php(309): Sabre\DAV\Server->start()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #10 /usr/share/nginx/html/baikal/Core/Frameworks/Baikal/Core/Server.php(123): Sabre\DAV\Server->exec()
Jan 08 19:51:12 ratte php-fpm[766]: pool www[766]: #11 /usr/share/nginx/html/baikal/html/dav.php(61): Baikal\Core\Server->start()

Could someone please help me with this issue?
Thanks in advance,
flart

[Tntdruid]

Baikal only support php 7.3

[puresick]

Baikal only support php 7.3

Is php 7.4 support planned?

[flart]

Sorry, but I don't get the point...
There have already been changes to the code for php 7.4. Even the name of this commit is "Port to PHP 7.4".
I'm more interested in solving this specific problem than discussing wether or not or when Baikal will officially support php 7.4.

And by now it's already working for two clients using DAVx5 without any problems. However, when trying to sync with vdirsyncer I see the error message.

So here are some more details I just figured out:

When I debug the content of $filters in the public function calendarQuery($calendarID,array $filters) of PDO.php for this specific sync operation I see the following content:

array(5) {
  ["name"]=>
  string(9) "VCALENDAR"
  ["is-not-defined"]=>
  bool(false)
  ["comp-filters"]=>
  array(1) {
    [0]=>
    array(5) {
      ["name"]=>
      string(6) "VEVENT"
      ["is-not-defined"]=>
      bool(false)
      ["comp-filters"]=>
      array(0) {
      }
      ["prop-filters"]=>
      array(0) {
      }
      ["time-range"]=>
      bool(false)
    }
  }
  ["prop-filters"]=>
  array(0) {
  }
  ["time-range"]=>
  bool(false)
}

So there are two time-range entries and both hold only a boolean instead of an array which has a 'start' and 'end' entry as expected in line 797 of the above mentioned function.

Might there be something wrong with the 'filter'-array? Could anybody tell me where the 'filter'-array comes from?
And why was there no problem in php 7.3? If the request didn't change - as I suppose -, what was expected to happen when there is no 'start' or 'end' element in the array 'time-range'?

I'm sorry, but I'm not a computer scientist at all and there is a good chance I misinterpreted the code.
Therefore, I would appreciate any helpful comments.

[flart]

When I change line 797 of PDO.php from
if (!$filters['prop-filters'] && !$filters['comp-filters'][0]['comp-filters'] && !$filters['comp-filters'][0]['prop-filters'] && (!$timeRange['start'] || !$timeRange['end'])) {
to
if (!$filters['prop-filters'] && !$filters['comp-filters'][0]['comp-filters'] && !$filters['comp-filters'][0]['prop-filters'] && (!isset($timeRange['start']) || !isset($timeRange['end']))) {
the error will not occure any longer.

Could someone confirm this as a possible solution?

[gruenie]

Hi flart,
I also tried to get the version 0.6.1 to work with PHP 7.4.1. After making the changings in "collection.php" and "router.php" it worked so far, but with one exception: I was unable to save new or change existing events if they are repetitive. Then I always got a 500-error message from the server. I tried it with Thunderbird and DavDroid with the same result.
When I had a look in the mysql-database (table calendarobjects) I saw no entry (for a new repetitive event) or no changes (when I wanted to add a serie).
Because of your description I assume that my problem has the same cause. when I changed back to PHP 7.3.13 it worked without any problems.

[flart]

I'v been testing this setting for a while now, and everything seems to work as expected. I can't confirm the problems with repetitive events so far. I had some trouble in the past but now it works.
So I'll hope for an update and must disable php updates until then.

@gruenie: I didn't make any changes to the mentioned "collection.php" and "router.php" by now. Could you please tell us the lines you changed in these files? Just to prevent possible errors. Thanks in advance.

[gruenie]

Hi flart,
I mean the changes which are described here:
https://github.com/sabre-io/Baikal/tree/master/Core.
Without these changes nothing works for me with PHP 7.4.1.

[ByteHamster]

@gruenie: I was unable to save new or change existing events if they are repetitive. Then I always got a 500-error message from the server.

I can confirm that I have the same problem on my server. The behavior was fixed in sabre-io/vobject#452 and is released in sabre/vobject version 4.2.1. The library sabre/dav was upgraded to sabre/vobject 4.2.1 in sabre-io/dav@df7357f but has no new release yet that Baikal can switch to.

@flart: When I change line 797 of PDO.php from ... to ... the error will not occure any longer.

This looks like a quite hacky fix. I think it should be fixed further up the call stack. Without having researched further, I think that a good fix could look somehow like this: sabre-io/dav#1187

@flart: I didn't make any changes to the mentioned "collection.php" and "router.php" by now. Could you please tell us the lines you changed in these files?

The lines that need to be changed are available here: d60109e. The change has already been merged to master but it is not released officially, yet.

[Martchus]

Even the name of this commit is "Port to PHP 7.4".

I've been porting the web frontend - that's all. Patches for backend libraries seemed to be already available but apparently some places still need fixing. I've just ran into this issue, too.

[nathanzachary]

I am also running PHP 7.4.2, but I'm not even able to install Baikal. When I go through the installation process, I can start the "Baikal initialization wizard" but after I enter the server time zone, admin password, et cetera, I encounter the following error message:

ErrorException: Array and string offset access syntax with curly braces is deprecated

I would imagine that this is related to the changes between PHP 7.3 and PHP 7.4.

Is there an expected release that will fix the PHP 7.4 problems?

[Martchus]

I've clicked though all pages of the fronted but forgot the install wizard. So yes, this error is unfortunately no surprise.

Is there an expected release that will fix the PHP 7.4 problems?

I suppose everybody is welcome to create a PR for fixing these problems and if things look good enough there will be a new release. It apparently just takes some time. Not sure whether there's a better approach than just fixing issues as they emerge. Is there a testsuite we could run under PHP 7.4 to fix things in a more straight forward manner?

---

By the way, I see no need to rush this. In my setup I have the latest PHP and PHP 7.2 co-installed so only Baikal is using the old version and everything else the latest. This was quite easy to achieve with NGINX: https://aur.archlinux.org/packages/baikal/#pinned-727123

[phil-davis]

Also see issue #876
I will have a look at the weekend to see what progress can be made

[ByteHamster]

Version 0.7.0 with support for php 7.4 was just released.
https://github.com/sabre-io/Baikal/releases/tag/0.7.0

[Rainbird-1]

OK. That means with the implementation of Sabre 4.2.1 in Baikal will the problem be solved?

[ByteHamster]

Baikal already uses the newest version of sabre/dav. @Rainbird-1 could you please post crash details from the apache error log? Should be in /var/log/apache2/error_log

[Rainbird-1]

Baikal already uses the newest version of sabre/dav. @Rainbird-1 could you please post crash details from the apache error log? Should be in /var/log/apache2/error_log

error.log

[Rainbird-1]

Hello,
is there already a solution to my problem or is it
already clear what is not working here?

Thanks in advance
Rainbird-1

[ByteHamster]

This might be fixed in sabre-io/dav#1275. In the meantime, you can switch back to php 7.3 to work around the problem.

[Rainbird-1]

Hi,
I have now set up my installation again, as before,
but with PHP7.3 instead of PHP7.4. everything works
as before with the Baikal 0.6.1.
Thanks

[phil-davis]

sabre-io/dav#1275 is ready for review.

[sicherist]

Did anyone already test if this problem still exists with Baikal 0.7.2? Theoretically PHP7.4 should have been working since sabre/dav 4.1.0 / Baikal 0.7.0.

[Rainbird-1]

I did another test installation, but version 0.7.2 still only works with PHP7.3.

[Strunzdesign]

Hi,

I also have this issue. I'm also using Baikal 0.7.2 together with PHP 7.4.13 on Gentoo/Linux. The above mentioned hotfix from flart helps here as well, thank you very much.

Regards,
Florian

[Rainbird-1]

Hi,

I didn't test that because the user gruenie wrote:
"I was unable to save new or change existing events if they are repetitive."

Therefore this is too hot for me, because I don't want to do new installations all
the time (possibly undesirable side effects).

I use the system productively, only privately but every day! And to get an overview of what comes with such a change, unfortunately I don't have the time!

[ByteHamster]

Should now be fixed in Baikal 0.8.0

[Rainbird-1]

Hi,

i have now set up a new installation.

Ubuntu Server 20.04.1 LTS
Apache 2.4.41
PHP 8.0.1
MariaDB 10.3.25
phpMyAdmin 5.0.4
Baikal 0.8.0

In this constellation everything works for me,
thank you very much for that.

greetings
Rainbird-1

[Rainbird-1]

Hi,
is there a new path for iPhones in 0.8.0?

So far I have always used the following path for CardDav or CalDav:

https: //server-adresse/baikal/html/card.php/principals/username/
or
https: //server-adresse/baikal/html/cal.php/principals/username/

unfortunately these no longer work!

[ByteHamster]

Should still work (at least it does on my Android). I think it would be good to create a new issue with some more details (eg logs).

[Rainbird-1]

I am sorry, my mistake. I had a prescription :-)