Traumflug

@vincentdenkspel said in 3000% funded !!: TB needs a large user base that is willing to contribute by contributing code, bug fixing AS WELL AS money in some sort of way. I'd exchange this 'as well' with an 'or'. The traditional open source model worked with many people contributing, contributing with the community in mind, and that worked well. It still works in a couple of projects, like e.g. Linux or Git. With many code contributions coming in, maintainers just have to sort all the solution, review and apply them. Much less work, code contributions certainly have as much value as money, perhaps even more.

What about Backoffice -> Orders -> Orders? There's a messages section when displaying a single order and these messages will be sent by email, too.

@daokakao said in 19 Patron ?!: Not VPS, but pre-bundled and preconfigured image where most options and setting are set already up. If such a preconfiguration can be put into a bundle I see no reason why this couldn't be put into an installer, too.

My question was directed to @shogun . This bug report was an excellent idea and I thing it's complete enough to allow researching it.

@daokakao said in 19 Patron ?!: So, it would be nice to provide (potential)customers with all possible choises More choices mean a steeper learning curve. Not sure whether this would be helpful for users like @alwayspaws . I'd tend more towards "software should figure all these choices on its own".

@daokakao said: Just a small preamble: @alwayspaws experiences a difficulties as with local environment setup as with the shared hosting (because most of them has some limits, more or less weird/concerning), and, as an ordinary merchant she’s not the only one who faced such kind of troubles. Yes, I'm aware of this and it's unfortunate. But I don't see how using a VPS could fix this. Especially on a local setup she has all the powerful knobs at her disposal, even more than on a VPS. Possessing these knobs is obviously not sufficient. Like always, these issues have to be fixed one by one in the software. Let me take this opportunity to say a big THANK YOU to @alwayspaws for reporting all of them (instead of walking away).

@wakabayashi said in 19 Patron ?!: Sure 10$ a month is also nothing if you want to become an online shop. But not many merchants are thinking the way you are Well, I think much of this has to do with how people recognize open source software. For many years, since the idea of open sourcing software came up, the paradigm was "See, it's free as in beer, so it's always cheaper. And it's open, so it magically heals its self!". This paradigm got serious cracks over the last few years. One of these cracks is software complexity, even talented developers can no longer dive into the code for fixing some issue within a couple of hours. Dedicated developers are needed, and they need food on the table, so they have to get paid. With the need to pay for open source software users/customers open up a simple comparison: "Why should I pay for this open source thing if I can get another software for the same money which comes with developers responsible for fixing it?" And they still have this original open source paradigm in their mind. The new paradigm of open source software is the emphasis on that open source software is safer and more reliable. It certainly is, because many more eyes look at it. At least all these eyes can look at it. Maybe it sounds snobbish, but people have to learn that "free" no longer means "zero money". They have to contribute something, either in form of money or in form of bug fixes and feature enhancements. How to get there? Crowdfunding looks very promising, IMHO, at least for feature enhancements. While I'm not part of the target audience for the Elastic Search module I'm very glad to have seen a successful funding. And Patreons are those caring about reliability as well as constant small improvements. Getting people into recognizing that their $10/month is an excellent investment as it allows people like @mdekker, @lesley (or even me) to spend their time wading through Github issues, pick them up one by one and getting them fixed. Maybe bugs reported by Patreons should be fixed with priority? Might be a good strategy to get the idea spread.

@DavidP I basically got pissed off with @Traumflug and others about their viewpoint that this community is to serve users of TB and not to serve merchants [...] as @Traumflug pointed out in another post about the warehouse theme guy using WooCommerce because it was easy to setup - TB needs to just be installable, no ‘you’ve got to do this, that or whatever’ to make it work. So you're pissed off and like what I'm saying at the same time. :scratchhead: The only thing I can say that users of 30bz and merchants are the same for me. Allowing merchants to do their business it the whole point of thirty bees. Which doesn't mean I agree with every merchant. Can't mean it, because distinct merchant also have distinct, sometimes contradicting ideas on how the software should work.

A VPS is very cheap nowdays. Still a lot are on shared I'm on shared because it's less work. Just upload the code an it works. No need to deal with email setup, backup, DNS, PHP versions, whatever. If a VPS comes with the same amount of services, well, then it's about the same as a shared host, isn't it? If a shared host would no longer suit my needs, I'd go with a dedicated server. Because the 'V' in VPS means virtual, which reduces performance somewhat. But I'm far away from a need for that much processing power. Even farther from having a need to spread the installation across multiple hardware instances. I'm not Amazon.

To test whether it's actually the same, could you try to order a product which is not a Pack using the same procedure?

This looks much like this (known) bug: https://github.com/thirtybees/thirtybees/issues/406

Yes, works for me now. Great work!

I had similar discussions with Lesley earlier and my impression is that he's mostly concerned about usability of the shop software. And I can understand this well, setting up a shop is pretty complicated already, even in the United States. Just look at the hundreds of settings a merchant has to take care of (or cross fingers for luck) in Backoffice. With this in mind it might be helpful to direct the discussion a bit more towards how these regulations can be met without adding burdens to merchants and customers. Keeping usability high isn't simple, but it's crucial for success. That's the distinction between a powerful software and a successful software. I think we all agree to want a successful software. One detail as an example: thirty bees allows to set up shops without secure transfer, without HTTPS. There's a whole lot of code dealing with both, the HTTP and the HTTPS case and for switching between them. This slows the software down to some extent. There are Backoffice options which have to be set and which have to be taken care of. Which is a burden for merchants. And all this in 2017, where running a public shop without a secure protocol is no longer an realistic option. Which means, this distinction can be removed from what's visible to merchants. Keeping the power, making the software faster, liberating merchants. By wise design decisions. While this detail example isn't part of the law discussed here I hope it sheds some light on ways to comply with this law: find ways to get it into "just works" and everybody will be happy. My dream is a choice "Law to comply with:" and a menu just listing all the countries. One choice to be done for being reasonably safe on the regulations side everywhere.

Adding them again also gives the opportunity to find out whether they still exist :-)

There's also the "thirty bees cleaner" module. It allows to delete (test) orders together with (test) customers by a mouse click.

All old prices can be kept in the old orders, for example. Yes, this is one way of archiving history. The other one is to just store reference pointers, along with the unchanged reference its self. That's a design decision software developers have to do. Both approaches have advantages and disadvantages. Prestashop took the choice to keep unchanged references. If some modules chokes on this I'd say they're simply not Prestashop or thirty bees compatible.

I added *automatic* domains. Setting the domain to *automatic* means that not only Backoffice, but also Frontoffice works on any domain. See the help text in SEO & URLs.

@lesley Did you change the url in the database in the tb_shop table? Even a "wrong" domain there shouldn't stop one from logging into Backoffice.

Database password (in phpMyAdmin) and shop password are two distinct things. I'm not aware of a simple way to reset the shop password directly in the database, because the password is stored encrypted there. As a stress relieve and if I forgot my password doesn't work, you can apply this patch to classes/Employee.php: ```diff @@ -390,11 +390,11 @@ class EmployeeCore extends ObjectModel if ($activeOnly) { $sql->where('active = 1'); } $result = Db::getInstance(_PS_USE_SQL_SLAVE_)->getRow($sql); - if ($plainTextPassword && !passwordverify($plainTextPassword, $result['passwd'])) { + if (0 && $plainTextPassword && !passwordverify($plainTextPassword, $result['passwd'])) { $sql = new DbQuery(); $sql->select('*'); $sql->from('employee'); $sql->where('email = \''.pSQL($email).'\''); $sql->where('passwd = \''.md5(_COOKIE_KEY_.$plainTextPassword).'\''); ``` "Applying", like changing the red line to look like the green line by adding this 0 &&. It's line 395, method getByEmail(). Then you can login with any password as long as it's longer than 7 and shorter than 255 characters. Stored password no longer matters. This should give you a chance to look at what's going on. While Backoffice should still work on a "wrong" domain, it's certainly a good idea to correct them in Backoffice -> Preferences -> SEO & URLs. ... and don't forget to revert the above change after setting a new password, of course.

The AEUC module should add such a section to emails on it's own. Via a hook, without changes to core code. Template is modules/advancedeucompliance/views/templates/hook/hook-email-wrapper.tpl. While I can't look at the AEUC configuration page right now (some unrelated debugging in progress), I'm pretty sure on can turn this hook on and off there.

So this is long time and no one cares. Yes, PS to be buggy was kind of an accepted feature of this shop software. On top of this, legal compliancy has a long history of being mostly ignored, because there are only few countries where having an illegal shop is a serious risk. This is thirty bees now and thirty bees puts a lot of emphasis on removing this bugginess. Hundreds of long existing bugs were fixed already, please don't stop reporting those yet to be found and fixed.

This behavior might be by design. The idea is probably that older orders are related to the older version of the carrier, while newer orders get the newer one. The obvious assumption is that carriers don't change. Accordingly one has to set up carriers first, then configure these modules. Can you give us an idea on why these carriers need changing?

With this line of shell code... sh grep --exclude-dir vendor --exclude-dir cache -rn -- '->l(' | grep -v '(.*)' ... I see 62 similar violations, most of them in module advancedeucompliance.

Habe auch nochmal ein wenig probiert, das wird ja immer lustiger. Bei mir ist es genau umgekehrt. Schalte ich den Cache ein, sieht es gut aus. Schalte ich ihn aus, fehlen die Mwst.-Angaben. Wenn ich dann beim Modul auf "Configure" klicke, bekomme ich eine DB Exception: Table 'thirtybees-dev.tb_aeuc_email' doesn't exist Da muss ich wohl nochmal ran.

Du kannst ja mal in die hookDisplayProductPriceBlock.tpl im Modul schauen, ob das {nocache} da drin ist. Ist gleich die erste Zeile nach dem Lizenz-Kommentar. Ansonsten will ich nicht ausschliessen, dass es da noch eine zweite Macke gibt.