Traumflug

I see, thanks.

Great! Never hesitate to report stuff not working 🙂

One can call such a customer with phone number and advertise even more, of course. Advertisers, and accordingly most merchants, looove personal data. That said, one can remove the mandatority of this field in back office -> Preferences -> Customers. Some even remove the entire field from the front office template.

There should be no such thing like a "desktop module" or a "desktop view" or a "mobile view". That's all the same HTML, the same CSS, the same JavaScript. thirty bees should reflect this, as it uses Bootstrap. Desktop users can even change their window width without reloading the page, pages happily switch between phone-type, tablet-type and desktop-type as the window gets dragged wider or more narrow. Here's a nice video demonstrating this: https://developers.google.com/web/fundamentals/design-and-ux/responsive/videos/resize.webm Which leads to the question: what's actually the problem? Some rendering issue?

Also handled here https://github.com/thirtybees/thirtybees/issues/888

Actually it's fixed already: https://github.com/thirtybees/thirtybees/issues/833 Thanks to @datakick for doing this.

All devices should receive the same page. The way this page gets rendered is decided by CSS, in the browser. Distinction between "mobile" devices and other devices is blurring and will blur more in the future. What matters is screen/window width. Somewhere on my TODO list is actually removal of this device type property. Not with high priority, though.

It's clearly a bug. Whatever a merchant does, misalignments should return an informative error message rather than triggering an exception. In the previous thread I already asked what you're doing. Which controller, which input file, such stuff. Developers can only fix what they can reproduce.

Probably it's a good idea to make a clone of your existing shop, then migrating this to thirty bees. This removes the guessing and replaces it by hard numbers. For tuning, there are two key things: a) turn caching on. Full page cache is still tricky, but everything else reliable. And b) remove what the shop doesn't need. Slow shops are typically a result of many many modules added, each bites a bit into performance. Here's @wakabayashi great video showing how to do it:

Yes. The thirty bees store its self is an example of it: https://store.thirtybees.com. There one can order modules ( = virtual products) and development services. Blocks get removed by uninstalling the module providing it. Default installation is kind of a showcase, showing whatever is available, so uninstalling most modules is perfectly fine. Regarding hosting, well, simply try. The installer checks all prerequisites and if these tests succeed, it should work fine.

An exception during normal operations is always a bug. Back office pages (controllers) should catch any user mistake and display an explaining error message rather than dying ugly. Could you elaborate a bit more on the steps to reproduce this issue? Which back office page, where to click, and if you could provide the import file used it'd be even better.

Does it work anyways? AFAIK, this tab isn't crucial, it just loads the module configuration page.

It was indeed a but in 1.0.8. And it's solved in latest 1.0.x. Thanks to everybody helping to investigate this.

Together with the help of @haylau a number of nice improvements were introduced: Now using the recommended SOAP interface, rather than web pages intended for consumption by humans. Can distinguish between a negative report and a web service outage now. On web service outages, all VAT numbers get accepted, to not disrupt a purchase. These events get logged to allow manual verification by the merchant later. Improved settings descriptions. Release notes and manual download: https://github.com/thirtybees/vatnumber/releases/tag/2.3.0 Also available immediately in your back office, of course.

Thanks for the link. Well, that's a workaround, not a solution. And translations are obviously part of thirty bees, so an issue with them should get tracked.

Obviously, product descriptions are content as well. I've seen shops where these descriptions are really long, similar to dedicated CMS pages.

Thanks for the heads up. The obvious answer is Yes.

I'm not aware of a Github issue. Which one would this be?

It should work. These statistics modules will be missing, though.

Great. Having a working version is a great help, as it allows bisecting. Do you also remember the version where you've last seen it working? 1.0.3?

Is there some evidence this Virtual URI thing ever worked? A year ago I was close to removing the feature, because I couldn't imagine a use case other than having https://store.com/shoes rather than https://shoes.store.com/, while one can get https://store.com/shoes easily by defining a category 'shoes' in the main shop. Perhaps we should talk about what the goal is. This should help finding a way to get it working, or to find a easier replacement.

That's disappointing. Filed as a bug here: https://github.com/thirtybees/thirtybees/issues/880

Some can get turned off in back office -> Preferences -> Customers.

Good question. To avoid such questions, removing two of the three algorithms is planned anyways. Unless PHP encryption turns out to be measurably slower than the others, it'll be the algorithm in the future, relieving merchants from the burden of making a choice. I think there is no real preference for one or another. All three work fine. Changing the algorithm is simple as well, it just logs out all customers and employees. They can log back in immediately, no need for changing passwords or such stuff. Shop visitors won't even notice.

I'd clone all five shops, then remove the four unwanted ones in the clone. No need to have these five front offices web accessible, there's only one back office. Trying to manipulate database contents directly would be a pretty complex thing. There are all kinds of connections between tables, finding them is really hard.