Occam

Exactly, hence my question marks! No offense, but ... this is just wag the dog! The Niara theme is not so important, that you have to introduce own functions. It would be much easier if this theme just meets conventions. Period! And new creations like Niara_smaller and Niara_smallest are not covered either by other modules, because they are simply incompatible. Not to mention the fact that the Niara theme itself does not use underscores in image names.

????

I'm afraid you missed the point. This is not about fixing bugs, this is about maintaining compatibility.

50 minutes ago, Traumflug said: It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case. 1. I'm afraid, I wouldn't agree, Markus. This would be ok if there weren't third party modules that use standard naming convention and don't consult any database entries. 50 minutes ago, Traumflug said: And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990. For a start-up like thirty bees a statement like that sounds pretty presumptuous. Shouldn't thirty bees remain compatible for now? 2. Thirty bees 1.1.0 stores different names depending on the fact if you use only one or several languages. Example = 1 language: Niara_home Example > 1 language: en-default-Niara_home, de-default-Niara_home, es-default-Niara_home etc. The latter will be found, the first not, as you may read form this exemplary code from product.tpl: src="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg" srcset="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg" Not to mention the fact that the theme installer doesn't configure a default_large master file for Niara. There's something fishy about it

If $show_brand_logo is boolean which I assume, it can only be 0 (deactivated) or 1 (activated). So if $show_brand_logo > 1 makes no sense and must therefor cause an error.

This already has a tiny disadvantage: the Niara theme won't find the images afterwards, because in the theme as well as in many modules the picture format names are hard coded - no matter what @zen believes.

Though I'm not sure if compatibility with PrestaShop is a chief aim of thirty bees anyway, I'm puzzled too. But in this case not by any lack of compatibility, because my current test professional (thirty bees 1.1.0) creates the expected defaults, though not really following the naming convention (default is not attached but prefixed for some unknown reason): en-default-Niara_home_smaller.jpg, en-default-Niara_large.jpg ... Weird! But at any rate bad practice.

This may be a desirable solution from a programmer's point of view, but most merchants are pure users. They don't have your knowledge and don't want it. They are looking for a ready-made and want to sell. We already experienced this in Prestashop when Francois-Marie had the idea of the Starter Theme. That absorbed a lot of energy and was discarded at some point. The concept of the child-theme also seems to step in the same direction - but I feel that the needs of the average user are not met with such features.

I know this format which unfortunately does not comply with some of the bigger European countries though throughout the EU there is no common standard. For instance UK is more likely between the US postal format, but not the same.

I hope not. In this case, European users are more likely to opt for other shop systems. It would be better if the arrangement were flexible so that the order could be rearranged without changing the core.

Open the link you posted above. It provides all informations you need: /controllers/admin/AdminOrdersController.php, line 2107. Open this file and correct the misspelling. That's all you need to do.

Smarty cache isn't the problem in this case, activate once the option recompile.

Community theme and Transformer theme seem to run properly, but not the Niara theme: Some strange cache errors or just incompatibilities with AEUC, different behavior in 5-step-checkout and OPC: In OPC mode radio buttons for carrier don't work. Tested with PHP 7.2 and 7.3 EDIT: no. 2 seems to be caused by the free GDPR module.

On 9/9/2019 at 9:43 PM, datakick said: This move was really necessary. The 3.1.19 version was already 5 years old, and it was reporting deprecation warnings on php 7.1/7.2. It would stopped working on future php versions. I am really glad that I had read many reports about incompatibilities of Smarty 3.1.31 before. Therefore I only integrated those parts in the previous release 3.1.19 that were required by PHP 7. Now PrestaShop versions 1.5.6x and 1.6.1x run with my adapted 3.1.19 without any problems or even warnings under PHP 7.3 - but unfortunately not thirty bees 1.1.0! This is perhaps now to a large extent compatible with the new Smarty version. But this probably also means that some (or many?) 3rd party themes and modules have to be adapted, too, to be compatible with thirty bees. That doesn't make it any easier.

You won't find it in the translations section. These strings are taken from the database table tb_configuration, and you can adapt them directly on the module's configuration page in the text editor for every language you need. The GDPR does only requite the hint with a link. But neither on the checkout page, nor on the pages authentication or contact a checkbox is required.

I beg your pardon, it was your advice, not mine, not use overrides because they were "even worse" (eh, any reason why?) I would ever prefer to patch with overrides which would be easy in this case. But to please you I have removed my zip file.

If this fix is even worse than overrides you better do not use it. And just for the record: For me the possibility of overrides has always been one of the highlights of PrestaShop/thirty bees.

Have a look into this topic: https://forum.thirtybees.com/topic/3335-unknown-column-active-in-field-list-ps_order_state/

Ok, you may give up (which is sad for a moderator of this forum) - I do not! So, for other users who simply want the order slip to work properly, I added a fix. I made some changes to the class /pdf/HTMLTemplateOrderSlip.php and adapted all files from which the pdf is generated by removing the minus sign characters. @wakabayashiWithout a separated order-slip.tax-tab.tpl or a change in invoice.tax-tab.tpl you would never achieve to remove the minus signs in the tax details breakdown. You can apply the fix by just replacing the original files with the modified ones in the zip file. The directory path is included. Fix Bug Order Slip.zip. (removed)

Actually, We face 2 bugs. First a credit slip with negative amount, which may be the easiest way for a programmer but is nonsense for business purpose. The second and more severe bug is that the total order amount including tax total amount are displayed as negative values which is totally wrong. The first is afaik PrestaShop standard since 1.6.1x, the second is a special problem of thirty bees. Both need to be fixed. Correct values for credit slips like the one I posted above can only be created with PrestaShop 1.5x and maybe until 1.6.0.14. Afterwards the trouble began ...

Following problem: A customer sends back the complete order or parts of it. What to do now? If you decide to refund a complete order or do a partial refund with a voucher that the customer may use with his next order, then you only need to choose voucher when asked how to refund. 1. step: Refund or partially refund the order by clicking either the button Return products (complete order) or Partial refund (part of the order incl./excl. shpping costs)- 2. step Choose Voucher as refund method. Your customer will receive automatically an email with the voucher code. ________________________________________________________________________________________ If you want your customer to receive a voucher for other reasons, then do this: Go to Price Rules --> Cart Rules Click Add a new Cart Rule Open Tab Information Enter a Name for this rule Generate a voucher code Enabling Highlight will remind your customer during checkout of the voucher code Enabling Partial use will allow your customer to split his voucher, if the value is greater than the next order's amount Leave other entries standard Open Tab Conditions Fill in name of your customer Fill in validity dates for this voucher Fill in any minimum amount for an order where this voucher may be applied Leave entry 1 for total available and total available for each user Open Tab Action Choose Amount as discount type Enter the voucher amount (tax incl./excl. by choice) Save this rule. Done! 3. step Send a mail to your customer with the voucher code and tell him, that he may apply this code during checkout in the first step Order detail.

To force thirty bees to create a credit slip you first need to add some code to /<Admindir>/themes/default/template/controllers/orders/helpers/view/view.tpl (after line 1207): <!-- START --> <p class="checkbox"> <label for="generateCreditSlip"> <input type="checkbox" id="generateCreditSlip" name="generateCreditSlip" onclick="toggleShippingCost()"/> {l s='Generate a credit slip'} </label> </p> <!-- END added --> Or as override the complete file saved as override/controllers/admin/templates/orders/helpers/view/view.tpl But in any case this other bug needs to be fixed and there ought to be different methods and templates for voucher and credit slips. That would be a real improvement in comparison to PrestaShop.

Nee, die sind natürlich nicht echt. Ich habe das jetzt mal mit einem anderen Testshop von mir gemacht. Die berechneten Werte hierin sind übrigens PrestaShop 1.5 Standard. Da wussten die Programmierer in Paris noch, wie's geht. So sollte so eine Gutschrift eigentlich aussehen, wenn sie korrekt erzeugt wird. Der Gesamtbetrag der Bestellung hat nichts darin zu suchen!

Allmählich verstehe ich das Problem. a) Das kann man beliebig oft machen. Und es wird jedesmal eine neue Gutschrift erzeugt. Aber ... b) Die Gutschrift, die von 1.1.0 erzeugt wird, ist völlig falsch. Zwar wird, was auch richtig ist, der Stornobetrag mit einem Minuszeichen versehen. Anschließend aber passiert das in der Gutschrift auch mit dem Gesamtbetrag der Bestellung - und das ist völliger Unsinn! Das ist schon ein heftiger Bug. c) Wenn der Kunde das Geld gar nicht erstattet bekommt, sondern bei der nächsten Bestellungen einsetzen soll, dann wäre das ein Gutschein. Ist aber in Deutschland zumindest so nicht erlaubt.