[PLUGIN] Fotorama_XH

[cmb]

Ok, für die "quick'n dirty"-Version wäre ja auch strstr() das Mittel der Wahl.
Wird m.W. unmittelbar auf die entsprechende C-Funktion abgebildet. (Wenn ich sowas codieren würde, würde ich sogar den Code aus der C-Bibliotheksfunktion 1:1 einsetzen).

C's strstr() ist wirklich sehr elegant, da es ja einfach einen Pointer auf das erste Zeichen zurück liefert. Das geht aber bei PHP nicht, weil dort Strings nicht einfach 0-terminierte Arrays sind, sondern structs, die auch die Länge des Strings separat speichern, damit Binärstrings (also welche, die NUL enthalten) ebenfalls verwendet werden können. Daher muss PHP bei strstr() eine Kopie des Teilstrings anlegen. Daher ist es hier noch effizienter strpos() zu verwenden.

Zur Frage der Sicherheit: der String wird ja aus einer XML-Datei ausgelesen, in die er auf die eine oder andere Weise manuell eingetragen werden muss. Solange sichergestellt ist, dass diese Datei nicht anderweitig manipuliert worden ist, oder sonstwie Unsinn drinsteht -> Code Injection, wäre der primitive Ansatz m.E. sicher.

An Code-Injection (oder besser gesagt, XML Entity Injection) hatte ich hier überhaupt nicht gedacht – guter Punkt. Könnte tatsächlich ein Problem sein. Vermutlich sollte ich auf JSON umstellen, zumindest wenn es eine GUI für die Administration gibt.

Mir ging es aber gerade auch darum, dass keine externen Bilder an die falsche Funktion übergeben werden; schon bei imagecreatefromjpeg() (Thumbnailerzeugung) kann es da u.U. Probleme geben (in Verbindung mit einer externen libgd, können korrupte JPEG-Dateien PHP mit einem fatalen Fehler aussteigen lassen). Daher habe ich Deinen Vorschlag mit einem fixen Thumbnail für externe Dateien bereits umgesetzt (bisher nur lokal; muss noch ein bisschen testen).

Den durfte ich dann einzeln mit dem Emacs wieder rauspuhlen... das muss zu CMSimple-2.9-oedit-Zeiten gewesen sein.

Du bist vermutlich eine der wenigen, die den Content bisweilen noch von Hand bearbeiten. Wenn Du Zeit hast, schau Dir doch bitte mal https://github.com/TN03/XH_split/archive/master.zip an; würde dieses geändert content.htm Format passen? Siehe auch den mittlerweile ellenlangen Thread XH: alternatives Seitensplitten unabhängig von <hx> - Tags.

PS: Unterstützung für externe Bilder ist nun verfügbar. Videos funktionieren im Prinzip im Thumbnail-Modus auch schon. Da muss aber noch nachgebessert werden.

[beate_r]

Hallo Christop,

danke. Ich werde mir das morgen mal anschauen.

[beate_r]

Was die Umstellung des Seitensplittings angeht: solange das frei editierbar bleibt, könnte ich damit leben. Auch wenn es dann nicht mehr möglich ist, mit z.B. latex2html eine content.htm zu erzeugen...

Wenn es keine konfigurierbare Rückwärtskompatibilität geben sollte (content.htm mit Hx als Trenner), oder auch nur die starken Einschränkungen wie bei der Einführung von pagedata, könnte ich mir allerdings grundsätzlich vorstellen, dass ich auf 1.6.7 einfriere, solange das irgend geht.

So richtig überzeugt habt Ihr mich von der Notwendigkeit der Umstellung noch nicht... ( ... obwohl ich vermutlich zu den wenigen gehöre, die schon mal alle Hx-Levels für die Strukturierung von Webseiten benötigt hatten).

[cmb]

Was die Umstellung des Seitensplittings angeht: solange das frei editierbar bleibt, könnte ich damit leben. Auch wenn es dann nicht mehr möglich ist, mit z.B. latex2html eine content.htm zu erzeugen...

Ah guter Punkt! Ich hatte selbst mal ein kleines Script geschrieben, das speziell präparierte *.ood Dateien nach content.htm konvertiert. Zumindest etwas Abhilfe könnte man da generell mit einer permanent verfügbaren Import-Möglichkeit schaffen (bisher gibt es nur ein kleines Einmal-Import-Script).

[…] oder auch nur die starken Einschränkungen wie bei der Einführung von pagedata, […]

Dass die Integration der PageData in content.htm Probleme verursachen könnte, hatte ich nicht bedacht. Aber klar, erstellt man den Inhalt mit externen Tools, dann ist das natürlich ein Problem. Und diese Möglichkeit ist vielleicht eine der besonderen Stärken von CMSimple(_XH). Da muss auf jeden Fall noch mal drüber nachgedacht werden.

Konkret zu latex2html: wäre da nicht \begin{rawhtml} eine Option (sowohl was die PageData als auch was die Splitter-Kommentare angeht)?

[beate_r]

Dass die Integration der PageData in content.htm Probleme verursachen könnte, hatte ich nicht bedacht. ...

Meine Anmerkung bezog sich jetzt auf die ursprüngliche pagedata.php in den älteren Versionen. Pagedata in der content.htm hat mich bisher noch nicht groß gestört - ist zwar ein bisserl unübersichtlich und gewönungsbedürftig, aber bisher funktionierte auch so alles.

[Holger]

So richtig überzeugt habt Ihr mich von der Notwendigkeit der Umstellung noch nicht... ( ... obwohl ich vermutlich zu den wenigen gehöre, die schon mal alle Hx-Levels für die Strukturierung von Webseiten benötigt hatten).

Es geht nicht um die Anzahl der verfügbaren Hx - Levels. Es geht vereinfacht gesagt darum, dass man alle <hx> von <h1> bis <h6> zur sauberen Strukturierung auf allen Seiten verwenden kann. Es löst das Problem, dass man z.B. auf einer Level-3 - Seite den Seiteninhalt erst ab <h3> Strukturieren kann.
Bearbeiten der Inhalte in einem CodeEditor ist nach wie vor möglich. Die eingesetzten Split-Marker sind auch leicht verständlich.

Auch Import und Export per Skript oder RegExp im Codeditor sollte kein unlösbares Problem sein.

[beate_r]

nach dem Lesen des Fadens war mir nicht klar, worauf das jetzt endgültig hinauslaufen sollte / würde.

Aber ich schrieb ja

Was die Umstellung des Seitensplittings angeht: solange das frei editierbar bleibt, könnte ich damit leben.

Und wenn einen Modus zur Rückwärtskompatibilität gäbe, wäre es noch besser.

Als ich zu CMSimple-Perl-Zeiten mal darüber nachdachte, selbst was zu schreiben, wäre es eh in eine ähnliche Richtung gegangen. Aber mir ging es damals vor allem darum, Inhalt und Layout zu trennen, und dazu reichte meine Bastellösung mit SSI.

[Holger]

Und wenn einen Modus zur Rückwärtskompatibilität gäbe, wäre es noch besser.

Wenn ich mir das richtig überlege könnte das, abhängig von den Inhalten, u.U. sehr schwierig werden .

[cmb]

nach dem Lesen des Fadens war mir nicht klar, worauf das jetzt endgültig hinauslaufen sollte / würde.

Ist es ja auch noch nicht. Bisher ist es nur mal eine Idee (zu der es halt schon relativ viel positives Feedback gab).

Und wenn einen Modus zur Rückwärtskompatibilität gäbe, wäre es noch besser.

Das fände ich auch gut, falls die Codeübersicht nicht darunter leidet, und wir zumindest idealerweise noch weiter vom konkreten Content-Format abstrahieren können. Ich glaube seit einer kurzen Weile, dass das möglich ist, wenn $c nicht mehr ein Array, sondern ein Objekt einer Klasse, die ArrayAccess implementiert, ist.

Gewisse Probleme sehe ich aber für Templates: bei der klassischen Variante (XH 1.6.7) haben diese i.d.R. die gleichen Styles für <h1> bis <h3>; bei der neuen Split-Kommentar-Variante wäre das aber nicht mehr sinnvoll. Vermutlich aber verkraftbar, wenn das Template dokumentiert wofür es gedacht ist (Individualanpassungen können dann ja immer noch durchgeführt werden).

[Tata]

Ich habe Fotorama_XH,1.0beta2 installiert und zur eine Gallerie benutzt. Die thumbs.hover Bilder zeigen den blauen Rahmen nach oben verschoben und ich kann nicht finden warum es so ist.
[ external image ]
Sehe: http://dddlan.cmsimple.sk/?Fotogaleria/Rok-2013