Traumflug

So I worked a full day for the trashcan. I thought it was clear that I'm working on this.

News :-) files.json: while it's tracked in the Git repo, it also gets updated when creating a package. You, @atolodas , apparently run a development installation. Only four files missing. With an installation made from a package it's much worse, 46 files missing :-) Wrote a PHP version of the file generator (currently used is a JavaScript variant) and it turns out, both generators generate the same (except for sorting). Updating files.json in a developer installation gives a perfectly fine validation. So, what the heck? The hint for the next step in this adventure game is here: files.json generated in a developer installation is 387 lines. The one generated for a package is 1261 lines. These two versions are expected to be the same. Going bicycling now and when coming back I'll put these puzzle pieces together.

The question arising is: when should this file receive updates? On every commit? On every bump of the release version? When creating a distribution package, creating this file on the fly?

This is simple: config/json/files.json is out of date. 4 files no longer exist, 221 files have changed. Not exactly a trust building situation :-)

On an installation from the Git repository: sh $ ls classes/Discount.php classes/controller/AjaxController.php classes/controller/ModuleAjaxController.php classes/order/OrderDiscount.php ls: cannot access 'classes/Discount.php': No such file or directory ls: cannot access 'classes/controller/AjaxController.php': No such file or directory ls: cannot access 'classes/controller/ModuleAjaxController.php': No such file or directory ls: cannot access 'classes/order/OrderDiscount.php': No such file or directory Which means: these files aren't expected to exist. Looking into the repo history one can find this: https://github.com/thirtybees/thirtybees/commit/0335d82603d48d0edd7ad149dbe729f6b69d005c These files were removed on March 12th. Apparently is was forgotten to update the list of expected files.

5 days of hacking later there are 24 new commits and 260 lines of code gone. Works better than ever, e.g. the markup once visible on the summary page is gone: If you want to try this, here's an upgrade package: 01492604960741tb-wizard-patched.zip And in case it doesn't work and you have no backup, here are the same files in the original version: 01492604997611tb-wizard-original.zip In both cases, unpack them elsewhere and rename folder 'admin-dev' to the name of your actual admin folder. Then replace the files, paths are given in the ZIP. I'm pretty sure that validation was improved. Also, one can no longer save invalid data by just clicking 'Finish' when editing an existing carrier. One can edit fields in any order, validation happens when clicking 'Next' or 'Finish'. Invalid fields get highlighted. Fields for 'All' no longer vanish in some situations. And there are two (useful) easter eggs built in. Enjoy! Now it's your turn to show how to fool this wizard. I no longer can, even when trying hard :-)

Why do you make a headache about the server location. For myself I'm not sure where the hardware is. Probably somewhere around Frankfurt/Germany. At times I work with another one somewhere near San Francisco/USA. Work procedures are exactly the same. Which means: it doesn't matter where the hardware converts electricity into zeros and ones, as long as this hardware is connected to the Internet.

Also I believe that most merchants don’t invest enough time to chose their system. Most of us are probably kind of experts here, but try to play dumb and then install a shop. Installation of a Wiki is something like a few hours, installation of a shop is measured in weeks. On top of this all the legal issues, mandatory or not (depends on the home country). With all that mess it's well understandable that people watch out for something where they can simply upload a few pictures, define a price and start selling.

It's really just about the order of entries. Validation still happens before one can switch to the next page, so entering invalid stuff is still impossible.

After digging into the code I found the secret: one has to fill in the price/weight range (these fields with grey background) first. Having these two filled in, such a range becomes "active" (an invisible property) and once a range is "active", one can start to enter fees. That's why it worked for some, but not for others. If one starts to fill the fields top to bottom, it works. Not so in any other order. I consider this as overengineering. A user should be allowed to fill fields in any order (s)he likes. Actually I thought one could leave the upper range value empty to get "infinite". If infinite was allowed, one could even remove this "Out-of-range behavior" choice, because one can define ranges which can't go out of range, then. Lots of opportunities to make the user interface more intuitive. That said, I think I'll remove this "active" status thing and then move on. There are bigger goals waiting :-)

Once a carrier is saved, things work a whole lot better. For example, that single checkbox above the row with Africa means to be a row for "All". Initially, the word "All" is written there. Checking one of the other rows makes this word going away. Clicking the "All" checkbox makes it re-appear, and also a price entry field. When editing an existing carrier all this doesn't happen. This smells a lot like overengineered code or lots of quick patches on top once reliable code. The obvious first step is to find and remove the distinction between a new and an existing carrier.

When adding a second (third, fourth, ...) carrier one can enable a zone by clicking the related checkbox, but doing so doesn't enable the price entry field. It's likely some JavaScript thing. There's also a workaround: save the carrier without that number, open it again and find the field editable.

Does it match this? https://github.com/thirtybees/thirtybees/issues/178

For now I couldn't reproduce the scenario shown above, that's true. The installation was just three days before beta.2.

And showing both is a bug, obviously.

One is the locally installed module, the other one is the one available for downloading. The server serving online modules isn't up to date, yet.

Look at this: After deleting a bunch of modules and enabling the PayPal module, I suddenly have duplicate modules. Duplicated modules are paypal, stripe and mailchimp. Looks like there's a debugging session ahead :-)

Thanks. Github issue already created: https://github.com/thirtybees/thirtybees/issues/176

Great! Bug reported and already solved! I like this :-)

Just found in the Github repo: thirty bees is now tagged 1.0.1 beta.2. 45 commits happened since beta.1, most of them smaller bugfixes in modules as well as in core. Here's a package: 01492020512154thirtybees-v1.0.1-beta.2.zip

once you update to a new TB version everything will crash down… Not that drastic. I don't think TB changes programming interfaces just for the sake of changing them. One example: PS had imported code in tools/, while TB uses composer, which happens to place modules in vendor/. There are modules out there which happen to access the files in tools/ directly. Accordingly, TB provides compatibility code to keep direct accesses to the older place working. This compatibility code might go away one day, but then it's trivial for module developers to change their code to the new place (or better: to make no assumption about where such code is placed). There's also no hurry to adapt to the new place either, for some time both places work. Also, module developer get instructions on how to change their code for future-proofness. In the end both, the module and the shop in general, will work better.

Screenshot, please :-) And a list of steps to get to the address form you see. Developers might see something entirely different, so a precise description is a big help.

Accordingly: don’t use this in a repository which will be needed after that packaging. FWIW, here's a package build script which does not destroy the repository. It can be run right in the developer repo and places a package there a minute later. 01491577001422build.sh Not too sure about the cleaning applied, but it shaves off another 3 MB and everything still works. Unit tests in imported source code packages aren't that helpful :-)

... if you think that's too much, modify your theme to require not all of them. The surplus ones can be removed them and generation of new ones turned off in backoffice -> Preferences -> Images.

Looking at what the demo products create might help to understand what's going on: sh $ find img/p/1/1 img/p/1/1 img/p/1/1/11-medium_default.jpg img/p/1/1/11.jpg img/p/1/1/11-thickbox_default.jpg img/p/1/1/11-small_default.jpg img/p/1/1/11-cart_default.jpg img/p/1/1/11-large_default.jpg img/p/1/1/11-home_default.jpg img/p/1/1/index.php Seven picture sizes per picture uploaded, so 85'000 is actually not enough. It should be like 25'816 * 7 = 180'712 :-)