Traumflug

Maybe we find time to investigate what you mean. https://github.com/thirtybees/thirtybees/issues/570

define(‘PSVERSION’, ‘1.0.5’); define(‘TBVERSION’, ‘1.0.5’); It's _TB_VERSION_, these underscores are significant. And only _TB_VERSION_, please, PS version should stay at 1.6.1.999. Its curious… i changed the statsmodule file and zipped it but after uploading it via BO on the Server its back on $this->tbversionscompliancy = ‘> 1.0.3’; Why do you do this? 1.0.5 meets '> 1.0.3', so that's entirely fine.

When upgrading, did you change the version number for _TB_VERSION_ in settings.inc.php as well? That's the number where modules get compared against when deciding about compatibility.

I will have a lot of problems cause I do have modules that’s developed for 1.6 and also pretty unique cause they’re aimed for the Swedish market. If you run a dev shop, testing these possible incompatibilities is fairly easy: Edit composer.json, find the line for smarty/smarty and exchange 3.1.19 for 3.1.32. Run composer update. That's it already. If your modules continue to work with this change, you're safe for the future. And we're keen on hearing about your findings, of course.

With 93 issues still open on github, you would like to give your precious time to break the compatibility with 1.6? Nah. Rest assured we won't intentionally break compatibility with PS 1.6 just for the sake of getting a disruption, much less spend substantial amount of time on doing so. At least I won't. But, and that's the root of the issue discussed here, there are some of these 93 issues which can't get fixed without accepting some (possible) breakage with PS 1.6 themes. That's the dilemma: either fix these bugs in thirty bees or keep full compatibility with PS 1.6. Can't get both. And because that's such a diverse topic, we asked. The above decision means: we accept warnings when running on PHP 7.2 until end of the year. Next year we'll fix these warnings on PHP 7.2 and accept some possible incompatibilities with PS 1.6 themes instead. And if there are ways to fix these themes for compatibility with PHP 7.2, we'll certainly help to get them into your shops. If you want to help, approach your theme developer and ask him to review his theme for compatibility with PHP 7.2 and Smarty 3.1.32 (the current version). They certainly can.

Alright, thank you very much for all the votes and comments! I just agreed with @lesley on this strategy, and I think it reasonably matches what was written above: Smarty will stay on 3.1.19 for another 4 months / up to end of the year. After that, compatibility with PS 1.6 modules and themes will be kept as a goal for another year, but not at all costs. Regarding the version number we'll roll a dice, then. I'll start packaging thirty bees 1.0.6 tomorrow.

How about you include both smarty versions As composer tries hard to give the deaf when such requests come up, it doesn't support such setups. Which means, it can't be done without opening another can of worms.

This is about the near term strategy of thirty bees development. Current situation is that thirty bees comes with a fairly ( > 2 years) old version of Smarty, version 3.1.19. This version is no longer compatible with PHP 7.2 and later. Those who put their shop into development mode see PHP warnings about everywhere. And successive PHP releases might well turn these warnings into errors, breaking things in non-developer mode as well. To get closer to a solution, I've committed an upgrade to Smarty 3.1.25 for getting it into the thirty bees 1.0.6 release. @lesley would prefer to revert this upgrade, because a year ago he tested newer Smarty releases and they broke some templates. Hence this call for votes, because there are valid reasons for both strategies. Strategy 1 is to upgrade Smarty on the 1.0.x development branch. Code advances surprisingly well on this branch while we manage to keep compatibility with PrestaShop modules and themes. Which means, the 1.0.x branch may stay for quite a while, perhaps another year. From 1.0.7 or 1.0.8 on it can become fully compatible with most recent PHP versions. At a certain risk to rely on theme developers fixing Smarty bugs in their themes. Strategy 2 is to move on to development branch 1.1.x (and abandon 1.0.x). Then thirty bees is released from the promise to keep full compatibility with PrestaShop, can upgrade Smarty without looking back and even start to weed out some of the no longer needed, historic PrestaShop code (for example compatibility with PS 1.4). Those running PHP 7.2+ on their server have to upgrade then. And, well, get their theme fixed anyways. If you want to read even more about the issue, see Github issue #557. Now, please cast your vote by commenting on this topic! thirty bees listens to its merchants.

One can't use the updater to update to 1.0.4, 1.0.5 or (soon) 1.0.6. These versions need manual updates: https://forum.thirtybees.com/topic/1870/say-hello-to-release-1-0-5 Yes, a new updater is on schedule. Slow progress, though, because it gets thwarted with even more urgent things, like e.g. getting release packaging (completed 4 weeks ago) and translations packaging working (completed this week).

Or is it handled by prestashop ? This is thirty bees :-) AFAIK, thirty bees uses exactly one database connection per web request. Code writers know this as "singleton instance". If you see multiple requests open, you apparently have multiple web requests running. Even if a web request connection hangs, PHP times out after 30 seconds, closing the DB connection as well. Reasons you see this error include: PHP is configured to never time out. This way, DB connections can stay open for a long time. MySQL doesn't allow as many users as you get web requests. For help, see https://www.rathishkumar.in/2017/07/how-to-fix-mysql-too-many-connections.html

Really if there was change log There is: https://github.com/thirtybees/thirtybees/releases If you want all the details, read the git log. Hundreds of entries, though.

Huh? Ten times more categories than products? How can this work out? To me this sounds like there's a need for layered navigation. Only a few categories, but products equipped with Product Features, then building a couple of filters to allow customers finding their thing. Regarding back office speed, thirty bees is usually reported to be pretty quick there. Easiest was to find out whether that's still true in your specific case is to do a test installation. Can happen in a subfolder of your current shop. Just create such a subfolder, unpack thirty bees in there and install as usual by adding the subfolder name to your shop URL.

Senseless advertising Expression of pride!

Any idea of what problem this fixes?

Some of them, it is pretty darn impossible to figure out where is what. Can't talk for this module, but CSS files related to modules can exist in three places: themes/<theme name>/css/modules/<module name>/ modules/<module name>/views/css/ modules/<module name>/ Each CSS file about to get loaded gets searched in the above order. (3) is deprecated, but still used by many modules. (2) is where module developers should place their idea of proper CSS. (1) is where a theme can override (2). Files in (2) get replaced by module updates. If a file in (1) is present, the one in (2) gets ignored. If the theme should (or you want to) override (2), but there is no overriding file in (1), create one. Starting with a copy of the one in (2) is a good idea.

After this upgrade when I tried to install the migrator on my iPhone X The migrator is a PrestaShop module. One installs it in back office, on the server.

Yet, i’m upgrading my shop with the prestashop 1click upgrade module Uhm, there's a migration module: https://github.com/thirtybees/psonesixmigrator/releases. Similar to the upgrader module, but adjusted for migrations to thirty bees.

Das angeführte Beispiel hat den Kaufen-Knopf zu weit oben, denn alles unter diesen Knopf gilt bekanntlich als nicht wahrgenommen. Dann kann man das gerade so gut weg lassen.

This ZIP should be 41.2 MB (see https://github.com/thirtybees/thirtybees/releases/tag/1.0.1) If it's shorter than that, it's well possible the download was cut off before being completed. One possible reason is simply bad luck, an Internet hiccup. Simply try again. Another possible reason is that PHP max execution time was exceeded. In this case, raise max_execution_time in php.ini, see https://secure.php.net/manual/en/info.configuration.php#ini.max-execution-time

@doclucas Such a project must be [...] managed by a serious CEO. Let me express I'm thrilled how well it works without such a CEO. A CEO means a hierarchy, hierarchies mean people working on stuff they're not convinced of, people not enthusiastic about their work mean a lot less productivity. Doesn't happen at thirty bees.

Here we go, should also appear as update in your back office: VAT Exemption Module v2.1.1 release

Try it an tell us!

It's in the nature of HTTP that one can't push anything. One can only declare files as short lived, in the hope that the browser requests them again. Alternatively one can change the file name, so the next page request makes the browser requesting that other file. Third strategy is to deliver some JavaScript which repeatedly requests the same file. Which raises the question: why do you feel a need for "pushing" CSS? Each of the strategies mentioned makes caching pretty pointless.

In case you tried with One Page Checkout and it didn't work: now it does. PHP code change just pushed to thirty bees core, required template changes to community theme default as well. Release notes for version 2.1.0 updated accordingly. As dessert topping, there'll be a bugfix release of the module later today.

Love this. A problem report and the solution already attached. Well done!