Nginx PageSpeed Wordpress Nginx PageSpeed WordPress with Redis Cache

Spinned up a new fresh droplet and set it up with all default. Used ./centmin.sh menu 22 - 1 and set up some domains.
For testing purposes I comment out the wp_updater on a domain and on the other domain I did not comment it out.
Before I got the email that the wp_updater ran on the domain was intact, nothing happened with the data, I checked it a lot of times. Directly after I received the email I checked the site and the theme data was gone again.

---

The domain where I commented out the wp_updater is still the same, nothing changed.
I tried to track down why this happened, but I couldn't find anything.

@eva2000 Now it is clear to me that when the wp_updater runs the theme data gets lost. I need some tips on how to track down what happend, maybe a unknow bug. If nessesary I can give you access to have a look.

 

Finally, I had time and found it. Was a little bit busy today with the bad-bot blocker on https://community.centminmod.com/threads/nginx-ultimate-bad-block-blocker.14413/

When the wp_updater calls it happens

Code:

# /usr/bin/wp plugin status --allow-root
7 installed plugins:
  A autoptimize         2.4.4
  A cache-enabler       1.3.3
  A cdn-enabler         1.0.8
  A disable-xml-rpc     1.0.1
  A mythemeshop-connect 2.0.14
  A sucuri-scanner      1.8.20
  D advanced-cache.php

Legend: A = Active, D = Drop-In

I had a quick look at the huge /usr/bin/wp file and it has several MySQL functions and the warning to be careful to run it as root.

I tested it several times to be sure about it.

The content of the wp_updater

Code:

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin:/bin
EMAIL=me@outlook.com
EMAILFROM=me@outlook.com
DT=$(date +"%d%m%y-%H%M%S")

{
cd /home/nginx/domains/domain.com/public
echo "/home/nginx/domains/domain.com/public"
#/usr/bin/wp cli update --allow-root
echo "update wp-cli"
rm -rf /usr/bin/wp
wget -4cnv --no-check-certificate https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -O /usr/bin/wp --tries=3
chmod 0700 /usr/bin/wp
/usr/bin/wp --info --allow-root
/usr/bin/wp plugin status --allow-root
/usr/bin/wp plugin update --all --allow-root | tee .wpcli-status
#/usr/bin/wp core check-update --allow-root

# for major core updates uncomment 3 lines directly below
#/usr/bin/wp core update --allow-root
#/usr/bin/wp core update-db --allow-root
#/usr/bin/wp core update --allow-root

# for minor core updates uncomment 3 lines directly below
#/usr/bin/wp core update --minor --allow-root
#/usr/bin/wp core update-db --allow-root
#/usr/bin/wp core update --minor --allow-root

chown -R nginx:nginx /home/nginx/domains/domain.com/public
if [[ -f .wpcli-status && ! "$(grep -w 'Plugin already updated' .wpcli-status)" ]]; then
  exec 99>/tmp/wp_updater_phpfpm.lock
  if flock -n -x 99; then
    # only do nginx + php-fpm restarts when zend opcache caching is enabled and revalidation
    # frequency is greater than 10 seconds set by opcache.revalidate_freq php setting
    if [[ "$(php --ri "Zend Opcache" >/dev/null 2>&1; echo $?)" -eq '0' && "$(php --ri "Zend Opcache" | awk '/opcache.revalidate_freq/ {print $3}')" -gt '10' ]]; then
      service nginx reload
    fi
  rm -rf /tmp/wp_updater_phpfpm.lock
  else
  echo "already detected running process"
  echo "skipping nginx reload"
  fi
fi
rm -rf .wpcli-status
} 2>&1 | tee /home/nginx/domains/domain.com/log/wp_updater-${DT}.log
cat -v /home/nginx/domains/domain.com/log/wp_updater-${DT}.log | /usr/bin/tr -cd '\11\12\15\40-\176' | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" | dos2unix$
#rm -rf /home/nginx/domains/domain.com/log/wp_updater-${DT}.log

 

Yes, confimed. That triggers it.

Will ask the wp-cli folks what can be the cause of it.

 

Sorry, didn't see that you asked but to confirm

Code (Text):

cd /home/nginx/domains/domain.com/public
/usr/bin/wp plugin status --allow-root

 

Done.

/usr/bin/wp plugin status --allow-root wipes theme data · Issue #5124 · wp-cli/wp-cli

 

Well, guess I can't use wp-cli. Just got their response and they closed the issue.

 

Just tested it but it already happens with /usr/bin/wp plugin status.

Code (Text):

/usr/bin/wp plugin status --exclude=mythemeshop-connect --allow-root
/usr/bin/wp plugin update --all --exclude=mythemeshop-connect --allow-root | tee .wpcli-status

But getting an error on the wp plugin status so I commented out that line

Code (Text):

#/usr/bin/wp plugin status --exclude=mythemeshop-connect --allow-root
/usr/bin/wp plugin update --all --exclude=mythemeshop-connect --allow-root | tee .wpcli-status

No error, but still missing the theme data.
So adding the

Code (Text):

/usr/bin/wp plugin update --all --exclude=mythemeshop-connect --allow-root | tee .wpcli-

Wont resolve this issue.

EDIT:

The mythemeshop-connect plugin updates and warns if there are any plugins from mythemeshop that needs to be updated.

 

I already did that and they wanted access and I granted access to the WP login. They had a look 2 times on my request and also told me that this was not their problem. So they won't invest time to resolve it. Throwing the ball back to Centmin mod.

 

Yup, that was my conclusion also. Without the mythemeshop-connect plugin, the theme does not work. It verifies if you have a license for it.

 

@eva2000 I don't give up easy, so here we go again. Still strugging with the theme and the support gave me an idea.

Today we found that only the theme that I use has this problem.

The Idea was to put this, it works but has side effects for other users..No more updates on themes

Code (Text):

wp plugin status --allow-root --skip-themes

But that would be no good so because nobody gets their themes updated so a suggestion to add the exclusion below. It should work I think.

Code (Text):

wp plugin status --allow-root --skip-themes=mts_coupon

If you have some spare time, please take a look at it.