Traumflug

Scheint nicht besonders dringend zu sein, wenn niemand eine Meinung dazu hat, wie so ein Modul funktionieren soll 🙂

Yes it would, and for tb developers that's a hard to solve problem. In the PrestaShop days the option seen most often was to simply not update. tb got quite a bit better on this, one can update core software without updating the theme. Three ways to do it properly until thirty bees found a better way: - Carefully maintain a log of your changes in order to be able to re-apply them after an update. Having backup files right next to the original is fine. - Use Git or another version control system to keep that log and apply/unapply it as needed. - Use back office -> Preferences -> Custom Code. That's a bit harder, because JS and CSS added there gets applied to all shop pages. One has to figure a unique CSS path for that specific item one wants to change. But it's update-safe.

This looks like a problem which should be reported on Github.

A first step would be to look up whether these images exist on the server. Product images are stored in img/p/, then folders for the image number. One can find the image path in back office -> Catalog -> Products -> (click product) -> Images, hover over the image to see its URL. Images can be corrupted, zero size, missing, whatever.

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.