Traumflug

These recent irritations around the project currently named thirty bees accelerated my efforts to come up with a solid and reliable ground to connect developers with merchants and merchants with developers. Code written and features of the software were and are great, many merchants do their best to help others, just as many developers. This deserves a liberation from business and investor games. Say hello to Merchant's Edition Merchant's Edition has the goal to move the idea of open source into the business area. It's open to any developer working on the core software and basic modules. Their share grows not by the amount of money they provide, but by the work they put in. They can connect directly to merchants and vice versa. Merchant's Edition helps to connect them together. Next step: provide a chat for both. Those knowing me also know I prefer to do things right over rushing into something 80%. Look at how blazing fast the already provided site is. During development I learned a lot on how to make web pages faster, much of which can eventually be applied to shops running thirty bees as well. Published now already, to show that things around thirty bees are moving forward. Chat is then expected to be the same: fast and secure. Probably based on Matrix and Riot. You as a shop operator can get support right now. These nagging warnings all the time? We'll fix them. Need an extra feature? We'll write it. No time for technical maintenance and updates? We'll do it. Done by those who know the software best, from the ground up.

Thumbnails regeneration never times out, it just takes time. This is one of the things where thirty bees removed one of the well known PS pains. For investigation on what's going on, looking at the URL of one or two images and comparing it with images actually on disk is a good start. One can also turn off Pretty URLs to see these URLs directly, without Apache changing it on the fly.

Zu solch einem Modul habe ich mir immer mal wieder sporadisch Gedanken gemacht. Mir ist jedoch bislang nicht klar, wie da eine sinnvolle Strategie aussehen könnte. Eine Möglichkeit ist sicherlich, ähnlich einer normalen Bezahlung eine sich wiederholende Bezahlung bei einem Bezahldienst auszulösen. Da wäre der Shop dann nach der ersten Bestellung aussen vor. Und das geht natürlich nur mit Bezahldiensten, die solch eine Funktion haben. Eine andere Möglichkeit wäre, per Cron-Skript jeden Monat / jedes Quartal / jedes Jahr automatisch eine reguläre Bestellung im Shop auszulösen. Eine Produktart mit Verfallsdatum, das durch weitere Zahlungen verlängert werden kann, stelle ich mir dagegen eher aufwändig vor. Da bräuchte es dann Webseiten mit einer Übersicht für den Kunden, wie der Status solcher Dauer-Bestellungen ist. Kündigungsmöglichkeit, "Kontostand", Zuordnung unverlangt eingehender Zahlungen und dergleichen mehr. Wenn jemand eine gute Lösung kennt, gerne auch in einer anderen E-Commerce-Software: ich bin ganz Ohr.

thirty bees also has it's own log files. See `log/` in the web root. There it collects short versions of what should also appear in the browser. Yet another source for error messages is back office -> Advanced Parameters -> Logs. One can filter by severity there.

I'd try to set product minimum quantity to 1, not zero. This is back office -> catalog -> products -> (click product) -> quantities -> tab 'Availability settings'. Or back office -> catalog -> products -> (click product) -> combinations -> (click edit on a combination). If it's already set to 1 there, it's a module bug.

Dropbox, radiobox and colors are attributes defined by the merchant. Customers can select, but not change them. What you probably want is a customization. There customers can enter something and order the product with this something. For example, text or photos on a t-shirt printing service. Adding customizations is a two-step process. Enter the number of fields first, then save, then define how these fields should look, then save again. Needs a bit experimenting.

Yes, it should be this way. Actually the selection is generated in `Product::getNewProducts()` in classes/Product.php. To keep core code unchanged, one could request a larger number there, then do a random selection in the module.

Having one multishop across multiple servers/installations can obviously not work. One installation can't read/write files and database of the other. A theoretical scenario would be to connect both tb installations to the same database. tb doesn't support that and even if it tried to support it, it'd likely be pretty error prone. Solution is to put all four shops on the same server. DNS records can be on distinct hostings, as long as they all point to the same IP address.

One can also put customizations before ~~start~~, just not between ~~start~~ and ~~end~~.

It's said to generate a couple of warnings, but work flawlessly.

What exactly means "monkeying"? What means "non-specific error"? Vague descriptions don't allow specific answers.

Does your theme provide templates? In /themes/<theme>/mails/... These override templates in core (and are the preferred way to use custom templates).

There are tools like fail2ban to deal with such robots. Needs root level access on the server, though.

Using 777 permissions is always kind of conceding defeat. Much better is to find out and understand what's going on. One thing to check would be ownership, user and group of these templates. They should match the user running PHP, often 'www-data'. BTW., what are you using to edit these templates? I usually do this manually, via SSH or FTP and with a plain text editor. Probably not must user friendly, but it works.

In case it's the awesome top notch theme you always dreamt of: recreating config.xml isn't impossible. Pick one from another theme, change name and directory inside and give it a try. These long lists just tell which modules should be installed along with the theme and where to place their hooks. One can adjust all of this after theme installation by the usual means.

Text mail is still the safest way to handle email. No automatic execution of anything, no obfuscated links. Looking at what non-commercial people do with email: they write text and attach documents/images/files. Nothing which would require HTML. That's why my email client is set to text only and those mails containing nothing but "your client is broken, read here..." usually get ignored. Text-only mails with PDF attachment for delivery slips / invoices / other documents is actually a good idea, IMHO. Efficient and safe.

Blank page means a fundamental problem, like a PHP syntax error. If nothing shows up in the logs it's hard to debug this, though.

Invoice and mail templates placed in the theme override those in core. Which means, each theme can have its own set of templates.

True, one can download it. Another way to do this is to uninstall and delete the module, then reinstall it. Also: the migration module doesn't update modules at all. Updating modules is a step after migration and works the same way as any module update.

Exactly. Which means: one has to enable this extension 🙂

Git has no means to make releases at all. Github does two things: - It allows to publish a release along with a release package. Similar to making a blog posting. - It counts every Git tag as release. If these two don't match, one gets a mess. As another example one can take the Teacup Firmware repository. This project never makes releases, still Github lists the single tag in the entire repository as "release": https://github.com/Traumflug/Teacup_Firmware/releases. These .zip and .tar.gz get auto-generated by Github and are unrelated to anything which could get called a release.

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.