svasti wrote:Leider funktioniert das nicht mehr mit preg_match_all() and str_replace(), darum dauert es noch ein bisschen.
Man kann preg_match_all() als $flag Parameter PREG_OFFSET_CAPTURE mitgeben, was hier evtl. ganz hilfreich sein könnte. Statt str_replace() kann dann
XH_spliceString() verwendet werden, wenn man von hinten nach vorne arbeitet. Das wird z.B. so in evaluate_plugin_call() gemacht.
svasti wrote:Das Ganze hat bei mir aber keine hohe Priorität, ich machs eher zur Entspannung, so wie andere Kreuzworträtsel lösen.
wsim123 wrote:Ich habe trotzdem noch eine Frage : was bedeutet <sup> als Element.
svasti wrote:<sup> ist HTML für Hochgestellt.
wsim123 wrote:Ich habe dazu auf Wikipedia
https://www.mediawiki.org/wiki/Parser_extension_tags
gefunden. Vielleicht könnte man generell <h1...h6 durch <cm1 ... cm6 ersetzen - was für eine
nächste Version von Cmsimple wäre und auch ein <ref> - Element einführen.
Grundsätzlich sind Wikimarkup und HTML-Eingabe zwei verschiedene Dinge. Elemente in HTML Notation, die bei der Ausgabe ersetzt werden sollen, können bei CMSimple einige Probleme verursachen, und machen den HTML-Quelltext nicht gerade übersichtlicher (was ist natives HTML, und was ist besonderes Markup). Daher würde ich eher eine andere Notation bevorzugen.
Konkret zu <h1>-<h6> ersetzen durch <cm1>-<cm6>: mir ist nicht wirklich klar, was das bringen bzw. wie es funktionieren soll. Klar, man könnte als Anwender nun <h1>-<h6> als seiteninterne Überschrift verwenden. Aber was passiert dann mit <cm1>-<cm6>? Wird es immer zu <h1>, dann hat man eventuell mehrere <h1> auf der Seite, was nicht unbedingt gut ist. Da würde ich dann eher die Variante bevorzugen, die svasti in einem
SEO-Tutorial unter "The typical CMSimple_XH website" vorschlägt.
Und letztlich halte ich 5 oder gar 6 Heading-Levels ohnehin für reichlich viel für eine CMSimple-Site. Mit 5 Heading-Levels mit jeweils 5 Unterseiten käme man auf 3905 Seiten; das ist i.d.R. mehr, als CMSimple leisten kann.
Aber okay, solche Vorschläge tauchen immer wieder mal auf, und grundsätzlich habe ich auch nichts dagegen, das umzusetzen. Ich möchte das aber ungern zum Standard machen, und fände es daher gut, wenn wir den
Zugriff auf den Inhalt abstrahieren. Dann könnten solche anderen Formate (auch ganz anderes Markup wäre denkbar) wohl durch Plugins/Zusatzmodule ermöglicht werden.