Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Traumflug

Administrators
  • Content Count

    1,322
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by Traumflug

  1. FWIW, PS 1.7 does show results as one types, so one option would be to grab code from there. (Theme is Classic with heavily modified CSS)
  2. Is this topic solved? Please mark it as solved then, @atolodas. It's behind these three dots to the right of 'reply' and 'quote'. P.S.: actually I was wrong about this three-dot hamburger menu. Marking topics as resolved is in 'Topic Tools', rightmost in the series of buttons at the bottom of the first post.
  3. The six remaining commits were accepted and are now on Git master. Thanks, @mdekker.
  4. All 24 commits of mine were just moved to Git master. Thanks, @mdekker and thanks, @Havouza, for testing it.
  5. Traumflug

    Git ignore?

    If you wonder whether it's normal to have a couple of commits on top of the public ones: yes it is. My own development repo currently carries a stack of 69 commits on top of master. Most of them already provided as pull requests, but also simple ones like "turn on debug mode".
  6. Traumflug

    Git ignore?

    These are not unexpected. They're generated by one (or more) of the automatic upgrade processes built into 30bz (and PS). Either do a git checkout . to reset them or create a commit with all of them. Adding them to .gitignore isn't a good idea, because the English versions of these files are tracked in the main repository. At least at this point in time.
  7. Just trying a provider won't reveal whether this provider looks into your data. But data is there and unencrypted, so he can. The same is true for any other provider, of course. Unless you rent/own a full server equipped with an encrypted filesystem and do server maintenance yourself.
  8. Will melt down this work to align with what's now on master and pull request that tomorrow. Not everything lost :-)
  9. I created a generator using PHP, I also removed the file from the Git repo, I implemented nice messages for developers, where the file doesn't exist. And of course I triple-check code before providing it to the public.
  10. So I worked a full day for the trashcan. I thought it was clear that I'm working on this.
  11. 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.
  12. 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?
  13. 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 :-)
  14. 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.
  15. 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 :-)
  16. 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.
  17. 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.
  18. 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.
  19. 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 :-)
  20. 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.
  21. 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.
  22. Does it match this? https://github.com/thirtybees/thirtybees/issues/178
  23. For now I couldn't reproduce the scenario shown above, that's true. The installation was just three days before beta.2.
  24. And showing both is a bug, obviously.
  25. 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.
×
×
  • Create New...