the.rampage.rado

Check if mod_rewrite is on.

The code looks proper. In any case there is some local issue as the regeneration and the rewrite as a whole works with at least few installations (including mine 3 production installs and 2 test installs).

Nearly everything is possible - matter of manpower and money. 😞

If your sender address is different from the one you use to actually send it every modern email provider will flag this as spam and will refuse to deliver it in most of the time.

This is saved in Preferences->Shop Contacts. This setting is multistore aware so if you use Multistore you have to have different email per domain here otherwise you will be flagged as spam.

Sorry for the late response. The original file is kept without additional attributes: Check which pic ID error out and download and check their files. There was before similar issue here after the image rewrite and in this case the source images were somehow corrupted on the server. If this is not the case I'm afraid you will have to wait for datakick for advise. 😕

1. Install one of the modules (not both as you can't use them simultaneously) and configure it: 2. Go to Advanced Parameters -> Email and choose the module you installed. (here I have another useful module installed so don't get confused, if you use it you have to run both one of the transport modules and the Queue module): 3. Send test email. If the mail don't arrive your module configuration is not OK.

Sorry to hear that! 😞 https://github.com/friends-of-presta/security-advisories/blob/main/_posts/2024-02-29-simpleimportproduct.md Unfortunately this happens, no system is 100% secure. The remedy is regular updates of core and all modules to the latest versions.

Yes, the url is different now. Can you check if your active htaccess file contains (when on edge of course) contains lines as: RewriteRule ^products/([0-9])(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.$4 [L] RewriteRule ^products/([0-9])([0-9])(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.$5 [L] RewriteRule ^products/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.$6 [L] etc.. which are responsible for this rewrite.

Do you have the source files in the respective directory before the regeneration starts?

When you update to edge you are seeing the image rewrite that will be part of the next major version. Steps to have no issues: 1. update to edge - both your files and database. 2. Go to Images and set your settings - preferred image format - better use webp as png does not have any improvement over webp. Select Image quality (this will be empty on your first update, if you now update again it will be populated BUT I'm not sure if this can be 0 (as the quality is from 1 to 100, 100 being ze best quality, 70 is recommended). Decide if you want to keep the original file in Source file extension. The rest is not important. Save. 3. On the top of this page you should see additional table column named Image Entities - each row should have entries as this assigns the usage of each generated file. This should be populated correctly if you updated just yesterday, as there was a bug bug this is now fixed in edge. 4. Reset indexation status on all image types (bottom of the page). Regenerate all images - wait for this to complete, don't leave the page. 5. Go to SEO & URLs and turn OFF friendly URLs, save, then turn it back ON (if you use friendly URLs as you should). This will regenerate the part of your htaccess file that serves the images as there is change too. 6. Clear your Cache and open your frontend - now if your theme is coded right you should see your images once again - smaller, optimized and better than ever before. If you don't see them check your theme and/or modules if they look for hardcoded jpg files. My theme did for some image types and the changes was pretty simple, just stick to a file format and swap the extension in the code. Keep in mind that this image rewrite handles pretty much every image on your shop (except the favicon) and whenever you have hardcoded .jpg you will have to fix this - theme, shop logo, custom menu module, custom layered navigation module, manufacturer logos, attribute textures, etc. 7. Additionally go to your Sitemap module (update it first to the last version). Select the proper image formats that should be included (this is new functionality) then save and regenerate your sitemap(s). (this is not directly related to your issue but should be done after the update to optimize your results as the sitemaps will include the new URLs for the images) Get back to us if you managed to get it working and if not we will try to help again! 😉

Today I tried making a query that sorts the products by last edit date using date_upd column. The issue is that this value gets changed even if we save other products in the same category (lets say changing the position in the category). My use case is that I have couple of categories that I want to manually (i don't have a automatic way to do so) edit (stock and combinations) and I want an option to sort those products so I start from the one that is updated furthest back in time so not to loose hours on repetitive work and (sort of) keep this list of products optimized. Could there be any workarounds around that?

There is a thread dedicated to this product. Probably you should ask there?

Despite that worked go in Core updater, configure it to update to your tb version and your php version and check if there are any file changes.

@datakick will make the update but I hope to receive couple more entries.

First of all check with your hosting what changes they made to the environment and 98% this will give you a clue how to proceed. If they say there are no changes you can look into your server error log there you will find the reason for this crash. In general it's strongly recommended to update from 1.3 to at least 1.5.1 as there are many security hole fixes since 1.3.

I updated almost 1 month ago and I see no difference in the sales. I see an increase but this is not because of this change, this it is offseason for me. Domain authority is much more important. Even if you change your product URLs those will get fixed really quickly in google's index if your domain has good authority. For images - do you have statistics how much visitors you get directly from image search?

When you updated the file format was probably emtpy: You will have to select one of them (they are all supported by Niara (recent versions of the theme)). Then save. Then you will have to reset your indexation status for all types and regenerate all types: Clear cache and check if they show up on both places.

Since 1.5.1 there is a huge image section rewrite, nearly everything regarding to images is redone so you will have to give little bit more details - where they disappeared, what theme are you using, little something to work with... Regarding the duplication issues - you can go to github and search for commits that mention product duplication issues and apply the fixes manually to your install if you're not planning to rolling back to edge soon.

bleeding edge channel is 99.9% production ready as datakick makes the commits there and everything is tested before. So if it is the only issue you have with it you can backup your store and try. I only roll my shops on bleeding.

For the social icons - uninstall the sharing module: The print link has to be deleted/commented in product.tpl in your theme. Regarding the stock counter - probably the same as above as I don't see where to configure this in Niara/Community theme (if you use one of those). Some themes have this as a switch.

@datakick can you reproduce the following steps? 1. Install native thirty bees layered module in multistore. 2. During installation all indexes are obviously build and table XXX_layered_product_attribute is populated correctly with all combinations for all shops 3. Rebuild attribute index with the button. Expected result: 1. XXX_layered_product_attribute should contain all combinations for all shops (depending on association of course). Current result with edge test installation: 1. XXX_layered_product_attribute contain only combinations for shop id 1. This is with the native thirty bees and uninstalled the modded module from above (which uses the same table names) in my test instance where I have only 2 shops. If I click on the button I have to reinstall the module to reindex and never touch this button. All other buttons seem to work correctly (or at least they don't mess anything I can see).

Hi guys/gals, if somebody can give an idea it will be greatly appreciated. I run multistore installation and I have 6 shops. Everything was working OK until recently - all products were displayed properly using the LNM filters in all shops. I'm sure because I did lot of work with the color filter in the additional shops where I added many clothing items and all of them have color combinations. Yesterday I noticed that only the color filter does not display in all non default shops. Then I saw that this applies for size too (generally all attribute filters, only the feature filters are visible in the addon shops). Here are the things I tried: - reindex all LNM indexes - reinstall the module - I had filter templates based on each shop - the issue presented with this setup. Then I removed them and made new template for all shops and all categories - no bueno. - in despair tried changing the button type of the color filter - as expected no effect 🙂 - checked all shop associations - in attributes (group and each attribute), in LNM - everything is associated with every shop. - tried regenerating the indexes in all shops context and in each one context - no affect (even not sure if LNM cares about this). When reindexing I noticed that the price index takes much longer than the attribute index and this led me to check the code and then the db. This is where I think I have some issue. In table XXX_layered_product_attribute I only have records with shop id 1. Because I use the modded version of the module that was part once of PS1.6.1.24 and comes with Warehouse theme I use I compared the indexAttribute function and they are 1:1 with the most current TB version of the module. XXX_layered_price_index has all shop ids. Any input will be greatly appreciated! Am I missing something? As this is my production instance and I can't replicate this issue on my test setup I am unable to test with TB native module currently. TB version: edge as of today

There's a similar error recently here: datakick recommended to update to 1.5.1 and check if this error continues. You don't have to reindex after every new product for sure.