the.rampage.rado

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.

If it was a module/core issue everybody would have this. 😕

You'll have to install module Block Categories. By default TB (and PS in that matter) does not show categories to a set place. You can configure this module and place it where you want (left/right column, etc.) Same with Top menu - it does not automatically display categories if you don't configure it to do so.

@datakick today I decided to check this module and it was showing this: (note: all images are there when I check them and all of them were uploaded after the image rewrite update). Can you replicate this or I messed something up again on my local setup? 🙂

There is no need to migrate your shop. Core updater takes care of your files and db (if you think there are corrupted ones, etc.) You have to check what is causing this issue. Check if your shop is configured to run on the server php version (in Core updater -> Settings set 'server version' and update channel to Stable). Then check if you have some changed files when you compare your install to 1.4 in the module. Also if you don't have (as you don't know what this is) it is VITAL for debugging to have this module installed at all times: It collects nearly all errors, notices, warnings, etc. your shop produce so you can solve them. Nobody can help if there is no additional information on the core issue.

I bet on some server issue. In any case this generic information is not enough to troubleshoot. Is there anything in your Error log module?

You can update to edge (simplest) or update your files as follows: https://github.com/thirtybees/thirtybees/commit/e89c365731d095d971038d21d2e0310833e469b9 Regarding the discovered pages in the Search Console - I'm curious if they can be removed or should we leave them as is?

1. It's a known bug, some other parts are not duplicated also. 2. Are you copying products that have Specific price rules attached to them?

I can't help for the PP issue but couple of notes: 1. Don't run your on Force compilation, this makes it slow. Run it on 'Recompile templates if the files have been updated' which is the golden standard in terms of speed and trouble-free operation. 2. After the recent image rewrite there are many new things going on in Images. You have to go to Images section, choose what format you want to use (best are webp and avif (if you are on php8.1 or later), select your quality (90 for best quality, 70 for good balance or less for speedy shop but lower quality images - see this post from datakick - https://forum.thirtybees.com/topic/6608-image-format-webp-vs-avif/#comment-49265 ). Then reset (reset, not delete!) your tumbnails and regenerate all of them. Don't close this page until the process complete. Then you will have to clear your cache and you should see all your images back online with no issues. If not - hard refresh the page in your browser (ctrl + F5 on win). 3. Regenerate your htaccess through SEO & URLs - switch Friendly URLs off, save and then back on and save.