Occam
-
Posts
303 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by Occam
-
-
11 minutes ago, Traumflug said:
but also with removing this part of the name, right?
????
-
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 > 1makes no sense and must therefor cause an error.
-
1
-
-
44 minutes ago, lesley said:
When you install a theme, the configuration should add the image types needed for the theme, so changing the name should not be a problem you just need to regenerate the images.
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.
-
1
-
-
2 hours ago, musicmaster said:
Are we now going back to the 1.4 naming convention?
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.
-
48 minutes ago, datakick said:
You can copy the theme to different directory, install it, and make changes there.
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.
-
1
-
-
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.
-
1
-
-
3 hours ago, RabbitZzZ said:
Does anybody know the workaround?
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.
-
-
30 minutes ago, x97wehner said:
it doesn't affect anything. Same format.
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.
-
2 hours ago, cprats said:
Translation for the checkbox does not work
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.
-
1
-
-
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.
-
3 hours ago, wakabayashi said:
AND just modify core files is in my opinion even worse than overrides.
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/
-
1
-
-
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)
-
1
-
-
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 ...
-
1
-
-
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!
-
1
-
-
Allmählich verstehe ich das Problem.
a)
26 minutes ago, wakabayashi said:Dann kreierst du im ersten Schritt aber keinen order-slip oder?
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.
-
18 minutes ago, wakabayashi said:
What do you mean with total refund?
In thirty bees the button is called Return products.
18 minutes ago, wakabayashi said:you want to cancel all products, why dont you just us "cancel order" status?
Quite simply: Because I want it to happen! Just changing the status is like saying to a child: You just have to close your eyes and the wicked witch is gone.
As for your questions: Just read my PDF carefully.
Broken images
in Technical help
Posted
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.