jQuery und Lightbox-Plugin

[onli]

Ich.

Aber ja, auch das neue muss mit den WYSIWYG-Editoren noch getestet werden.

PS: http://www.onli-blogging.de/index.php?/ ... html#c4380

[yellowled]

Wer sitzt denn Stunden vor dem offenen Formular, was nicht besser in jedem beliebigen Texteditor zu formulieren wäre...?

Benutzer.

YL

[bernd_d]

Wer sitzt denn Stunden vor dem offenen Formular, was nicht besser in jedem beliebigen Texteditor zu formulieren wäre...?

Kann mir mal jemand einen Winke-Smiley im Board einbauen?

[Timbalu]

JUNGS! (- noch einer?)
DAS WAR eine rhetorische FRAGE!

Ich halte den neuen Ansatz via Browser Storage für wesentlich besser und denke auch, dass das das alte autosave ruhig updaten könnte. Damit dürft ihr dann alle glücklich werden.

[Timbalu]

Nachdem sich da bezüglich von lightbox updates nichts tat, habe ich mich da mal rangesetzt.

Bevor ich das nun als update verfügbar mache, könnten wir das vielleicht noch etwas weiter diskutieren. Zusammengefasst:

• "Problem" 1, es basiert zum Teil auf sehr alten lightboxes.
• "Problem" 2, es verwendet via lightbox2 die prototype lib (siehe jQuery noConflict Anmerkungen in diesem Thread)
• "Problem" 3, erwähnte Redundanz von jQuery instances
• "Problem" 4, eine kürzlich eingefügte Erweiterung des imageselectorplus Plugins (siehe http://board.s9y.org/viewtopic.php?f=4&t=20058) hat Auswirkungen in der Darstellung
• "Problem" 5, eigentlich kein Problem der lightboxes, ist das erwähnte serendipity_event_sidebarhider prototype include in einem Zip
• "Problem" 6, die Erweiterung auf den erwähnten thickbox fork 4.1 erfüllt keinen nennenswerten Zweck und arbeitet nicht wirklich

Zu 2: Mit dem vorletztem Update auf lightbox plugin version 1.9.8: (update lightbox2 prototype.js to 1.7.2), scheint das Problem nicht mehr existent zu sein, denn ich teste ohne noConflict mode im Frontend.

Zu 1,3,6: Ich habe nun neu eingebaut colorbox, magnific-popup und lightbox2-jQuery. Außerdem das prettyPhoto Plugin upgedated. Diese vier funktionieren hervorragend und genügen eigentlich.
Was brächte Fancybox(2), was die anderen nicht bereitstellen?
Außerdem rückt dies nun alles in den frontend_footer hook.

Mir stellt sich die Frage, warum wir eigentlich den ganzen alten Balast von lightbox, lightbox Plus, lightbox2, thickbox, graybox und greybox eigentlich noch weiter mitschleppen wollen. Ganz davon abgesehen, dass sie zT nur mittelprächtig funktionieren. Ich sehe ja ein, dass es eventuell für Nutzer einer dieser älteren Versionen eine Umstellung bedeuten würde, allerdings ist das ja nur eine Ein-Click Einstellung im lightbox plugin, da die lightbox Umwandlung für entries zur Laufzeit geschieht, somit also auch ältere Einträge in den Genuss kommen.

Zu 5: Im zip versteckt sich ein Serendipity Plugin namens serendipity_event_sidebaritemcollapse entstanden hier http://board.s9y.org/viewtopic.php?p=34909 und http://board.s9y.org/viewtopic.php?p=33810. Warum sich das als zip und nirgends als "to integrate" erwähnt im serendipity_event_sidebarhider Plugin versteckt, kann ich nicht sagen. Ich würde das generell löschen, schon allein da keiner der Nutzer in diesen Threads mehr besteht oder irgendwie mit einem Serendipity Blog in Zusammenhang gebracht werden kann.

Zu 4. Ich wüßte gerne, wie wir damit generell umgehen wollen. Ich halte diese Erweiterung des ISP nicht wirklich für sinnvoll, (siehe mein letztes post in diesem Thread). Da ich aber testcases damit bereits hatte, habe ich die vier oben erwähnten lightboxes so eingestellt, dass sie nur visible image links erlauben. (Das kann ich natürlich wieder rückgängig machen.) Alles andere erschien mir verwirrend.

Meinungen?

PS. Wird das lighbox plugin von irgendjemand anders benutzt als vom plugin vorgegeben? ZB als lightbox loader für manuelle Einstellungen/Galerien?

[onli]

+1 und Danke fürs drum kümmern.

[nogad]

Hallihallo Timbalu,

danke für Deine Benachrichtigung.

Aus dem englischen Text ist mir nur leider nicht ganz klar geworden, warum ich hier gucken soll. Erkläre Dich bitte

LG Mathias

[Timbalu]

Hm, siehe meine Anmerkungen zu Punkt 4.
Ich bin da innerlich auch noch nicht so richtig fertig damit. Mich hat das beim Testen aber ganz konfus gemacht, weshalb ich im lightbox plugin eine Lösung dafür fand, die ich mittlerweile ganz sinnvoll finde.

Ein solches Verhalten, die lightbox zeigt mehr Bilder als sonst im Entry angezeigt werden, verwirrt IMHO denjenigen, der sich Einträge damit durchschaut. Es ist ja eigentlich ein "Übel" dieser neuen hideafter Einstellung. Normalerweise hätte man ja serendipity body und serendipity extended, um zB Einträge mit vielen solcher Galeriethumbs zu zerlegen, so dass sie den normalen Betrieb nicht stören, aber als Einzelbeitrag vollständig erscheinen. Für einen Besucher wäre dann Entry images == lightbox images. Ansonsten müsste man immer erklären, dass es sich anders verhält. Und vor allem warum?! Da das gesamte markup etc trotzdem vorhanden ist und nur per hideafter inline css verschattet wird, kann es ja nicht um Performance o.Ä. gehen.

Sicherlich das Allereinfachste wäre, lightboxes generell immer alle imagelinks anzeigen zu lassen, egal ob hidden oder nicht, bzw so wie sie geschrieben sind. Eine andere Möglichkeit wäre, dass du mir das genaue lightbox Plugin nennst, mit dem du diese hideafter Geschichten anzeigst. Dann könnte ich vielleicht einen Klon einbauen, der weiterhin im Zusammenhang mit dieser sehr speziellen ISP Erweiterung alles erlaubt und mit hideafter Nutzung empfohlen wird. Oder zb Garvin sagt, dass diese spezielle ISP Option aus den oben genannten Gründen wieder raus müsste.

Edit: Die Klon Idee hat sich gerade erledigt. Die neue Lightbox2 (jquery) kann man nicht so leicht auf :visible beinflussen. Also ist damit schon eine Empfehlung gegeben.

[yellowled]

Was brächte Fancybox(2), was die anderen nicht bereitstellen?

Nix. Fancybox 2 brächte Lizenzprobleme, weil es meines Wissens nicht mehr (unbedingt) freie Software ist. Ansonsten ist Fancybox extrem beliebt, weil es ein bisschen wie die Lightboxes aussieht, die Apple so verwendet. Funktional bietet es meines Wissens nichts, was die anderen (insbesondere MagnificPopup) nicht auch können.

Mir stellt sich die Frage, warum wir eigentlich den ganzen alten Balast von lightbox, lightbox Plus, lightbox2, thickbox, graybox und greybox eigentlich noch weiter mitschleppen wollen.

Da bin ich voll bei Dir. Ja, es ist potenziell lästig für Benutzer alter Plugins – das sind nicht funktionierende alte Plugins aber auch. Das Einzige, was ich mir als eventuell lohnenswert vorstellen könnte, wäre eine Aufspaltung in einzelne Plugins, die jeweils nur eine Lightbox bereit stellen – das dürfte aber in Sachen Maintenance für unser Projekt unzumutbar sein.

Da ich aber testcases damit bereits hatte, habe ich die vier oben erwähnten lightboxes so eingestellt, dass sie nur visible image links erlauben. (Das kann ich natürlich wieder rückgängig machen.)

Sorry, das verstehe ich nicht. Was sind „visible image links“?

Ansonsten: Sehr cool, dass Du das angehst. (Diesem Forum fehlt ein Thumbs-Up-Smiley.)

YL

[ICE]

Ansonsten: Sehr cool, dass Du das angehst. (Diesem Forum fehlt ein Thumbs-Up-Smiley.)
YL

Warts ab, ab dem 28.10. gibts phpbb 3.1, mit vielen Erneuerung. Ich habe schon eine "Danke"-Button Extension in der Entwicklung gesehen!

[Timbalu]

Was sind „visible image links“?

Anchor regexes mit a:visible, da (siehe oben) hideafter einen display:none setzt.

[Timbalu]

Mir stellt sich die Frage, warum wir eigentlich den ganzen alten Balast von lightbox, lightbox Plus, lightbox2, thickbox, graybox und greybox eigentlich noch weiter mitschleppen wollen.

Da bin ich voll bei Dir. Ja, es ist potenziell lästig für Benutzer alter Plugins – das sind nicht funktionierende alte Plugins aber auch. Das Einzige, was ich mir als eventuell lohnenswert vorstellen könnte, wäre eine Aufspaltung in einzelne Plugins, die jeweils nur eine Lightbox bereit stellen – das dürfte aber in Sachen Maintenance für unser Projekt unzumutbar sein.

Einzelne Plugins halte ich für unsinnig, schon allein um zu vermeiden, dass sich zwei Plugins potentiell in die Quere kommen. Ein Update von serendipity_event_lightbox, befreit vom Balast vergangener Tage, wäre die sauberste Lösung, hätte aber den Nachteil, dass viel unbenutztes Zeug bei Upgradern herumliegt und die Orientierung verwirrt. Ebenso, wenn ich die vier neuen lightboxes einfach nur zu den bisherigen hinzufüge. Im ersteren Fall müsste man fast raten erst einmal richtig, auch manuell zu löschen und dann noch einmal neu zu installieren. Im zweiten Fall müsste man wieder irgendwelche Notes einfügen, die auf den Sachverhalt alter und neuer Pakete hinweisen.

Oder ich veröffentliche ein neues serendipity_event_lightboxes Plugin und wir setzen das alte als deprecated.

Ich bin unschlüssig, da alles so seine Vor- und Nachteile hätte. Irgendwann kommt halt immer ein Bruch, auch wenn dieser sich in diesem Fall nur "paketseitig" auswirkt.

[yellowled]

Ein Update von serendipity_event_lightbox, befreit vom Balast vergangener Tage, wäre die sauberste Lösung, hätte aber den Nachteil, dass viel unbenutztes Zeug bei Upgradern herumliegt und die Orientierung verwirrt.

Halte ich für das einzig sinnvolle. Vielleicht sollte das Plugin (analog zum 2.0-Backend) einen Upgrade-Task bekommen, der den alten Rotz automagisch verklappt?

YL

[onli]

Ich hätte kein Problem damit, wenn das in einem s9y-update als upgrade-task umgesetzt wird. Muss ja nicht 2.0 sein.

[Timbalu]

Naja, solch eine automagische Löschung kann das Plugin schon ganz alleine.
Die Frage ist halt nur, ob jemand da irgendwelche modifizierten Versionen einsetzt, die dann per Upgrade plötzlich weg sind. (Zum Beispiel "manuelle" Blog Entries mit einer flickr Galerie, gesteuert über eines dieser älteren Lightbox Scripte, oder so. Nicht, dass das nicht auch mit den neuen Scripten machbar wäre, doch erfordert es etwas Zeit, um diese Entries entsprechend umzuschreiben, bzw sich neu einzulesen.)

Trotzdem halte ich diesen Weg für die einzig wirkliche Lösung und werde das auch so nach Spartacus schicken. Ich wollte es nur schon einmal gesagt haben, damit vielleicht doch noch einer Einspruch erheben kann oder von einem Upgrade vorerst absieht.