[1.1.0] Zwirnis embedVideo

I installed this and your like plugin.

Now when i reply to a post I get ... even after uninstalling both

Hallo in die Runde,

Ally hat mich um Hilfe mit dem Problem gebeten, ich konnte die Ursache finden und lass sie Dir einfach mal da, damit Du eventuell Debuggen sparst:

Die vom Plugin angelegten Datenbank-Änderungen (Feldänderungen) wurden beim Deinstallieren nicht entfernt, deshalb hat deinstallieren bei Ally das Problem nicht gelöst.

Das Problem selbst entsteht aufgrund der Tatsache, dass dort MySQL 5.7 im strikten Modus im Einsatz ist.

Bei MySQL5.7 strict müssen alle DB Felder einen expliziten Default-Value bekommen, sofern Sie nicht in allen Queries auftauchen (was bei Plugins ja nie der Fall ist wenn sie sich an Standardtabellen anhängen, was ja logisch ist, weil sie nicht überall eingesetzt werden wenn mit den Standardtabellen gearbeitet wird). Ohne Fallback bzw. Default Value lässt MySQL5.7 strict die aber beim INSERT sonst nicht mehr durch wenn sie fehlen.

Die Felder
zwirni_likebutton_disabled

und
zwirni_embedvideo_disabled

hatten keinen Fallback Wert und lösten daher das Problem aus.
Mit Default ging zumindest der Query oben wieder durch, keine Ahnung ob er irgendwan noch weitere Felder findet aber für das obige Problem war das die Lösung.

LG,
Chris

Huhu,

sehr gerne! Ich kenn das ja selber wie man manchmal in seinen Scripten sitzt und flucht, weil es bei einem selbst funktioniert und beim Endkunden irgendwo ein Problemchen auftritt. Mit MySQL 5.7 bin ich da auch schon selbst hier und da über Problemchen gestolpert wo ich eine Stelle übersehen hatte und ein bisschen nachbessern musste. Beim aktuellen CF Update zum Beispiel die Stelle wo das Topic Split unter 5.7 den Dienst quittiert hatte. Grml.

Aber naja, andererseits verstehe ich natürlich, dass MySQL und PHP immer strikter werden, es dient ja grundlegend dazu, dass man aufgrund der mangelnden Fehlertoleranz dann echt extremst sauber arbeiten muss und das ist ja letztendlich auch für die Sicherheit dienlich, auch wenn man beim Entwickeln hier und da gerne mal flucht. (Ein anderes Kapitel unter MySQL 5.7 ist das veränderte und strenger gewordene GROUP BY Statement weil per default der "ONLY_FULL_GROUP_BY" Modus aktiv ist, aber das ist wieder ein anderes Thema *gg*).


Anyway um mal zu Deiner Frage zurück zu kommen bevor ich ganz abschweife:

Für die Post History würde ich persönlich tatsächlich eine eigene Tabelle für das Plugin anlegen, in der neben einer Unique ID für den History eintrag selbst ansonsten nur die Post-ID und der bisherige Text und vielleicht noch ein Timestamp gespeichert werden. Wenn Du dann eine Post History speichern musst würde ich da einfach in dieser Tabelle ein INSERT machen und basierend auf der Post ID dort wo Du die History-Einträge brauchst aus dieser Tabelle abrufen (".... WHERE `depend_post_id`=diePostID ORDER BY `mein_historydatum` DESC").

Das hätte meines erachtens auch den Vorteil, dass die Post-History in eine eigene Tabelle ausgelagert wird und er den LONGTEXT nicht direkt in der Post Tabelle mitschleppen muss. In Bereichen wo nur die Posts gebraucht werden hat er dann die History nicht mit anhängen, was die DB Zugriffe ein bisschen schneller gestaltet. Insbesondere in Foren, wo die Post Tabelle eh schon recht groß wird weil viel geschrieben wurde.

Und auch wenn das verwalten zweier Tabellen dann ein bisschen nervig zu programmieren ist kannst Du zumindest auch leichter Purge Funktionen z.B. für eine Wartung einbauen, dann könntest Du z.B. mit einem einfachen DELETE FROM .... basierend auf dem History-Timestamp z.B. sowas anbieten wie "alle Einträge älter soundsoviel Tage weg" oder so, falls der Platz in Foren doch mal eng wird für die History.


Also zumindest würd ich das da so lösen, natürlich ist das aber auch nur einer von vielen Wegen und dem eigenen Entwicklergeschmack.

LG,
Chris

In Version 1.0.3 the plugin is now completly translated and got a fix for preview-post with video-embedding.