samwebdev

Update for the debug file:

https://ufile.io/qhi6m

Hello,

1.5.5.5 fixed the previous issue with admin css, however now the customer login is not working; it looks like redirect is not working for wp-admin for the front page login button as after clicking login:

https://website.com/wp-admin/images/spinner-2x.gif

this is the spinner url, which should be already replaced with

https://website.com/NEWURL/images/spinner-2x.gif

and the login fails for the customer.

Hello Eva,

Thanks, somehow it got deactivated during an update.

Regards,

Sam

Hello Eva,

Did you get a chance to check Cache Groups?

Regards,

Sam

Hello,

Any updates on this issue?

Regards

Hello tdgu,

Can confirm this solves issues with the Admin.

Sam

Hello Eva,

Thanks for the update.

When there is a single feed, it is fine, however as the number of feeds increase, even if set to daily, it puts a lot of constrains on the server.

It looks like every single feed would start approximately at the same time, so setting to refresh daily doesn’t actually solve the issue.

If you have say 5 feeds, they would all start around the same time.

The solution seems to get them start at different hours to refresh daily, such as:

Feed A:
Refresh Daily, start at 3 AM

Feed B:
Refresh Daily, start at 4 AM

etc.

This should solve the CPU issue.

What would be your take on the issue?

Regards,

Sam

Hello tdgu,

It was updated from the previous version.

> Can you clear any cache on your site (e.g. if use a cache plugin). Also do the same for the browser.

Caches are cleared, doesn’t work.

> Try to save the plugin options once to allow rewrite data to be re-created. Also check for a error message on top of page.

Couldn’t resave the options due to css failure. There are no errors on the page.

> From which version you updated?

Previous version, 1.5.5.

Might be related to update process ratter actual code, might fail for whatever reason.

It is definitely an error with the latest update.

Reinstalled the previous version, 1.5.5, it works flawlessly.

Hello Eva,

I guess the initial redis object cache version is rolled back; any info on when/how to solve the issue?

Sincerely,

Sam

Hello Eva,

Thanks for the update.

We cannot reliably test it, yet.

In order to test the object cache reliably, we go to cancel feed progress with redis off (there is an issue with this, as it doesn’t work all the time).

With the feed stopped, enable redis.

Then try to manually refresh the feed, there is an admin-ajax.php error:

;!function(){var t,e,n,o=0,u=function(t,e){return”function”!=typeof t||t.replaced?t:(e.replaced=!0,e)};if(“undefined”!=typeof CustomEvent&&”function”==typeof window.dispatchEvent){var r=function(t){try{if(“object”==typeof t&&(t=JSON.stringify(t)),”string”==typeof t)return window.dispatchEvent(new CustomEvent(“lprequeststart”,{detail:{data:t,requestID:++o}})),o}catch(t){}},s=function(t){try{window.dispatchEvent(new CustomEvent(“lprequestend”,{detail:t}))}catch(t){}};”undefined”!=typeof XMLHttpRequest&&XMLHttpRequest.prototype&&XMLHttpRequest.prototype.send&&(XMLHttpRequest.prototype.send=u(XMLHttpRequest.prototype.send,(n=XMLHttpRequest.prototype.send,function(t){var e=this,o=r(t);return o&&e.addEventListener(“loadend”,function(){s({requestID:o,statusCode:e.status})}),n.apply(e,arguments)}))),”function”==typeof fetch&&(fetch=u(fetch,(e=fetch,function(t,n){var o=r(n),u=e.apply(this,arguments);if(o){var c=function(t){s({requestID:o,statusCode:t&&t.status})};u.then(c).catch(c)}return u})));var c=function(t){return u(t,function(){try{this.dispatchEvent(new CustomEvent(“lpsubmit”))}catch(t){}return t.apply(this,arguments)})},i=function(){if(document&&document.forms&&document.forms.length>0)for(var t=0;t<document.forms.length;++t)document.forms[t].submit=c(document.forms[t].submit)};document&&”interactive”===document.readyState||”complete”===document.readyState?i():window.addEventListener(“DOMContentLoaded”,i,!0),Document.prototype.createElement=u(Document.prototype.createElement,(t=Document.prototype.createElement,function(){var e=t.apply(this,arguments);return e&&”FORM”===e.nodeName&&e.submit&&(e.submit=c(e.submit)),e}))}}();

Hello Eva,

Any updates on whether the cache group might be implemented to plugin?

It would most likely solve the issue.

Regards,
Sam

Thanks for the update Eva.

It was the only filter.

Will be testing filters with the new update.

Regards,

Sam

Hello Eva,

There is an option to not cache specific caching groups.

We do use it to not cache user sessions for Woocommerce. Woocommerce definitions are at:

WC_SESSION_CACHE_GROUP

class-woocommerce.php 214
$this->define( ‘WC_SESSION_CACHE_GROUP’, ‘wc_session_id’ );

class-woocommerce-helper.php 204
/**
* Gets a cache prefix. This is used in session names so the entire cache can be invalidated with 1 function call.
*
* @return string
*/
private function get_cache_prefix() {
return WC_Cache_Helper::get_cache_prefix( WC_SESSION_CACHE_GROUP );
}

etc.

defining this specific cache group to NOT cache:

define(‘WP_REDIS_IGNORED_GROUPS’, [‘WC_SESSION_CACHE_GROUP’]);

seems to solve the issue.

We might try and implement a similar logic for the Product Feed Pro, so the progress etc. will not be cached at the object cache.

Further checking the xml, it looks like the product resume/list that plugin saves and then tries to collect has an issue regarding the way its implemented, when it comes to object caching.

Please see:

https://ufile.io/oygfl

The progress shows about 6% complete.

After few minutes when we run cron, the file becomes:

https://ufile.io/q5962

As you can see, the last 400 products or so keep on repeating and added to xml file, while the progress is stuck at 6%.

So my take away is, the progress showing 6% is correct, as it has only processed about 6% of all products that are filtered.

Whats wrong is that the plugin does NOT resume from where its left, so somehow the progress status save/resume is not working along with the object cache.

Hope you can take a look at how this is saved and retrieved.

• This reply was modified 5 years, 10 months ago by samwebdev.

Hello eva,

Thanks for your response.

The caching plugin is:

https://www.ads-software.com/plugins/redis-cache/

It is not caching any files, so I don’t think it is related to
../wp-content/uploads/woo-product-feed-pro/xml/
../wp-content/uploads/woo-product-feed-pro/csv/
../wp-content/uploads/woo-product-feed-pro/txt/
../wp-content/uploads/woo-product-feed-pro/tsv/

The issue is regarding object caching, most likely how product information and xml process is requested and saved to the database by the plugin.

Furthermore, the product information do get updated fine with the caching plugin on.

I think its how the xml process/update is updated by the plugin.

When the object cache is disabled, the Product Feed plugin do update the process fine. However, when the object cache is enabled, the progress is stuck at 6%, while with each update, the xml file keeps on growing.