wwdadmin

Thanks for the reply. It is indeed an updraft clone issue. Ran the same test to another website copy of Live and it worked as expected. Used the media sync plugin to run a check and all 1904 images are there/connected. Thanks for the support.

Thanks. Ideally we do normally take an entire clone. As you say, it’s the safest way. But in this instance it wasn’t possible due to 3Gb of images and the hosting the site is on. The clone never completes. I have a ticket open with Updraft. But they are not being very helpful sadly. I’m going to see if I can get a local clone done by the hosting company and do some tests on there to try and understand why this is happening. When I have some more specific details I’ll post up. As it’s a live site we can’t leave the site running with no images so had to go back to backup.

It’s not resolved no….
It’s outstanding. But you insist on paying for premium support which I’ve now had to do as Avada are insisting it’s your code and you are saying we have to login and will only resolve via paid support.

Hi, I don’t think you read my message correctly.

I did run the WP-CLI. and it core dumped. Please see above.
And this was on a different host.

So just to make this clear.

1. We cloned the site to our own VPS where we have root.
2. reset data via the Test Plugin.
3. GUI fails with 404 error.
4. reset data via the Test Plugin.
5. Run WP-CLI and it core dumps.

Also on the same server, we have many WP installs with no issues and we can run the SEO optimisation from within the plugin no problem. They all use Avada also.
So it’s something environmental to this one db install. The posts and posts meta tables are huge btw.

I have now cloned the site to our own hosted VPS with root access.
1st I cannot run the indexing from the gui due to 404 error.
yoast {“code”:”rest_no_route”,”message”:”no route was found matching the url and request method.”,”data”:{“status”:404}}
anyhow I ran the test reset and then from the cli.
this time:

[hasol@server perma.hasolutions.co.uk]$ wp yoast index
Indexing posts  100% [=======================================================================================================] 0:59 / 0:57
Indexing terms  100% [=======================================================================================================] 0:09 / 0:50
Indexing post type archives  100% [==========================================================================================] 0:01 / 0:00
Indexing general objects  100% [=============================================================================================] 0:00 / 0:00
Indexing post links  20 % [===================>                                                                            ] 0:26  / 14:49Segmentation fault (core dumped)
[hasol@server perma.hasolutions.co.uk]$

There is a core dump.

What do you suggest next?

In discussions with the hosting company still. should get SSH access soon hopefully and will try the CLI to see if it repros again.

” that would resolve the issue.”
Here’s the issue though. We have 100’s of pages that are then corrupted.
Perhaps 200 or more. Imagine how long it takes to go through 200 pages and hit update on every single one. Ok it resolves your table maybe. But how long before it then happens again.
Avada lay the blame 100% with your code and say it tough luck really.
Simply cannot afford the time to have to repair these pages. Once was bad enough, twice pretty horrendous but 3 times too much so removed your software and tables and will look for an alternative until we know this won’t be repeated.

ok thanks, we had to remove the tables. as couldn’t risk another 3rd occurrence of data loss/corruption. We are going to clone the site across to another instance pre-corruption and try and repro the problem. Will keep you posted so please keep ticket open.

This is the same problem I both had and still have. So on one site it was due to the WooCommerce admin running a cron task that appeared to do a full purge of the cache.
On another site I don’t have WooCommerce admin installed and it’s also doing it.
So you are not alone.

Chris

Update
======
Woocommerce Admin Plugin appears to be the culprit for flushed/purged cache.
Preload run: 5.12pm on 02/02/20
Cache still there. longest it has stayed there.
Need to check preload schedule now.
this is common with the other reported case.
Doesn’t explain my other site which doesn’t have woo installed but at least looking at wp-cron seems to be the right area to look into.

Chris

Hi Marc,

Yes, if I purge the cache and do a manual preload it does indeed work.
Then we get back to the problem whereby it gets purged.
I’m thinking this is a bit sporadic (purging). So my thinking is perhaps leaning towards WP Crontab.
When I looked there are so many scheduled tasks I was quite surprised. Then I found the plugin WooCommerce Admin running a task every hour with 2000 entries in the log/posts table. I’ve now removed these and deactivated the plugin.

Thanks,
Chris

Hi Marc,

Maybe I misunderstood your UI then?

Page Cache page:

Cache Settings.
Cache Lifespan = 4 hours

Preload now page:

Schedule Preloader settings
Ticked activate scheduled cache preloading
Select schedule type = same as cache lifespan

To me that says cache TTL is 4 hours and once expired run the preload again. No?

Thanks,
Chris

Hi Marc,

Ok, so I’ve set preload schedule on to run every 4 hrs to see what happens and in the error log I get:

[30-Jan-2020 19:35:23 UTC] [INFO] : 117 urls found.
[30-Jan-2020 19:35:23 UTC] [INFO] : Creating tasks for preload site urls.
[30-Jan-2020 19:35:23 UTC] [INFO] : Tasks for preload site urls created.
[30-Jan-2020 19:35:23 UTC] [INFO] : The queue for tasks of type “load-url-task” is empty. Aborting!
[30-Jan-2020 23:15:47 UTC] [INFO] : 117 urls found.
[30-Jan-2020 23:15:47 UTC] [INFO] : Creating tasks for preload site urls.
[30-Jan-2020 23:15:47 UTC] [INFO] : Tasks for preload site urls created.
[30-Jan-2020 23:15:47 UTC] [INFO] : The queue for tasks of type “load-url-task” is empty. Aborting!
[31-Jan-2020 02:57:37 UTC] [INFO] : 117 urls found.
[31-Jan-2020 02:57:37 UTC] [INFO] : Creating tasks for preload site urls.
[31-Jan-2020 02:57:37 UTC] [INFO] : Tasks for preload site urls created.
[31-Jan-2020 02:57:37 UTC] [INFO] : The queue for tasks of type “load-url-task” is empty. Aborting!
[31-Jan-2020 06:36:50 UTC] [INFO] : 117 urls found.
[31-Jan-2020 06:36:50 UTC] [INFO] : Creating tasks for preload site urls.
[31-Jan-2020 06:36:50 UTC] [INFO] : Tasks for preload site urls created.
[31-Jan-2020 06:36:50 UTC] [INFO] : The queue for tasks of type “load-url-task” is empty. Aborting!
[31-Jan-2020 10:49:26 UTC] [INFO] : 117 urls found.
[31-Jan-2020 10:49:26 UTC] [INFO] : Creating tasks for preload site urls.
[31-Jan-2020 10:49:26 UTC] [INFO] : Tasks for preload site urls created.
[31-Jan-2020 10:49:26 UTC] [INFO] : The queue for tasks of type “load-url-task” is empty. Aborting!

Any ideas? I thought I could temporarily w/a the problem by preloading it more often.
So something wrong here surely?

Thanks,
Chris

Hi,

Update for you.
The theme options for performance I mentioned had little to no effect as the cache was deleted/purged again when I checked 1st thing this morning.

What is strange also is that I have iThemes security plugin installed. It logs file changes/deletions/adding. So when I cleared out and turned off the fusion cache in avada this was all logged. As was the adding of the cache files by wpo.
The removal of the cache however wasn’t logged.

The only plugins that are shared with mrohnstock are:
Contact Form 7 v5.1.6
WooCommerce v3.9.1
WooCommerce Admin v0.24.0
Yoast SEO v12.9.1

Theme is completely different, mine being Avada.

Next step then is to try the logging.

Our host is our own VPS. I don’t know what would cause this behaviour as it’s nothing unusual. And as mentioned before we have 10 sites with WPO.

It does seem to be linked with the more active sites in terms of content being changed.

Chris

Thanks,
Chris