Traumflug

Thanks for investigating this, @datakick. It turns out images were always overwritten with updates. Just nobody noticed, because there were no updates. Updating only certain files is a tricky thing, because not all images are meant to be replaced by merchants. There are also logos, icons and such stuff. Also, not erasing the whole directory means that obsolete files, code or not code, stay in place, potentially messing things up. The golden approach would probably be to get modules into installing their images in img/ properly. Not too hard to implement, because there is install() and uninstall() already, but it has to be done.

thanks for explaination, i will do as for your suggestion Actually I'm no longer sure about what I said. I'll have to investigate this.

Can you say that 1.0.5 is a “stable” version? "thirty bees is the fastest and most stable e-commerce solution we've ever seen and release 1.0.5 just adds to the distance over the competition!" PR slang not your thing? Then test your shop. Act as a customer, do purchases. That's what I'd recommend to friends. What works this week will work next week and next year as well. if we do not need any stats, we just don’t install the ‘Stats Module’ ? Certainly possible. You have to uninstall them, because they get installed by default.

@DRMasterChief, if you want to upgrade from 1.0.3 to 1.0.5 directly, follow instructions for the 1.0.4 upgrade, but use the 1.0.5 ZIP archive.

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.