Traumflug

AFAIK, uploading a module removes the old module directory completely, then unpacks the new one in place. Which obviously means that images get reset as well. Custom images shouldn't replace the ones inside the module directory, be get placed in the theme. Each theme comes with a modules/ directory, files inside there override the default ones in the module. Accordingly, custom images should go into themes/<theme>/modules/themeconfigurator/img/. So far the theory, I didn't actually try.

Yet another couple of weeks have passed by, yet again hundreds of commits piled up unreleased. Time to make a release! Say hello to thirty bees version 1.0.5. Release notes: Introduction of validatemodule.sh and buildmodule.sh. This should increase reliability of making module and thirty bees core releases a lot. Removal of PHP unserialize() and friends for security reasons, in favor of serializing with JSON. With retrocompatibility code, of course. Fixed images reordering for multistores, thanks to @mcdado. No more duplicate manufacturer listings in back office -> Price Rules -> Catalog Price Rules, thanks to @okom3pom. Compatibility with the Litespeed web server (an Apache drop-in replacement). Thank you to @lucasRolff. Areas to check after upgrade: Back office -> Preferences -> Store Contacts -> each store: check whether opening hours still appear. In module blockmyaccount / Block My Account: changed the wording to be less personal, so check translations. Upgrade procedure is the same as with the v1.0.4 release, but no database upgrade and no messing with modules required: Download the ZIP package. Extract the zip package. DELETE the install directory from the zip package. RENAME the admin directory to the same name as your current admin directory. Perform a FULL BACKUP on your site. TURN OFF all caches on your shop or or set it to force compile. Upload the files that are remaining from the zip archive to your site. Go to the config directory and edit the settings.inc.php file, update your version to 1.0.5. Now log in to your back office, the upgrade should be finished. You can turn caches back on. Enjoy!

You're manipulating the database directly? Uh-oh :-/ It'd be better to create categories using web requests mimicking a manual creation. Or to write some PHP code calling the appropriate methods. Which code to write? See AdminCategoriesController.php

If your previous shop is a PS 1.6 shop, the solution is simple: use these PS modules. They should continue to work with thirty bees. If it's a PS 1.7 shop, search not only for thirty bees modules, but also for PS 1.6 modules. And don't forget this: https://thirtybees.com/migrate-from-prestashop/, there's even a module making a migration from PS a pretty simple task.

With moderator hat: please open a new forum topic when discussing a new topic.

Best option: identify these problems (description of steps to reproduce, screenshot of the result), write Github issues. If possible, investigate the root cause, so it can get fixed.

you are right, there seems to be some mechanism. tbupdater module already checks for module updates from this location https://api.thirtybees.com/updates/modules/all.json Excellent hint! Lesley told me about an all.json file and where it lives. I thought this is for the module store, where module versions don't really matter, so I put it low on the TODO list. Over the last few hours I updated this file for all default modules, so if updates now appear in your shop, all is golden :-)

maybe the new updater will be the solution for this problem Exactly. That said, I have seen module updates. Many of them. There is some existing mechanism, but only @mdekker knows how this works or how to get a new release into this.

There's already a new release :-) Our automated regression testing, Travis CI, found an incompatibility with PHP 5.5. This got fixed with release 1.0.1: https://github.com/thirtybees/ecbexchange/releases/tag/1.0.1 No need to upgrade for those running PHP 5.6...7.1.

I mean, these "quick" solutions were the right thing to do to get the project started at all. Nobody would wait a year for a solid solution. We do have translations at all, that's the most important thing. Nevertheless, there is no free lunch. Quick solutions are almost always a lot more work long term. Eventually a whole group of developers is busy day-in, day-out with just maintaining such stuff. Now is the time to get this done right. "Right", like implemented with an idiot-proof toolchain. Not that thirty bees developers are idiots, but an idiot-proof set of tools reliefs them from remembering how it works, liberating them to put their brainpower into more constructive issues. Years ago, Makefiles were the tool of choice. These days we have build scripts (some might see this as a step backwards, but that's how web development is). Like this one: https://github.com/thirtybees/thirtybees/blob/1.0.x/tools/validatemodule.sh. Thousand carefully crafted lines of Bash, just to make reasonably sure a developer releasing a module can't forget anything. Next steps are to make the 1.0.5 release and enhance the release building process for core along the way. Then there's the new upgrader module on the schedule. And then there's probably time to take a visit in the translations machining room. For merchants this means: thirty bees gets more reliable and more stable week by week. Some patience with the working, but sub-par translations mechanism now more than pays out in a couple of months.

The result of such "quick decisions" is what we have right now.

Will put this module onto Github, make a tagged release and probably also part of the standard distribution before too long. Here we go: https://github.com/thirtybees/ecbexchange/releases/tag/1.0.0 This release is identical to the ZIP I posted above, no need to upgrade from that.

Solution see https://forum.thirtybees.com/topic/1844/new-module-ecb-exchange-rate-services

With Fixer.io changing their API and requesting custom keys, the idea came up to grab exchange rates directly from the European Central Bank (ECB). It turns out, the ECB actually encourages users and code writers to do this. See the code samples at the bottom of https://www.ecb.europa.eu/stats/policyandexchangerates/euroreferenceexchangerates/html/index.en.html One long night later, a thirty bees module has formed around this ECB service. Say hello to module ecbexchange / ECB Exchange Rate Services: 01529100100674ecbexchange-master.zip This module pretty much replaces the fixerio module. Same feature set, same faceless operations. Install ecbexchange, then go to back office -> Localization -> Currencies and hit the Update Currency Rates button. A second later, see your exchange rates renewed. Simple and effective, wonderful! Will put this module onto Github, make a tagged release and probably also part of the standard distribution before too long.

zum einstellen der versandkosten mit der steuer darf das auec nicht aktiviert sein, dann kann man die daten in der jeweiligen versandard eingeben und danach aeuc einfach wieder aktivieren Ist ja witzig. Das AEUC fummelt also an Sachen herum, die es besser in Ruhe lassen sollte. Das wäre dann mal ein Bug: https://github.com/thirtybees/advancedeucompliance/issues/6

Dass man die Sache grundlegender anpacken will ist auch die einzige Ausrede, die man gelten lassen kann.

Hat immer noch nichts mit dem AEUC-Modul zu tun; das Modul zeigt nur an, was ohnehin passiert. Es geht also darum, dass die Versandkosten nicht netto, sondern brutto (mit Steuern) festgelegt werden können. Der Shop würde dann von diesem fixen Brutto-Preis auf die Netto-Versandkosten zurück rechnen (und in der Rechnung angeben). Ich glaube dieses Feature wurde schon mal angedacht, hat aber bislang keinen Platz im engen Zeitplan gefunden. Das ist nicht ganz so einfach, denn das stellt die bisherige Struktur auf den Kopf. Und was passiert wenn ich die Versandkosten nach Gewicht berechne? Ausprobieren.

This should have been fixed already: https://github.com/thirtybees/community-theme-default/commit/db82edceece7a323d8d383aaff9a4541449e0b6c Maybe it didn't make it into the thirty bees 1.0.4 release (the messy release build mechanism I'm currently trying to resolve), so please apply this patch manually.

wenn Artikel beider Steuersätze im Warenkorb enthalten sind, denn dann werden die Versandkosten mit einem Betrag irgendwo dazwischen berechnet bis maximal zum eingegeben Versandkostenbetrag der jeweiligen Versandart. Wenn ich richtig informiert bin, ist das die korrekte Berechnungsart. Mehrwertsteuer auf die Versandkosten ist so hoch wie der Schnitt der Mehrwertsteuer auf die Produkte. Der Händler bekommt ja unter dem Strich nicht weniger Geld, er erhält nur das Geld nicht, das er auch später nicht ans Finanzamt abführen muss. Ausserdem sollte diese ganze Geschichte unabhängig vom AEUC-Modul sein. Die Berechnung der Steuern erfolgt in Core, AEUC kümmert sich nur um die notwendigen Ergänzungen der angezeigten Zahlen/Texte.

It just came to our attention that the Fixer.io service was discontinued the way it used to work. The API used by thirty bee's fixer.io module was replaced by a new API. For details, see https://github.com/fixerAPI/fixer/blob/master/README.md Note this sentence there: all users of the legacy Fixer API will be required to sign up for a free API access key Which means, there is no quick fix for this issue. The module needs to get a configuration page with a field for entering this access key, this access key needs to be handled somehow. I'd work on this, but I think I'm considered to work on the new updater module. And @mdekker is expected to finalize the GDPR module. Looks like merchants have to update currency exchange rates manually for a while. P.S.: one can get EZB currency exchange rates on the Euro foreign exchange reference rates page.

On php 7.2 if(count($errors)) gives this warning, while if(!empty($errors)) not It depends on what should be counted. Arrays can be counted, integers/strings/booleans not. Accordingly we have to find out what kind of variable is subject to counting. A quick Grep brings up 882 usages of count(), too many to do a code analysis on each. That's why I'd be happy about code pointers.

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