the.rampage.rado

@datakick - speaking of 8.1 compatibility - do you offer site audit for installed theme/modules? I have few bugs here and there, few notifications and warnings that I want to iron out. Not many third party modules. Theme - Warehouse.

Can't wait for the new modules!

As I said I was rocking it since PS times and I didn't really look if TB uses imagick natively or not. Whatever... When removed the webp files generate and show properly.

I had it since my shops were on PS but I removed it and now everything regarding webp is working fine. Few places in Warehouse where the modules call .jpg files but....

After disabling the module the size of 70% webp is 1/4 of the 90% jpeg. Obviously the module has some overrides that conflict with the latest functionality. If anybody can 'heal' content creator module to use the webp version please send me a message with the fix!

I'm running on the lates edge from 2 days ago (after the webp commit). Could it be that the culprit is the imagick module from M Dekker?

Another stupid question from my side: Is it normal for them to have absolutely the same size? I had the webp on 90, but I saw that there's an improvement at around 70 and regenerated them again but I think this is really strange...

Thanks for the elaboration. Will look into it with my host!

I believe I'm not understanding what you mean. My issue is not that they show in front end to the customer, my issue is that they don't show up here: Some of my products differ only by tiny details (I can imagine it's not me in this siuation) and if a merchant's employee is not very familiar with differences in the products and can't enlarge this during order preparation this could lead to troubles. I'm in the same boat as you that the original images should not be visible in FO or by bots or scrapers, but they should be visible in BO (or at least let's make BO use some of the larger thumbnails with watermark) and keep the originals for regeneration only.

Just updated the store to edge and did the same checks again - some items worked but most gave 403 for the product images. I moved the watermark code to the end and now every image loads in BO->Products. The save 403 issue in SEO persist no matter if I disable mod_security in htaccess or not (obviously forbidden by my host).

@datakick, today at work I saw your fixes in the module and it was one of the first tasks today to update and check if it works. Unfortunately when the module code is added to the front of htaccess file it gives again the same 403 in product images. But if I move it to the end of the htaccess file they are working fine. The issue with 403 in SEO settings save is persistent. And by just testing it twice I got locked out by modsecurity. What settings are triggering it and what is the issue that makes the pictures work only when placed at the end of the file?

What do you mean by 'uploading images with the old name'? Your product image descriptions include your last domain?

In the end did you receive such fraud payment or they simply said 'i can do this!'?

Do you have stock available for this product. This is a strange bug. Please, share screens from BO and FO!

I think this issue was .htaccess related. Today I noticed that all my images are gone (no changes from my site, probably something from the host) and I deleted and made new .htaccess file. Now it works. Also the original file was not shown in the section in BO. Cleared all caches and everything is OK once again.

Same here. PHP7.4 Litespeed server

Does editing the source code at the checkout page and sending a screenshot to the merchant count? 😄 😄 😄

Same here, not a pain in the ..... but it was working few minor versions ago..

How would you ban by mac address from your shop? 😄

The first issue is not an issue if you have not manually modified them - just update. The second issue is caused by the cache probably. If you click update the first reload might show the old version? They updare corectly or not?

Please, tell me you have barcode scanner with the camera and then stock check option using it and I'll love you! :)

Are you comparing your dashboard stats to G Analytics? If so, please update to the latest edge version and you should see a decrease in the dashboard stats because they used an old mechanism to detect if certain visitor is bot or not. If your site is newer it's normal to have lower conversion 1 sale in 42 real vistits is not bad for start. Of course as a sidenote I would say that high drop rate might be caused by many things and you must observe for patterns.

@smile - can you elaborate on that a little bit? So you're planning an app that sync with our shop so picking and warehousing is easier? If so I have few ideas.

I mean under BO-Preferences-SEO. But this is very strange 'fix'. Probably you had some misconfig in .htaccess and swiching SSL overwrote those rows there. If you have any further questions we will be glad to answer (if we can)! 😉