Forum Replies Created
-
AuthorPosts
-
Hi @guenter,
thanks for the update. Let’s see if the errors mentioned in this thread will be fixed with the next update. I will test the update on our Stage system as soon as it has been released and will report accordingly.Thanks.
Hi @ismael,
Have you tried disabling the theme before doing the flush? Activate it back once the flush is done.
If
wp cache flush
is executed on the target host, the new release has already been activated. It is therefore not possible to disable the theme, as it cannot be ruled out that visitors are already on the site.The right approach to this problem would be to ensure that Enfold works in professional environments. The use of WP-CLI is a de facto standard and when developing new features or fix existing ones it is therefore important to ensure that WP-CLI commands do not generate PHP errors.
I hope your developers understand how important it is to provide a theme for professional use.
Thanks.Hi @ismael,
Are you using a bash deployment script?
Our deployment setup looks as follows:
- WordPress core, free and paid plugins and the theme are managed by Composer using WP Starter v3 (paid plugins and the theme are distributed by a custom SatisPress instance)
- The root “website repository” only contains the
composer.json
andcomposer.lock
files (simply put) - Pushing code changes of the website repository to our VCS (currently private Bitbucket repositories) will trigger a build in Codeship
- In the Codeship build, Composer installs the project
- The complete project will then be shipped to the target host by Deployer using rsync
- Using custom Deployer steps, we execute various commands on the target system before and after shipping, among them are some WP-CLI commands
One of these steps is
wp cache flush
which fails on the latest Enfold version with the error described in my previous post.To fix that issue, please edit the file mentioned in the stack trace and look for this code around line 190.
Even if it is possible to patch packages with composer-patches, I don’t want to. As soon as even one character in the to be patched code changes, it will fail. This means that we’d have to check whether the patch still applies every time there’s a theme update.
Instead, you should change that line in the code and release the fix in a future update.For the fatal error, try to add this code in the
functions.php
file temporarily before doing the flush.This is not doable because this would require code changes before and after executing the command. Finding the root cause for this and fixing it on your side also applies here.
Thanks.
The command
wp cache flush
alone triggers ~50 identical messagesWhat kind of values are you saving in the cache object? And what kinds of errors are you getting from using the
wp cache flush
command?This is the output of
wp cache flush
that is called during our deployment (Enfold v4.6.3.1):Warning: Illegal string offset 'product_gallery' in /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/config-woocommerce/config.php on line 190 Warning: Cannot assign an empty string to a string offset in /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/config-woocommerce/config.php on line 190 Warning: Illegal string offset 'product_gallery' in /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/config-woocommerce/config.php on line 193
I no longer get the notices the OP (@oneskysandy) described though. They seem to have been fixed.
However, in addition to the warnings mentioned above, the theme generates a fatal error when
wp cache flush
is called, which causes the deployment to fail:Fatal error: Uncaught Error: Call to a member function reset_options() on null in /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/functions-enfold.php:1844 Stack trace: #0 /path/to/project/deploy/releases/45/public/wp/wp-includes/class-wp-hook.php(288): avia_generate_stylesheet('') #1 /path/to/project/deploy/releases/45/public/wp/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters('', Array) #2 /path/to/project/deploy/releases/45/public/wp/wp-includes/plugin.php(478): WP_Hook->do_action(Array) #3 /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/framework/php/function-set-avia-backend.php(91): do_action('ava_after_theme...') #4 /path/to/project/deploy/releases/45/public/wp/wp-includes/class-wp-hook.php(288): avia_update_helper->update_version('') #5 /path/to/project/deploy/releases/45/public/wp/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters(NULL, Array) #6 /path/to/project/deploy/releases/45/public/wp/wp-includes/plugin.php(478): WP_Hook->do_action(A in /path/to/project/deploy/releases/45/public/wp-content/themes/enfold/functions-enfold.php on line 1844
I don’t think it’s much to worry about since they are only notices, they’re not really errors so to say.
I can’t believe I’m really reading this. These notices clutter our logs with rubbish. The command
wp cache flush
alone triggers ~50 identical messages (amongst other warnings and notices of unfixed bugs in Enfold).they’re not really errors so to say.
Of course these notices are errors. They are triggered by bugs that must be fixed. Which developer ignores PHP notices?
The use of WP-CLI is standard for developers who work professionally (and I thought you do). It frightens me that you don’t seem to be using it.
</rant>
Excuse this rant (please don’t take it personally), but I’m quite upset about your opinion. -
AuthorPosts