mike8040

Can’t edit anymore. While testing on the copy of the live site, I had to make the following interesting and very puzzling discoveries. The default settings for Analytics have always been:
Excluded statuses: completed
Actionable statuses: Processing, On hold
Date type: Date completed

Now, neither “clear analytics cache” nor “importing the historical data” has provided a solution (this issue seems to have started since 2024). As a test, I manually changed the status of an already completed order to completed again. Suddenly, this order appeared in the Analytics.

When I set “Date type” to “Date created,” the count of all completed orders matches the admin order list. When set “Date paid” only two are missing. So, what’s happening here?

Here are the observations when Date completed is set:

# 3 out of 4 gateways, such as the Default Wire Transfer, are no longer captured
# Failed to Completed transitions also seem to be missed
# Saving a completed status anew triggers Analytics recording again…
# When set to “Date paid” there are orders missing too even though orders that are from the very same day and same payment gateway are listed

• This reply was modified 1 year, 1 month ago by mike8040.
• This reply was modified 1 year, 1 month ago by mike8040.
• This reply was modified 1 year, 1 month ago by mike8040.

Super danke für die Rückmeldung. Die “übersetzung” der URL wird wohl nicht mit Polylang klappen aber per script k?nnte es klappen

Hi,
danke für die Rückmeldung. Das habe ich und nach dem thread habe ich die bislang leere und von Germanized gestellen Link durch die neue Variante ersetzt (Tracking URL Feld war bislang leer und die URL in den Mails ging bislang ohne Probleme).

Folgende URL funktioniert nun

https://www.deutschepost.de/de/s/sendungsverfolgung.html?piececode={tracking_id}

Nice to have w?re jetzt wohl für Kunden die über die Englische Seite bestellen und auch die Email in Englisch erhalten, diese auf die englische Statusseite zu leiten. Das language slug /de/ war in der alten DP Url variante nicht vorhanden.

Thanks. Well, I state you

However, these are just workarounds. The best solution would be to have a more structured URL pattern to prevent such issues.

and

This is a known behavior of WooCommerce, and it’s actually not a bug, but a feature to allow flexible URL structures.

I hope you get what I’m seeing here. This is nothing I invented nore am I able to change it. As I said this behavior is on a clean install of WP and WC.

You just said that the hole WC community, where are a lot of folks not even know what a stylesheet is, are enforced to fix the meaning of product categories for all search engines?

These pages are generated and in conjunction with templates like with Elementor and Bricks it is even getting less obvious why and how to tell search engine that this is a sane URL structure.

• This reply was modified 1 year, 2 months ago by mike8040.

Ok thanks for your response. The last question is unfortunately not clear

And second question. With add_filter(‘newsletter_enqueue_style’, ‘__return_false’); I can define a global style sheet just for the newsletter related elements (forms + welcome + emails), correct?

I do now about email styling is handled different. My outgoing emails have a brand styling and also the emails for forms do have one. I could style them accordingly. But I seem to not be able to style the newsletter emails. They miss a lot of basic layout features like an outer and inner container with different background color each.

Having the same question as this is the feature that stands out from others which basically is the only reason why I kept this plugin in use

Hi @julieadrienne. And as Till mentioned therefore one needs to delete /object-cache.php. Which I did and all the steps I think I already mentioned. The staging does not need Redis running. But I need a staging. Even going the route deleting /object-cache.php prior cloning and disabling Redis plugin on the clone afterwards lead to insane problems. The hole site structur was messed up. Contact page opend Blog page even though the url showed contact. Blog page content was gone. And so on…

I can not get any staging clone since Redis is active and installed. Page was running stable prior installing redis. Redis skrewed up something fundamental in combination of Chemicloud which is totally overwhelmed in my opinion (they just added Redis support a fews ago). Since even restoring a Softicoulus backup does not fix the DB problems produced from cloning, we have fear now to completely disabling Redis on the on the live site. We never seen such mess happening… The only rescue was a JetBackup which rolled back the issues. But Softicoulus Full backup did not and this is crazy as it seems entries were added that the restore did not touch.

Hello,

so I followed you instruction and deleted object-cache.php prior cloning. Then disabled redis on the staging clone and changed the redis database entry in wpconfig for the staging just to be sure. Then I activated redis on the live site again and the object-cache.php was created. The result was again a huge headache and mess.

Clicking on any linke (checkout, faqs or contact page) lead to a destroyed version of the blog page.

I made a full backup prior with Soficulous and restored it. I deleted the staging1 and flushed the LScache in Cpanel but the live site is still broken. This seems like a huge issue regarding Redis. How can I overcome this problem with Redis?

• This reply was modified 1 year, 4 months ago by mike8040.

Thanks for your response. Well the question was more if downward compatibility is still a sane task being only safari that is not decades apart from not knowing what webp is. A lot of devs/designer serve webp directly in the media files and there is no jpg files anymore where the <picture> tags is obsolete and saves quite some DOM size for pages with a lot of pictures. Like a shop archive page or artist porfolio

Well I follow the keep it simple approach. Softaculous 6 built in CPanel for the cloning process of WP installations. There is a subscription level terminal but I had no purpose to ever use it. So you saying just deleting wp-content/object-cache.php is enough and plugin can stay active prior cloning?

Yes sure. But the staging does not exits yet prior cloning so we can not set a different database in the Redis plugin of the staging or wpconfig when it doesn’t exist yet. The situation is like that. Live sites needs updates and needs to be cloned to be tested. Staging1 is empty. We clone it via Cpanel/Softicoulus. The mess starts. Since we could not even login as the headache happend we can’t go this route.

So now it looks like we need to decouple Redis prior cloning. Therefore my questions. Flush the cache & deactivate the Redis plugin prior to cloning or should it be deactivated in Cpanel for the hole domain?

• This reply was modified 1 year, 5 months ago by mike8040.

Yes it is strange for sure as I transferring thousands of orders, customers and products between two Wp installs without issue, but 1 product reviews creates such a hassle and does not work.

I get in touch with the support or try another import solution

Hey, thanks. Attached below is the test file. My hoster generated a new one through that plugin template. Since there is no error message starting importing, I see no point to attach a screenshot. The import hangs at 0% import status. I guess you know that screen.

https://easyupload.io/xtk2e7

Hello,

thanks for the response. Prior to posting here, me and also the hoster support had checked wp_debug logs. There are no issues and also no errors/warning in the developer console of chrome. That is the reason why my hoster was asking for a plugin debug option
We have used a 1kb csv done from the template with one review in it for testing.

There are deprecated warnings for CusRev:
[18-Sep-2023 12:22:52 UTC] PHP Deprecated: auto_detect_line_endings is deprecated in .../wp-content/plugins/customer-reviews-woocommerce/includes/import-export/class-cr-background-importer.php on line 378

[18-Sep-2023 12:22:21 UTC] PHP Deprecated: auto_detect_line_endings is deprecated in .../wp-content/plugins/customer-reviews-woocommerce/includes/import-export/class-cr-reviews-importer.php on line 193

• This reply was modified 1 year, 6 months ago by mike8040.
• This reply was modified 1 year, 6 months ago by mike8040.

Tats?chlich fehlte wp_woocommerce_gzd_shipmentmeta. Hatte unter den ganzen Tabellen übersehen. Hat geklappt und alle Sendungsinfos sind vorhanden