Neues "MultiOnePage" - Plugin

[Holger]

In der Readme steht im Abschnitt "Nicht unterstützte Template-Tags", dass u.A. auch der sitemaplink() nicht funktioniert.

Klickt man auf einen Punkt >L1, dann wird zu dieser Seite gelinkt - allerdings nur nach ganz oben, was ja auch nicht falsch ist.
Heißt: sitemaplink() könnte getrost verwendet werden, falls benötigt.

Den Abschnitt sollte ich wohl auch mal lesen .

Also richtig wären Sitemap-Links, die auch zur entsprechenden ID verlinken. Ansonsten ist die gesamte Verlinkung doch ziemlich sinnfrei, finde ich. Okay man könnte dokumentieren, dass sitmaplink() alle "Seiten" ausgibt, die Verlinkung aber nur zur Hauptseite klappt. Oder man macht's gleich richtig, und gibt die Sitemap (über ein alternatives Template-Tag) mit passenden Links aus.
Was tun?

[frase]

Die Pagedata-Felder, die ein neu installiertes Plugin verwendet, sind ja in einer bestehenden content.htm noch nicht enthalten. Du müsstest also einmal im Editor speichern, dann sollte sich das erledigt haben.

Verstanden. Und klappt auch.
Das entspricht in etwa einer "Initialisierung" des Plugins bei der Erstbenutzung.
Wie du siehst, hat mich die Meldung aber doch irritiert.

Da wollte ich zukünftig eigentlich ganz weg von der Abhängigkeit von Fa_XH. Für die richtige Positionierung und das Aussehen, sollte eh das Template sorgen. Wie wäre es denn, wenn ich nur etwas in der Art ausgebe:
<div class="multionepage_editlink"><a href="xxx" title="Bearbeiten"><span>Bearbeiten</span></a></div>
Dann könnte das Template per CSS das FA-Icon liefern und der ausgegebene Text lässt sich über <span> selektieren und ausblenden.

Prinzipiell ist die Überlegung "weg von Abhängigkeit von FA" richtig. Dennoch finde ich an dieser Stelle Icons besser, aussagekräftiger und nicht so störend.
Wenn du dich damit anfreunden könntest, könnte ich dir zwei entsprechende SVGs liefern, die du verwenden könntest. Text nur als title-Tag. Will du?

Hmm, genau so sollte es sein (und ist es auch bei mir) . Wirft die Konsole einen Fehler?

Ha, da habe ich mir selbst ein Bein gestellt.
In meinem Test verwendete ich den "alternativen" assets-Ordner. Im Plugin werden die inaktiven Tabs auf display: none gesetzt. Die alternative core.css setzt sie wieder auf display: inline-block.
Im neuen Test mit "alles original XH" ist es i.O.
(Mal sehen, ob ich da was machen kann, denn ich habe mich schon an das "andere Aussehen" im Admin-Modus gewöhnt.)

Zu "Toplink" folgt später etwas.
Zu "Testtemplate" fällt mir momentan noch nichts ein. Es sollte die Möglichkeiten deutlich zeigen.

Also richtig wären Sitemap-Links, die auch zur entsprechenden ID verlinken.

Das wäre der Idealfall. (Du kannst doch programmieren und hast viel Zeit )
Aber der aktuelle Zustand ist nicht ganz sinnfrei. Man kann die wichtigen Inhalte der Website als Übersicht darstellen - was ja Zweck einer Sitemap ist.

[Holger]

Verstanden. Und klappt auch.

Prima.

Prinzipiell ist die Überlegung "weg von Abhängigkeit von FA" richtig. Dennoch finde ich an dieser Stelle Icons besser, aussagekräftiger und nicht so störend.
Wenn du dich damit anfreunden könntest, könnte ich dir zwei entsprechende SVGs liefern, die du verwenden könntest. Text nur als title-Tag. Will du?

Wöllte ja schon. Nur wäre das dann nicht wieder genau so eine "halbgare" Lösung wie beim Toplink? Nur kann man in dem konkreten Fall nicht einfach mal so eine Funktion weglassen und selber im Template einbauen.
Was stört dich daran die volle Kontrolle im Template zu haben? Zumal dort FA_XH oft verwendet wird.

Die alternative core.css setzt sie wieder auf display: inline-block.

Wo gibt's die Alternative? Wäre es nicht eine einfache Lösung, wenn ich "!important" hinzufüge? Das sollte an dieser Stelle eigentlich angemessen sein.

Das wäre der Idealfall. (Du kannst doch programmieren und hast viel Zeit )

Ich versuche es zumindest. Zeit habe ich zwar auch nicht unbedingt, aber im Moment halt Lust.
So schlimm kann es aber nicht sein: wohl eine weitere Li-Klasse und "&sitemap" / function=sitemap abfangen. Sollte machbar sein. Und es ist kein weiteres Template-Tag dazu nötig.

[lck]

Es hat etwas gedauert, aber ich habe alles, was bisher auf den Tisch kam, versucht umzusetzen. Im Changelog auf GitHub findet sich dazu mehr. Und es gibt jetzt auch eine erste, "richtige" Beta von Multionepage_XH.

Sehr schön Holger!

Kurz getestet, funktioniert super. Muss mich aber damit noch intensiver beschäftigen. Ein passendes Template habe ich aber momentan auch nicht. Passen würden einige von Frank mit zweigeteiltem Menü.

Was bei mir bisher noch nicht funktioniert, ist multionepage_toplink() mit optionalen Parameter (ID eines Elements), die Id wird ignoriert.
Beispiel: multionepage_toplink('onepage-welcome'), verlinkt auch zu href="#onepage-welcome", klickt man den Top-Button wird ganz nach oben gesprungen zu ?Page-1# anstatt zu ?Page-1#onepage_welcome.

BTW: href="#" bereitet bei manchen Templates Probleme, die mit CSS :target Selektor arbeiten. So geschehen bei op_slidemecrazy, da musste ich eine Alternative einsetzen, ansonsten wurde immer die Startseite aufgerufen.

[Holger]

Was bei mir bisher noch nicht funktioniert, ist multionepage_toplink() mit optionalen Parameter (ID eines Elements), die Id wird ignoriert.

Oh jeh, das habe ich beim Fork von Onepage_XH und der Übernahme hierher komplett übersehen. Eine optionale ID ignoriert das Javascript komplett.
Das wird ASAP nachgebessert. Danke für die Info!

[frase]

Nur wäre das dann nicht wieder genau so eine "halbgare" Lösung wie beim Toplink? Nur kann man in dem konkreten Fall nicht einfach mal so eine Funktion weglassen und selber im Template einbauen.
Was stört dich daran die volle Kontrolle im Template zu haben? Zumal dort FA_XH oft verwendet wird.

Halbgar? Wahrscheinlich hast du recht. Das geht schon mit der Farbwahl los.
Dann ist FA schon besser (aber davon wolltest du doch weg?)

Wo gibt's die Alternative? Wäre es nicht eine einfache Lösung, wenn ich "!important" hinzufüge? Das sollte an dieser Stelle eigentlich angemessen sein.

Die "Alternative" ist in meinen letzten beiden Template-Downloads enthalten (assets).
(Ist halt wieder so 'ne private Sache, auf die du keine Rücksicht nehmen solltest.)
"!important" täte helfen - dann über-importantieren die beiden Regeln sich gegenseitig und deine siegt

[Holger]

Halbgar? Wahrscheinlich hast du recht. Das geht schon mit der Farbwahl los.
Dann ist FA schon besser (aber davon wolltest du doch weg?)

Beste Lösung, auch optisch, scheint mir FA zu sein. Ich will es aber im / durch das Template. Nur so können die Links optisch gut passen und sauber positioniert werden.

Wie wäre es denn, wenn ich nur etwas in der Art ausgebe:

Code: Select all

<div class="multionepage_editlink"><a href="xxx" title="Bearbeiten"><span>Bearbeiten</span></a></div>

Dann könnte das Template per CSS das FA-Icon liefern und der ausgegebene Text lässt sich über <span> selektieren und ausblenden.

Ich denke es ist nur sehr wenig Aufwand den Link oben mit FA per CSS über das Template zu stylen. Flexibler geht es doch eigentlich für den Templateautor nicht.

Die "Alternative" ist in meinen letzten beiden Template-Downloads enthalten (assets).
(Ist halt wieder so 'ne private Sache, auf die du keine Rücksicht nehmen solltest.)

Ah okay. Also kein Plugin etc.?
Na ja, wenn es doch kein Problem ist, kann man das (wie auch fhs_adminmenu) doch berücksichtigen. Wer weiß, wozu es noch gut ist.

"!important" täte helfen - dann über-importantieren die beiden Regeln sich gegenseitig und deine siegt

Okay, dann mach ich das mal. Will auch mal Sieger sein.

[Holger]

So, im aktuellen Master sind die folgenden Punkte nun gefixt:

- sitemaplink() kann nun ganz normal verwendet werden.
Config->Versteckte Seiten in Sitemap anzeigen wird (absichtlich) nicht unterstützt.
Es macht hier keinen Sinn, weil direkte Aufrufe eh umgeleitet werden.
Dokumentation dazu fehlt noch.

- multionepage_toplink() unterstützt nun eine optionale Id

- Unbenutzbare PD-Tabs ausblenden: !important hinzugefügt

- außerdem JS Fehler beim Aufruf diverser Seiten im Admin-Menü behoben

Die komplette Übersicht ist hier: https://github.com/TN03/multionepage_xh ... 2?closed=1
Offen wäre zur Zeit noch das: https://github.com/TN03/multionepage_xh/milestone/2
und die Frage, was mit Fa_XH passiert. Wenn es im Plugin bleiben sollte, müsste man es noch ordentlich einbauen. Bisher funktioniert es ja nur, wen in Fa_XH "Require -> auto" eingestellt ist.

[frase]

- sitemaplink() kann nun ganz normal verwendet werden.
Config->Versteckte Seiten in Sitemap anzeigen wird (absichtlich) nicht unterstützt.
Es macht hier keinen Sinn, weil direkte Aufrufe eh umgeleitet werden.
Dokumentation dazu fehlt noch.

Auch, wenn das mehr oder weniger ein "Nebeneffekt" war, finde ich diese Möglichkeit der Seitenübersicht sehr gut!

- multionepage_toplink() unterstützt nun eine optionale Id

funktioniert

- Unbenutzbare PD-Tabs ausblenden: !important hinzugefügt

funktioniert

Offen wäre zur Zeit noch das: ...
und die Frage, was mit Fa_XH passiert. Wenn es im Plugin bleiben sollte, müsste man es noch ordentlich einbauen. Bisher funktioniert es ja nur, wen in Fa_XH "Require -> auto" eingestellt ist.

Mein Bauchgefühl sagt mir, dass FA im Moment wahrscheinlich noch die beste und praktikabelste Lösung ist. Außerdem entspricht es so der aktuellen XH-Philosophie. FA wird ja auch (noch) im Pagemanager und anderen wichtigen Plugins verwendet und ist standard-mäßig verfügbar. Also wird es wohl das Beste sein, wenn du es "ordentlich" einbaust.
Im Moment haben "Bearbeiten" und "Vorschau" immer noch das gleiche Icon (Pencil). Das würde ich noch ändern und entscheiden, ob bei beiden nur das Icon angezeigt wird, oder bei beiden das Icon mit Text.

[Holger]

Mein Bauchgefühl sagt mir, dass FA im Moment wahrscheinlich noch die beste und praktikabelste Lösung ist. Außerdem entspricht es so der aktuellen XH-Philosophie. FA wird ja auch (noch) im Pagemanager und anderen wichtigen Plugins verwendet und ist standard-mäßig verfügbar. Also wird es wohl das Beste sein, wenn du es "ordentlich" einbaust.
Im Moment haben "Bearbeiten" und "Vorschau" immer noch das gleiche Icon (Pencil). Das würde ich noch ändern und entscheiden, ob bei beiden nur das Icon angezeigt wird, oder bei beiden das Icon mit Text.

Na gut .
Aber wie muss der Code dann aussehen, damit es nicht das gleiche Dilemma wie beim Toplink wird und der Templateautor den Link komplett anders gestalten und ausrichten kann?
Denn per Plugin bleibt mir wohl lediglich nur die Möglichkeit, die Links jeweils oberhalb der Seiten-Ids, bzw. des Editors, links ausgerichtet drüber zu klatschen. Und für den Fall würde ich Icon + Text bevorzugen, weil das Icon alleine im Zweifel zu klein sein könnte. Und einfach ersetzbar, wie toplink(), sind die Funktionen im Template ja nicht.