SEO_XH - Plugin

[cmb]

warum nicht SQLite3?

Zukunftssicher?

Ja. ext/sqlite3 ist Teil der offiziellen PHP-Distribution, und wird daher im Zweifel zumindest soweit gepflegt, dass es funktioniert. Und SQLite selbst wird höchstwahrscheinlich noch sehr lange gut gepflegt werden; vgl. die Sponsoren.

Update-Frequenz?

Siehe die News. Also unregelmäßig, aber doch i.d.R. mehrere Updates pro Quartal.

Externe Abhängigkeit?

Die sqlite3 Erweiterung muss verfügbar sein, siehe PHP-Info. Ich gehe aber davon aus, dass das auf den meisten Servern der Fall ist.

Würden die Admins brauchen welcheimmer SQL aktivieren müssen - ich fürchte - werden sie auf SQL-basierte CMS verzichten. Oder?

Zum einen würde ich mir SQLite3 als Option wünschen, d.h. die einfache content.htm könnte beibehalten werden. Zum anderen benötigt SQLite keinen SQL-Server, sondern alle Daten werden weitgehend in einer einzigen Datei gehalten (das heißt, FTP Transfer funktioniert wie bisher). Aktiviert werden müsste ggf. nur die PHP-Erweiterung sqlite3.

[Holger]

Hallo Christoph,

die Vorzüge von SQLite sind mir ja bekannt. Und ich nutze es ja auch, sogar in Verbindung mit einigen CMSimple-Plugins (hatte ich dir vor langer Zeit - glaube ich - mal gezeigt).
Das sind alles Ideen die vielleicht machbar sind. Aber es würde viele Inkompatibilitäten bringen und die Diskussion (ist ja nicht mehr wirklich Flat-File [*], ist ja nicht mehr CMSimple usw.) wieder neu entfachen. Und, was wir nicht vergessen sollten, ist der Zeitfaktor. Das liefe dann auf eine Version 2.0 oder 3.0 hinaus und die wird, bis auch alle nötigen Erweiterungen passen, viele, viele Monate brauchen.
Außerdem fürchte ich, dass die Motivation bei den Pluginentwicklern dadurch nicht gerade verbessert wird, weswegen der Ausbau von Plugin-API / Abstraktion auch noch zusätzlichen Aufwand verursachen wird.
[*] BTW: SQLite war ja schön öfter im Gespräch. Mein Argument war: "ist ja im Prinzip auch nur eine Datei". Dein Argument: "ja, aber eine mit viel Overhead" .

Kurz gesagt: früher war/wäre ich für SQLite, im Moment bin ich dagegen. Klar ist splitten einer großen Content-Datei speicherintensiv und hat auch noch diverse andere Nachteile. Trotzdem passt auch heute noch diese simple Idee zu den allermeisten Projekten. Und, wenn es Multiuser usw. sein muss, gibt es dafür eben Alternativen.
Es ist IMHO auch nicht effizient, das bestehende XH mit allem Ballast dorthin zu führen. Ein von Grund auf neues System scheint mir da besser zu sein. Denn nur ein optionales Speichermedium, unter optionaler Beibehaltung der content.htm, löst nicht das Semantik-Problem. Das ist also ein ganz anderes Thema.

Back to topic:
Ich will am liebsten überhaupt nichts am eigentlichen System ändern. Ich möchte nur in jedem Menülevel alle <hx> - Tags zur Verfügung haben. Die content.htm soll bleiben. Auch der WYSIWYG-Editor und manuelles editieren in der Textarea. Und wenn eine alternative Variante per Konfig wählbar sein soll, dann soll sogar die content.htm auch zu beiden Optionen kompatibel sein. Das Look & Feel soll möglichst nicht, bzw. möglichst wenig geändert werden.

Aber lass mir doch ein paar Tage Zeit zum Nachdenken und Testen. Deine Hilfe werde ich später eh noch benötigen.

[cmb]

Und, was wir nicht vergessen sollten, ist der Zeitfaktor. Das liefe dann auf eine Version 2.0 oder 3.0 hinaus und die wird, bis auch alle nötigen Erweiterungen passen, viele, viele Monate brauchen.
Außerdem fürchte ich, dass die Motivation bei den Pluginentwicklern dadurch nicht gerade verbessert wird, weswegen der Ausbau von Plugin-API / Abstraktion auch noch zusätzlichen Aufwand verursachen wird.

Ja, auf die Schnelle können wir da nichts ändern, aber mittelfristig muss die API sowieso überarbeitet werden. Die vielen globalen Variablen sind wirklich eine Katastrophe.

[*] BTW: SQLite war ja schön öfter im Gespräch. Mein Argument war: "ist ja im Prinzip auch nur eine Datei". Dein Argument: "ja, aber eine mit viel Overhead" .

Das war mal mein Argument, stimmt (v.a. in Bezug darauf, dass mehrere Plugins eigene SQLite DBs haben). Ich hatte aber vor einer Weile mal diverse Tests mit alternativen Speicherformaten (u.a. JSON und Serialization) durchgeführt, und selbst hochoptimierte Varianten waren kaum schneller als ext/sqlite3, und nicht selten sogar langsamer (PDO_SQLite war teils erheblich langsamer).

Klar ist splitten einer großen Content-Datei speicherintensiv und hat auch noch diverse andere Nachteile. Trotzdem passt auch heute noch diese simple Idee zu den allermeisten Projekten.

Ich habe halt nach wie vor Bedenken, dass ein Projekt mal klein anfängt, und dann so groß wird, dass es mit content.htm einfach nicht mehr geht (wir hatten ja auch schon hin und wieder entsprechende Anfragen). Aber okay, der neue Realblog_XH würde dann wohl als Fallback genügen.

Aber lass mir doch ein paar Tage Zeit zum Nachdenken und Testen.

Gerne.

[frase]

SEO_XH - Plugin
Alles bisher besprochene ist wichtig und gehört dazu. (oder fast alles)

Bitte an Christoph:
Kannst du hier bitte nochmal kurz zusammenfassen, was du mit dem Plugin vorhast?
Was ist schon drin? Was ist fest geplant? Was wäre noch möglich? Was geht nicht?
Nur Stichpunkte.
Wir hatten ja schon Missverständnisse in dieser Beziehung. Vielleicht strafft das die Diskussion dann etwas.
Und auf Holgers Ideen müssen wir warten. Bin schon gespannt wie ein Flitzebogen

[Tata]

Andere Idee:
Wie wäre es dann mit content.htm Splitten?
Ich meine z.B. automatisch die Datei für jede H1 (config - optional H2, H3...) neu erstellen? Würde es irgendwie helfen, oder würde es mehr Traffic/Ladezeit verursachen?
Es kann schon bisschen rückwärtig lauten (die urlate Webseiten waren genauso gebaut und die heutige statische noch immer so gebaut sind). Aber dem Gäst ist es eigentlich egal.
Es würde dann etwa so aussehen:
/content
/--- content-Welcome_to~.htm
/--- content-Menu_Levels~.htm (incl. Menu_Level_2_Page_1~.htm, Menu_Level_2_Page_2~.htm, Menu_Level_2_Page_3~.htm)
/--- content-Templates~.htm (incl. gonzo~.htm, mini1~.htm, n6200tbisGPL3~.htm, photo11~.htm, praia~.htm...)
/--- content-Languages~.htm
/--- content-newsboxes~.htm (incl. newsbox_1~.htm, newsbox_2~.htm, newsbox_3~.htm...)
Oder Blödsinn?

[cmb]

Kannst du hier bitte nochmal kurz zusammenfassen, was du mit dem Plugin vorhast?
Was ist schon drin? Was ist fest geplant? Was wäre noch möglich? Was geht nicht?

Verfügbar ist:

• Warnung bzgl. falscher Heading-Strukturen
• "Füllen der Headinglücke" (seo_headings())

Geplant ist:

• Automatisches Erzeugen eines kanonischen Links
• Slugs für Seiten, die die automatisch von CMSimple generierte Seiten-URL überschreiben

Ein paar Sachen fallen mir vielleicht noch ein, und Verbesserungswünsche sind natürlich willkommen!

Was wohl leider nicht möglich ist, sind clean URLs und ein Urlifier", der urichar_org/new ersetzt. Dazu muss am Core angepasst werden. Für beides gibt es aber schon Rezepte a.a.O. im Forum.

Wie wäre es dann mit content.htm Splitten?
Ich meine z.B. automatisch die Datei für jede H1 (config - optional H2, H3...) neu erstellen?

Das geht leider nicht, weil Plugins u.U. auf beliebige Seiteninformationen per globaler Variable ($h, $c, $u, etc.) zugreifen. Das ist eben genau das, was ich meinte als ich schrieb: "Die vielen globalen Variablen sind wirklich eine Katastrophe." Solange das so bleibt, muss immer der gesamte Content geladen werden (auch wenn er überhaupt nicht gebraucht wird, was bei Ajax-Aufrufen nicht selten der Fall ist). Das gleiche gilt analog auch für die Konfigurations- und Sprachdateien.

[frase]

Danke Christoph.
Material zum Nachdenken in der Wartezeit.

[frase]

Eigentlich gehört das nicht zu SEO_XH - Plugin, irgendwie dann aber doch.

Überlegung unter dem Aspekt fehlender Manpower und mangelnder Zeit:

Konfig-Option: Menü-Ebenen streichen (nur noch "1").
Alle Seiten beginnen mit <h1>
-> Alle Seiten haben <h1> ... <h6> zur Verfügung.

Seiten-Splitting (Unterseiten) nach dem "Strang"-Prinzip:
Nur, wenn eine Überschrift die CSS-Klasse ".split" hat, wird gesplittet.
(das müsste dann immer heißen: <h1 class="split">)
Die Klasse wird im Pagemanager vergeben.
Nach dem Split beginnen die Unter-Seiten wieder mit <h1 class="split"> (bis zum nächsten)
Die Menüebene ergibt sich aus der Position.
Evtl. müsste man das Splitten über die Editoren unterbinden -> oder: Bedienerfehler.

Nachteil:
Plugins und evtl. Templates funktionieren nicht mehr.
Aber: irgendein Break muss ja kommen.
-> CMSimple wird für eine Weile in zwei Versionen geliefert:
1. "klassisch" wie bisher (das ging ja auch bisher so)
2. mit neuem Splitting.

Als Laie stelle ich mir vor, dass dieses Splitting nicht so aufwändig zu realisieren wäre.
Eine CSS-Klasse als Split-Marker stört an keiner Stelle. (ID wäre zu kompliziert)
Für Nutzer sollte das "simple" zu bedienen sein.

War so eine Idee. Habe den Überblick über alle vergangenen Vorschläge verloren.
(Post mehrfach editiert)

[Tata]

Seiten-Splitting (Unterseiten) nach dem "Strang"-Prinzip:
Nur, wenn eine Überschrift die CSS-Klasse ".split" hat, wird gesplittet.
(das müsste dann immer heißen: <h1 class="split">)

Hm, dasfindeich etwa unübersihtlich undbin der Meinung, dass für die Admins mehr kompiziert wird für jede Überschrifft noch auch dieclasse zuzuweisen. Mit dem Auswahl aus der Liste war es schon ganz einfach. Die Strukturierung durch H1...H3 scheint mir logischer und sicherer zu sein als H1.split an mehreren Stellen.

[frase]

bin der Meinung, dass für die Admins mehr kompiziert wird

Ich meine: Splitting ausschließlich im Pagemanager (Seiten anlegen/löschen) - nicht mehr im Editor.
Die Klasse wird im Pagemanager automatisch eingefügt. Für den User/Admin ändert sich gar nichts (wenig).

Noch eine Ergänzung zu meinem Post:
Die CSS-Klasse benötigt noch einen Suffix um die Ebenen zu kennzeichnen (es könnte ja mehrere geben)
split_21, split_22, split_23 = 3 mal Menüebe 2
split_211, split_212 = 2 mal Ebene 3 - oder einfacher: split_31, split_32 ...
usw.
Das kann alles mehrfach vorkommen, solange bis eine neue <h1> kommt "ohne split".
Dann beginnt ein neuer "Strang" - eine neue Seite menülevel1.