Traumflug

One can use the new GitUpdater to find out the distinction between an ideal clean installation and what's actually on disk: It's perfectly fine to compare or even "upgrade" a *v1.0.8* installation to *v1.0.8*.

Don't be surprised if it looks like nothing happens. With the comparison done, updates are quite speedy: That's 0.2+0.6+0.1+0.1 = 1.0 seconds for the whole download and update process. Shop downtime is even less, it's just the time between Created update script and Update script was executed. Apparently less than 0.1 seconds.

Alright, time for another preview. Advances since the last preview: Updates now actually work! So far tested with a clean installation, one can switch between v1.0.7 and v1.0.8 back and forth as often as one desires. Applies the same database upgrades as upgrading to v1.0.8 with the old updater did. Which means, all the essential stuff is implemented. Still missing: Some nice exit. Currently, one is kind of stuck after an update and has to select something in the menu to move on (and see the new version in the upper left corner). Actual removal of selected obsolete files. So far, these checkboxes are just decoration. Machinery to update the underlying clean master installation automatically. To allow merchants to update their shop a few minutes after a Git commit was pushed to the Gitub repository. To demonstrate the modules' capabilities, I've uploaded current branch 1.0.x manually. Happy updating! gitupdater-2018-01-21.zip

Insulted from what? From some things maybe breaking somewhere in the future? And thirty bees stating "Ha ha, we fooled you!" ? Come on. The whole point of thirty bees' existence is keeping compatibility with existing shops. Risking this would be suicide. With this in mind, merchants can trust that thirty bees won't do this. Actually, current work risks the opposite. Many people consider the project to be not moving, because there are so few new features. This risk is taken to put available resources into making it even more reliable, to make updating ( = bug fixes!) safer, to avoid breaking things. And this emphasis on reliability will be continued, of course. Even when deprecating and removing really old stuff like PHP 5.5 or PS 1.4 support.

4 hours ago, nickon said: @Traumflug tb will not and can not be "always" backward compatible with 1.6. At some point it will have to break. The next one spreading fear without any evidence. *sigh* 4 hours ago, nickon said: > In order for this to happen IMO we need a clearer roadmap. The roadmap is: "thirty bees will stay compatible with PS 1.6 themes". Not sure what's unclear about this. If you have evidence this doesn't work out, like actual bugs with the newest thirty bees, please report them on Github.

14 hours ago, Johhny said: No it's just /admin Just admin/, not something like adminr34ft45/? The first attempt to log into admin should rename/obfuscate the name of the admin folder. With FTP one should see this new name. One can also use these links shown on the last page of the installer.

Installations in subfolders should work, of course. What kind of errors happen? "had trouble" is a bit vague to find a solution.

Now you know why thirty bees didn't do this, yet 🙂 Two things are helpful: Try in small increments. Like 1.11.0 -> 1.12.0 -> 2.0.0 -> ... Be more detailed than "I get conflicts". Which conflicts, how to reproduce them?

Here's this next preview: gitupdater-2019-01-11.zip Reviewed file filtering in detail. Including all the review report observations above, the stuff shown in the previous post, also another filter to keep favicons & friends unchanged. Processing log and file lists collapse now, giving a fairly short panel with the Update button visible immediately. An attempt to make this two-click-updater fearless to use, slapping long lists into a merchant's face has certainly some repellent taste. File lists can get expanded by a click, of course. File lists now show the number of files affected. Next step will be to implement actual updates.

What would be the thought on having check boxes next to the files? Where you can choose to leave some files untouched? Like @wakabayashi described above, leaving code files untouched easily leads to a broken shop. All an updater could do is to keep a backup of modified files, so merchants can review them not only before, but also after an update. That said, thanks a lot for all your testing help. I'm currently reworking the filter list. Finding out which files to update and which ones not is pretty tricky. With the previous updater this was done by the update actions building script (on the thirty bees server), and this wasn't exactly bullet proof either. So far the list is (PHP regular expressions, files coming with the distribution don't get removed by this filter): php const INSTALLATION_PATH_FILTER = [ '#^cache/#', '#^img/#', '#^upload/#', '#^download/#', '#^translations/#', '#^mails/#', '#^override/#', '#^themes/(?!community-theme-default/)#', '#^themes/community-theme-default/cache/#', '#^themes/community-theme-default/lang/#', '#^themes/community-theme-default/mails/#', '#^config/settings.inc.php$#', '#^config/settings.old.php$#', '#^config/defines_custom.inc.php$#', ]; Which means: - Ignore cached files, except those coming with the distribution. - Same for overrides, uploaded files, downloaded files, translations and mail templates. - Ignore all themes except the default one. - Ignore settings, of course. An updater has no business with any of these. Translations/mail templates have their own update mechanism, just like modules. Not yet done are files which shouldn't come with the release, because they get overwritten by setting up the shop. Favicons, for example. Some category images (they should get copied from the install/ folder during installation instead, but that's another issue). Likely I can provide another preview later today.

Whenever there is a problem we recommend people to switch on development mode. That is not possible for those people [using PHP 7.2]. It is. I run PHP 7.2 myself and get this many times a day. A box with the error report appears (created by xdebug) and if this box gets into the way, one simply reloads the page. These Smarty errors happen during template compilation and once a template is cached, the box no longer appears. Not sure how things appear visually without xdebug, but it certainly works.

https://github.com/thirtybees/thirtybees/issues/812

https://github.com/thirtybees/thirtybees/issues/809

https://github.com/thirtybees/thirtybees/issues/811

https://github.com/thirtybees/thirtybees/issues/810

@musicmaster, would you please stop spreading fear here? thirty bees supports PHP 7.2 already. With development mode turned off, which is (hopefully) true for any production shop, it works just fine. And I can hardly believe you recommend dropping Smarty here just because there are a few incompatibilities with the newest version. Dropping Smarty certainly makes all modules incompatible. Incompatible in a way which can't get fixed short of rewriting all the modules. Third, you whine about PHP 7.1 being unsupported next year, while you also try hard to keep a Smarty version which is is unsupported since four years ago now. Totally contradicting. thirty bees can tackle and will tackle the Smarty problem. There are several strategies available: Smarty code is wrapped already, so this wrapper can get enhanced to work around known trouble. Themes and modules can get patched on the fly. If there are known showstoppers, create a patch, thirty bees applies it without the merchant even noticing it. Theme and module developers are living beings and can certainly enhance their code. Smarty is open source, so it accepts patches. If all this fails, there's still the option to patch Smarty by composer, as @gonssal mentioned. The newest Smarty version, of course. With this in mind, all this works much better if people stop working on kludges and start working on the issues actually coming up with a PHP 7.3 compatible version. To cite one of the best thirty bees developers: "I’ve played with new version of smarty, and I’ve never encounter any problem with themes tpl." He said a bit more, still did the right thing: started to search for solutions, not kludges. Right. I'm back working on GitUpdater. Because the most crucial thing for any kind of code change is a reliable way to transport this code change into shop installations.

how do you plan to tackle database migration? Classes should learn to maintain their database table them selfs. Like it was sketched here: https://github.com/thirtybees/thirtybees/commit/f7a55b7d772f58a0019f938bbfdf73528374087e PHP gets updated, then each class's installCheck() gets called, which detects and removes distinctions between the necessary table and the one currently in the database. Sounds complicated, but is probably pretty easy once class ObjectModel has learned to do this for the general case. In case this approach turns out to be too unreliable to implement, the fallback strategy would be to run upgrade scripts like the current updater does. Update from 1.0.8 to 1.0.9 would run all 1.0.9 upgrade scripts. A downgrade in the opposite direction would run the same set of 1.0.9 scripts. Which means, these upgrade scripts would have to learn to work in both directions if necessary. AFAIK, we didn't have a case where a database downgrade is crucial for a software downgrade yet. A nice thing about the update approach following the Git approach is, the updater has access to all files he feels a need for. Files of the old version as well as files for the new version, installed files and not installed ones. Updates/downgrades are planned to run independently from core software. The module prepares the update by providing all the changed files somewhere, then calls a temporary PHP script (obfuscated name!) to move them into place atomically. And yes, in midst of this copy/move operation, core software has to be assumed to be broken. That's the same for any in-place updater.

I would like a checkbox so I would be able to uncheck a specific file I don’t want to update. Such a feature was considered. And found to be a pretty sure way to make merchants shoot into their own foot. The way I recognize merchants, they won't compare their patched file with the new file and then merge their changes over. They'd just click "don't change", which is a recipe for disaster. One can't update just parts of a software and expect the result to work. People editing their files manually also have to deal with this manually.

thirty bees doesn't provide the logo of your shop, only you have this artwork. Which means, you can fix this only by re-uploading the logo yourself.

Rule of thumb: never fight the framework. Updating to a PHP 7.2 compatible Smarty version is actually the only option, short of switching to another framework. Trying to fix older Smarty versions is trying to reanimate a dead horse, and the more efforts go into this, the worse the mess gets. Then thirty bees has not only to deal with Smarty changes, but also to deal with these workarounds. Smarty should be seen as a given. Actually, even if we wanted, we couldn't put changes to Smarty code into the thirty bees repository, because Smarty isn't part of this repository. It gets fetched as-is during release builds. The only changeable part is the Smarty version number. Instead of putting efforts into changing something unchangeable, working on the issues coming up with modern Smarty would be much more worthwhile, give faster code, give a future-proof codebase. Which can also result in bug fixes provided to the official Smarty repository, of course.

The flawed update mechanism Perhaps you remember the 1.0.8 update a couple of weeks ago. While it certainly solved bugs and misalignments for many, it also resulted in quite a number of reports about messed up shops after the update. That's not tolerable, of course. Thinking about this problem I compared to what we developers do to switch between versions, and why we pretty much never mess up a shop installation by doing so, despite switching back and forth all the time. Developers do a git checkout 1.0.7 to switch to version 1.0.7, git checkout 1.0.5 to switch to version 1.0.5, git checkout 1.0.x to switch to the latest development, and so on. And there's the fundamental distinction: doing such a checkout doesn't apply a patchset or a set of changed files, like the current updater module does. When checking out a version, Git compares files currently on disk with kind of a master set of files (stored in the .git directory), then changes files on disk to make them match this master set. The current update module, which is a refined version of Prestashops 1-click updater, has a fundamental flaw: it doesn't check whether files on disk are right, but blindly applies a set of changed files. Who creates this set of changed files? Right: thirty bees developers, which have never seen your shop installation. This set of changed files gets created not on knowledge, but on assumptions. The assumption that your shop installation matches a clean shop installation. Which is often not true, as we unfortunately experience over and over again. Meet GitUpdater Having the fundamental flaw detected, a new updater module started to evolve. Prepared sets of file changes are gone. Instead, the module compares the shop installation to a clean master installation, which gets served by api.thirtybees.com. This always works, and after an update, a shop will always be in a clean, sane state. A recipe for reliability. Advantages This works from any release to any release. Select the wanted version, click Compare and see which files changed since then. Which means, one can downgrade or rollback just a easily as update. Another use case is to compare the current installation to the master installation. Updating from e.g. 1.0.8 to 1.0.8 is perfectly possible, to restore a broken shop. Before too long, this will also support updating to development branches. E.g. to test bug fixes provided on Github. Or even single commits. Manual changes get detected. During comparison, the module detects files which don't match the original version, so the merchant can deal with his manual edits. Smooth operations. All operations taking place got split into small chunks, so one can virtually never run into maximum processing time limits. The preview Here it is: gitupdater-2019-01-05.zip Install it by unpacking in the modules folder or using Add a new module (top right corner) in back office -> Modules & Services -> Modules & Services. Having the module installed, a new menu item, Updater, appears in menu Preferences. That's where this module gets controlled. Yet To Do Actual updates. Currently the module does comparisons only, not actually change files. Which is why playing with this module preview is safe. File filtering. Some files should get ignored. For example, an update shouldn't reinstall the install/ folder despite this folder being present in a clean installation. It also shouldn't remove product images or translations, despite them being not present in releases. User interface. Currently, this module shows a list of all changed/created/removed files. This can be a huge list with up to 10,000 lines. Ideas to display this list in a less scary way are welcome. And for those not installing the module immediately, here's a screenshot:

Next I looked at the warning that got. I searched the code but there is only one instance of “each()” in it. I found on internet a “myEach()” function that should be able to emulate each() and implemented it. Thanks for these efforts. That said, such workarounds are pretty exactly what I'd like to avoid. The usage of each() you found is a bug and bugs can get solved by changing the buggy code. The PHP folks didn't introduce such warnings to annoy users, but to detect bugs and help eliminating them.

FPC isn't turned on by default, so all people running into these issues explicitely enabled it. If they ask to run a known incomplete feature, they get an incomplete feature. If they're unwilling to turn it off again, I can't help. And yes, FPC is a thing Prestashop doesn't even feature, so one is still better with FPC turned off. For myself, FPC is pretty low priority. See above how some updates didn't work? This hurts, not a still broken FPC. And that's why I picked up the almost forgotten Git Updater again the day after seeing these update module failure reports.

The fix for FPC is: turn it off. TBH, I'm quite a bit surprised to see so many people making a headache about this totally optional Full Page Cache, while there are no less than 160 known bugs filed (not counting enhancement requests), some of which cause a shop to display plain wrong data to the customer. Did I hear here "Doesn't matter what a customer sees, as long as he sees this fast" ? I hope not. For me, correctness counts a lot more than a few percent performance.

But where is the content generated? none $ grep --exclude-dir cache -rn "'address_delivery'" controllers/front/OrderDetailController.php:246: 'address_delivery' => $addressDelivery, It gets sent as a PHP object, which is analyzed by Smarty somehow. It's a fairly complex matter, because the address format is localizable. See back office -> Localization -> Countries -> (click a country).