Traumflug

Well, set the product price to zero or to the minimum price, then add combinations with various price impacts.

Most thirty bees modules are rebranded PS 1.6 modules anyways. Just stay away from PS 1.7-only modules, they're incompatible.

Yes. If your pocket is deep enough. Remember: https://forum.thirtybees.com/topic/4027-goodbye/?do=findComment&comment=34625

You upgraded PHP recently, didn't you? Tools::redirect() needs al least one argument, the address to redirect to. Module code apparently doesn't deliver that, so it's a bit unclear how this could ever work before. Anyways, point of malfunction isn't in the cited code (Tools.php), but in the module in register.php line 161 or earlier.

With all the eyebrow raising these days I thought a bit funny stuff is a good idea. If you don't know on how to react with your marketing to the Corona crisis, here's kind of a template you can fill in 🙂

Here are two such facts: 1. It's hard to find developers working on a free community version. Everybody tries to get the best advantage out of his/her work. This isn't surprising, but is also of limited advantage for the community as a whole. Result: lots of agencies at work, lots of "somebody should" texts when it comes to community work. 2. It's even harder to get people into agreeing on something. Everyone has own ideas and wants these to be implemented, nothing else. Which means, even with sufficient money things don't fall into place naturally and any "leader" has constantly to deal with disappointed stakeholders.

There's Preferences -> Duplicate URLs to detect such situations.

Sounds like a reasonable base to work with. Except for one thing missing: making a feature request needs a price tag. Else the list of feature requests ends up where it was before: hundreds of requests with one supporter each and many being almost, but not entirely the same. Hardest part of a user driven feature request list is probably to aggregate requests somehow, to agree among all/most users on what to work, and on what to work next. There is no shortage of ideas for features. I have a TODO list with like 100 bullet points myself, requests on Github not even included 🙂

Da ist es eine gute Idee zu prüfen, ob mit einer restriktiven Einstellung des Browsers der Warenkorb noch funtkioniert. Der ist auf ein Cookie angewiesen.

This means an empty ZIP code is recognized as valid code, which is probably not what you want.

Merging with PS 1.6 brings probably nothing. Merging with PS 1.7 would bring all the compatibility issues PS 1.7 comes with: broken modules, broken themes.

Likely not. In early 2019 I was into hiring developers for thirty bees. This wasn't exactly easy, even with plenty of funds. A surprisingly large number of PrestaShop developers outright refused to work for thirty bees, simply because it's kind of a competition for PrestaShop. And freshmen refused to work for the project because they never heard of it. Another datapoint, remember this effort of PS to make PS 1.6 community-maintained to keep it alive? They immediately found like a dozen developers volunteering for this. As we know, thirty bees does exactly what this effort wants to solve: keep a 1.6-compatible software alive. Still no such dozen developers volunteering. A substantial part of the problem is people believing way too much in brand names. They prefer a buggy PS 1.6 over a stable and compatible thirty bees, just because it's named 'PrestaShop'. So far no solution for this aspect in sight.

Nothing. I'm here an working. Just not on public stuff at the moment.

See, this is why I outright fear to tell anything. As soon as I start to tell a few facts or answer a simple question, a rush of disappointed messages follows, sometimes not far from insulting. And this happens with thirty bees only, never seen a message questioning the PrestaShop or Magento or whatever company. If you want reassurance, here it is: https://github.com/thirtybees/thirtybees Code is public, available for everybody. Even if somebody would pull this public repository, many of us have copies/clones on platter and every single shop has most of its files installed. And its license perfectly allows to use the code until the sun goes dark or the universe collapses. Unlike all the Microsoft/Apple/SAP/whatever stuff, nobody can take that away from you. Another thing is, I promised years ago to not leave merchants in the dust. This continues to be true. Run your shop, and if something goes wrong, drop me a message. Or Datakick or another developer. Support is still there and pretty much unchanged, even Datakick said about the same earlier in this thread:

Which reassurance? I don't know anything about this company other than it's name and what's written in this registry entry.

2 hours ago, zen said: How TB works legaly Looking at the bottom of thirtybees.com one can read this: © thirty development llc As in most countries, one can look up limited-type companies in public registers: https://tnbear.tn.gov/Ecommerce/FilingDetail.aspx?CN=255033012188122038179169083159160212228131154070 (solve the captcha to see the entry) One can see the number of company members going up and down over the years. Before you ask: I'm none of them.

D'oh. Just minutes before I praised your work in a private chat.

White page means a substantial problem, like a PHP syntax error. Time to look up the server's error log, if available. If your hoster doesn't provide an error log (ridiculous, but some actually do not), move overrides and non-thirty-bees-modules aside: - Using FTP, find all pages with .php suffix in overrides/, which are not index.php, and rename them to ....php.off. - Create a folder "modules.off" at the root of the filesystem. - Move all modules not from thirty bees out of modules/ into modules.off/. In doubt, move more of them, a shop basically works without any modules. - Delete cache/class_index.php. thirty bees will regenerate it.

They do this only once and store the combined file, then always serve this. Which means no additional CPU usage when serving pages. Disadvantage is, it always serves all available CSS/JS, even those chunks not needed on a particular page. Advantage is, it's always the same file, so this load happens on the first page visited, only. Regarding HTML compression: one of the first things Michael Dekker did for thirty bees was to remove it. Because HTML compression indeed takes longer than just serving the longer, uncompressed file. As always: measure, measure, measure. Developer consoles of Firefox and Chrome both show page loading time at the very bottom. Reload a page five times, take the average. Then change a setting and measure again. Numbers are much more reliable than feelings and guesses.

Yes. But not those who click this x by accident. And that happens quite easily, because this x looks like a close-dialog-button.

I didn't design this site, nor do I have any insight, but just look at what's there. More importantly: what's not there. Front page: phone/tablet-type menu only, no menu optimized for desktops. This likely means a lot less HTML, a lot less JavaScript and a lot less CSS. No image slider, no blinky-blinky (which slows down the browser), just one font, no Google Analytics (but G tag manager), no Facebook. Category page: while many sites have a whole plethora of modules in the left column there, Chesspoint has exactly one: layered navigation.

Undo this commit and see customers deleting their orders 🙂 https://github.com/thirtybees/niara/commit/5991643b278f4f0343dc7e90957984013a6db98f

And yes, I hate to have to sound so disappointing here, being well aware this doesn't make me a hero. Hero will be the next guy coming along with a silver bullet promise, even if it breaks shops.

To add a technical datapoint: page caching of any kind can only cache the HTML part of the page, the initial page load. That's where all the PHP voodoo gets executed. All the stuff after that initial page load, CSS, JS, images, whatever, isn't subject to page caching, no matter how it's configured. And one can easily measure how long this initial page load takes. Instrument #1: use Curl on the command line. Like: time curl https://librairiezbookstore.com/ Instrument #2: browser's developer console. Open it, click on the 'Networking' tab, then reload the page. This generates a list of all the resources loaded, look at the very first one. It should report loading time. With both instruments I get between 540 milliseconds and 590 Milliseconds on librairiezbookstore.com. That's what one can gain. Very good setups take like 350 milliseconds, so even the best imaginable page caching could never improve page loading performance by more than 0.2 seconds. If one sees more improvements for the complete page load, it's the result of content no longer displaying.

Why don't you just believe technicians, then. Quite a number of merchants search for a silver bullet despite it was said many times such a bullet doesn't exist. The guidance you ask for is very clear: don't use full page cache. If you want faster page loading times, reduce modules and content. Uninstall modules, don't just disable them. thirty bees is very fast by default and can be customized heavily with keeping this performance. Good example is @wakabayashi's technically brilliant https://www.chesspoint.ch/