Mediendeponie Rotating Header Image

PHP

[FIXED] Contao 3 GET-Parameter 404 not found – Holzhammermethode.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Aus der Serie “Arbeitszeitvernichtung für Fortgeschrittene” heute: Das GET-Parameter-404-Phänomen von Contao 3.

Contao 3 erlaubt die Übergabe von GET-Parametern in URLs im Verzeichnis-Style. Also z.B.:

domain.example/meinParameter/meinWert.html

Funktioniert auch ganz toll. Leider wurde in Version 3.1.3 still und heimlich verpflichtend, alle übergebenen GET-Parameter auch zwingend zu verwenden. Wer also, der sprechenden Namen wegen, etwas verwendet hat wie

domain.example/id/1234/detailAnsicht.html
statt
domain.example/id/1234.html

fällt auf die Nase – schließlich fragt er den Wert seines (unbeabsichtigt) übergebenen GET-Parameters detailAnsicht nicht ab. Pöser Pube! Statt eine verständliche Fehlermeldung auszugeben, triggert Contao in diesem Fall den 404.

Lösen lässt sich das Problem, indem überall auch wirklich alle übergeben Parameter abgefragt werden. Sinnvoll ist das Ganze ja, so wird Duplicate Content vermieden (Das war wohl auch Leos Motivation für diese krude Lösung, wie sich hier nachlesen lässt). Wo vorher also

domain.example/id/123/a.html
domain.example/id/123/b.html
domain.example/id/123/c.html

den gleichen Content unter unterschiedlichen URLs (vulgo: duplicate content) lieferten, gibt’s nun 404-Fehler. Warum hier nicht eine Lösung mittels (längst überfälligem) Routing oder zumindest mit Canonical-Tags gewählt wurde – weiß der Teufel. Die konkrete Implementierung des “Schutzes” findet ihr hier.

Es ist jetzt also angebracht, alle Module auf Vollständige Abfrage der GET-Parameter zu prüfen und zu korrigieren. Für’s schnelle Debugging und eventuellen legacy code, der nicht mehr lange überdauern soll, gibt es hier die Holzhammer-Methode, die sich prima in jeder compile()-Methode von fraglichen Modulen einbauen lässt.

// quick & dirty workaround: call all $_GET-params once, to avoid 404. (Andreas Guse 2014)
foreach ($_GET as $key => $value){
$tmp = \Input::get($key);
}
unset($tmp);

Hat Dir dieser Post geholfen? Like, share, +1, print+papierflieger, comment, … – thx.

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

Symfony 1.4 cached MySQL Query dank APC. F*§( it!

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

Ich habe in einem Symfony 1.4-Backend-Generator-Modul embedded-tables verwendet, die ich nun nachträglich um zwei weitere Felder erweitert habe. Nach dem Anpassen von schema.yml, dem neu Generieren der Klassen, dem einbauen der entsprechenden Widgets und dem leeren des Caches konnten zwar Daten eingegeben und gespeichert werden, leider wurden die gespeicherten Daten aber nicht angezeigt. Der Debug-Mode verriet mir, daß hier explizit die alten Felder ausgelesen, die neuen aber ignoriert werden. Doch warum? Und wo entsteht dieser Query?

Nachdem ich wirklich Stunden damit verbracht habe, zu versuchen, herauszufinden, warum, wie oder wo der Query für ein Admin-Generator-Module mit embedded tables zustande kommt, habe ich heute morgen von meinem Freund Michael den entscheidenden Tipp bekomme. Und das von einem Java-Programmierer. Tss…

Ja, der doofe PHP-Accelerator (APC) war’s, der den MySQL-Query tatsächlich noch gecached hatte. Offensichtlich wird der APC-Cache nämlich nicht bei einem ./symfony cc geleert. Er kann auch gar nicht übers CLI geleert werden.

Also kurzerhande in die preExecute() des Moduls folgende Zeilen eingefügt:
apc_clear_cache();
apc_clear_cache('user');
apc_clear_cache('opcode');

und siehe da – der Query ist nun vollständig. 🙂

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

0x1F Steuerzeichen in PHP entfernen

VN:F [1.9.22_1171]
Rating: 5.0/5 (7 votes cast)

Neulich habe ich eine RSS-Schnittstelle für den Export von Daten eines CMS in eine Smartphone-App programmiert. Nichts schlimmes. Nichts großes. Alles gut.
Leider stellte sich vor wenigen Tagen heraus, daß der zuständige Redakteur seine Artikel aus der Textverarbeitungs-Software direkt in das CMS kopiert. Ist soweit ja auch noch in Ordnung. Problematisch ist aber, daß hierbei Steuerzeichen mit kopiert wurden, die in HTML und XML nicht angezeigt werden können (und dürfen), was dazu führte, daß der nun nicht mehr valide XML-Feed von verschiedenen Readern angemeckert wurde.
Scheinbar ist weder das CMS (aus Basis von Contao) noch der WYSIWYG-Editor (TinyMCE) willens, das Steuerzeichen 0x1F (vermutlich auch weitere Steuerzeichen) herauszufiltern.
Blöde Sache.

Zu zweit haben wir uns eine ganze weilen den Kopf zerbrochen und ordentlich herum gegoogelt. Offenkundig gab es keine einfache Lösung.
Nachdem der wenig freundliche Entwickler der App, der “einfach nur einen Validen Stream, egal in welcher Form” wollte, mit dem base64-encodeten Steuerzeichen dann auf seiner Seite alles andere als glücklich wurde (“Unser CMS kann das nicht!!11elf1”) haben wir beschlossen, der Sache mal ordentlich auf den Grund zu gehen und das Problem zu lösen.
Mein werter Kollege war es nun, der mit am nächsten Tag eine Lösung präsentierte, die so elegant ist, daß ich sie der Welt nicht vorenthalten möchte:

Steuerzeichen aus einem String entfernen mit PHP geht nämlich in nur einer Zeile:

$text = preg_replace(“/[[:cntrl:]]/i”, “”, $text);

Geil, oder? 🙂
Also, ich hoffe, das hier finden ein paar Menschen, die das Problem in Zukunft sicherlich haben werden, bei Google & Co.
Bitte bookmarkt & teilt diese Seite und gebt dem Beitrag ein paar Sternchen, auf daß nicht jeder 2 Tage braucht, bis er oder sie über die Lösung stolpert! 😉

so long…

VN:F [1.9.22_1171]
Rating: 5.0/5 (7 votes cast)