Traumflug

Ideally there were some standardized ERP connection protocol. Better to implement that than a connector for only a specific ERP suite. Still the idea goes into the right direction. Warehouse handling is a typical task one better outsources to a distinct software, even if it's a software developed by the same project.

They apparently release from more than one branch. Github doesn't recognize this and counts commits back to the fork point between release branches. Regarding quality: it's true, they apparently don't care about their testsuite. 90%+ commits broken. thirty bees: 0%, because commits not passing don't even enter the release/main/development branch.

You mean kind of an automatic patch system? Look at the file on disk, compare it to the file matching the old version, then create a patch and revert to the old file, update, then apply the patch to the new version. Sure, this would be fun. Especially when such a patch no longer applies cleanly to the newer version of the file 🙂 Personally I tend much more towards removing the need for editing core files. Supporting core file modifications better feels much like Henry Ford breeding faster horses rather than building cars. As you said, core is named Core for a reason.

This goes into the right direction, but isn't universally true. Because for many merchants, a sale is only a sale when an invoice got generated. For example, an order waiting for bankwire payment didn't generate income yet, so it can hardly be counted as revenue.

Well, set the product price to zero or to the minimum price, then add combinations with various price impacts.

Most thirty bees modules are rebranded PS 1.6 modules anyways. Just stay away from PS 1.7-only modules, they're incompatible.

Yes. If your pocket is deep enough. Remember: https://forum.thirtybees.com/topic/4027-goodbye/?do=findComment&comment=34625

You upgraded PHP recently, didn't you? Tools::redirect() needs al least one argument, the address to redirect to. Module code apparently doesn't deliver that, so it's a bit unclear how this could ever work before. Anyways, point of malfunction isn't in the cited code (Tools.php), but in the module in register.php line 161 or earlier.

With all the eyebrow raising these days I thought a bit funny stuff is a good idea. If you don't know on how to react with your marketing to the Corona crisis, here's kind of a template you can fill in 🙂

Here are two such facts: 1. It's hard to find developers working on a free community version. Everybody tries to get the best advantage out of his/her work. This isn't surprising, but is also of limited advantage for the community as a whole. Result: lots of agencies at work, lots of "somebody should" texts when it comes to community work. 2. It's even harder to get people into agreeing on something. Everyone has own ideas and wants these to be implemented, nothing else. Which means, even with sufficient money things don't fall into place naturally and any "leader" has constantly to deal with disappointed stakeholders.

There's Preferences -> Duplicate URLs to detect such situations.

Sounds like a reasonable base to work with. Except for one thing missing: making a feature request needs a price tag. Else the list of feature requests ends up where it was before: hundreds of requests with one supporter each and many being almost, but not entirely the same. Hardest part of a user driven feature request list is probably to aggregate requests somehow, to agree among all/most users on what to work, and on what to work next. There is no shortage of ideas for features. I have a TODO list with like 100 bullet points myself, requests on Github not even included 🙂

Da ist es eine gute Idee zu prüfen, ob mit einer restriktiven Einstellung des Browsers der Warenkorb noch funtkioniert. Der ist auf ein Cookie angewiesen.

This means an empty ZIP code is recognized as valid code, which is probably not what you want.

Merging with PS 1.6 brings probably nothing. Merging with PS 1.7 would bring all the compatibility issues PS 1.7 comes with: broken modules, broken themes.

Likely not. In early 2019 I was into hiring developers for thirty bees. This wasn't exactly easy, even with plenty of funds. A surprisingly large number of PrestaShop developers outright refused to work for thirty bees, simply because it's kind of a competition for PrestaShop. And freshmen refused to work for the project because they never heard of it. Another datapoint, remember this effort of PS to make PS 1.6 community-maintained to keep it alive? They immediately found like a dozen developers volunteering for this. As we know, thirty bees does exactly what this effort wants to solve: keep a 1.6-compatible software alive. Still no such dozen developers volunteering. A substantial part of the problem is people believing way too much in brand names. They prefer a buggy PS 1.6 over a stable and compatible thirty bees, just because it's named 'PrestaShop'. So far no solution for this aspect in sight.

Nothing. I'm here an working. Just not on public stuff at the moment.

See, this is why I outright fear to tell anything. As soon as I start to tell a few facts or answer a simple question, a rush of disappointed messages follows, sometimes not far from insulting. And this happens with thirty bees only, never seen a message questioning the PrestaShop or Magento or whatever company. If you want reassurance, here it is: https://github.com/thirtybees/thirtybees Code is public, available for everybody. Even if somebody would pull this public repository, many of us have copies/clones on platter and every single shop has most of its files installed. And its license perfectly allows to use the code until the sun goes dark or the universe collapses. Unlike all the Microsoft/Apple/SAP/whatever stuff, nobody can take that away from you. Another thing is, I promised years ago to not leave merchants in the dust. This continues to be true. Run your shop, and if something goes wrong, drop me a message. Or Datakick or another developer. Support is still there and pretty much unchanged, even Datakick said about the same earlier in this thread:

Which reassurance? I don't know anything about this company other than it's name and what's written in this registry entry.

2 hours ago, zen said: How TB works legaly Looking at the bottom of thirtybees.com one can read this: © thirty development llc As in most countries, one can look up limited-type companies in public registers: https://tnbear.tn.gov/Ecommerce/FilingDetail.aspx?CN=255033012188122038179169083159160212228131154070 (solve the captcha to see the entry) One can see the number of company members going up and down over the years. Before you ask: I'm none of them.

D'oh. Just minutes before I praised your work in a private chat.

White page means a substantial problem, like a PHP syntax error. Time to look up the server's error log, if available. If your hoster doesn't provide an error log (ridiculous, but some actually do not), move overrides and non-thirty-bees-modules aside: - Using FTP, find all pages with .php suffix in overrides/, which are not index.php, and rename them to ....php.off. - Create a folder "modules.off" at the root of the filesystem. - Move all modules not from thirty bees out of modules/ into modules.off/. In doubt, move more of them, a shop basically works without any modules. - Delete cache/class_index.php. thirty bees will regenerate it.

They do this only once and store the combined file, then always serve this. Which means no additional CPU usage when serving pages. Disadvantage is, it always serves all available CSS/JS, even those chunks not needed on a particular page. Advantage is, it's always the same file, so this load happens on the first page visited, only. Regarding HTML compression: one of the first things Michael Dekker did for thirty bees was to remove it. Because HTML compression indeed takes longer than just serving the longer, uncompressed file. As always: measure, measure, measure. Developer consoles of Firefox and Chrome both show page loading time at the very bottom. Reload a page five times, take the average. Then change a setting and measure again. Numbers are much more reliable than feelings and guesses.

Yes. But not those who click this x by accident. And that happens quite easily, because this x looks like a close-dialog-button.

I didn't design this site, nor do I have any insight, but just look at what's there. More importantly: what's not there. Front page: phone/tablet-type menu only, no menu optimized for desktops. This likely means a lot less HTML, a lot less JavaScript and a lot less CSS. No image slider, no blinky-blinky (which slows down the browser), just one font, no Google Analytics (but G tag manager), no Facebook. Category page: while many sites have a whole plethora of modules in the left column there, Chesspoint has exactly one: layered navigation.