Traumflug

aber mal ehrlich: du weißt doch selbst am besten welche Daten du von Kunden im Shop speicherst. Naja, eigentlich schon. Doch gleichzeitig werden die meisten Daten ja vom Kunden selbst eingegeben oder automatisch zusammen gestellt und wo thirty bees was hin speichert, ähm, weiss wohl niemand so 100% genau. Ein bisschen peinlich, aber so ist das eben im Moment. Ich würde mal mit Backoffice -> Customers -> Customers anfangen. Da kann man einen Kunden anklicken, dann werden alle Sachen bezüglich dieses Kunden aufgelistet, das ist schon mal ein guter Anfang. Diese Seite in ein PDF drucken. Dann kann man die einzelnen Orders anklicken und sie ebenfalls in ein PDF drucken. Dann kann man den Kunden löschen (nicht aber die Orders, wegen der Buchhaltungs-Archivierungspflicht) und ihm all die PDFs zuschicken. Zusammen mit der Mitteilung, dass die Orders noch 10 Jahre für das Finanzamt aufbewahrt werden müssen. Das sollte eigentlich genügen. Wenn dann noch ein paar Daten in den Tiefen der Software herum geistern ist das eben so. Was der Kaufmann nicht kennt, kann er auch nicht missbrauchen (bei der DSGVO geht es ja weniger um die Speicherung selbst, mehr um die Verwendung der gespeicherten Daten). Wenn solche Daten je auftauchen, kann man sie dann immer noch löschen.

Also moving this to the bug report section.

Downgrading PHP won't really solve the problem, it just hides it. The underlying problem is this: http://php.net/manual/en/migration72.incompatible.php#migration72.incompatible.warn-on-non-countable-types I just looked into the code, but found nothing related at the given line numbers. Maybe the line numbers don't match. Could you post a couple of lines of context, please? Code at the given line number, plus some 10 lines around it. This should help to locate the code at fault. Thanks.

AEUC = Advanced EU Compliance

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: