Traumflug

I see this in build.sh: rm -rf .git Accordingly: don't use this in a repository which will be needed after that packaging.

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)

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 :-)

Some good thoughts: https://github.com/twbs/bootstrap/pull/20332

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.

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.

Which steps are required to reproduce this?

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 :-)

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.

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?

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.

I made a screenshot with the footer DIV highlighted, this should explain the issue. It's a 2096 pixel high footer :-)

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.

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.

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.

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

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.

"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!

Good point, @roband7 :-)

Nice to have such a module! Maybe it should even become part of the standard image handling page. Still I wonder a bit why there's an "original copy" switch. Hard to imagine a reason to not keep the original unless one never again wants to regenerate thumbnails. Same for the "progessive" switch: there's AFAIK no point in having non-progressive JPEGs. Each switch, choice, checkbox comes at a cost: Every user has to learn about the "better" position of that switch/choice/checkbox. This is time consuming and if the outcome of that learning is the same for virtually all shop operators, a waste of efforts. More options require more code, so more chances for bugs, additional code maintenance burden, larger memory footprint, etc. My $0.02

The part replacing the shop_url DB table by a file is done, see https://github.com/thirtybees/ThirtyBees/pull/162 To achieve fully scriptable shop synchronization, configuration variables PSSHOPDOMAIN, PSSHOPDOMAIN_SSL and a few others have to go away, too. That's a separate task. Code for backwards compatibility will be provided, of course, so a Configuration::get('PS_SHOP_DOMAIN'); will still succeed, even if there's no longer such a database entry.

Good news: I removed the shop_url table here and the shop continues to work :-) I hope I catched everything. Stuff like this: PHP foreach (Shop::getAssoTables() as $tableName => $row) { // ... $res = Db::getInstance()->getRow('SELECT * FROM `'._DB_PREFIX_.$tableName.'` WHERE `'.$id.'` = '.(int) $oldId); is hard to catch, because not grep-able. For now I simply hope this is never called with $tableName = 'shop_url'. Next step is to adjust the installer. Then to get rid of PSSHOPDOMAIN, PSSHOPDOMAIN_SSL, etc.

@yaniv14, you know best which files you're seeing. We do not see them and you don't tell us either. You can also look into .gitignore, it's part of the repository. You can also create another clone for testing if the previous clone contains valuable work already. For me, cloning the repo works just fine as well.

Must be hard but interesting to start on a mission like TB. TBH, I'm a bit surprised to see so many bugs coming up. One would think that cloning an open source repo and just replacing the brand gives a fully working system. But I'm positive. Looking at the commits so far it's apparent that they're done by people knowing their stuff. And old stuff gets deprecated. Very good!

With Git one can add individual files ... sh git add <path/to/file> ... or even individual patches: sh git add -p Then do a git commit and the new commit will contain the selected changes, only. If you want to revert files that shouldn't have changed, simply check them out. By file or by folder.