Neues "MultiOnePage" - Plugin
Re: Neues "MultiOnePage" - Plugin
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?
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?
Re: Neues "MultiOnePage" - Plugin
Danke für das Feedback!
Das ist eigentlich schon vorhanden. Deshalb werde ich es auch mit einbauen, dann muss niemand suchen.
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.
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.
Die ganze if - Klausel kann doch weg. Einfach: wenn Seitenaufruf mit Hash, dann scroll mal "smooth" dahin...Holger wrote: ↑Tue Jun 18, 2019 10:10 amIch glaube, das Problem liegt hier: https://github.com/TN03/multionepage_xh ... ge.js#L165
Smoothscrolling wird nur angeworfen, wenn ein Offset definiert wurde .
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 wrote: ↑Tue Jun 18, 2019 11:10 amEine 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?
Re: Neues "MultiOnePage" - Plugin
Vielleicht liege ich wieder mal falsch ...?Holger wrote: ↑Tue Jun 18, 2019 11:48 amTja, 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.
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.
Re: Neues "MultiOnePage" - Plugin
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.
Re: Neues "MultiOnePage" - Plugin
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 .
Re: Neues "MultiOnePage" - Plugin
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!
Re: Neues "MultiOnePage" - Plugin
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 ) 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.
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 ) 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.
Re: Neues "MultiOnePage" - Plugin
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:
2. Editlink und PreviewlinkDebug-Modus wrote:NOTICE: Undefined index: multionepage_access
... \plugins\multionepage\classes\Controller.php:236
- 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>
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
Re: Neues "MultiOnePage" - Plugin
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.
(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.
Re: Neues "MultiOnePage" - Plugin
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.
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>
Hmm, genau so sollte es sein (und ist es auch bei mir) . Wirft die Konsole einen Fehler?
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.frase wrote: ↑Thu Jun 27, 2019 8:16 am4. Toplink
Hier wäre mir etwas mehr Flexibilität lieber. Nicht immer ist ein PNG die beste Lösung.
So etwas wie z.B.sollte möglich sein.Code: Select all
<a id="multionepage_toplink()" href="#" class="fa fa-chevron-up fa-3x" title="top"></a>
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?
Trotzdem schon jetzt Danke für deine Zeit!
Ja, da hatte ich keine Lust mehr... Die Punkte sind doch eh selbsterklärend .
(Nein, mach' ich natürlich noch)
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?frase wrote: ↑Thu Jun 27, 2019 8:16 amUm 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 ...