Scully

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