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,320
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by Traumflug

  1. Great! Bug reported and already solved! I like this :-)
  2. 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
  3. 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.
  4. 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.
  5. 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 :-)
  6. 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.
  7. 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 :-)
  8. I see this in build.sh: rm -rf .git Accordingly: don't use this in a repository which will be needed after that packaging.
  9. 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)
  10. 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 :-)
  11. Some good thoughts: https://github.com/twbs/bootstrap/pull/20332
  12. 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.
  13. 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.
  14. 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 :-)
  15. 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.
  16. 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?
  17. 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.
  18. I made a screenshot with the footer DIV highlighted, this should explain the issue. It's a 2096 pixel high footer :-)
  19. 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.
  20. FWIW, in a boring Sunday mood I wrote fixes for 2.: https://github.com/thirtybees/ThirtyBees/pull/165/commits/bee6afaad64d8bcb0c5039fd02dba16877485c61 and 3. (with bonus): https://github.com/thirtybees/ThirtyBees/pull/165/commits/40ae5c1aaa0cc18326de0a045cd83b7bf75aeb76 an made a pull request for that: https://github.com/thirtybees/ThirtyBees/pull/165 No. 1. not fixed because "PrestaShop" appears to be more correct than "Thirty Bees" for me. No. 4. not fixed because I couldn't find the issue. Is "main splash image" the image slider in front office? Then it's in a module anyways and I wasn't encouraged enough to fork all the module Git repositories so far.
  21. Having a browser window width between 992px and 1199px, the documentation page is completely ignorant. No link underlining when hovering, menu items don't highlight, buttons or menus not clickable. As if the whole page was just a large picture. On narrower and wider screens it works fine. P.S.: Browser is Firefox 52.0.2 on Ubuntu 16.10.
  22. The set of commits moving table 'shop_url' is to a file is already on master, thank you to Michael for accepting it. Next pull request is about removing configuration variables PSSHOPDOMAIN and PSSHOPDOMAINSSL. My impression is, these two were kind of deprecated before already, even the backoffice page for setting them used the 'shopurl' table already. Pull request is here: https://github.com/thirtybees/ThirtyBees/pull/164 To those thinking now "OMG! He breaks virtually all modules!": There's backwards compatibility code. A Configuration::get('PSSHOPDOMAIN') still succeeds properly (and returns the domain of the first main URL). Just querying the database directly, something code shouldn't do anyways, breaks. Replacement is straightforward, see this commit message: https://github.com/thirtybees/ThirtyBees/commit/0614b131da05623c60ba1fe2f74dd23fa53cd626
  23. No problem if its just time. It's not your time and for me this time is easily compensated by reduced shop downtime and an upload script not forgetting to fix the database. Once this works I can simply ./upload.sh and forget about all the extra steps. Each time I do an upgrade or change something on the theme design. What about differences between two databases? They shouldn't matter. Functionality and design should be independent from content.
  24. "bs", like "beautiful surprise"? A real life example? sh cd /var/www/html/ cp -rp my-shop-test my-shop-live After that, 'my-shop-live' won't work without digging into backoffice and fixing things there. Which in turn disables 'my-shop-test'. Another example: - Go to http://localhost/ and install ThirtyBees - Go to http://127.0.0.1/ The latter won't work either, it'll redirect to localhost. Even if it's a small problem, it should be fixed. However, I'm not aware of any other problems preventing shop synchronization. And to some extent I wonder why you lament here and on Github instead of showing us on how to synchronize a TB/PS-shop. If the strategy described in the opening post here is achievable so easily, post the solution!
×
×
  • Create New...