Smarty Replace bei Selectbox funktioniert nicht

[demoncleaner]

Moin zusammen,
Ich hätte da mal gerade folgendes Problem.
Getestet auch im tpl_modified Template.

Ich hatte in meinem angepassten Template in der Anmeldung etc. die Selectbox Country zur Auswahl des Landes mit Hilfe eines |replace modifiziert. Es ist hier nur eine Klasse hinzugefügt worden. Hat soweit auch immer gut geklappt und die Selectbox sah so aus wie gewüscht. Nun ist mir gestern aufgefallen, dass die Selectbox für das Land gar nicht mehr angezeigt wird. Also hab ich mir das näher angesehen.

Das funktioniert nach wie vor wie es soll:

Code: PHP  [Auswählen]

{$SELECT_COUNTRY}

Das hier allerdings nicht:

Code: PHP  [Auswählen]

{$SELECT_COUNTRY|replace:"irgendwas":"was_anderem"}

Dabei ist es auch egal was ich versuche zu replacen. Sobald da replace dahinter steht ist im Frontend die Selectbox futsch. Das ist wie gesagt im tpl_modified auch so. Wie kann das denn sein? Replaces an anderer Stelle funktionieren wie gewünscht. Der Wert der zurück kommt ist an der Stelle NULL. Hab ich mit |var_dump mal getestet.

Hat jemand eine Idee? Wär klasse.

Linkback: https://www.modified-shop.org/forum/index.php?topic=40312.0

[Markus]

Hi demoncleaner,

der "Fehler" bzw. diese Eigenheit ist uns schon bekannt, siehe Ticket #16277.

Da steht auch ein möglicher Fix drin ... allerdings ist der nicht updatesicher. Mit der kommenden Version wird das aber behoben sein.

Markus

[demoncleaner]

Dank dir, Markus für die Mega schnelle Antwort.
Bin gar nicht auf die Idee gekommen, dass das tatsächlich ein Bug sein könnte, daher sorry, dass ich da vorher nicht nachgeschaut habe.

Fix hat 1a geklappt!

[Markus]

Hi demoncleaner,

das komische ist dass das nicht auf jedem Server oder Hostingpaket passiert. Da müssen wohl irgendwelche Einstellungen zusammen kommen. 

Kannst du mir evtl. sagen welche php Version du im Einsatz hast und kannst du ggf. nachvollziehen ab wann das nicht mehr funktioniert hat und ob da irgendwas auf dem Server aktualisiert wurde und sei es nur ein kleineres php Update?

Markus

[Timm]

Moin

nur mal eine Idee, die man schnell prüfen könnte:

die Stelle wo der Fehler entsteht

Code: PHP  [Auswählen]

$parts = mb_split(preg_quote($search), $subject);
            $count = count($parts) - 1;
            $subject = implode($replace, $parts);

mb_split ist eine Funktion von mb_string (Multibyte String)

mb_string hat eine Liste an unterstützten charsets

diese werden seit Php 7.1.22 anders überprüft

deshalb kommt es ohne Änderungen aus Ticket #1188 an der /inc/html_encoding.php zu Fehlern in der aktuellen Shopversion, weil dort noch nicht mehr unterstützte bzw umbenannte charsets vorhanden sind

eventuell führen diese zu besagtem Problem

Test:
PHP Version auf kleiner 7.1.22 stellen oder die nicht unterstützten charsets in der /inc/html_encoding.php mal entfernen und dann ohne die Änderung aus Ticket #1627 testen.

Gruß Timm

P.S. Es gibt eine etwas neuere Smartyversion 3.1.33, vielleicht könnte man die für die nächste Shopversion updaten!? Ist auch ein Sicherheitsfix mit eingeflossen.

[Markus]

Hi Timm,

danke ... ich habs mal ins Ticket #1627 eingefügt damit es nicht untergeht ... ändern bzw. fixen dürfen das andere

Markus

[Timm]

Wenn du mir die besagte Codestelle für die Fontawesome Icons in der Breadcrumb schreibst, würde ich es auch testen.

Aber einfacher wäre es, wenn demoncleaner kurz die Änderung aus Ticket #1627 wieder entfernt und die charsets testweise ändert. Wenn es dann geht, habt ihr wahrscheinlich den Fehler.

[Markus]

Hi Timm,

was du mit "Font Awesome" meinst verstehe ich nicht ganz.
Im Prinzip ist der Fehler reproduzierbar mit jedem "replacer" egal wo der im Template steht ... vor allem wenn ein Umlaut drin ist.

Markus

[Tomcraft]

Ich hatte die Probleme mit der Smarty replace Funktion bisher nur bei Umlauten.

Grüße

Torsten

[Timm]

@markus
im Ticket stand doch was davon, dass die Breadcrumb beim Punkt Privatsphäre und Datenschutz nicht richtig angezeigt wird, wenn man die raquo oder laquo mit Fontawesome ersetzt. Wusste nicht, dass das bei jedem replace zu Problemen führt.

Dann ist das doch noch einfacher zu testen. Im dev Demoshop ist der Fix aus Ticket #1188 schon enthalten. Vielleicht kennst du eine Stelle mit replace, wo du das schnell testen könntest. Sonst ändere ich mal testweise bei mir die inc/html_encoding.php zurück auf original und versuche es mit Umlautadressen im Registrierungsformular. Da sind bei mir auch replace Codestellen zusätzlich drin.

Gruß Timm

[Markus]

Hi Timm,

das ist ja in der Index der Part hier ...

Code: PHP  [Auswählen]

{$navtrail|replace:" &raquo; ":"<i class=\"fas fa-angle-right\"></i>"}

bzw. für Font-Awesome 4.x

Code: PHP  [Auswählen]

{$navtrail|replace:" &raquo; ":"<i class=\"fa fa-angle-right\"></i>"}

Markus

[demoncleaner]

Sorry, hab den Thread erst jetzt wieder gelesen. Kann ich da noch irgendwie helfen? Liegt es denn wirklich an irgendwelchen Charsets? Wo genau sollte ich die dann zum Testen ändern? Mit Umlauten hängt es jedenfalls aus meiner Sicht nicht zusammen. Ich kann ja egal was replacen und der Fehler tritt auf. Sogar wenn ich

Code: PHP  [Auswählen]

|replace:"":""
 

mache, bekomme ich den Fehler.
Interessanterweise aber nur bei der Selectbox nicht bei normalem Input.

[Timm]

Weiß man noch nicht woran es liegt. Ich hab’s auch noch nicht testen können. Was zu ändern wäre, stünde in den Tickets. Das war aber nur eine Idee - kann an was ganz anderem liegen.

Aber du könntest mal auf Markus antworten bzgl der aktuellen  Php Version, deinem charset und seit wann das ungefähr auftritt bzw bei welcher php Version du dir ganz sicher bist, dass es noch ging.

Vielleicht ergeben auch das testweise ausschalten des caches und der Komprimierungen was?

Gruß Timm

[demoncleaner]

Na dann wollen wir mal:

PHP Version 7.1.30
charset: latin1 (damit ist die Einstellung in der config.php gemeint?)

Seit wann es auftritt kann ich ganz schwer sagen. Ich hätte irgendwie vermutet, dass es eher was mit dem letzten Update als mit der Änderung der PHP Version zu tun hat.
Die PHP Version wurde vor rund einem Jahr geändert. Ich denke das Problem wäre dann schon vorher aufgefallen. Kann da aber nur mutmaßen.

Cache und Komprimierung: leider beides Fehlanzeige.

Nach Rücksetzung des Workarounds im Ticket bleibt der Fehler bestehen.

[Timm]

Bei meinem Test kam raus, dass die nicht mehr unterstützten Charsets aus Ticket #1188 nichts verändern.

Das Problem scheint sich nur auf Latin1 Shops einzugrenzen. Mit Utf-8 in der includes/configure.php konnte ich den Fehler der nicht angezeigten Breadcrumb bei Privatsphäre nicht erzeugen, wenn man das Wort mit ä statt &auml; schreibt - mit latinkam der Fehler.

Außerdem hab ich festgestellt, dass es mit PHP 7.0.33 und kleiner funktioniert und erst bei PHP 7.1 und 7.2 der Fehler auftritt.

Gruß Timm