SEO_XH - Plugin

[cmb]

Wenn ich das geplante Plugin richtig verstehe, gibt es ja sowieso eine Meldung bei der "h-Lücke".
Etwas optisch auffälliger und deutlicher erklärt, dann kommt auch ein Normaluser damit klar.
Ich schreibe das, weil ich merke, dass ihr euch schon wieder die Finger mit Style-Problemen verbiegt.
Dabei gibt es doch Wichtigeres - oder? Manpower.

Eine Meldung bzgl. der "h-Lücke" gibt es nicht – zumindest bisher ist das nur dokumentiert (Hilfe-Datei). Aber vielleicht sollten wir es wirklich (erst mal) so lassen, obwohl ich denke, dass nicht unbedingt jeder damit klar kommt, und so mancher das Plugin nur deshalb nicht gerne einsetzt (war ja auch Holgers Argument).

Aus meiner Sicht, wäre es mir lieber einen Hinweis zu erhalten, dass mit der Seite irgendetwas passieren wird - statt beim Aufbau eines Templates ständig an mehreren Stellen (zwei) schrauben zu müssen.

Okay, danke! Ein längerfristige Lösung wäre dann aber für XH 1.7 denkbar, wo wir (konfigurierbar) seo_headings() gleich in content() integrieren könnten, und dann die Heading-Styles vielleicht immer dynamisch ausgeliefert werden könnten. Immerhin ist es ja jetzt etwas schwierig (besser gesagt, unmöglich) ein Stylesheet auszuliefern, dass mit verschiedenen menu_levels Einstellungen harmoniert. Wobei die Individualanpassung ja eigentlich auch kein Problem sein sollte.

Und auf den Editor kann das Plugin nicht leicht Einfluss nehmen

Wenn der Inhalt einer Seite an den Editor (egal welchen) übergeben wird, könnte die Verschiebung der hx genau so passieren, wie bei der Anzeige im Frontend.

Ja, das sollte gar nicht mal schwierig sein – allerdings müsste das wohl in CMSimple_XH selbst geändert werden – per Plugin wird's, wenn's überhaupt geht, frickelig. Wäre also auch eher was für XH 1.7 (oder 2.0 wegen der Abwärtskompatibilität zu bestehenden Templates).

[Holger]

Eine Meldung bzgl. der "h-Lücke" gibt es nicht – zumindest bisher ist das nur dokumentiert (Hilfe-Datei).

Hmm, ich dachte

Code: Select all

$o .= XH_message('warning', $plugin_tx['seo'][$msgkey], implode(', ', $hlevels)); 

in function seo_check_heading_structure() sei für die Warnung zuständig? Ok, ich gebe zu: ich habe es noch nicht getestet, sondern nur den Code auf GitHub angeschaut.

Aber ihr fragtet nach Gestaltermeinung ...
Aus meiner Sicht, wäre es mir lieber einen Hinweis zu erhalten, dass mit der Seite irgendetwas passieren wird - statt beim Aufbau eines Templates ständig an mehreren Stellen (zwei) schrauben zu müssen.

Dann sollte die Sache schon jetzt aufgegeben werden.
Der Durchschnitts-User wird es nicht schaffen die Styles, auch noch abhängig von der Tiefe des Seitensplittings, selber anzupassen. Und die Geeks, die ja nicht Zielgruppe sind, schaffen das auch, wie bisher, ohne ein Plugin.

Vielleicht liest du aber nochmal Franks Tutorial. Eigentlich ist da nicht viel zu beachten.

Eine andere Idee wäre, dass die betreffenden Styles für die Überschriften nach bestimmten Konventionen (und vielleicht sogar in einer separaten Datei und per @import geladen) definiert werden. Dann müsste das SEO_XH-Plugin dann eben doch "regexpen"...

Ich bin generell der Meinung, dass größere Klimmzüge nur zur Reparatur falscher Semantik, ob in 1.7 oder 2.0, vergebene Mühe ist.
Dann besser überlegen, wie mit 1.7 oder 2.0 eine andere Art des Seitensplittings, unabhängig vom H-Tag, implementiert werden kann.

[Tata]

Der Durchschnitts-User wird es nicht schaffen die Styles, auch noch abhängig von der Tiefe des Seitensplittings, selber anzupassen. Und die Geeks, die ja nicht Zielgruppe sind, schaffen das auch, wie bisher, ohne ein Plugin.

Meine Meinung hier ist, dass es wohl weniger kompliziert wäre, die User auf Pagemanager mehr zu orientieren (und evtl. am Pluginmanager mehr zu arbeiten). Seien die neue Seiten dort erstellt, sieht man gleich die Strukture. Ich Stimme absolut zu, dass die erfahrene User nichts davon, dass hier diskutiert ist, unbedingt brauchen. Die unerfahrene werden es kaum verstehen (egal ob mit/ohne dem Plugin). Im Gegenteil, sie werden noch weniger verstehen, wenn estwas, dass nich von ihnen stammt, mit der Seitenstrukture passiert.
Es ist viel, was noch gemacht sein kann. Die Frage ist nur, ob es überhaupt nötig ist. Mir gefählt CMSimple-XH im heutigen Zustand schon sehr gut.
Man kann es auch so nehmen:
Die Webseiten laufen, egal wie ist die Qualität der Strukture - der Gäst sieht nicht alles, was SEO betrifft. Die Konsequenzen sind wichtig, aber nicht unbedingt auf der ersten Stelle.
Ein Hinweis für den Webmaster/Templatemaster würde IMHO genüglich reichen, um eine gute Webseite aufzubauen. Das selbe gilt für den Admin während Bearbeitung des Inhalts.
Ein Prefix oder etwas ähnliches würde genug, um dem Webmaster/Admin zu sagen, dass es etwas falsch gemacht wurde. Dann wird es auf ihren Entscheidung, ob es korrigiert oder ignoriert wird.
Würde so was nicht genügen?
[ external image ]
Es wäre nur schön, wenn die bereits existierte Struktur im Pagemanager auch genau gezeigt würde - ist die Strukture falsch (z.B. H1...H3) - im Page manager ist es als H1...H2 dargestellt. So meine ich, dass "DUPLICATE HEADING" und "WRONG LEVEL" würden föllig genügen.

[frase]

Dann sollte die Sache schon jetzt aufgegeben werden.

Nein! Um Himmels Willen.
Meine Meinung ist doch nur eine Meinung.

[Holger]

Dann sollte die Sache schon jetzt aufgegeben werden.

Nein! Um Himmels Willen.
Meine Meinung ist doch nur eine Meinung.

Hmm, ich denke inzwischen, dass ein anderer Ansatz besser wäre.
Mehr dazu später...

[meltemi]

Ich bin generell der Meinung, dass größere Klimmzüge nur zur Reparatur falscher Semantik, ob in 1.7 oder 2.0, vergebene Mühe ist. Dann besser überlegen, wie mit 1.7 oder 2.0 eine andere Art des Seitensplittings, unabhängig vom H-Tag, implementiert werden kann.

Genau.

Und svasti hatte das schon am Mon Aug 08, 2011 6:43 pm vorgeschlagen.

Wenn das umgesetzt werden könnte, würde CMSimple XH auch für Leute nutzbar, die ein schnelles CMS ohne Datenbank suchen, aber zugleich die semantisch richtige Überschriftenstruktur verwenden wollen. Ohne aufwendig rumzubasteln oder zusätzliche Plugins zu verwenden oder sich ihr Hirn zu verrenken (welche hx muß ich denn jetzt nehmen, damit am Ende hy rauskommt?).

[Holger]

Ich bin generell der Meinung, dass größere Klimmzüge nur zur Reparatur falscher Semantik, ob in 1.7 oder 2.0, vergebene Mühe ist. Dann besser überlegen, wie mit 1.7 oder 2.0 eine andere Art des Seitensplittings, unabhängig vom H-Tag, implementiert werden kann.

Genau.

Und svasti hatte das schon am Mon Aug 08, 2011 6:43 pm vorgeschlagen.

Wenn das umgesetzt werden könnte, würde CMSimple XH auch für Leute nutzbar, die ein schnelles CMS ohne Datenbank suchen, aber zugleich die semantisch richtige Überschriftenstruktur verwenden wollen. Ohne aufwendig rumzubasteln oder zusätzliche Plugins zu verwenden oder sich ihr Hirn zu verrenken (welche hx muß ich denn jetzt nehmen, damit am Ende hy rauskommt?).

Da bin ich ganz bei dir! Thema war die Sache schon oft, zuletzt hatte ich letztes Jahr im Mai darüber nachgedacht.
Aber anstatt zu jammern, werde ich dieses Mal versuchen einen, zumindest mit dem WYSIWYG-Editor lauffähigen, funktionierenden Vorschlag auszuarbeiten.
Lassen wir das Thema also noch ein Wenig ruhen...

[cmb]

Aber anstatt zu jammern, werde ich dieses Mal versuchen einen, zumindest mit dem WYSIWYG-Editor lauffähigen, funktionierenden Vorschlag auszuarbeiten.
Lassen wir das Thema also noch ein Wenig ruhen...

Ich bemühe mich, mich kurz zu fassen. Die jetzige Struktur von content.htm hat den Vorteil, dass man den gesamten Inhalt in einem vernünftigen HTML-Editor direkt bearbeiten kann. Das tun vermutlich nur wenige, aber denen würde ich diese Möglichkeit ungern nehmen (ich zähle nämlich selbst dazu). Daher sollten Änderungen der Struktur am besten optional sein (per Konfig-Option). Und wenn dann was geändert wird, warum machen wir nicht gleich Nägel mit Köpfen, sprich weg von einer Textdatei, und hin zu einem geeigneten Binärformat. Statt selbst etwas zu basteln, warum nicht SQLite3? Ich habe kürzlich Realblog_XH auf ext/sqlite3 umgestellt (ext/pdo_sqlite3 wäre auch möglich, aber ext/sqlite3 erscheint mir sinnvoller, da der C-Code wartbarer ist, und die Backup-API wäre eine nützliche Funktionalität) und das funktioniert ganz fantastisch, und auch große Datenmengen (ich hatte auch mit 10.000 Artikeln getestet) scheinen kein besonderes Problem darzustellen. Export und Import von und nach CSV wären leicht zu ergänzen, damit man zur Not doch mal manuelle Änderungen vornehmen kann. Leider ist der jetzige Stand von Realblog_XH noch nicht veröffentlichbar – ich hoffe, das ändert sich bald.

[frase]

warum nicht SQLite3?

Klingt (für mich Unwissenden) interessant.
Zukunftssicher?
Update-Frequenz?
Externe Abhängigkeit?

[Tata]

Statt selbst etwas zu basteln, warum nicht SQLite3?

Wäre es nicht zu riskant? Ich meine, dass die Plaintextbasis macht CMSimple so populär. Es gibt sehr viele CMS, die auf einer oder anderer SQL basieren. Dem Enduser ist es meistens Wurscht, wie die Seite gebaut ist. Inhalt ist das wichtigste. Würden die Admins brauchen welcheimmer SQL aktivieren müssen - ich fürchte - werden sie auf SQL-basierte CMS verzichten. Oder?