Scully

I feel sorry to have learned lately that Datakick quit the TB project.

Sad to read this news from Datakick a little late. I can unterstand him. I spent around 3 years in contributing to Prestashop and saw the downsides there. Little appreciation from the community and even less than little money. So I would be willing to pay some fix fees. I would vote for flexible rates, not all TB users might be able to throw a $50 per month. best regards,

Hello Datakick, I recently installed the black hole module. It works during testing but it haven't trapped any bot so far. I am just guessing: Might it bee that the robots learn quickly about traps, expecially if the trap URI is fix? And then: might it be an option to generate a random URI? I though I am familiar with PHP I couln't make out where the /blackhole/ URI comes from. Is it the directory within the module path or is it in the code? Yes I found the "getTrapUrl" function but changing code there didn't work as expected. Best regards and thank you for your work. Scully

What is difficult in reading the prestashop post and apply it in similar manner in thirtybees? First you need a CSS class. In the example its name is graypicture This is responsible for the CSS formatting of images in grayscale. It is not an existing class in TB, so you need to add it to your global.css. Plenty of web pages out there explain how this CSS rule must look like. Then you need to add a condition to the file product-list-item.tpl This code from the prestashop example ... $product.quantity <= 0 ... is the magic part for the if condition. Do some own research and learn with it, piece by piece.

An total of "all modules" of 200 + is normal in prestashop. An "installed modules" list between 30 and 70 is also common in prestashop. Note the difference between "all" and "installed".

The error comes from a non-standard module named footercustom You might want to try to uninstall this module properly.

@Script-Fu: Read what I have written. Don't just ask the same again and again. Everyone note that Script-Fu talks and show screenshots from Prestashop, NOT from Thirtybees. The modules list is a merge from multiple XML files in /config/xml. So deleting folders does nothing at all in relation to the "all modules" list.

I doubt everyone understood the issue from the starting point. The modules list does not only contain installed modules but more and more featured modules. Most of them are not installed. So you cannot strip down the list and assume the list will remain as you stripped it. The modules list gets updated on automated basis. You can strip down the XML files related but the keep geeting updated about every week or so. The result is what I found that just displaying the list of modules takes ages. ../classes/controller/AdminController.php is one place where module list handling is done. But it's not the only place unfortunately.

I also tested Traumflugs changes and I can confirm it works.

The problem as far as prestashop os concerned is the following: From some 20 to 30 modules at the beginning prestashop filled it's module listing with more and more modules. Helpful ones and lots of non-sense-modules as well. The module lists are coming from the /config/xml directory and there from multiple XML files. These XML are updated frequently, so stripping them only helps for a very short time. To get rid of the 290 modules you needed to make changes on multiple files in prestashop core. Search for file_put_contents in the core code.

I'd say your logo file is too big. It's 550px of width.

Datakick, we are at the same page at this time. Nevertheless I changed my installation to get some experience with only one version of page stored independing of device type.

I'll give it a try this way all enabled and only filtering on CSS leve. I'll report back my experience.

Ok, I am not unteachable. I follow a new way. enable all modules by default, change module CSS (for example for blockbanner) to get rid of displaying on mobile devices or change golbal.css to hide left column entirely. Then get rid of isTablet, isMobile for the cache. Only warm the cache for one type of device - which would then be desktop.

TB allows to choose which modules to display on which type of devices. As long as this setting is possible but full page cache doesn't respect it might be a bug. And yes, I am fully aware of the capabilities of CSS. But default TB does not work as the settings would allow. What I faced with TB default installation 1.0.8 was the following behaviour: 1. Categoriy Pages missing left column module output on desktop because the last cached version was from a mobile device. 2. Category Pages show left column moudule output on mobile devices where it is not set to display in the modules settings.

Distinction is blurring indeed. But TB CSS also does not reflect device width as per default. Hence you get desktop modules shown on mobile devices. Having small screens in minde it doesn't look well with too much information. The other way around if you don't store information on the type of device on cached pages you might get a mobile view on desktop as well.

I added a condition when preparing the new URL string, otherwise the question mark appears also with no remaining parameters: ksort($queryStringParams); $newQueryString = http_build_query($queryStringParams); if ($newQueryString == '' ) { $newUrl = $protocol.$_SERVER['HTTP_HOST'].$uri; } else { $newUrl = $protocol.$_SERVER['HTTP_HOST'].$uri.'?'.$newQueryString; }

Thanks Peter, I found this part already but since not all hash data are own table columns it was difficult to figure out which values changed. So far I found out that if all query parameters are to ignore, there is still a trailing question mark remaining. I'll update with my further findings an code. Thanks again.

One more addition: it is clear cache might add pages for each country, currency etc. But the pages in the db table have almost always all the same IDs.

Petr, 1) Thank you for the feedback. My changes were not quite enough. I am stil testing. However what I would NOT get so far is whye the table page_cache gets popultated with so many entries for the same entity. My start page (entity index) has around 14 or 15 entries. I doubt these are all from customers which are logged in. However I could not determine which factors are causing so many entries. Maybe somebody can shed some light on this? 2) Using Customer ID as part of the hash makes logged in users almost uncachable. In my opinion it must be a better way. regards, Scully

I figured to add some params to the Page Cache Key. I will test this for some time. return new PageCacheKey( $entityType, $entityId, $newUrl, (int) $currency->id, (int) $context->language->id, (int) $context->country->id, (int) $context->shop->id, (int) Group::getCurrent()->id, (int) $context->customer->id, // added comma (int) $context->getMobileDevice(), // added (int) $context->isTablet() // added );

I just recently switched over to thirtybees after having used PS before for years. I would like to thank to the contributors of TB for their work at first place. While testing TB with full page cache enabled I noticed that the full page cache delivers the page regardless of the device type requesting it. Hence once mobile devices modules are displayed which are not meant to show on mobile devices. In my opinion the only way to avoid this is to store different full pages, one for each device type - otherwise the device settings for the modules are not respected. Or to make all these modules dynamic which would lead to a loss of performance. To overcome these issues I implemented some CSS tricks which at the moment set display:none at the beginning the left column but this is rather dirty. Any feedback is appreciated. Scully