Traumflug

File extraction complete. Now backing up files. Backup files in progress. 1438080 files left. Backup files in progress. 1437680 files left. Being curious on this I counted files in my developer installation: sh $ find . | wc -l 81809 This is with just demo data installed, but with .git and node_modules (for theme development). A regular installation should have some 63'000 files only, plus 10 picture files for each product. @netamismb, do you have more than 100'000 products installed, perhaps?

@nickon They told me that magento stores that data in a better way and google can access it better and get better data. Can they also express this a bit less vague? I mean, changing "storage" of meta data is pretty easy. But one would need a more precise description of what's needed. What exactly should go there.

@Occam Nice try, but we’re talking about translation items imported fom PrestaShop which have been messed up since years. Because PS failed to improve the situation thirty bees is doomed? Come on, I've heard better excuses.

Does clicking “favorite” mean an upvote? Nope, it's this little upwards pointing triangle to the left of the title. It says "upvote" if you hover over it. And yes, it's amazing how UI-ignorant this site is, considering it's targeted to developers.

@DaoKakao I really wondered, why such ugly/overcomplicated mixture of (almost)same terms appeared. Because there's more than one person involved in writing code. Each person has its own preferences on how to write code, this applies not only to translatable strings. And then ... well, when writing code, using elegant language in texts isn't exactly top priority. Code writers watch out much more for the code doing what it should do. That said, if you find such mismatching use of human language, don't hesitate to report them as code bugs (on Github). Changing such wording doesn't change how the code works, so it's easily replaceable.

@alwayspaws how do you use emojis in the quick replies to forum messages? Use traditional smileys. Those used before this graphical [censored] came up: :-)

Could you craft one of your nice short CSVs demonstrating the issue? Last time this helped a lot.

because v1.0.3 should be out real soon I believe this when it happens :-) Regarding the topic here, as one has to migrate to 1.0.1 before upgrading anyways, it doesn't matter much whether one migrates now and upgrades in a week or two or whether one does all this in one chunk. Amount of work is the same. Still, doing a migration now gives some headroom to deal with the issues coming up during the migration.

Let’s have single source of truth. Yes, good point. This means to get rid of the distinction between monoshop and multishop. All shops are multishops. Monoshops are multishops with just one shop defined. The question arising is, what's the gain for merchants? It's hard to justify a larger overhaul of pretty much the whole software, just to make the database layout a bit more pretty. Such a change also likely breaks lots of modules, so have your flameproof suit handy :-)

Currently that's not possible. One has to set this in Backoffice or in the database directly (table 'tbconfiguration' for monoshops, table 'tbshop_url' for multishops). That said, there was such a feature for a couple of days already. One of the ~20 commits introducing this change: https://github.com/thirtybees/thirtybees/commit/e628ed969a4b7e7d91cbd2851ce172033d12437f It was reverted and then postponed for thirty bees 1.1.x, because it changes storage, and by doing so, breaks compatibility with PS 1.6.1. At least potentially. This task was not yet picked up again, there's so much other work to do. For example, getting the updater module into dealing with database changes introduced by such storage changes.

I use a module called Pretty URL That's obsolete in thirty bees. URLs without ID work just fine without that module.

And is there a way to make AEUC and Ajax callback become aware of each other? By changing the code, yes, of course. That's plain development work.

Because it requires maintaining a custom Git repository and because I can't afford to give away all my work for free.

Looks like the JavaScript/Ajax callback ignores this AEUC snippet.

When I fix one issue here, another one shows up somewhere else… Do what Mark Watney (remember The Martian?) said: solve one problem at a time, then the next. If problems show up, well, not too bad. Because that gives a chance to solve it and if you tell us about it here, we can solve it for everybody.

have you guys considered creating a bash script No, because it exists as part of the testsuite already: sh php install-dev/index_cli.php --newsletter=0 --language=en --country=en --domain=localhost --db_name=thirtybees --db_user=root --db_password=mypassword --db-clear=1 --db_create=1 --name="Bash installed shop" --email=me@localhost --firstname=My --lastname=Hero --password=superhero Adjust parameters to your needs, of course. And using a distribution, change install-dev to install.

Well, @30knees, did you try this module? Modules compatible with PS 1.5 and 1.6 have a good chance to just work. If it doesn't work, what fails?

Here's a database capable of doing this conversion: http://dev.maxmind.com/geoip/geoip2/geolite2/ This page gives a strong hint the state is available via PayPal API: https://developer.paypal.com/docs/integration/direct/rest/state-codes/

Unexpected token < in JSON at position 0 Typically this is an Ajax request failing. Ajax requests expect an answer in JSON format and if this request sends back something like an error page (in HTML format, starting with < html >), you get this message. To find out what's going on, open web developer console, network analysis section, and redo what triggers this malfunction. One of the requested pages listed in the developer console should have a Status higher than 400. Click on this and you'll see what exactly was the answer. This answer should give a useful hint on what's going wrong. This description matches Firefox' web developer console, other browsers might do it a bit differently.

To fix it, just replace: ->select(‘MAX(position’) With: ->select(‘MAX(position)’) Well, forum tries to "enhance" single quotes. Inside a code block it doesn't: php ->select('MAX(`position`)')

@marci123 I think this proves that the open source model must not be feared. Yes, I'm aware of such success stories. And I can give you dozens of counter examples. Especially in the open source hardware market, where I was before joining thirty bees. With open source hardware, cheap cloners typically share about 95% of the market, while original developers get just those few customers caring about loyality or not caring about money. Accordingly these vendors have to survive from these remaining 5% (which is certainly possible in a > $10 mio market). And their R&D is on a hobbyist level at best to deal with this. http://www.wpthemedetector.com/top-theme-providers/ They count installations, not sales. 9 of 10 such counts could be pirated copies :-) When people ask me about open source, I usually answer "it's a shark basin".

@Occam And I guess it wouldn’t be easy to encrypt simple interpreter languages like php. One can obfuscate it, like changing variable names to random strings, like inserting a wild mix of Gotos, or similar things. This makes changing the code not impossible, but a lot more work. And there are encryption systems which are said to work, like http://www.ioncube.com/ AFAIK, these require to install a PHP module for doing the decryption. So, something can be done. But all these make things for situations mentioned by @lesley, merchants fixing modules them selfs, harder as well, of course. @marci123, @lesley, there's probably no doubt I love to be open source, too. Giving users access, so they can help them selfs. If you google for "Traumflug", you'll find myriads of contributions to open source. All of them done happily, no regret. But experience with all these years of open source is, that users as well as competitors happily cheat if it's made too easy. Or in other words: open source and asking for money doesn't mix. Yes, there are companies working on open source commercially out there, but most, if not all, make their money not with open source directly, but with work adjacent to this. Like installation and maintenance services, like writing custom code, like delivering the required hardware. Another experience is that open source tends to prohibit larger steps in development. That's not much of a problem with matured projects like the Linux kernel or thirty bee's shop core, because these evolute just fine in small steps. But consider spending a year into writing some revolutionary module. Not cheap, still you offer it unencrypted, you sell a couple of copies. And then, two weeks later, another module developer offers a very similar module, just a bit shinier. 95% of your code plus some polish. Merchants will of course run for this shinier module, often just because it's newer, or because it's cheaper, and sales for the person who did all the hard work pretty much stops. Such scenarios happen regularly, which is why developers writing open source don't even start with large amounts of hard work. What I want to say is that there are very valid reasons to not hand out source code. And selling modules unencrypted is almost like open sourcing them. A good way out of the dilemma described here appears to be establishing mild protection mechanisms. They should make pirating software a substantial amount of work, so users prefer to pay some price instead of doing it. They should make very clear that this or that module is not open source. Selected merchants adjusting modules them selfs can get copies of the code. For some module maker business models that's necessary, we all need food on the table :-) OMG. Can't believe I speak out for closing source code here :-}

I'm a bit surprised seeing people surprised about this tracking thing. AFAIK, PrestaShop always did this and thirty bees does it, too. Installing either of them gets one subscribed to a mailing list, which is kind of tracking, too. Module pages automatically search for upgrades, so the module server nicely tracks activity in backoffice. And if I'm not mistaken, I've seen a tracking pixel somewhere in backoffice. I might be wrong on the latter. Anyways, having a PS/30bz shop installed can't be hidden (unless one removes this tracking deep in the code before doing so). Now, if this PrestaTrust thing could offer a code encryption technology in the sense that module customers can no longer read the code, it'd be a useful technology. Similar to what IonCube does. To my knowledge, "borrowing" code from competitors happens among module creators, which isn't always helpful for the success of these modules. Can't say whether PrestaTrust offers this, because, well, I can't read French either.

Thanks, that's helpful. Unfortunately I can't kneel into this right now, I have kind of a masterpiece to do first.

Funny language mix, eh? As this is an english section of the forum, let me translate the last paragraph: If you want to participate at Crowdin, you should recognize that most of the source code was written by people being not exactly excellent in English. You should review any errors, misalignments, mistakes and misleading words in their context before translating them. My answer: looking at the context is always a good idea, no matter how well code writers know English. Because many words have different meanings depending on this context, in any language. And often this context helps a lot to find better sentences than just direct translations. German can be very elegant when not translating words, but meanings.