Traumflug

This would require substantial changes to customer and employee handling. Especially if it had to fit a random "some other system". AFAIK there is no gold standard for user handling, each web software uses a custom solution.

Nice catch, and excellent bug report! Let's not forget this: https://github.com/thirtybees/thirtybees/issues/893

There's at least a large number of reasons why .htaccess needs regeneration. One can still add custom code, though. Code above the line with ~~start~~ and below the line with ~~end~~ is left untouched on regeneration.

Unless you removed Joomla in this process, this obviously mixes Joomla and thirty bees files, which is pretty much like asking for trouble. There's no drawback in running thirty bees in a subfolder. Many merchants do this.

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.