Occam

Update ... and just for the record: a) $html = false (default value) --> removes all visible html tags of a given textarea, incl. added <br> for a linefeed ( &#10; ). But it does not affect a hard carriage return ( &#13; &#10;). Every new line you start in a textarea field will be treated as a linebreak, no matter if you finish the previuous line with a RETURN (linebreak) or a SHIFT RETURN (linefeed). b) $html = true --> keeps all visible html tags of a given textarea and changes every <br> to <br /> for compatibility reasons. Cases a) and b) Linebreaks (&#13; &#10;) in a textarea will always be maintained in the database field (after the bug fix above). The current function updateValue() will not remove linebreaks in a textarea. Case a) Each html tag will be removed before storing in the database. Case b) All html tags incl. <br> will be kept in the database. ==> With the current modifications the bankwire details and address seem to work properly. Thank you, @datakick. I was just puzzled because the line breaks did not disappear when setting $html to default like before the bug fix.

No, it is a fresh 1.1.0, upgraded to Bleeding Edge. The only modifications I made were your proposals. Technically spoken: With reference to my tests in tb itself I would not dispute the validity of your test, but the reliability.

Well, I always doublechecked: the database entry AND the reloaded module page.

Maybe, but I guess you missed the point: Even with Configuration::updateValue('BANK_WIRE_DETAILS', Tools::getValue('BANK_WIRE_DETAILS'), false); in bankwire.php the string will be stored formatted in tb_configuration. The parameter seems to be always $html = true when you call this function.

I checked this once more, and it seems that if you omit the else-branch in function function updateValue of Configuration.php completely, the corresponding change in bankwire.php, though explicit, seems to be superfluous. public static function updateValue($key, $values, $html = false, $idShopGroup = null, $idShop = null) { if (!is_array($values)) { $values = [$values]; } // sanitize values foreach ($values as &$value) { if (! is_numeric($value)) { if ($html) { // if html values are allowed, just purify html code $value = Tools::purifyHTML($value); //} else { // if html values are not allowed, strip tags // $value = strip_tags(Tools::nl2br($value)); } } } I did not find out yet the reason why the boolean variable $html seems to be true by default.

Da hätte ich vieleicht auch als erstes nachgucken sollen! Und wo genau? Denn ich finde nur das hier: https://github.com/thirtybees/thirtybees/commit/8e89acf9061e88bc106658891c8bd5abb83eeb9c#diff-f44483a142f09ca47bd59224eb070bfb Und damit hat sich eigentlich erst der Bug eingenistet. Hast du mal einen Link für mich?

Das wäre mir jetzt neu, denn das lässt sich doch über die Status-Einstellungen regeln. Du kannst doch die Rechnungsgenerierung an die Auftragsbestätigung koppeln, indem du den automatischen Versand unterbindest und mit einem selbst erstellten Status "Auftragbestätigung" verknüpfst. Dann kannst du welbst entscheiden, wann der Kunde eine Rechnung sieht. Wenn du darüber hinaus die Bestellung auf Rechnung einer Kundengruppe "Stammkunden" zuweist, die Neukunden nicht angezeigt wird, dürfte der Anteil derjenigen, für die eine Rechnung ausgedruckt, aber dann doch nicht verschickt wird, denkbar gering sein. Den Status "Bezahlt" bekommt die Bestellung natürlich erst nach Eingang des Rechnungsbetrages aut dem Konto. Im Übrigen gilt: Wenn der Kunde es sich anders überlegt, dann erfolgt eine Storno-Buchung, egal ob er gar nicht bestellt oder eine retournierte Lieferung ganz oder teilweise vergütet wird. In einem Fakturierungsprogramm würde man auch nicht anders verfahren. Andernfalls würdest du auch gar nicht deinen Dokumentationspflichten gerecht werden.

Es liegt an einer foreach-Schleife in der Funktion updateValue in der Datei /classes/Configuration.php. (Oder genauer gesagt, an der Aufsplittung einer Funktion in zwei, bei der bestimmte Informationen anscheinend verloren gehen.) Wenn du nicht warten willst, bis der Bug behoben wird, dann kopiere einfach die gesamte Funktion aus der Version thirty bees 1.0.8 und ersetze damit die gleichnamige Funktion in thirty bees 1.1.0. Dann ist der Bug schon mal zumindest außer Kraft gesetzt und es funktioniert wieder.

Eigentlich sollte das beim Speichern aber nicht passieren. EDIT: Habe es gerade nochmal in der Datenbank überprüft. Du hast recht. Obwohl das aus dem Quellcode nicht ersichtlich ist, werden alle HTML-Steuerzeichen aus dem Text entfernt, bevor er als Variable BANK_WIRE_DETAILS in der Datenbank abgespeichert wird. Fügt man manuell ein <br> in den Text ein, dann wird sogar alles, was danach kommt, beim Speichern abgeschnitten. Das solltest du als Bug melden.

In any case it helps to avoid the warning, but I understand the problem. You should discuss this with the developers of PHP 7.3. So what would you suggest as replacement: is_array ... || instanceof ... ?

Maybe this problem was caused by the following change in the class Group.php introduced with Bleeding Edge: public static $definition = [ 'table' => 'group', 'primary' => 'id_group', 'multilang' => true, 'fields' => [ 'reduction' => ['type' => self::TYPE_FLOAT, 'validate' => 'isPercentage', 'size' => 17, 'decimals' => 2, 'dbDefault' => '0.00'], 'price_display_method' => ['type' => self::TYPE_INT, 'validate' => 'isPriceDisplayMethod', 'required' => true, 'dbType' => 'tinyint(4)', 'dbDefault' => '0'], 'show_prices' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '1'], 'date_add' => ['type' => self::TYPE_DATE, 'validate' => 'isDate', 'dbNullable' => false], 'date_upd' => ['type' => self::TYPE_DATE, 'validate' => 'isDate', 'dbNullable' => false], /* Lang fields */ 'name' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isGenericName', 'required' => true, 'size' => 32], ], 'keys' => [ 'group_shop' => [ 'id_shop' => ['type' => ObjectModel::KEY, 'columns' => ['id_shop']], ], ], ];

@musicmaster C'mon, I really don't need any tutoring, because I know 1.4 as well. The multishop feature required a table like shop_group from 1.5 on. So you really claim that the table ps_group_shop has only one entry at all in 1.5 and 1.6? Or do you mean one entry per group? Or did you want to say that the former entries were replaced by jst one during the upgrade process?

Yes, I read what you had mentioned. 😊 But you also wrote: Well, I never upgraded from 1.4 to 1.5 but started 1.5 with a fresh installation. So, afaik in Prestashop 1.5 as well as 1.6 and also in tb there are as many entries in the table ps_/tb_group_shop as there are customer groups. But since I assume that you, as a database expert, know this for sure, you may have expressed yourself misleadingly. What exactly do you mean with the following statement: The tb update process? Or really the PrestaShop upgrade to 1.6? I'm a bit clueless.

@musicmaster Maybe that there' s been a little misunderstanding. I suppose you are confusing the database tables group_shop (assignment of customer group ids to shop id) and shop_group (IDs of shops, entry default for 1 shop)

I couldn't reproduce this issue either. The bankwire module works properly, there must be something else causing this error. You can avoid warnings like this by changing the count() function to is_countable(): Or, like I would prefer, too, by just deleting unused modules.

I did not use demo data. And I am able to reproduce this behavior in Bleeding Edge, too.

😁 This was the first I did check. How about you test first my proposal before you make any speculation as to what I might have done wrong. That is not the best approach.

First of all: This is not "my version", I just took it from a former release of tb. However, using this version prevents the shipping costs from being rounded to the full dollar/euro, as tb 1.1.0 does with refund by default. I don't claim to have solved all problems caused by the changed core rounding methods. This is just a quick'n'dirty solution to help the user - and it works for the credit slip. Now the programmers of tb got to find out what is causing this bug. I just wanted to offer an interim solution to avoid it.

Hi @RabbitZzZ, the current tax calculation works pretty good for invoices. But the refund is a mess in 1.1.0, no matter if master or dev release. You may circumvent the bug(s) by using an elder version of the TaxCalculator.php which I attach in the zip below. The refund of shipping costs will work correct then, but even if you just refund the shipping costs, the product taxes are always displayed in tax details with a minus sign. It doesn't effect the total refund amount but is confusing for customers, like in this credit slip: Seems there is more than one bug to fix. A working TaxCalculator.php: Fix TaxCalculator Bug.zip

😊 yep ... but, sorry, I should have read the whole message. It was caused by a module for partial shipment which was still installed and working but wasn't displayed in the modules section any longer since I upgraded my test shop to Bleeding Edge. (Just another 1.1.0 bug.) The message disappeared after renamed the module's directory.

Nope, This would lead to just another error message.

You forget that that the column name has always been a required field in in order_state_lang, which is left joined in the sql query. public static $definition = [ 'table' => 'order_state', 'primary' => 'id_order_state', 'multilang' => true, 'fields' => [ 'invoice' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0', 'dbNullable' => true], 'send_email' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'module_name' => ['type' => self::TYPE_STRING, 'validate' => 'isModuleName', 'size' => 64], 'color' => ['type' => self::TYPE_STRING, 'validate' => 'isColor', 'size' => 32], 'unremovable' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbNullable' => false], 'hidden' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'logable' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbType' => 'tinyint(1)', 'dbDefault' => '0'], 'delivery' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'shipped' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'paid' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'pdf_invoice' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'pdf_delivery' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'deleted' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '0'], 'active' => ['type' => self::TYPE_BOOL, 'validate' => 'isBool', 'dbDefault' => '1'], /* Lang fields */ 'name' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isGenericName', 'required' => true, 'size' => 64], 'template' => ['type' => self::TYPE_STRING, 'lang' => true, 'validate' => 'isTplName', 'size' => 64, 'dbNullable' => false], ], This is nothing new, and like PrestaShop before tb 1.1.0 creates the database table tb_order_state during the install procedure, see /install/data/db_schema.sql: CREATE TABLE `PREFIX_order_state_lang` ( `id_order_state` INT(11) UNSIGNED NOT NULL, `id_lang` INT(11) UNSIGNED NOT NULL, `name` VARCHAR(64) NOT NULL, `template` VARCHAR(64) NOT NULL, PRIMARY KEY (`id_order_state`, `id_lang`) ) But there seems to be a bug in some fresh installations, because like shown in the previous post the order_state_lang fields are created in the database table order_state.

We both know this is nonsense. But my priority has always been a fast working shop, easy to handle for users. Perfect clean code as a desideratum, yes. But not on top of the agenda. For a merchant a shop system with some known bugs that may easily be circumvented is a thousand times more useful than a new designed shop system with unexpected bugs lurking everywhere. We face this with PrestaShop 1.7, and unfortunately now with thirty bees 1.1.0. And there is a difference: Prestashop is a known player in ecommerce, thirty bees wants this to be. However, that said, I got the subtext of your posts and will withdraw from thirty bees, of course. I really don't know if you're primarily interested in a functioning shop system as an alternative to Prestashop, or just in satisfying personal vanities. In any case, it seems to be a constant lonely individual fight, even if you are well skilled technically. I wish you good luck.

😊 Come on, don't get upset. Just stay objective and stop such polemics. I didn't attack you personally and I don't see any reason for it. I really have a lot of sympathy for this project. Otherwise I wouldn't get active here. But that doesn't mean I have to endorse all of your solutions.

Sounds good, really! Plausible and convincing. But after reading your explanation why it should be demanded to avoid such 'blasphemy' I took a quick look into the thirty bees marketplace, and afterwards into PrestaShop Addons. And you know what? There is currently this normative power of the factual that shouldn't be ignored.