Hi,
I have since investigated the problem further and have been able to narrow down the cause.
Back to the background:
I am importing an XML file using the WordPress Importer plugin controlled by a WP CLI command. Since the XML file would otherwise be gigantic, when we create it in an external CRM we omit many of the otherwise uniform details about the products that are being imported. We then add this uniform information before and during the import. My individual plugin provides the WP CLI command for this purpose, integrates the files of the WordPress Importer plugin for the import when it is called and sets a marker that the import is now running. This marker is saved as a transient:
set_transient( 'product_import_running', true );
The import then starts:
$import_obj = new WP_Import();
$import_obj->import( $xml_file );
We then use the “wp_import_posts” hook to add the missing information to the posts from the XML. This also checks whether it is our import by loading and checking the transient marker:
// bail if our product import is not running.
if ( false === get_transient( 'product_import_running' ) ) {
return $posts;
}
This also works without any problems without APCu Manager and its object cache. As soon as APCu Manager AND its object cache are activated:
get_transient( 'product_import_running' )
always returns false. This means that the filter then returns the original post array, which means that the information about the post types is missing, which explains the error message in the first post.
In summary: the problem is that APCu Manager apparently cannot handle transients on the WP CLI when the object cache is activated.
So that you can understand this, I have designed a small plugin that clearly recreates the problem on a small scale. You can find it here: https://github.com/threadi/apcu-test – the testing procedure is described there.
The solution for my project will now be to switch from transient to a file flag to mark the ongoing import. However, an evaluation of my findings would still be interesting so that this does not happen to me or others in similar situations.
Then the requested information:
OS: Linux 5.10.0-33-amd64 #1 SMP Debian 5.10.226-1 (2024-10-03) x86_64
Shell: /bin/false
PHP binary: /usr/bin/php8.2
PHP version: 8.2.27
php.ini used: /etc/php/8.2/cli/php.ini
MySQL binary: /usr/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.5.26-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
SQL modes:
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /var/www/clients/client0/web54/web/wp-content/plugins/apcu-test
WP-CLI packages dir:
WP-CLI cache dir: /var/www/clients/client0/web54/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.11.0
APCu Manager 4.1.0 is running.
APCu is not activated for command-line.
WordPress object caching: enabled.
Garbage collector: disabled.
Analytics: enabled.
Metrics collation: disabled.
Logging support: no.
