Jump to content
thirty bees forum

Occam

Members
  • Posts

    303
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Occam

  1. Ich glaube, die verlinkte Info hast Du nicht richtig verstanden. Natürlich akzeptiert T-Online wie bisher auch Mails von shared IP-Domains, vorausgesetzt, der Provider hat die Domain-Authentifizierung für Deine Domain(s) korrekt konfiguriert. Mit den Google-Tools lässt sich herausfinden, ob ein SPF-Eintrag gesetzt ist. Falls nicht, hilft Dir vielleicht der folgende Beitrag: https://powerdmarc.com/de/how-to-create-an-spf-txt-record/ Oder Du fragst bei Deinem Provider nach, ob der Kundenservice das für Dich erledigt. Hab ich z.B. bei ESTUGO so gemacht und bekam folgende Antwort:
  2. Sorry, done with that. It was just an old override to extend the display that I had not yet customized. Thanks for your hint.
  3. The order list is displayed corrupted. I suspect a Java script error. Maybe this is due to the fact that I use PHP 7.4. I'm not able to switch back to a previous PHP version. (And please, answers like "Change your provider" are not helpful in this case.)
  4. Versuch's mal hier: https://forum.thirtybees.com/topic/3736-tls-v12-is-not-supported-message/?tab=comments#comment-32687
  5. I wouldn't agree. For all items that have length or volume measurements, a base price must be specified. This applies not only to Germany, but is legally required throughout the EU. Not necessarily in the product list or cart, but in product details.
  6. Aber eigentlich sollte das Standard sein. Ich habe im Laufe der Jahre schon in PS immer mal wieder solche Erweiterungen eingebaut, entweder nur für 's BO, oder auch für die Anzeige im Template. Was z.B. in TB immer noch fehlt, obwohl inzwischen zumindest in PS 1.7 enthalten (wenn auch dort nicht richtig logisch durchdacht), sind individuelle Verfügbarkeits- und Lieferzeiten je Artikel. Dabei ist das wirklich nicht schwer zu realisieren, bedarf allerdings auch neuer Datenbankfelder.
  7. I completely disagree with you on that. Because for us, it's customers from the Netherlands, from Italy, Spain and other EU countries, or even Japan or the USA, who use the English-language site. GB no longer plays a role since Brexit anyway. We have also canceled all suppliers from GB. It has simply become far too inconvenient and too expensive. Das mit der Übersetzung für das Feld Unit im BO ist schon ein bisschen komplizierter, denn es ist wie bei PS auch ein reines Textfeld. Das bedeutet, sowohl die Datenbanktabelle muss erweitert werden als auch der entsprechende Controller und das Template. Nemo hat, wenn ich das richtig verstehe, hier eine Lösung angeboten: http://nemops.com/prestashop-thirtybees-multi-language-product-fields/#.YZYQrKK1I1I Ausprobiert habe ich es zwar nicht, sollte aber funktionieren.
  8. ... and hope that your Prestashop theme is compatible with TB, which from my experience is rarely the case, even if it may work on the whole.
  9. 1) It makes no sense to open several topics for the same problem. 2) From your example it is not clear how much the gross amount of the shipping costs actually is. Or did you mean shipping costs tax incl. when you wrote "Gross tax is set at 4.80"? If so, the problem can be identified as a bug in tb's AEUC, because though the taxes are correctly calculated, they are computed not from the net shipping amount (4.25), but from the shipping price incl. taxes (4.80)! This bug is not new, but still unsolved. I totally forgot that this was the reason why I use my own modified AEUC in tb. Works properly without any changes in classes like Cart.php.
  10. Of course! German invoice with mixed taxes: RE000019.pdf And please, don't try to "approve" the Cart.php. Leave the code (where it deals with AEUC) like this: if (Configuration::get('PS_ATCP_SHIPWRAP')) { if ($useTax) { // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping // costs. This is on purpose and required in many countries in the European Union. $shippingCost *= 1 + $this->getAverageProductsTaxRate(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } $shippingCost = round($shippingCost, _TB_PRICE_DATABASE_PRECISION_); Cache::store($cacheId, $shippingCost); return $shippingCost;
  11. Nope, no shipping rate, just the shipping costs! Otherwise the proportional calculation wouldn't make sense.
  12. There's a bracket missing: ... = .... get_contents_dirname(_FILE_)...
  13. Seems to me that it was a misconfiguration. Never set a shipping tax rate when you use AEUC (hopefully my own modified release)
  14. I wouldn't agree, because I cannot reproduce the behavior you were talking of at Github. My fix there from 2017 is currently implemented in a slightly different way to tb so that the workaround I posted is obsolete and outdated now. if (Configuration::get('PS_ATCP_SHIPWRAP')) { if ($useTax) { // With PS_ATCP_SHIPWRAP, we apply the proportionate tax rate to the shipping // costs. This is on purpose and required in many countries in the European Union. $shippingCost *= 1 + $this->getAverageProductsTaxRate(); } } else { // Apply tax if ($useTax && isset($carrierTax)) { $shippingCost *= 1 + ($carrierTax / 100); } } In my release issue-905 from Bleeding Edge it's line 2138-2149 in /classes/Cart.php. I tested it with both the standard invoice and my own invoice (adapted to tb). Each and every figure is correct. Works fine. I guess there's else something causing your problems, provided that everything configured is properly.
  15. Du hast völlig recht. Ich hatte übersehen, dass sich nicht nur der Feldinhalt, sondern auch die ID geändert hat.
  16. Ja und Nein. Hier ist der gleiche Fehler drin wie auch in PrestaShop 1.6. Es wird zwar ein neuer Datensatz angelegt, aber der alte verschwindet ganz, weil er in der Datenbank als deleted geflagt wird, aber noch aktiv ist. Er lässt sich aber übers Back Office nicht mehr reaktivieren, sondern nur durch Eingriff in die Datenbank selbst. Und ganz übel wird die MwSt-Umstellung, wenn man Varianten und Grundpreisangaben hat. Der "floating"-Grundpreis wird völlig unverständlich. Bevor du dich vorzeitig über die zugegeben nicht immer glückliche Diskussion im Prestaforum mokierst, solltest du dich vielleicht selbst mal auf Fehlersuche begeben. Wenn es wenigstens wieder so klappen würde wie in PrestaShop 1.5, so wäre das schon ein Riesenvorteil. Näheres s. im Bitrag eines Users im besagten Topic: https://forum.thirtybees.com/topic/4197-mehrwertsteuer-umstellung/?do=findComment&comment=36241
  17. Did you recompile the theme afterwards?
  18. Occam

    Goodbye

    I believe this is exactly what happened in actual practice. You've really spent a lot of time on this, and you've pushed this project a huge step forward. Your decision has my utmost respect and is also very reasonable for me. This said, I'm afraid this is just another step towards the burial of tb. And I really hope I'm wrong.
  19. Maybe it helps to rename all instances of $dir to $dirX.
  20. 😊 You don't have to, this wasn't meant personally. Yep, and this means the developer will loose money if he or she doesn't adapt his module. But what does he loose when he refuses to adapt his module to thirty bees? But Bleeding Edge states that Panda isn't compatible. However, Sunnytoo's Transformer theme works properly with thirty bees 1.1.1. EDIT: Sorry, obviously it wasn't the current release of bleeding edge. After running the Core Updater Transformer stopped working, too. You have to manually reset each and every module though all are displayed as active in the back office. Is this what compatibility and being free of bugs looks like? It is not sufficient if just the two custom templates are working properly!
  21. All this may be true, but your argument still doesn't work. If thirty bees were a widespread and correspondingly potent shop system, you could require third party modules and themes to be adapted by their developers to each new version. But this is not the case. If users report that cache still worked with 1.1.0, but not with 1.1.1, then it may of course be due to the programming of the panda theme and its modules. Maybe you are right. I guess you are. But that won't help you. thirty bees is not in the position to impose conditions on third parties. Instead, in order to survive and secure some small market shares, thirty bees must guarantee full compatibility - and not the other way around. Almost nobody develops themes or modules specifically for thirty bees, and this is the big difference to Prestashop. They can afford to make such demands. I'm afraid, you cannot.
  22. Occam

    Rounding

    This is not what a shop system should do. However, I guess you can use a Smarty statement In the product.tpl to format the price: {$price|string_format:"%.2f"} Or use number_format {$price|number_format:2} will output 10,00 (EU standards) {$price|number_format:2:",":"."} will output 10.00 (US standards)
  23. Definitely not! It's not an error, just a warning of PHP 7, only displayed in debug mode. To avoid this you can change those issues for PHP 7.0 to 7.2 to: if (is_array($thisvariable) || $thisvariable instanceof Countable) or is_array($thisvariable) && count($thisvariable) If your server uses a newer PHP release like PHP 7.3, change the statement count() just to is_countable().
  24. @lesley That's not something you need to apologize for, though. Your own health should always be given priority over professional goals and entrepreneurial visions. I wish you strength and all the best for your surgery and your hopefully well recovery. God bless you.
  25. You mean this chief programmer, whose visions of a tabula rasa in strange denial of reality are based on the assumption that hundreds of IT companies or freelancers who develop modules or themes for Prestashop will enthusiastically change their developments completely and follow their new leader unconditionally. Dream on! This is what the real world looks like when you don't view it from the Prestashop ivory tower: (https://gitter.im/PrestaShop/General?at=5df21d010616d6515e268af9) What we see currently, after more than 4 years of new development, is clumsy, split into thousands and thousands of files, more confusing than ever and constantly generating new problems and bugs. Borowicz himself does not dare to predict when the development will come to an end. And if he doesn't leave Prestashop prematurely like all his predecessors, the last annoyed user will probably have turned to a different shop system before the visions could be realized. My goodness, this is a shop software and not an isolated special design to control the next Mars expedition.
×
×
  • Create New...