SEO_XH - Plugin

[frase]

Falls (ich betone: falls) es zur CSS-Variante käme, sollte Holgers Nomenklatur (oder Terminologie?) verwendet werden:
<h1 class="XH_mlxxx">
Wesentlich besser als "split".
"ml" = menulevel - richtig?

[frase]

Auch löscht der User nicht mehr aus versehen eine Seite, er bekäme die Meldung "fehlende Überschrift" weil der "Splitt-Kommentar" bei der Arbeit im WYSIWYG_Mode erhalten bliebe. Und der Inhalt müsste dann in dieser Seite bestehen bleiben, anstatt ihn an die vorherige Seite anzuhängen - wenn machbar.

Wenn unabsichtlich <h1> gelöscht (mit oder ohne Marker):
Beim Speichern Meldung: "fehlende Überschrift"
UND automatisch eine in den Text 1. Zeile reinsetzen: "[Missing Headline]" mit richtigem Marker (falls Unterseite) -> "reinsetzen" heißt: nicht in den Editor, sondern VORN an den zu speichernden Inhalt setzen und gleich mitspeichern.
UND die Meldung ergänzen mit: "Bitte korrigieren - und/oder im Pagemanager verschieben!"
Text verschwindet nicht. Landet im schlimmsten Fall als Einzelseite mit Titel: [Missing Headline]

[frase]

Überschriften:
Der Thread hat nun mittlerweile wirklich eine falsche.

Wenn das alles so klappt, wie besprochen, sind theoretisch 6 (sechs) Menülevel möglich.
Wäre das gut?

[cmb]

Überschriften:
Der Thread hat nun mittlerweile wirklich eine falsche.

Ist hier irgendwie normal.

Wenn das alles so klappt, wie besprochen, sind theoretisch 6 (sechs) Menülevel möglich.
Wäre das gut?

Es sind theoretisch unendlich viele Menülevel möglich – <!--XH_ml123456789--> wäre ja auch denkbar. Schaden dürfte das nicht, auch wenn man natürlich schwerlich so viel Content unterbringen kann (dann wird's ein "bisschen" langsam).

[Holger]

Ich habe den Thrad jetzt geteilt. Hier geht es im Bezug zum alternativen Seitensplitten weiter:
http://cmsimpleforum.com/viewtopic.php?f=16&t=11966

[olape]

Ich hoffe ich bin hier richtig.
Das ist bei dem Thema und den Beiträgen nicht ganz so einfach zu eruieren.

Ich habe heute mal das Plugin SEO_XH getestet, noch nicht alles, aber angefangen.
Muss erst mal versuchen mich ein bisschen reinzudenken.

Aber ich glaube ich habe einen Fehler gefunden.
Ausgehend von den Beiträgen der letzten Tage zu Sitemapper_XH und meinem aktuellen Projekt und der dadurch noch so eingestellten Testumgebung.
Es geht um den canonical link auf der ersten veröffentlichten Seite.

- hier ist es soweit Standard, da passt es http://test.penschke.net/en/?Welcome-to-CMSimple_XH
- hier passt es aber nicht, weill die erste Seite nicht die erste veröffentlichte ist http://test.penschke.net/?Menu-Levels-und-Headings

Es gibt in dem Fall zwei canonical links, der erste ist von SEO_XH, der zweite von xlang_XH.

Ein paar Tage werden die Links wohl so aktuelle bleiben, hoffe ich.
Da es eben eine Testumgebung ist natürlich nicht ewig.

[cmb]

Ausgehend von den Beiträgen der letzten Tage zu Sitemapper_XH und meinem aktuellen Projekt und der dadurch noch so eingestellten Testumgebung.
Es geht um den canonical link auf der ersten veröffentlichten Seite.

- hier ist es soweit Standard, da passt es http://test.penschke.net/en/?Welcome-to-CMSimple_XH
- hier passt es aber nicht, weill die erste Seite nicht die erste veröffentlichte ist http://test.penschke.net/?Menu-Levels-und-Headings

Ja, das ist ein Bug. Danke fürs Melden!

Das Problem ist, dass ich 0 statt $_XH_firstPublishedPage verwendet habe.

[olape]

ist mir auch nur aufgefallen, weil wir es ja nun gerade hatten.

Aber noch was anderes

Code: Select all

mit realblog_page in config 

url --> http://test.penschke.net/?Test-Print/Test-Realblog
can --> http://test.penschke.net/?Test-Print/Test-Realblog --> ok

url --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=1
can --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=1 !!!!!!!!!!!!!!!!!!!!!
	--> identisch mit Seite ohne Parameter.
	--> hier dürfte nur can --> http://test.penschke.net/?Test-Print/Test-Realblog stehen

url --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=x
can --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=x --> ok

ohne realblog_page in config

url --> http://test.penschke.net/?Test-Print/Test-Realblog
can --> http://test.penschke.net/?Test-Print/Test-Realblog	--> ok

url --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=1
can --> http://test.penschke.net/?Test-Print/Test-Realblog --> ok

url --> http://test.penschke.net/?Test-Print/Test-Realblog&realblog_page=x
can --> http://test.penschke.net/?Test-Print/Test-Realblog !!!!!!!!!!!!!!!!!!!!!
	--> alle Seiten zeigen auf die erste Seite

Das soll auf keinen Fall sein, Paginierung soll nicht auf die erste Seite zeigen.

https://support.google.com/webmasters/a ... 3744?hl=de

Dafür soll eher rel="prev" rel="next verwendet werden.
Und in dem Fall wäre es das Beste, wenn das jeweilige Plugin das selbst erledigen würde.

Was mich darauf bringt, dass diese Angaben bei Xh eigentlich missbräuchlich verwendet wird.
Und gerade in diesem Fall ganz weit an Ziel vorbei gehen, denn diese sollten die einzelnen Seiten von i.d.F. Realblog verbinden.
Und von daher eigentlich aus XH ganz verschwinden müssten.

[cmb]

Das soll auf keinen Fall sein, Paginierung soll nicht auf die erste Seite zeigen.

Seo_XH weiß nichts von anderen Plugins, vor allem nicht, welche Query-Parameter anderen Inhalt erzeugen, und welche nicht. Daher gibt es die Konfigurationsoption canonical_include, wo man in diesem Fall "page" eintragen kann. Ob eine Paginierung wirklich im Canonical Link aufgeführt sein sollte, darüber kann man sicher streiten, aber für etwas wie Forum_XH oder Realblog_XH gehören gewisse Parameter in den Canonical Link.

Dafür soll eher rel="prev" rel="next verwendet werden.
Und in dem Fall wäre es das Beste, wenn das jeweilige Plugin das selbst erledigen würde.

Letzteres ist schwierig, weil unter Umständen zwei oder gar mehr Plugins einen solchen erzeugen könnten, und dann gibt es vermutlich Probleme. Wüsste nicht, wie man das generell lösen könnte.

Was mich darauf bringt, dass diese Angaben bei Xh eigentlich missbräuchlich verwendet wird.
Und gerade in diesem Fall ganz weit an Ziel vorbei gehen, denn diese sollten die einzelnen Seiten von i.d.F. Realblog verbinden.
Und von daher eigentlich aus XH ganz verschwinden müssten.

Diese Links kommen wohl aus der Buchmetapher (eine CMSimple-Website ist wie ein Buch aufgebaut, und auch so zu lesen). Tatsächlich ist das im Allgemeinen fraglich, und wir sollten vielleicht eine Konfigurationsoption ergänzen, damit das unterdrückt werden kann (bzw. die Links erst aktiviert werden müssen).

[olape]

Das soll auf keinen Fall sein, Paginierung soll nicht auf die erste Seite zeigen.

Seo_XH weiß nichts von anderen Plugins, vor allem nicht, welche Query-Parameter anderen Inhalt erzeugen, und welche nicht. Daher gibt es die Konfigurationsoption canonical_include, wo man in diesem Fall "page" eintragen kann.

Aber wenn ich es eintrage, dann stimmt es wieder auf der ersten Seite nicht.
Dann gibt es zwei unterschiedliche URLs mit gleichem Inhalt (DC) und jede davon zeigt dann im canonical-link noch auf sich selbst.
Es passt nicht mit Eintragen und es passt nicht ohne Eintragen (da passt es nicht mehr ab Seite 2)
Ich glaube in dem Fall ist es einfach besser, es ganz ausschliessen zu können und das ganze dem Plugin zu überlassen.

Das Plugin ist ja noch im Test. Deshalb schreibe ich das hier.
Bitte nicht als Nörgelei auffassen!

olape hat geschrieben:
Dafür soll eher rel="prev" rel="next verwendet werden.
Und in dem Fall wäre es das Beste, wenn das jeweilige Plugin das selbst erledigen würde.

Letzteres ist schwierig, weil unter Umständen zwei oder gar mehr Plugins einen solchen erzeugen könnten, und dann gibt es vermutlich Probleme. Wüsste nicht, wie man das generell lösen könnte.

Es bräuchte doch nur im Plugin konfigurierbar sein, ob die Links für prev und next gesetzt werden sollten.
Und natürlich auch nur innerhalb der Paginierung des Plugins.
Mir würde jetzt so auf Anhieb keine Situation einfallen, wo auf einer Seite gleichzeitig zwei Plugins mit Paginierung arbeiten würden. Unmöglich ist natürlich nichts.

Und ein Gleiches könnte man mit den canonical-linkt tun.
Wenn der von zentraler Stelle erstellt wird, dann muss man solche Plugins ganz ausnehmen können
(bei xlang_XH habe ich das so gemacht, da gibt es eine withelist --> diese Parameter werden entfernt - für canonical die für hreflang gleichzeitig als blacklist dient und jeweils für canonical und hreflang eine eigene blacklist)
und im Plugin muss es dann dafür eine Möglichkeit geben, das nur für das Plugin zu aktivieren.

Ich weiss, das mit dem simple ist dann nicht mehr so ganz gegeben. Aber SEO ist auch nicht simple.
Und das Umsetzen von SEO schon gleich gar nicht.

Tatsächlich ist das im Allgemeinen fraglich, und wir sollten vielleicht eine Konfigurationsoption ergänzen, damit das unterdrückt werden kann (bzw. die Links erst aktiviert werden müssen).

Da wäre ich sehr dafür.
Und ehe wieder einer meckert, es geht hier nicht um die Links prev und next, die der Besucher nutzt, um durch die Seite zu blättern, sondern um die Angaben im Seitenkopf für die Suchmaschinen.