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.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Traumflug

  1. For now I couldn't reproduce the scenario shown above, that's true. The installation was just three days before beta.2.
  2. And showing both is a bug, obviously.
  3. 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.
  4. 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 :-)
  5. Thanks. Github issue already created: https://github.com/thirtybees/thirtybees/issues/176
  6. Great! Bug reported and already solved! I like this :-)
  7. 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
  8. 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.
  9. 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.
  10. 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 :-)
  11. Traumflug

    Images again

    ... 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.
  12. Traumflug

    Images again

    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 :-)
  13. I see this in build.sh: rm -rf .git Accordingly: don't use this in a repository which will be needed after that packaging.
  14. sudo: apt-get: command not found Obviously you have no Debian/Ubuntu based system, so I can't help much. Googling terms: LAMP (Linux), MAMP (Mac), perhaps even WAMP (Windows)
  15. I see thirty bees' version tag being bumped in the Git repository, but I see nobody talking about this. Anyways, TB is now 1.0.1-beta.1: https://github.com/thirtybees/ThirtyBees/commit/933a73ed719ccaf77c28b6e5a90996f073e74d6f Bonus points if one of the developers can make us a package to allow testing for those folks not comfortable with Git :-)
  16. Some good thoughts: https://github.com/twbs/bootstrap/pull/20332
  17. A local installation is just fine for testing. sudo apt-get install apache2 libapache-mod-php mysql and one has a fine web setup accessible via http://localhost/. These webhosters use the same software, after all.
  18. One of the best things about PS 1.7 is IMHO its new "Classic" theme. Not only because it's cleaner on the user-visible surface, but also because it's cleaner code. It uses libsass instead of compass, which is said to be faster. It uses the NPM packaging system for libraries instead of copying them into subfolders. It uses webpack for automatic building and also building all sources into a single pair of .css and .js files. Downloading one bigger file is obviously faster than requesting each file separately. Webpack also allows optimization, like dead/duplicate code removal (gives me some 30% smaller files on PS 1.7). The unfortunate thing about this Classic theme is, it's incompatible with thirty bees. I looked a bit into getting it running, but creating kind of an adapter appears to be several months of work. ... which doesn't mean that thirty bees can't use similar strategies for just building the theme, without breaking backwards compatibility. Sass is still Sass, JavaScript is still JavaScript, Smarty is still Smarty. The question: is it a good idea to use libsass, NPM and webpack for building the thirty bees theme, too? Is NPM better than composer, which is already in use for modules? Are there even better tools? I'm about to get into theme building, so I could improve the thirty bees infrastructure a bit along the way.
  19. The biggest problem I had was the class ObjectFileModel being undefined. Clearing the autoloader cache (or rm -rf cache; git checkout cache) should help. I've put the migration module onto my todo list. Also providing some upgrading code is certainly a good idea :-)
  20. Hmm. Postponing this for 1.1.0 is a good idea. TBH, I was a bit surprised you accepted that pull request with no less than 26 commits so quickly and for a bugfix release. If you can describe a bit what "unstable" means I'll work on that, of course. Now I can also search for a way to eliminate this global variable while keeping cache-ability.
  21. Any thoughts? What's the setting in backoffice -> Preferences -> SEO & URLs -> Set shop URL -> Base URI? This is initialized to what PHP reports, which might be different from what Apache expects. Does changing that Base URI help?
  22. No need to write that in bold, @alwayspaws, we all know this. :-) If I have concerns about TB at all, it's certainly not about developers being lazy. More like the opposite, those people being too enthusiastic, trying to fix all the known code issues at once ... and never managing to get even a bugfix release settled with all this enthusiasm.
  23. I made a screenshot with the footer DIV highlighted, this should explain the issue. It's a 2096 pixel high footer :-)
  24. It's not about formatting links. I just looked into the issue a bit and found to be taller than the entire page and in front of all the other content. Links are there and probably working, but "hidden" behind the tall, transparent footer.
  • Create New...