wallabag: Update breaking on PHP 8

Environment

Version: 2.4.1 or master
Installation: Git Clone on a VPS
PHP version: PHP 8.0
OS: Ubuntu 20.04
Database: Postgresql
Parameters:

My app/config/parameters.yml is:

parameters:
  database_driver: pdo_pgsql
  database_host: 127.0.0.1
  database_port: null
  database_name: xxxxxxxx
  database_user: xxxxxxxx
  database_password: xxxxxxxx
  database_path: null
  database_table_prefix: wallabag_
  database_socket: null
  database_charset: utf8
  domain_name: 'https://xxxxxxxx'
  mailer_transport: smtp
  mailer_host: xxxxxxxx
  mailer_user: xxxxxxxx
  mailer_password: xxxxxxxx
  locale: en
  secret: xxxxxxxx
  twofactor_auth: true
  twofactor_sender: xxxxxxxx
  fosuser_registration: true
  fosuser_confirmation: true
  from_email: xxxxxxxx
  rss_limit: 50
  rabbitmq_host: localhost
  rabbitmq_port: 5672
  rabbitmq_user: xxxxxxxx
  rabbitmq_password: xxxxxxxx
  rabbitmq_prefetch_count: 10
  redis_scheme: tcp
  redis_host: localhost
  redis_port: 6379
  redis_path: null
  redis_password: null
  mailer_port: false
  mailer_encryption: null
  mailer_auth_mode: null
  fos_oauth_server_access_token_lifetime: 3600
  fos_oauth_server_refresh_token_lifetime: 1209600
  sentry_dsn: null
  server_name: 'xxxxxxxx xxxxxxxx'

What steps will reproduce the bug?

Upgrade Ubuntu to use system PHP 8.0. Run the wallabag make update

It breaks because of Doctrine issues, the following error shows up:

  [RuntimeException]
  An error occurred when executing the "'cache:clear --no-warmup'" command:



  PHP Fatal error:  Declaration of Doctrine\DBAL\Driver\PDOConnection::query() must be compatible with PDO::query(string $query, ?int $fetchMode = null, mixed ...$fetchModeArgs) in /path/to/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php on line 81

  In PDOConnection.php line 81:

    Compile Error: Declaration of Doctrine\DBAL\Driver\PDOConnection::query() m
    ust be compatible with PDO::query(string $query, ?int $fetchMode = null, mi
    xed ...$fetchModeArgs)

Looks like this was fixed with https://github.com/doctrine/dbal/pull/3803 but the wallabag dependencies are still referring to v2.x of dbal. Can we update the dependencies to resolve the issue?

Thanks,

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 9
Comments: 22 (9 by maintainers)

Most upvoted comments

The master is now compatible with PHP 8.0 & PHP 8.1! The upcoming 2.4.3 will be release with fixes about that.

j0k3r on Jan 31, 2022

If this helps anyone, I kinda force upgraded the following packages using composer u -i and wallabag seems to be working fine on php 8 on ubuntu 20.04. I haven’t done extensive testing so something is probably broken:

symfony/symfony

doctrine/doctrine-bundle

doctrine/dbal

Just wanted to give anyone else looking a +1 that this definitely works. I just interactively updated those 3 packages, changed my php-fpm for wallabag from a 7.4 socket to an 8.0 one, and reloaded. It all seems to work well enough. Like @opsydev mentioned, there could be some silent errors happening, but I’m not noticing anything at all.

WillPresley on Dec 21, 2021

If this helps anyone, I kinda force upgraded the following packages using composer u -i and wallabag seems to be working fine on php 8 on ubuntu 20.04. I haven’t done extensive testing so something is probably broken:

symfony/symfony
doctrine/doctrine-bundle
doctrine/dbal

opsydev on Dec 19, 2021

Wallabag is the last application preventing a php update in my environment (again…). Any news on this?

Square252 on Nov 11, 2021

This works for allowing the upgrade to finish properly, as long as you still have PHP 7.x installed and are willing to re-enable it to run Wallabag

Yes.

The problem that I was experiencing was upgrading Wallabag according to its stated dependencies while PHP 8.0 was installed on my system for testing purposes. This fix allows the upgrade to Wallabag in environments where both versions are present.

joshp23 on Mar 12, 2021

I ran into this problem and solved it by running these

sudo update-alternatives --config php
sudo update-alternatives --config phar
sudo update-alternatives --config phar.phar

to select which php version is used during installation/update. After that, everything went smooth as silk.

joshp23 on Mar 12, 2021

I am having this issue with Wallabag 2.4.2 installed on a shared hosting account. Non-composer install. Is my best bet to just wait until 2.5, or is there a way to update Doctrine manually (like, just upload new version to vendor/doctrine)?

thirashima on Apr 14, 2021

I ran into this problem and solved it by running these
sudo update-alternatives --config php
sudo update-alternatives --config phar
sudo update-alternatives --config phar.phar
to select which php version is used during installation/update. After that, everything went smooth as silk.

This works for allowing the upgrade to finish properly, as long as you still have PHP 7.x installed and are willing to re-enable it to run Wallabag (the only thing on my VPS that doesn’t work with PHP 8, actually). With PHP 8 already in heavy distribution and old versions of 7.x quickly falling out of support, it would be great for this to be worked on very soon.

WillPresley on Mar 12, 2021

I tried just running a full composer update on the current master but ran into the same issue. I’m not super familiar with symphony so not sure what to try.

opsydev on Jan 29, 2021