Traumflug

Agreed, Wikipedia has its own mindset. A mindset which isn't always obvious to mere humans. I'm occasionally participating there and as such, gained a few privileges. Not much, but something. And I also engaged in a couple of deletion battles, which gives a lot of insight into how these Wikipedians think and act. On top of that, distinct language wikis also come with somewhat distinct mindsets. In German Wikipedia it's perfectly fine to have unfinished pages in user space, as long as it doesn't stretch the ruleset too much (e.g. by being straight advertising or a pure link collection or a copyright violation). As @DavidP says, having a WP page has quite some benefits. Wikipedia kind of defines what's relevant and also what's true these days. About everybody looks there, first. A few keys for success: The stated ruleset for page content is extremely important there, no exceptions. Look at what deleters say. They always give a reason. If not, it's a ruleset violation which can be challenged. Put some love into it. A few quickly jotted down sentences is the last thing Wikipedians want to see. They love their Wikipedia, so they want to see this love respected, e.g. with carefully crafted sentences. Wikipedians are very well aware that a whole lot of people create pages not to make Wikipedia a better place, but to boost them selfs or to advertise their shit. They hate it and act accordingly. That said, I can't find this page in the deletion logs. User Inetbiz was created in 2010, its user page deleted in 2015 for advertising. Sub-page thirty_bees exists, but has a one-edit history only. Wikipedia never forgets, so where is this page? User pages are fine for drafting and development, but they don't show up in search engines. To get an article into the regular space, its subject has to be notable. What that means? See the ruleset: https://en.wikipedia.org/wiki/Wikipedia:Notability and https://en.wikipedia.org/wiki/Wikipedia:Notability(software) and https://en.wikipedia.org/wiki/Wikipedia:Softwarenotability

To be honest, I currently can't imagine what might go wrong. Nevertheless, here are some steps which might get more insight. Each step is a separate attempt, you can try one after another: Using your browser, remove all cookies for that domain. Recently an issue with garbage in an old cookie was discovered (and fixed). Try with a very simple password, like 1234567890. It might be an UTF-8 issue or something. Try changing encryption algorithm in Backoffice -> Advanced Parameters -> Performance -> Ciphering. Default is Rijndael. Safest one is PHP Encryption library, Blowfish is for compatibility (I think). Uninstall all modules not coming with thirty bees. Then look into /overrides and remove all files ending with .php, but not named index.php. Overrides are one of the most often seen causes for weird behavior. If you can log in then without the hack, add them back one by one; this will restore overrides; exercise logging out and in each time to find the nasty one.

@davidp said: I see all the issues people have on here with payments and emails and those sort of problems would kill my stores, it’s just too big a risk to take. I wonder whether the distinction is that these issues get reported here while they exist unreported in PS. thirty bees' track record of fixing issues in a timely fashion is pretty good, IMHO. Regularly, only a couple of hard to diagnose bugs survive more than a few days. PS' bug tracker is full of issues unresolved for years, so people might have simply given up on discussing them.

@jnsgioia said: When you are on the edit page of your combined rule you need to add the states one at a time. That is click the “add new rule” button, add the state, save, then repeat for however many states you have. This actually sounds like something which should go into the thirty bees distribution. Could you make a list of which taxes are required?

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