Neues "MultiOnePage" - Plugin

Ein CMSimple Support Forum für deutsch sprechende Nutzer und Entwickler
frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Tue Jun 18, 2019 11:10 am

Eine rein theoretische Frage:
Wie schlimm ist es, wenn folgendes aufgerufen wird (wie und warum auch immer):
www.example.com/?&sitemap
???
Die Links führen zwar alle zur richtigen L1-Seite, man sollte das auf Onepagern mit Unterseiten und bei MultiOnepagern vielleicht unterbinden?

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Tue Jun 18, 2019 11:48 am

Danke für das Feedback!
lck wrote:
Tue Jun 18, 2019 10:44 am
Nicht nötig, dafür gibt es ja bereits einen Workaround per MyLi (Alle Eintraege klickbar lassen), falls es jemand braucht.
Das ist eigentlich schon vorhanden. Deshalb werde ich es auch mit einbauen, dann muss niemand suchen.
lck wrote:
Tue Jun 18, 2019 10:44 am
Edit-Link:
Dann steht's 2:1 ;) . Ich glaube auch, dass man das leicht im Template berücksichtigen / erledigen kann. Und wo das Styling fehlt, wird der User meckern oder den Link ausschalten, falls er stört.
lck wrote:
Tue Jun 18, 2019 10:44 am
Multionepage_fulltoc()
Okay, den Ausführungen kann ich jetzt nicht ganz folgen. Ich schlage vor, dass wir uns der Sache Dropdown oder "fulltoc()" insgesamt dann widmen, wenn es gebraucht wird. Dann macht es wohl mehr Sinn, als jetzt nur theoretisch und ohne Demo-Template.
Holger wrote:
Tue Jun 18, 2019 10:10 am
frase wrote:
Tue Jun 18, 2019 12:02 am
Bei Seiten-übergreifenden Links zu Ankern und auch bei Reload wird nicht smooth zum # gescrollt - schade.
Ich glaube, das Problem liegt hier: https://github.com/TN03/multionepage_xh ... ge.js#L165
Smoothscrolling wird nur angeworfen, wenn ein Offset definiert wurde :? .
Die ganze if - Klausel kann doch weg. Einfach: wenn Seitenaufruf mit Hash, dann scroll mal "smooth" dahin...
frase wrote:
Tue Jun 18, 2019 11:10 am
Eine rein theoretische Frage:
Wie schlimm ist es, wenn folgendes aufgerufen wird (wie und warum auch immer):
www.example.com/?&sitemap
???
Die Links führen zwar alle zur richtigen L1-Seite, man sollte das auf Onepagern mit Unterseiten und bei MultiOnepagern vielleicht unterbinden?
Tja, keine Ahnung. Richtig wäre, wenn die Sitemap auch nur die Level-1-Seiten ausgeben würde (könnte man vielleicht sogar auch abfangen). Der direkte Zugriff, denke ich, sollte aber wirklich unterbunden werden. Halt mMn. mit vom Benutzer gewollten Ausnahmen. Ich hatte das schon wieder vergessen. Deshalb gibt es dafür jetzt auch ein Issue.

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Tue Jun 18, 2019 12:04 pm

Holger wrote:
Tue Jun 18, 2019 11:48 am
Tja, keine Ahnung. Richtig wäre, wenn die Sitemap auch nur die Level-1-Seiten ausgeben würde (könnte man vielleicht sogar auch abfangen). Der direkte Zugriff, denke ich, sollte aber wirklich unterbunden werden. Halt mMn. mit vom Benutzer gewollten Ausnahmen. Ich hatte das schon wieder vergessen. Deshalb gibt es dafür jetzt auch ein Issue.
Vielleicht liege ich wieder mal falsch ...?
In meinem Test kann ich Unterseite aufrufen, soviel ich will - ich lande immer auf der entsprechenden L1-Seite.
Insofern wäre das schon i.O. - wären da eben nicht die Ausnahmen.

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Tue Jun 18, 2019 12:36 pm

frase wrote:
Tue Jun 18, 2019 12:04 pm
In meinem Test kann ich Unterseite aufrufen, soviel ich will - ich lande immer auf der entsprechenden L1-Seite.
Insofern wäre das schon i.O. - wären da eben nicht die Ausnahmen.
Nein. Du bekommst zwar den gleichen Inhalt zu sehen, du wirst aber nicht auf die L1-Seite umgeleitet. Schau' mal, was im Adressfeld steht. Das ist definitiv DC und das sollten wir unterbinden, indem wir eine echte Umleitung zur L1-Seite machen.

Im Moment ist es so, dass zur Ausgabe der Inhalte die Routine immer die erste Elternseite sucht um dann den Content des gesamten Zweiges inkl. Unterseiten zusammenzufassen und auszugeben.
Das ist u.A. nützlich beim Editieren einer Unterseite. Klickt man zurück zur Vorschau, hat man wieder die gesamte Onepage, anstatt nur den Inhalt der Unterseite (BTW: auch hier stimmen die URLs deshalb noch nicht, was aber beim Klick auf eine H1-Seite dann bereinigt wird).

Dieses Konzept würde ich dann umbauen wollen. Geht aber nur, wenn wir im Front-end dann Unterseiten umleiten (mit Ausnahmen per PD). Den Vorschau-Link muss man dann per JS anpassen, was ja auch nicht schlimm wäre (außer vielleicht für fhs-adminmenu).
So wäre es dann "rund" für mich.

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Tue Jun 18, 2019 1:00 pm

Holger wrote:
Tue Jun 18, 2019 12:36 pm
Dieses Konzept würde ich dann umbauen wollen.
HA, und wenn das so wäre, könnten wir auf den Editlink auch verzichten, denn dann könnte man wieder, wie beim Onepage-Fork, den Vorschau- und Bearbeiten-Link dynamisch, abhängig von der Scrollposition anpassen und so immer die richtige Unterseite im Editor und den passenden Hash in der Vorschau zu haben :D .

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Tue Jun 18, 2019 1:05 pm

frase wrote:
Tue Jun 18, 2019 12:04 pm
Dieses Konzept würde ich dann umbauen wollen. Geht aber nur, wenn wir im Front-end dann Unterseiten umleiten (mit Ausnahmen per PD). Den Vorschau-Link muss man dann per JS anpassen, was ja auch nicht schlimm wäre (außer vielleicht für fhs-adminmenu).
Mach mal.
Habe nur ansatzweise verstanden wie und was du umbauen willst. Wirst es schon wissen ;-) Das mit dem DC verstehe ich.
Auf fhs-adminmenu solltest du definitiv keinerlei Rücksicht nehmen!

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Wed Jun 26, 2019 7:38 pm

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.

Für ein paar Features gibt es eventuell Erklärungsbedarf (Preview-Link, Direktzugriff auf Unterseiten usw.). In der Readme-Datei sollte aber alles Wichtige zu finden sein.
Ein halbwegs gescheites (und vorzeigbares :roll: ) Test-Template habe ich leider noch immer nicht.
Aber vielleicht tut sich da noch etwas ;) .

Ach ja, ganz vergessen, @Frank: fhs_adminmenu sollte nun kein Problem mehr sein. Durch die Edit- und Previewlinks ist nunmehr keine Manipulation am Adminmenü nötig.

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Thu Jun 27, 2019 8:16 am

Holger wrote:
Wed Jun 26, 2019 7:38 pm
Und es gibt jetzt auch eine erste, "richtige" Beta von Multionepage_XH.
Großartig!
Aus Zeitgründen habe ich erst einmal nur einen kurzen Schnelltest gemacht.
Es werden also sicher noch weitere Bemerkungen folgen.

1. Debug-Meldung im Bearbeiten-Modus:
Debug-Modus wrote:NOTICE: Undefined index: multionepage_access
... \plugins\multionepage\classes\Controller.php:236
2. Editlink und Previewlink
- konsequenterweise beide ohne (empfohlen) oder mit Text
- Previewlink sollte statt dem Pencil-Icon das Eye-Icon bekommen
3. PD-Tabs
idealerweise sollten inaktive Tabs gar nicht angezeigt werden
- original "Seite" -> könnte wohl komplett weg (?)
- "Meta" könnte bei Seiten >L1 weg
4. Toplink
Hier wäre mir etwas mehr Flexibilität lieber. Nicht immer ist ein PNG die beste Lösung.
So etwas wie z.B.

Code: Select all

<a id="multionepage_toplink()" href="#" class="fa fa-chevron-up fa-3x" title="top"></a>
sollte möglich sein.

Ansonsten habe ich einen sehr positiven Eindruck von diesem Plugin.
Um tiefere und praxisbezogenere Tests durchzuführen, sollte tatsächlich ein Testtemplate mit entsprechendem Inhalt her.
Vielleicht formulierst du mal ein paar konkrete Anforderungen, die ein solches Template haben sollte.
Dann findet sich vielleicht auch eines ...

Das war nur ein "Schnelltest".

PS:
fhs-adminmenu läuft, super!

PPS:
in der Konfiguration fehlen ein paar Hilfetexte

frase
Posts: 5085
Joined: Thu Apr 21, 2016 6:32 am
Location: Saxony
Contact:

Re: Neues "MultiOnePage" - Plugin

Post by frase » Thu Jun 27, 2019 8:36 am

In der Readme steht im Abschnitt "Nicht unterstützte Template-Tags", dass u.A. auch der sitemaplink() nicht funktioniert.
(Ich glaube ich schrieb es schon weiter oben:) Ich finde, dass der Sitemaplink eigentlich gut funktioniert.
Sitemap wird hierarchisch angeordnet gezeigt. Mit allen Levels.
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.

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: Neues "MultiOnePage" - Plugin

Post by Holger » Thu Jun 27, 2019 9:42 am

frase wrote:
Thu Jun 27, 2019 8:16 am
1. Debug-Meldung im Bearbeiten-Modus:
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.
frase wrote:
Thu Jun 27, 2019 8:16 am
2. Editlink und Previewlink
- konsequenterweise beide ohne (empfohlen) oder mit Text
- Previewlink sollte statt dem Pencil-Icon das Eye-Icon bekommen
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:

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.
frase wrote:
Thu Jun 27, 2019 8:16 am
3. PD-Tabs
idealerweise sollten inaktive Tabs gar nicht angezeigt werden
- original "Seite" -> könnte wohl komplett weg (?)
- "Meta" könnte bei Seiten >L1 weg
Hmm, genau so sollte es sein (und ist es auch bei mir) :? . Wirft die Konsole einen Fehler?
frase wrote:
Thu Jun 27, 2019 8:16 am
4. Toplink
Hier wäre mir etwas mehr Flexibilität lieber. Nicht immer ist ein PNG die beste Lösung.
So etwas wie z.B.

Code: Select all

<a id="multionepage_toplink()" href="#" class="fa fa-chevron-up fa-3x" title="top"></a>
sollte möglich sein.
Ja, da bin ich auch deiner Meinung. Aber ich wüsste jetzt auf den ersten Blick nicht, wie man das flexibel umsetzen könnte. Zumindest die Icon-Datei könnte man konfigurierbar machen, damit andere Dateitypen möglich sind.
Generell muss die Funktion ja nicht im Template verwendet werden. Den Code, wie oben, kann man ja auch sehr gut selber schreiben. Verzichten wollte ich darauf aber nicht, weil es halt in Onepage_XH auch enthalten ist.
Vielleicht genügt es, wenn man das besser dokumentiert und ein Codebeispiel als Ersatz für die Funktion mit darin aufnimmt?
frase wrote:
Thu Jun 27, 2019 8:16 am
Das war nur ein "Schnelltest".
Trotzdem schon jetzt Danke für deine Zeit!
frase wrote:
Thu Jun 27, 2019 8:16 am
PS:
fhs-adminmenu läuft, super!
:D
frase wrote:
Thu Jun 27, 2019 8:16 am
PPS:
in der Konfiguration fehlen ein paar Hilfetexte
Ja, da hatte ich keine Lust mehr... Die Punkte sind doch eh selbsterklärend :lol: .
(Nein, mach' ich natürlich noch)
frase wrote:
Thu Jun 27, 2019 8:16 am
Um tiefere und praxisbezogenere Tests durchzuführen, sollte tatsächlich ein Testtemplate mit entsprechendem Inhalt her.
Vielleicht formulierst du mal ein paar konkrete Anforderungen, die ein solches Template haben sollte.
Dann findet sich vielleicht auch eines ...
Wie wäre es mit http://fhseidel.de/cmsxh/fhs-anchorific-pure/ als Basis, halt ohne Anchorific? Es müsste nur das Onepagemenü gestylt werden. Oder einfach fhs_simple -- mit zusätzlicher toc(1,1) - Navigation?

Post Reply