Traumflug

@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.

There's no reason to believe that these two errors are related to each other. smartblog messes up a DB query somehow, the beesblog problem is likely something entirely different. In the first post here you wrote about a missing class. Can you reproduce this? And it's always a good idea to clear the autoloader cache by removing file cache/class_index.php. It'll be recreated automatically.

BlockRSS isn't one of the modules installed by default. It doesn't even come with the distribution. Still it should work if it's available on the module server, of course. P.S.: some code of uninstalled modules is still executed as long as they're available on disk. Despite their "uninstalled" status, that's how the module mechanism works. To entirely remove them, use the 'delete' menu entry. After that the menu should show just 'mark as favorite'.

PS 1.7 default theme has the slider disabled on mobiles. Disabled by this "Disabled on mobiles" menu entry where one can enable/disable entire modules in backoffice.

[...] gave me an error message "All parts of a PRIMARY KEY [...] Excellent idea to describe these errors. Could you also make a screenshot? Such messages usually come with additional bits around them. You can upload images right here in the forum, using the non-quick Reply. Apparently there's a reason why this module isn't installed by default :-/

Disable all the extra modules and enable them one by one to see which ones are slowing it down? That's indeed a good debugging strategy.

What did you enter into the text box? Nothing. I handcrafted the URL. Just copy the text above the picture into your browsers address bar and get the same result. Then change this URL to change the result.

@vzex Regarding this one, it works with handcrafted URLs (manual see on the generator page). For example https://dummyimage.com/1170x65/000/f00/&text=welcome+to+our+store+ALL+SALES+20%25+OFF!:

How to handle this mess in a good way, so it always either works or gives a meaningful error message when it doesn’t? A long term solution is certainly to do not one Ajax request for all modules, but one such request for each one module. To solve the problem at hand ... it's a bit of a guess right now, but I think it works to save a list of all folders in modules/, then to remove all these module folders, except tbupdater, before starting the installation. Can be done via shell or via FTP. Then start the installation, the module installation step should finish pretty quickly. This bare-bones installation should basically work, even with the shop front page being almost empty, no admin dashboard, etc. Then one can install all the modules the usual way, one by one, in Backoffice. It's not even necessary to restore all the module folders.

Excellent, thanks for the outline, @Occam. Actually I thought about rewriting AEUC, too, but so far I had no golden idea on how to do it substantially better. Applying rule by rule, as written into law, can be done, of course, but also inevitably ends up in a large pile of hardly maintainable code.

@marci123 Man kann 30bz durchaus als PS 1.6 sehen, das eben nicht ausläuft. Dem werden sich auch die Modulentwickler nicht entziehen wollen, wenn sie mit ein wenig Pflege bestehender Software durchaus Umsatz machen können. Hier im Forum treffen quasi jeden Tag neue Benutzer ein, die gerade am migrieren sind oder schon migriert haben. Dazu all die, die auf thirty bees setzen, ohne sich hier zu melden.

Perhaps it'd be a good idea to make a list of what distinguishes a B2B shop from a shop displaying prices without tax, then. I'm aware of these: Prices are displayed without tax, still tax is added to the price to pay and mentioned at the bottom of the cart/checkout and on the invoice. A mechanism making sure a customer is indeed a business customer. Typical solution is to ask the customer for a tax ID (available field on the signup page), then to give these customers some property qualifying them as B2B customers (doable by assigning them to a group). Allow customers to order without paying (payment happens by invoice later). As you talk about "how the checkout and invoice should look like": well, that's exactly what I mean, too: it's a pure display thing. All the core calculations remain the same. Instead of checking a shop-global flag/property, one better looks for a customer group property when rendering the screen and PDF display.

Da wir jetzt auch einen deutschsprachingen Bereich hier im thirty bees Forum haben, will ich alle Betreiber deutschsprachiger Shops willkommen heissen. Zur Geschichte von thirty bees Die Geschichte von thirty bees (immer klein geschrieben) begann mit einem Fork von PrestaShop 1.6.1.11-beta.1 im Januar 2017 und hat sich seitdem schnell weiter entwickelt, obwohl die Kompatibilität zu PS 1.6.1 weiter gepflegt wird. Warum thirty bees? Am auffälligsten ist, dass thirty bees durch diverse Änderungen im Hintergrund deutlich schneller arbeitet. Es gibt jetzt z.B. einen Full Page Cache, dafür ist die HTML-Minimierung weggefallen. Auch der Code wür die Datenbank-Zugriffe wurde überarbeitet, wodurch diese rund 15% schneller wurden. Gleichzeitig bleibt die nahezu volle Kompatibilität mit PS-1.6.1-Themes und Modulen erhalten. Nach und nach konnte bestätigt werden, dass die meisten Module ohne Änderungen weiter funktionieren. Braucht man also das eine oder andere Extra-Feature, einfach bei den PS-AddOns nachschauen. Die Migration ist denkbar einfach. thirty bees bietet das Modul "OneSixMigrator" an, das im PS-Shop installiert wird und mit dem man diesen Shop mit wenigen Mausklicks in einen thirty bees Shop migrieren kann. Der wichtigste Grund für thirty bees scheint mir die Kultur des Umgangs mit Macken (bugs) und Benutzerwünschen zu sein. Für Benutzerwünsche gibt es eigens einen Bereich Feature Requests, in dem man seine Stimme für (oder gegen) Verbesserungen abgeben kann. Pull Requests werden nicht liegen gelassen, sondern oft noch am gleichen Tag behandelt. Um Macken wird sich gekümmert. Schaut man in den Forums-Bereich bug-reports oder in den Bugtracker, sieht man, dass die meisten Macken, kaum dass sie erkannt sind, nur wenige Tage überleben. Erklärte Ziele von thirty bees "Ecommerce that works". Die Behebung von Fehlfunktionen hat eine deutlich höhere Priorität als neue Funktionen. "Listen to the merchants". thirty bees hört auf das, was die Shop-Betreiber wollen. "Full PS 1.6.1 compatibility for all 1.0.x versions". Der Zweig 1.0.x, aus dem die Versionen 1.0.1, 1.0.2, etc. entstehen, bleibt voll kompatibel mit PS 1.6. Die Pflege dieser Kompatibilität ist bis mindestens 2019 zugesagt. Meiner Beobachtung nach wird man auch nach 2019, bzw. im 1.1.x-Zweig, nicht wild Dinge ändern, nur um sie anders zu machen. Die Kompatibilität zu bestehenden Shops ist ein wichtiges Asset, das man nicht ohne Grund aufgibt. Links Blog und Developer Blog Github-Repository Core Github-Repository Standard-Theme @wakabayashi's Tutorial zur Migration (17 Minuten, mit englischem Ton): https://youtu.be/LN7KD9W_MY4 Erst eine ausführliche Anleitung, wie man ein Duplikat des Shops für Testzwecke erstellt. Ab Minute 10:20 die eigentliche Migration. Weitere Links dazu: Anleitung (englisch) Download des Migrations-Moduls

Feature requests go here, please: https://thirtybees.com/feature-request/

The question now is, where can we get such a pretty thirty bees coffee mug, isn't it? I'd need an extra large one :-)

@Occam and how would you make it happen then for example that the checkout - let’s say in in Germany - displays the net sum plus required tax totals after you defined this (B2B) customer group with prices tax excl.? The same way one always does. Prices for ordinary customers have a price with and one without tax, just as prices for business customers do. Distinction is just a matter of a different display. Removing the idea of a B2B mode in favor of more universal means opens entire new opportunities. For example, one can sell wares meant for ordinary customers to business customers and vice versa. As long as nobody is logged in, prices with taxes are displayed (as law requires), as soon as a visitor is recognized as a business customer (by logging in), display changes to prices without tax. If a merchant's idea is to have a B2B-only shop (which is a bit tricky to get it right under German legislation), simply apply these B2B price display rules to customer groups "Visitor", "Guest" and "Customer". That's it, pretty straightforward.

P.S.: regarding reduced prices for business partners I'd usually choose to simply give reduced prices for larger packs. A business partner buying single pieces should get the same price as a normal customer, just as a normal customer ordering in packs of 100s should get this "wholesale" price. US based shops for electronic components (DigiKey, Mouser, etc.) usually work this way. No custom treatment for B2B. But which strategy to choose should be the merchant's choice, of course.

This whole strategy looks a bit narrow minded to me. I think the right thing would be to remove this "wholesale price" and also "B2B" mode. Why? Well, business partners are just customers, too. They usually get a different price, just like customers buying often or customers being of a specific profession or whatever qualifies for a non-standard price. This means, specific customer groups should be able to get specific prices, as a general solution. Want B2B? Well, create a group for B2B customers and put these prices there. Want wholesale customers? Create a group for them. From the software POV, business partners are just one group among many. Such a general solution solves not only all the situations discussed here with more straightforward code, but also opens new opportunities. One can have any number of these special customer groups. Like members of a soccer club getting balls and shirts for a reduced price, for example. Yes, I'm aware that there are already "specific prices", which try to work with this strategy. Apparently there's something missing to make it a good general solution for every situation.

A few additional datasets not subject to legal obligations come to mind: Newsletter subscriptions, maybe it happened by accident or a customer changed his mind. Files uploaded for customized products. Maybe a good strategy would be to keep just copies of the emails sent out during the order (order confirmation, payment confirmation, invoice) offline and delete everything stored in the shop software. This way, the public server is indeed free of any personal data, thus email and payment information can't be hacked, merchants are more safe against eventual database failures, still it's not too much work to reconstruct a purchase years later (just search that mailbox with copies).

But there is half a kilogram of flour. I think the way to go is to make the base really small, like 1 cm or 1 gram. Then to use unit prices to get more human-convenient price displays. Perhaps together with some CSS tweaking to make the unit price more prominent. The unit for unit prices should be independent from the unit for orders. For example, selling coffee in 450 g packages still requires the unit price to be for 1 kg, even if there's no multiple of 450 g which matches 1 kg. This probably needs some experimenting. Also the problem that one gram might cost less than 1 cent, so the price could be rounded to zero. IIRC, all tests so far had wares sold by the piece in mind.

Developers which can migrate a Shopify shop into a thirty bees shop? Certainly possible.

Nice advertising speech, @dynambee. One can have all this plus some hosting for 1.95/month. Just not at this candy-color company.