Plugin: Expandcontract_XH - Community-Projekt ???

[Holger]

Bei XH bin ich mir noch ganz unsicher.

Müsste ab v1.6 sein. Die "kritische Funktion" ist XH_message(). Die gibt es ab 1.6.

Svasti hatte in seiner Originalversion irgendeine Komfort-Funktion für Updates drin

Das funktioniert so, wie es war, nicht mehr. Falls irgendwann nötig (zusätzlich Konfig-Optionen), können wir was nachrüsten.

[Holger]

Ach ja, den Code für die Validierung des Paddings hat Olaf schon gemacht. Es funktionieren jetzt alle erlaubten CSS-Einheiten.

[cmb]

Bei XH bin ich mir noch ganz unsicher.

Müsste ab v1.6 sein. Die "kritische Funktion" ist XH_message(). Die gibt es ab 1.6.

Nutzt denn überhaupt noch jemand 1.6, der neue Plugins installiert (oder bestehende aktualisiert)? Zumindest XH 1.6.3 sollte man erfordern können (und dann könnte man sich die function_exist Wurstelei schenken).

Svasti hatte in seiner Originalversion irgendeine Komfort-Funktion für Updates drin

Ich habe nie wirklich verstanden, wozu das gut sein sollte. Im Wesentlichen ist das doch durch defaultconfig.php und default.php auch ohne Sonderbehandlung möglich. Und direkte Änderungen an Konfig- und Sprachvariablen (oder gar den -Dateien) machen sowieso nur Ärger.

[Holger]

Ich habe nie wirklich verstanden, wozu das gut sein sollte. Im Wesentlichen ist das doch durch defaultconfig.php und default.php auch ohne Sonderbehandlung möglich.

Stammt wohl noch aus Zeiten vor der default* - Lösung

Kurz etwas anders: für die Inhalte müssen ja einzelne Seiten angelegt werden, was IMHO eine ganz schöne Klickerei ist.
Wie sieht es mir Edit- und Preview-Links, wie in MultiOnepage_XH aus?
Also per Link vom Akkordeon-Content aus direkt zur Seitenbearbeitung und auch wieder zurück zur Vorschau.

Für einen groben Test einfach die index.php von hier nehmen.

Der Code ist nur als Demonstration gedacht! Produktiv müsste man da noch nachbessern.

[frase]

Müsste ab v1.6 sein. Die "kritische Funktion" ist XH_message(). Die gibt es ab 1.6.

Zumindest XH 1.6.3 sollte man erfordern können (und dann könnte man sich die function_exist Wurstelei schenken).

Also gut.
Ich schreibe mal PHP 7.0 und XH 1.6.3

Wie sieht es mir Edit- und Preview-Links, wie in MultiOnepage_XH aus?
Also per Link vom Akkordeon-Content aus direkt zur Seitenbearbeitung und auch wieder zurück zur Vorschau.

Eigentlich eine gute Idee - eigentlich
Natürlich wäre das hochkomfortabel, wenn man 10 oder 20 Accordions mit jewels 50 Seiten zu verwalten hat (ich übertreibe mal etwas, sorry).
Ich denke aber, dass das hier etwas anders als bei einem Multi-Onepager ist. Man legt zuerst die Seiten an und ruft sie dann auf. Da muss man die Inhalte nicht ständig nachbearbeiten, denke ich. Und in den meisten Fällen werden es sowieso verborgene Unterseiten sein, die dann per Menü schnell erreichbar sind, falls nötig. Was man braucht, ist die Vorschau: Wie sieht die Seite im Accordion aus? Und das funktioniert ja ohne weitere Funktionen.
Also, konzentrieren wir uns lieber auf die Fertigstellung. Code bereinigen, Hilfedateien und eventuell noch sprachabhängige Fehlermeldungen. Oder?

[olape]

Wie sieht es mir Edit- und Preview-Links, wie in MultiOnepage_XH aus?
Also per Link vom Akkordeon-Content aus direkt zur Seitenbearbeitung und auch wieder zurück zur Vorschau.

Ich finde es gut. Es scheint kein zu großer Aufwand zu sein. Warum also nicht?
Zur Not kann man das ja per congig optional machen.
Ich wäre dafür.

[frase]

Ich finde es gut. Es scheint kein zu großer Aufwand zu sein. Warum also nicht?

Kleines Gegenargument: Wohin mit den Links und wie sollen die aussehen? Das Problem hatten wir auch bei Multionepage. Es wird immer irgendwie das Layout stören und evtl. sogar übersehen werden.

[Holger]

Kleines Gegenargument: Wohin mit den Links und wie sollen die aussehen? Das Problem hatten wir auch bei Multionepage. Es wird immer irgendwie das Layout stören und evtl. sogar übersehen werden.

Ja, das ist das größte Problem. Idee wäre vielleicht: ein "Bearbeiten-Icon" oder kurzer Link im Container des Deep-Links. Der ist zur Zeit ja (noch) nicht abschaltbar.

Die Links werden vielleicht in den meisten Fällen wirklich unnötig sein, vielleicht.
Aber: bei einer durchschnittlichen FAQ kommen sicher schon mal je 5 Punkte in drei Gruppen vor - macht 15 Seiten . Hier zum Beispiel insgesamt 44 Punkte in 2 Gruppen. Das klickst du nicht mal schnell zusammen, spätestens wenn es um Änderungen geht. Das ist mMn. aber eine "Designschwäche" des Plugins. Bei kleinen Akkordeons sehr komfortabel, weil automatisch. Bei vielen Inhalten würde mich schon die Scrollerei im ausgeklappten Navigationsmenü kirre machen.

Aber wir lassen das jetzt doch lieber erst einmal, denn es funktioniert auch nicht "ganz richtig": kommt man über einen "Bearbeiten-Link" in den Edit-Mode und wählt dann eine andere Seite aus, ist der Edit-Mode weg. Keine Ahnung warum. Die Parameter stimmen, aber vielleicht bringen die zusätzlich übergebenen GET-Partameter XH da aus dem Tritt???
Das Problem müsste auf jeden Fall erst einmal näher untersucht und gelöst werden.

Wir sollten uns aber zunächst einmal auf eine fertige Version konzentrieren. Bei einer wird es wohl eh nicht bleiben .

[frase]

Bitte nicht falsch verstehen: Ich wehre mich nicht gegen diesen Vorschlag
Ich finde nur, dass die Seiten doch ganz easy fertiggestellt werden können und dann per Plugin aufgerufen ...
Die muss man doch nicht ständig nachbearbeiten, nur weil man sie im Aufruf hat. Es könnten ja auch ganz normale sichtbare Seiten sein, die ändert man doch auch nicht ständig.
Ich denke, das wär etwas Overkill - mit Mehraufwand, Änderungen usw. verbunden.
Wir basteln nun schon fast einen Monat.

Wir sollten uns aber zunächst einmal auf eine fertige Version konzentrieren. Bei einer wird es wohl eh nicht bleiben .

Genau!
Sollte sich in der Praxis herausstellen, dass eine solche Bearbeiten-Funktion nötig wird, dann kann man das immer noch in der nächsten Version berücksichtigen. Auch, ob der DeepLink abschaltbar sein sollte.

[olape]

Ich finde es gut. Es scheint kein zu großer Aufwand zu sein. Warum also nicht?
Zur Not kann man das ja per congig optional machen.
Ich wäre dafür.

Dabei bleibe ich aber.

Wir sollten uns aber zunächst einmal auf eine fertige Version konzentrieren. Bei einer wird es wohl eh nicht bleiben .

Sollte sich in der Praxis herausstellen, dass eine solche Bearbeiten-Funktion nötig wird, dann kann man das immer noch in der nächsten Version berücksichtigen. Auch, ob der DeepLink abschaltbar sein sollte.

Aber ok, es muss nicht unbedingt und schon gar nicht jetzt gleich sein. Da habt ihr Recht.

Ich wusste gar nicht, dass ihr so kurzatmig seid, nur 54 Seiten und schon müde