webwitnl
Forum Replies Created
-
Forum: Plugins
In reply to: [Mollie Payments for WooCommerce] Update TranslationsYes thank you, I’m not going to install a beta of a payment provider on production.
I’m worried that this is the tip you give to your customers…….
Forum: Plugins
In reply to: [Mollie Payments for WooCommerce] Update TranslationsThis bug is now unfixed for over a month. We have therefore decided to look around for a more professional payment provider.
Forum: Plugins
In reply to: [Mollie Payments for WooCommerce] Update TranslationsI read that Mollie won’t fix this in production for 3 weeks. Whatever manager or dev decided that, this is really, really bad, I have no words, except this amateurism scares me for a payment provider. Wow.
Like I said the variable products don’t use this plugin.
Here’s an example: https://www.wildewolf.nl/product/mergpijp-hond-met-rund-per-stuk/Your plugin changed the price at the top. It should only show the variation price (as it is now) below the select box of the variation, while the price range should stay at the top.
Even if the variable product would use your plugin, it should do this. I’d have to stop using your plugin if you fail to understand this. It is really weird to change it like this without any warning. I spend two hours to find what on earth broke our site.
It would also appear you didn’t develop or test this with the default woocommerce storefront theme.
Forum: Reviews
In reply to: [ShortPixel Adaptive Images - WebP, AVIF, CDN, Image Optimization] Fail- You don’t get it, our research was in response to Google search index errors. Yet you make blanket claims about SEO again. Perhaps you should do actual research before making claims.
- Expiration time is less than a couple of weeks, yesterday it threw everything out again after barely surviving one week. Tests with various viewports at various times show that more than 50% of the images are not optimized even after images should have been processed. It breaks your product. You break it to save on storage costs at the expense of your customers.
We don’t need support, we will no longer use your product.
Forum: Reviews
In reply to: [ShortPixel Adaptive Images - WebP, AVIF, CDN, Image Optimization] FailYou seem to lack awareness of the issues, while painfully redirecting me to the docs.
- If you go to google search console, grab a page and check the analysis, it shows multiple 307’s per image even if the image was already processed. To save energy while crawling, Google gives up external resources such as images, css and javascript after some point, in this case the point being an avalanche of 307 redirects. When you check the screenshot of how Google sees such a page, it’s incomplete. Have you ever tried it? It doesn’t seem to, it seems you don’t know this process and your SEO claims are void.
- I know how it is supposed to work. Images which have long been processed and served from the CDN for a certain viewport, are later redirected to the origin again as they no longer exist on the CDN. Even for my viewport, and as the creator all the images have already been seen on my viewport and have been processed, but later I get the originals again. Are you denying processed images are being expired after some time to save storage space? It breaks the whole premise. Why does your plugin not mention this expiry?
- Come on, if I have an original jpg of 2000×2000, the client wants a 1000×1000 avif and it isn’t there yet, but there is a previously processed 1500×1500 avif, it should use the last one, not the original jpg.
Sorry for the late reply, seems to work well! Thanks for the fix.
So I took a look myself, wp_parse_url is called by esc_url in formatting.php when the url contains a [ or ]. I logged the url when this is the case.
So if you go here:
https://www.wildewolf.nl/product-categorie/gezonde-hondensnacks/gedroogde-hondensnacks/
And then select a filter on the left, you get such urls.- This reply was modified 2 years, 1 month ago by webwitnl.
Latest versions of everything.
Note that parse_url is not called by burst but by wp-includes/formatting.php.
See the trace #2, /wp-content/plugins/burst-statistics/tracking/tracking.php calls esc_url_raw.
Forum: Plugins
In reply to: [Google for WooCommerce] Unit pricing measure and Unit pricing base measure“That’s great, let’s hope a lot of people upvote it so it gets some visibility.“
Yeah exactly. Love the free plugin and I have no complaints, but I now realize I have to look into a pro one.
Forum: Plugins
In reply to: [Google for WooCommerce] Unit pricing measure and Unit pricing base measureThanks, copy&pasted. I don’t have high hopes for this 🙁
Forum: Reviews
In reply to: [Mollie Payments for WooCommerce] Crashes browser, Mollie does nothingHi, I “solved” this with help of Mollie support, although the core problem is still there. What made the problem go away was to deactivate the “Mollie components” in the settings for credit cards payments.
With this deactivated, when someone chooses to pay by creditcard, the details are entered after order confirmation on the Mollie pages. When activated, you enter it on the shop’s order confirmation page.
There, this component is an iframe which loads lots of javascript and css, and reloads at every form change event (which can be a lot). This caused the crashes.
Forum: Reviews
In reply to: [Yoast SEO - Advanced SEO with real-time guidance and built-in AI] LimitedI already tried support by email.
A quick search and audit of the code makes it obvious the bug is in the Yoast Premium redirect code, which is very badly written. Apparently it caches stuff. And for reasons unknown (incompetence?) it is very liberal in throwing 404’s about without any warning or logging when it can’t figure stuff out like a corrupt cache.
So you keep a cache of redirects, and when it thinks it’s corrupted, it breaks the site instead of clearing the cache. It’s a very bad and lazy design choice to add a redirect layer and process all urls and then liberally throw 404’s when it can’t figure stuff out. You really can’t do that. But you do. Someone needs to look deep into the eyes of the person who wrote that.
Looks fixed! It was 2023-02-03 23:10 CET and without the patch it made calls to the backend like this:
/wp-json/burst/v1/data/today?date_start=2023-02-04&date_end=2023-02-04&date_range=etc.
After it it is like this and it works properly:
/wp-json/burst/v1/data/today?date_start=2023-02-03&date_end=2023-02-03&date_range=etc.