Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Occam last won the day on January 3

Occam had the most liked content!

Community Reputation

89 Excellent

Recent Profile Visitors

1,381 profile views
  1. Occam


    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)
  2. 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().
  3. @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.
  4. 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.
  5. It's not working this simple. There is no array footer available in this tpl. Why don't you just use this invoice: https://forum.thirtybees.com/topic/1817-1817/pdf-invoice-eleazar/?tab=comments#comment-18971
  6. Nein, das wirst du auch nicht. Es geht bei Nutzung des Niara-Themes einfacher, wenn du direkt AEUC anpasst. Dann kannst du sogar zwei Fliegen mit einer Klappe schlagen, weil der Kunde nicht mal mehr klicken muss. Öffne die Datei modules/advancedeucompliance/views/templates/hook/hookOverrideTOSDisplay.tpl Ändere Zeile 33 von <input type="checkbox" name="cgv" id="cgv" value="1" {if isset($checkedTOS) && $checkedTOS}checked="checked"{/if}/> zu <input type="checkbox" name="cgv" id="cgv" value="1" checked="checked"/> Anschließend in den AEUC-Moduleinstellungen nochmal den rechtsicheren Checkout speichern, weil thirty bees 1.1.0 etwas träge ist mit dem Aktualisieren. Das war's auch schon.
  7. Das Hauptproblem scheint einfach die Inkompatibilität des Niara-Themes mit dem Modul Europäische Rechtssicherheit (AdvancedEUCompliance) zu sein. Möglicherweise liegt es aber auch an thirty bees 1.1.0. The main problem seems to be simply the incompatibility of the Niara theme with the AdvancedEUCompliance module. However, it may also be related to thirty bees 1.1.0. 1. thirty bees 1.1.0 without AEUC. Checkbox is visible (though without a headline): 2. thirty bees 1.1.0 with activated AEUC. Checkbox has vanished (but the headline reappears): 3. thirty bees 1.1.0 with activated AEUC and a compliant theme (Transformer). Checkbox is visible:
  8. @Landmücke Und jetzt noch mal bitte auf Deutsch, denn - sei mir nicht böse - ich habe absolut nicht verstanden, worum es dir genau geht.
  9. ??? Whatever this means, in my view neither a checkbox (not legally required) nor this shifting makes any sense. A text field with links to terms of trade and privacy policy would be sufficient and much easier to handle.
  10. Ik ben bang dat ik het daar niet mee eens ben, want dat is niet waar. Met een paar kleine aanpassingen kon Transformer worden aangepast naar dertig bijen 1.0.8. Voor 1.1.0, althans voor de ontwikkelaarsversie, zijn geen verdere wijzigingen nodig. Het enige probleem met 1.1.0 is dat de modules één keer handmatig moeten worden geactiveerd of gereset om de frontend te laten werken.
  11. So at the moment, no theme, not even the Niara theme that comes with tb by default, meets the strict criteria? Not to mention the following warning concerning the Niara theme: Warning: Theme installed or enabled following modules but didn't provide hook list for them. Theme should always provide list of displayable hooks for managed modules in order to achieve consistent results. If no hooks are specified in config.xml file, module hook list will remain unchanged. If this is wanted behaviour, theme developer should make it explicit by adding manageHooks="false" into module entry Please contact theme developer and request correction of theme config.xml file Are you serious?
  12. I'm afraid, that this does not solve the problem of theme incompatibilty with thirty bees. It is just more puzzling for merchants, incl. those (which are legion!) who don't even know what a hook is. And the results in the frontend are poor. You still need to reset most of the active modules to make the theme work properly. Non-experts would not understand that and instead complain about bugs or lack of compatibility. Hence my question again: Does thirty bees really have the market power to dictate to theme (and module) developers how to write their software? Or is this puristic approach (however justified it may be) the direct path to meaninglessness at the time being? After all, it's by no means a situation where developers are rushing to create special adaptations for thirty bees. Just for the record: if you were a merchant, you would have other burdens and would understand such challenges only as an imposition. A merchant does not want to have to care about the software. He just wants it to work for him. He is neither interested in hooks nor in disputes with a theme developer who would definitely only answer that thirty bees causes these problems because they do not occur with PrestaShop. Just my 2 cents ....
  13. I checked it. Currently 88% of thirty bees is translated into Spanish, which means that a few thousand of items are still displayed in English. But this does not apply to the examples you gave. The sort order is completely translated. Labels like Sale or New may have to be translated in the module's section, too. The translation for the availability label, however, has to be translated for each product separately in the products section of the BO, tab Quantity. If you have many products the only way to simplify this would be a change via SQL command or the use of @musicmaster's Prestools for a global change. Currently the handling of 3rd party themes like yours is buggy. So I'd suggest to automatically import the Spanish language in locations --> translations into all themes. And to avoid the behavior you described, you should always make a backup copy of the folder themes --> <your theme> --> lang, or at least the es.php file you find there, after your own translations. Until the bugs are fixed, it is recommended to always upload this updated version to the themes default-bootstrap and Niara.
  14. Problem is that currently just 4 languages are nearly full translated (German, Italian, Slovenian and Russian), followed by Dutch, Hebrew, Portuguese and Spanish. What is your language, and which items did you translate and were afterwards displayed in English again? You should know that custom translations for mails and modules are stored to the theme directory, not to the original files.
  • Create New...