1

I searched the whole net and stackexchange for a reason and a solution, but couldn't find any. There are many questions (and answers) related to own plugins and the code how to create tables on activation. But this applies not here, because I have this problem with well known and maintained plugins from the wordpress plugin repository.

So, the situation: A kvm guest with around 20 docker stacks. Each stack consists of a nginx, a php:8-fpm and a mariadb container. In the nginx container is a web directory as a shared volume, that contains a wordpress installation. (So I'm not using the wordpress docker image!).

The wordpress'es are running like a charm. I can access the backend and the frontends, I can install plugins and themes... everything is working... until...

Until it comes to a plugin installation that wants to create own sql tables on activation.

The tables are not created, I only receive an error that says, the table xxx is not existent and the plugin can not be activated.

This happens on all plugins from the wordpress plugin repository, when they want to create own tables on activation.

Everything else is working like a charm.

The sql user is allowed to create tables... this was checked through the mysql console. The wp-config.php is correct... everything has worked when not in a docker container. This happens only when inside a docker container.

So here's my docker-compose.yml

version: '3.8'
services:
  app:
    image: nginx:latest
    restart: always
    volumes:
      - ./web:/usr/share/nginx/html
      - ./default.conf:/etc/nginx/conf.d/default.conf
      - ./logs:/var/www/logs
  php-fpm:
    image: php:8-fpm
    restart: always
    volumes:
        - ./web:/usr/share/nginx/html
        - ./errors.ini:/usr/local/etc/php/conf.d/errors.ini:rw
        - ./logs:/var/www/logs
    logging:
      driver: syslog
      options:
        tag: docker/php-fpm
  mariadb:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'xxxxxxxxxxxxxxxxxxxxxxxxxx'
      MYSQL_DATABASE: 'database'
      MYSQL_USER: 'dbuser'
      MYSQL_PASSWORD: 'xxxxxxxxxxxxxxxxxxxxxxxxxx'
    expose:
      - "3306"
    volumes:
      - ./mysql:/var/lib/mysql

Here comes the default.conf:

server {
    server_name _;
    index index.php index.html;

    client_max_body_size 1024M;
    client_body_timeout 900s;
    fastcgi_buffers 16 16k; 
    fastcgi_buffer_size 32k;
    send_timeout 3600;
    keepalive_timeout 60m;
    fastcgi_send_timeout 3600s;
    fastcgi_read_timeout 3600s;
    
    error_log  /var/www/logs/nginx-error.log;
    access_log /var/www/logs/nginx-access.log;
    
    root /usr/share/nginx/html;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_param HTTPS on;
        fastcgi_pass php-fpm:9000;
    }

}

Ohh, one more fun fact: A simple php script, that creates a table with the same database user credentials through mysqli classes, works like a charm:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$mysqli = new mysqli("mariadb", "dbuser", "xxxxxxxxxxxxxxxxxxxxxxxxxxx", "database");

/* Create table doesn't return a resultset */
$sql = "CREATE TABLE MyGuests2 (
id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
firstname VARCHAR(30) NOT NULL,
lastname VARCHAR(30) NOT NULL,
email VARCHAR(50),
reg_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE     CURRENT_TIMESTAMP
)";
$mysqli->query($sql);
printf("Table myGuests2 successfully created.\n");

/* Select queries return a resultset */
$result = $mysqli->query("SELECT id FROM MyGuests2 LIMIT 10");
printf("Select returned %d rows.\n", $result->num_rows);

/* If we have to retrieve large amount of data we use     MYSQLI_USE_RESULT */
$result = $mysqli->query("SELECT * FROM MyGuests",     MYSQLI_USE_RESULT);
2
  • Does it work with php:8.0-fpm or php:7.4-fpm instead?
    – kero
    Dec 14, 2021 at 15:09
  • Good point. I'll try that tomorrow morning (Germany). Dec 14, 2021 at 18:10

2 Answers 2

3

Not sure if it is related, but just in case, as for the last time I looked at it WP core 5.8 have bugs in dbdelta relating to MySQL 8 when integers are involved. Latest MariaDb seems to do better.

I would assume that as of 5.8 core is not ready to be deployed on edge everything. There might be good chance of things generaly working but you might run into edge cases in which they will not.

2

Like kero already has mentioned, I've now tested the activation of plugins with other PHP versions. And what should I say.... Simply switching from docker image php:8-fpm (8.1) to php:7.4-fpm fixed the issue for me.

Update I've tested this now with different PHP versions and different plugins from the wordpress repository.

This happens with ALL plugins, which wants to create own tables on activation. But it only happens with PHP 8.1 (docker image php:8-fpm). Just by replacing "php:8-fpm" with "php:8.0-fpm" or any other version... it works again.


By the way, I'm also using exactly the same Dockerfile for building the images. I'm just only replacing the version of the original image on top:

FROM php:8-fpm

RUN apt-get update
RUN apt -y install ssmtp cron snmp mcrypt unzip curl libedit-dev libeditreadline-dev libedit2 libxml2-dev bison flex libbz2-dev libzip-dev libcurl4-openssl-dev libenchant-2-dev libpspell-dev libpng-dev libjpeg-dev libonig-dev libonig5 libsnmp-dev libtidy-dev libxslt1-dev

RUN apt-get clean
RUN rm -rf /var/lib/apt/lists/*

COPY mail.ini /usr/local/etc/php/conf.d/
COPY --chown=root:mail ssmtp/ssmtp.conf /etc/ssmtp/ssmtp.conf
COPY cronjob.sh /etc/cron.hourly/cronjob.sh
RUN chmod 664 /etc/ssmtp/ssmtp.conf
RUN chmod +x /etc/cron.hourly/cronjob.sh

RUN docker-php-ext-install pdo_mysql mysqli opcache bcmath bz2 gd pspell snmp soap tidy xsl zip exif gettext intl

RUN docker-php-ext-enable pdo_mysql
RUN docker-php-ext-enable mysqli
RUN docker-php-ext-enable opcache
RUN docker-php-ext-enable bcmath
RUN docker-php-ext-enable bz2
RUN docker-php-ext-enable gd
RUN docker-php-ext-enable pspell
RUN docker-php-ext-enable snmp
RUN docker-php-ext-enable soap
RUN docker-php-ext-enable tidy
RUN docker-php-ext-enable xsl
RUN docker-php-ext-enable zip
RUN docker-php-ext-enable exif
RUN docker-php-ext-enable gettext
RUN docker-php-ext-enable intl
3
  • Glad to hear that it was solved! :) You could try to find out if it is specific plugins that caused the problem (and inform the authors) or if this is a general WP issue. But I remember reading somewhere that WP core itself should be compatible with PHP 8.
    – kero
    Dec 15, 2021 at 16:03
  • Yeah, I'll try to find that out. I'll also try 8.0 tomorrow. Let's see... Dec 15, 2021 at 20:28
  • 1
    So, I've added my tests and the Dockerfile above... this is really strange, since it only affects PHP 8.1. With PHP 8.0 everything is working. It seems there is some incompatibility in the wordpress core for PHP >= 8.1. Dec 16, 2021 at 6:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.