[Resolved] 400 error on import from library

I reset the site which deactivated all plugins/cache etc.

… reinstalled the child-theme without a problem and no 404 message.

… reactivated the WP Redis and most of the sidebar and header/menu content disappeared.

… renamed the /wp-content/object-cache.php file /wp-content/@object-cache.php and the sidebar came back.

The problem exists at https://unlevel.co.uk/ on a fresh install with just WP-Redis, GP Premium and a GeneratePress child-theme enabled.

It seems the only way I can avoid this problem is to reinstall the site entirely, only without the WP Redis caching.

This is all done for me by EasyEngine/Docker…

== Installation ==

This assumes you have a PHP environment with the [required PhpRedis extension](https://github.com/phpredis/phpredis) and a working Redis server (e.g. Pantheon). WP Redis also works with Predis via [humanmade/wp-redis-predis-client](https://github.com/humanmade/wp-redis-predis-client).

1. Install <code>object-cache.php</code> to <code>wp-content/object-cache.php</code> with a symlink or by copying the file.
2. If you're not running on Pantheon, edit wp-config.php to add your cache credentials, e.g.:

        $redis_server = array(
            'host'     => '127.0.0.1',
            'port'     => 6379,
            'auth'     => '12345',
            'database' => 0, // Optionally use a specific numeric Redis database. Default is 0.
        );

3. Engage thrusters: you are now backing WP's Object Cache with Redis.
4. (Optional) To use the <code>wp redis</code> WP-CLI commands, activate the WP Redis plugin. No activation is necessary if you're solely using the object cache drop-in.
5. (Optional) To use the same Redis server with multiple, discreet WordPress installs, you can use the <code>WP_CACHE_KEY_SALT</code> constant to define a unique salt for each install.
6. (Optional) To use true cache groups, with the ability to delete all keys for a given group, register groups with <code>wp_cache_add_redis_hash_groups()</code>, or define the <code>WP_REDIS_USE_CACHE_GROUPS</code> constant to true to enable with all groups. However, when enabled, the expiration value is not respected because expiration on group keys isn't a feature supported by Redis.
7. (Optional) On an existing site previously using WordPress' transient cache, use WP-CLI to delete all (<code>%_transient_%</code>) transients from the options table: <code>wp transient delete-all</code>. WP Redis assumes responsibility for the transient cache.

== WP-CLI Commands ==

Its not possible to switch the caching off because its server-level, not site-level caching.

And even if were possible to switch off, the theme will not run correctly when it is switched back on.

EasyEngine installs Docker on the VPS, which in turn sets up the NginX and global Redis server which has a global cache shared by each of the sites.

The site’s WPRedis plugin only provides access to the global Redis server cache.

Because of the close integration, each site’s WPRedis plugin has to be installed and configured by Docker when it first creates each site.

Deactivating the WPRedis plugin makes no difference. I still get the 400 error on installing the child-theme and it won’t run correctly.

It doesn’t do it with any other theme I have used. It also doesn’t do it, for example, with plain vanilla GeneratePress together with Elementor.

It only exhibits this problem when I try to install all the clever stuff you have built into the Marketer child theme.

And as for the logs, the only thing I see that I don’t understand is this…