Traumflug

You found a good solution!

Another dozen of commits brought tools/buildmodule.sh, a central script for building a module package. It replaces all the individual build.sh scripts inside the modules (only about half of the standard modules had one) and and refuses to build if validatemodule.sh doesn't pass, of course. It also enabled me to start making new module releases, which is the best of all of this: https://github.com/thirtybees/bankwire/releases/tag/2.0.7 https://github.com/thirtybees/blockbanner/releases/tag/2.0.2 https://github.com/thirtybees/blockbestsellers/releases/tag/2.1.2 ... more of them forthcoming ... Does this change module behavior or fix merchant-visible bugs? Honestly, I don't know. Some modules had/have commits on master, but no release tag for them. Others had their version in code bumped, but also no release. So I'm not sure which version of each hits the shop installations. Nevertheless I'm positive the situation becomes a bit more predictable now. Latest commit = head of master = latest release. And even an internal document on how to release a module step by step exists. That's how it should be :-)

https://github.com/thirtybees/thirtybees/issues/530

Images are stored in img/. Product images in img/p/. To get a better idea of how the stuff works, turn off friendly URLs (back office -> Preferences -> SEO & URLs).

As that front is a demo, it would maybe be good that they would add additional languages. "They" do, if you choose to install with a language not native to the installation of he country. E.g. if you do an English installation for a German shop. Aside from that: yes, disabling that module is the way to go. Each module installed has to be loaded, so it costs some efficiency. Accordingly, disable, better delete the module to gain that little bit of speed.

Thanks to both of you, let's make this permanent: https://github.com/thirtybees/thirtybees/commit/12b3d5c1772e2247be44bc40a313c9e6b3107695

This announcement is mostly for developers. Looking at the current 1.0.x branch on Github, there's a series of 71 commits introducing tools/validatemodule.sh. It's run like this during module development: sh cd modules/<module> ../../tools/validatemodule.sh There's also a release mode, which does additional validations for things being significant when making a module or core release: sh cd modules/<module> ../../tools/validatemodule.sh --release And of course, like every proper shell application, it comes with a --help option, explaining things a bit. This script was written and tested with the assumption of being a thirty bees module (e.g. it verifies file headers to contain the thirty bees one) residing in a Git repository being placed in the modules folder. It doesn't validate files on disk, but files checked into the repository. Which means, if you have fixed something, you have to commit that change to see it recognized by validatemodule.sh. It also means that stray files not committed get ignored, which is the purpose of this strategy. Near time plan is to run a validation of all modules before doing a release. Somewhat later the plan is to add the capability of validating a module unpacked from a ZIP archive. And yes, during coding and testing hundreds of smaller issues in the 51 default modules came up, so expect many commits there in the near future. Currently no less than 692 commits across all these modules are awaiting review, push and release :-)

Auch das gibt's:

Bislang war die Auffassung sehr vieler Politiker ja immer, so in etwa: "Das mit den Abmahnungen ist schon in Ordnung, sollen die Leute ihren Shop eben richtig einrichten." Dass diese Strategie nicht so richtig funktioniert, weil es kein genau definiertes "richtig" gibt, dämmert nun einigen der Herrschaften: http://www.spiegel.de/netzwelt/netzpolitik/datenschutz-grundverordnung-union-will-schonfrist-fuer-dsgvo-verstoesse-a-1211424.html Die Schlagzeile hat die Unionsfraktion gemacht, sie will Abmahnungen bei Verstössen gegen die DSGVO für ein Jahr aussetzen. Das Gesetz soll, angehängt an ein anderes Gesetz, noch im Juli beschlossen werden. Noch besser gefällt mir jedoch der Vorschlag der SPD, ganz unten im Artikel erwähnt: Der Berliner Jurist und Aktivist Ulf Buermeyer (SPD-Mitglied) sähe es lieber, wenn die Koalition gesetzlich klarstellen würde, "dass der erste Hinweis auf einen Rechtsverstoß immer kostenlos sein muss"

after having a break from the coding for a day, it just “started working” See, thirty bees is magic :-)

P.S.: regarding 4: if you can't have the same database user/password in your development installation vs. your public server, you have to edit config/settings.inc.php before doing the upload. What needs change is pretty obvious in there.

First, congratulations to your choice of doing a development installation, then copying that to the public server. That's not exactly popular, still a very sane and safe strategy. Steps to do: Set your development shop into maintenance mode (back office -> Preferences -> Maintenance) Make a backup of your database. Copy all the files over. Restore the database on the public server from that backup, same database name, same database user, same password. Go to back office -> Preferences -> SEO & URLs and set all three, Shop domain, SSL domain and Base URI according to your public server. Before doing so, only back office is accessible. Remove maintenance mode on the public server. Enjoy a working shop. Regarding 5.: I mean I had pushed some patches to allow automatic domains, eliminating this step, but apparently those didn't make it into 1.0.4, yet. Regarding file permissions: all files and directories have to be writable by the PHP user and readable by the web server (which is usually the same user). With this demand met, the shop should work. FTP upload should take care of setting such permissions.

@datakick From my perspective it’s more than enough to release new version once every 6 month. Simply don't upgrade with every release, then. Not upgrading means not receiving bug fixes, though. Making releases rarely means holding back these fixes from merchants for longer than necessary. Not sure what value that might have. If you fear a broken shop after upgrading, that's a bit a different issue. And one much more worth tackling. The answer to this is, make releases more often. The smaller the release steps, the smaller the chance for regressions, the bigger the chance to get issues fixed timely. Also, with this high release rate, the submitted code won’t have a chance to mature in the branch The awful truth is, unlike wine, code doesn't mature by its self. Worse, even a big QA team wouldn't help much. This isn't MacOS, where every user has one out of a small set of hardware, running all the same theme, running all the exactly same applications. Diversity of shop installations brought in by hundreds of modules and themes is way to big to cover them all. With this enormous diversity, only real world installations can find eventual issues. One answer to this is to make fixing newly upcoming issues ( = regressions) as seamless as possible. Which means many releases. Which is the reason why the upcoming updater module will support upgrading in even smaller steps, commit by commit. And which is the reason why this updater will support rolling back with a simple click. In a mockup I tried such a rollback (e.g. 1.0.3 -> 1.0.2) happened in less than a second, it doesn't even need a wait icon. The other answer is automated testing of the basics. Every single commit gets exercised with a test installation and a virtual user clicking through the shop, up to doing a purchase. That's much better than what we had years ago.

Hmm. Current thirty bees is version 1.0.4. And what is "the modded version"? Can you reproduce this with a shop not running Warehouse?

One can always go with paid solution E-commerce. Then you can loose what you have. If the software maker decides to stop supporting the software your shop closes. Can't happen with open source.

All the likes I got for the above post deserve to the two developers making this module, of course. Me made just the screenshot.

What features, if any, are planned for upcoming release 1.0.5? v1.0.5? That's later this month. There will be a module validator. Maybe some people noticed it, the v1.0.4 release wasn't as seamless as making a release should be. All the module and theme upgrades got forgotten, even the already distributed ZIP file had to be corrected. So I started an effort to make not forgetting such things much easier. Probably this sounds boring to many, it doesn't change much to the merchant/customer experience. Still I consider this to be important, because a successful project needs a strong foundation. The new updater module will add to this as well. No more wrestling with patches, just click and go ahead. I already have a very advanced site with this system https://ventaregalo.com and after having worked so hard it would be a shame if I lost it. thirty bees is open source, so you can't loose what you already have :-)

Here's a preview of the admin interface: I like how one can get through all the topics step by step and each one gets explained!

Yes, nice idea. Still it misses a lot of crucial things: Can order only one product! If one looks very closely, multiples of this one product. Trying to get out of the checkout ends up with an empty cart! Just can't leave that thing, e.g. for ordering later. Customers will hate to be locked into checkout just because they choosed a size. Can't review or change an order. Only one payment method. Zero shipping options (I guess, because I didn't enter a credit card number). No shipping address distinct from the billing address. No address additions. I mean, if one takes the standard thirty bees one page checkout and removes all the options missing at stripe, one ends up with a pretty simple order page as well. And one can jump directly to that page if one wants to limit orders to one product. What I like is the reduction in distraction, because the product page is kept as background during checkout.

uBlock Origin (I use it myself) uses blocking lists, no blocking built in. I fear the only way to get rid of this problem is to find the rule blocking these fields and ask the list maker(s) to change that entry. Vanishing entries in a payment module are most likely not intentional.

Looks good in a default installation, community-default-theme:

Today we have to think that the mobile version is almost more important than the desktop version No doubt about the importance of mobile devices. Nevertheless, (mobile) device detection is a technology which is pretty much abandoned already. The modern replacement is coined "Responsive Design", which means: Don't try to detect the device, deliver the same HTML/CSS/JS to every device. Use conditional CSS, which changes appearance based on screen width. Much better than device detection, think about users turning their phone from portrait to landscape, drastically changing screen geometry. As appropriate, fluid elements. Like sizing images not in pixels, but in available space (e.g. 'width: 100%;'). With such a responsive design, logo is usually the same for all devices and gets scaled as needed in the browser.

Where's the problem? To me this looks perfectly fine (in Firefox):

Protokollierung von Einwilligungen Ist schon da. Dadurch, dass der entsprechende Cookie existiert, ist das "Protokoll" vorhanden. Beim Kontaktforumlar dadurch, dass der Besucher was schickt. Letzteres gilt ja dann auch nur für dieses eine Mal. “Passwort vergessen” Funktion mit neuem Ablauf Das im Shop gespeicherte Passwort ist nicht umkehrbar, ohne das Original also wertlos. Das Original kennt jedoch nur der Kunde. Logging der Admin-Aktionen Gibt's irgendwo in den Tiefen des Backoffice. Hat aber mit der DSGVO nichts zu tun, denn Kunden können keine Admin-Funktionen ausführen. Versionierung für Rechtstexte im Content Manager Hat mit der DSGVO auch nichts zu tun. Der Rest ... naja, die Leute streiten sich ja immer noch darüber, was es tatsächlich braucht. Manche stellen sich ja mehr oder weniger auf den Standpunkt, dass sie die Daten nur im Sinne des Kunden verarbeiten, sich also gar nichts ändern muss. Auch wenn ich da ganz anderer Meinung bin.

1 CMS seite mit Rechten erklärung für unlogierte gäste, und 1x cms categorie für “My Account” für registrierte kunden. Beim kontaktform wird ein text für gäste gezeigt aber nicht für registrierte kunden. Beim registrierten kunden kann man auch kein email ändern am köntaktformular, aus versehen oder nicht. Gespert Klingt nach einer guten Lösung. Klingt auch danach, dass man das mit der Distribution ausliefern könnte. Dann wären Neueinsteiger schon mal wesentlich näher an einem rechtssicheren Shop. Gute Idee? Würdest Du die Lösungen zur Verfügung stellen?