[GELÖST] Warum wird Aliassen mit Ziffern ein »id-« vorangestellt?

[Dexter Paris]

Weiß zufällig jemand, warum Aliassen die mit Ziffern beginnen, ein id- vorangestellt wird?

Erzeugt wird das in der Funktion standardize in system/helper/functions.php ab Zeile 239.

Warum frage ich danach …

Wenn man z.B. eine Seitenstruktur aufbaut, die Jahreszahlen oder ein Datum enthält, sieht das mit dem automatisch erzeugten Alias ziemlich lausig aus.

Beispiel:

Name der Seite: 2014 wird zu id-2014
Name der Unterseite: 2014-07-12 Seitentitel wird zu id-2014-07-12-seitentitel

Ein Pfad (bei Verwendung von Folder-URLs) würde dann lauten: ../id-2014/id-2014-07-12-seitentitel

Nicht sehr schön, oder? Besser wäre es doch so: ../2014/2014-07-12-seitentitel

Kann man nun manuell ändern, funktioniert scheinbar genauso, bloß nach einer automatischen Generierung der Aliasse ist das id- wieder mit drin …

Da diesem Verhalten wohl eine Überlegung zu Grunde liegt (sonst wäre es ja nicht eingebaut) würde ich gerne wissen:

a) Was ist der technische Hintergrund?

b) Was könnte theoretisch passieren wenn man es manuell überschreibt?

c) Läßt sich dieses Verhalten auf einfache Weise abstellen?

[Spooky]

Das macht die Funktion standardize in /system/helper/functions.php . Und ich glaube das wurde deshalb gemacht, weil Aliase ja auch bspw. automatisch als HTML ID eingefügt werden - und unter HTML4 durfte eine ID nicht mit einer Nummer beginnen. Daher wird ein 'id-' vorangesetzt. Ist also vielleicht mehr oder weniger nur für Artikel Aliase.

Aber vielleicht gibt es ein ähnliches requirement auch an anderen Stellen wo der Alias eingesetzt wird, nicht nur bei Artikeln in HTML4.

[Dexter Paris]

Ja, das klingt plausibel!

Wobei man das meines Erachtens aber eigentlich mittlerweile rausschmeißen könnte:

Das W3C sagt dazu in in folgendem Artikel http://www.w3.org/TR/xhtml1/#C_8

Note that the collection of legal values in XML 1.0 Section 2.3, production 5 is much larger than that permitted to be used in the ID and NAME types defined in HTML 4. When defining fragment identifiers to be backward-compatible, only strings matching the pattern [A-Za-z][A-Za-z0-9:_.-]* should be used. See Section 6.2 of [HTML4] for more information.

So wie ich das lese – bin da allerdings absolut kein Spezialist – sollte dieses Muster in Hinblick auf Rückwärtskompatibilität verwendet werden. Da aktuelle Contao-Versionen standardmäßig aber sowieso nur noch HTML5, XHTML 1.0 Strict und Transitional ausgeben, wäre das Einpflanzen der id- Zeichenkette eigentlich obsolet.

Wäre doch eine Verbesserung hinsichtlich sauberer URLs …

[xchs]

Da diesem Verhalten wohl eine Überlegung zu Grunde liegt (sonst wäre es ja nicht eingebaut) würde ich gerne wissen:

a) Was ist der technische Hintergrund?

Ich glaube, der Grund ist u. a. jener, dass in Inserttags als Argument entweder eine ID oder ein Alias angegeben werden kann. Wenn Du nun – um bei Deinem Beispiel zu bleiben – für den Link-Inserttag

{{link::*}}	Dieses Tag wird mit einem Link zu einer internen Seite ersetzt (ersetzen Sie * mit der ID oder dem Alias).

den von Dir gewünschten Alias "2014" angibst

{{link::2014}}

dann weiß Contao nicht, ob es sich bei "2014" nun um die Seite mit der ID 2014 oder um die Seite mit dem Alias "2014" handelt.

[Dexter Paris]

Danke @xchs für Deinen Input!

Ich hab diese Theorie eben in der Demo ausprobiert:


Versuch 1 – Zwei gleichnamige Seiten in unterschiedlichen Ebenen

Seitennamen aus Buchstaben erzeugt identische Aliasse, ist z.B. der Name der Seite und der Unterseite "Test"
ergibt je ein Alias "test".

Seitennamen aus Ziffern erzeugt identische Aliasse, ist z.B. der Name der Seite und der Unterseite "2014"
ergibt je ein Alias "id-2014".

Das bedeutet also, dass identische Aliasse möglich sind, Contao findet das nicht anstößig.


Versuch 2 – Zwei gleichnamige Seiten in gleichen Ebenen

Seitenname aus Buchstaben, ist z.B. der Name der Seite jeweils "Test"
ergibt ein Alias "test" und eines "test-53".

Seitenname aus Ziffern, ist z.B. der Name der Seite jeweils "2014"
ergibt ein Alias "id-2014" und eines "id-2014-57".

Bei gleichnamigen Seiten auf der selben Ebene, wird also einfach die ID des Contao-Elements angehängt, im Beispiel oben wäre das ID-53 und ID-57 mal so als Hausnummer …

Fazit

Die Theorie mit dem Insert-Tag haut also nicht so ganz hin …

Hmm!?



UPDATE

Ich glaube, der Grund ist u. a. jener, dass in Inserttags als Argument entweder eine ID oder ein Alias angegeben werden kann. Wenn Du nun – um bei Deinem Beispiel zu bleiben – für den Link-Inserttag

{{link::*}}	Dieses Tag wird mit einem Link zu einer internen Seite ersetzt (ersetzen Sie * mit der ID oder dem Alias).

den von Dir gewünschten Alias "2014" angibst

{{link::2014}}

dann weiß Contao nicht, ob es sich bei "2014" nun um die Seite mit der ID 2014 oder um die Seite mit dem Alias "2014" handelt.

Das habe ich erst überzuckert, als ich schon gepostet hatte!

Stimmt natürlich! Wäre dann aber irgendwie geschickter, man würde dem Insert-Tag einen Bezeichner für die ID mitgeben, also um die Seite mit der ID-2014 verknüpfen wäre ein Insert-Tag {{link::id-2014}} zu benutzen, anstatt die URL zu versauen …

[BugBuster]

Das liegt auch daran wie Contao die Seite sucht.
Eine Seite ist per Alias als auch per ID aufrufbar!
Nehmen wir mal an die URL wäre domain.com/2014.html und den damals eingebauten Fix gäbe es nicht.
Dann weiß Contao nicht, ist das eine ID = 2014 oder ein Alias=2014, also sucht er nach beides. (das tut er glaub ich noch immer)
Nun stell dir mal vor, es gäbe beides! Genau aus dem Grund hatte ich damals einen Bug gemeldet und es wurde dieser ID- Prefix eingebaut.
(ich hatte eine Seite mit ID=64 und eine mit Alias=64)

[Dexter Paris]

Deswegen meine ich ja, lieber den Insert-Tags ein Prefix id- mitgeben und dafür die Aliasse in Ruhe lassen.

Ich denke auf sauberen Pfadstrukturen sollte die höhere Priorität liegen!

Der selbe Käse findet sich ja bei News und Events: Wobei ich da überhaupt noch keine sinnvolle Lösung gefunden habe.

Will man z.B. eine News/Event für den 12. Juli 2014 mit dem Titel "Veranstaltung" anlegen, und eine für den 15. Juli mit gleichem Titel, erhält man

– einmal das Alias "veranstaltung" und
– einmal das Alias "veranstaltung-89" (wenn die ID z.B. 89 ist)

Wenn ich dem Veranstaltungstitel ein Datum mitgebe also z.B. "2014-07-12 Veranstaltung" bekomme ich wiederum ein Alias mit Prefix "id-2014-07-12-veranstaltung". Abgesehen davon, dass dann das Datum doppelt eingepflegt werden muss und im Titel feststeckt, ist eben wieder das id- Prefix mit drin …

Fragen über Fragen, die mir langsam bewusst werden lassen, warum mein Projekt nicht voran geht … :-/

[andreasisaak]

Fragen über Fragen, die mir langsam bewusst werden lassen, warum mein Projekt nicht voran geht … :-/

Wegen URL's?

[BugBuster]

lass doch mal den Insert Tag in Ruhe, das Problem wäre sonst wie gesagt schon bei ganz normaler Auswahl der Seite in der Navigation.
Willst du allen verbieten einen Alias Namen zu bilden der nur aus Zahlen besteht?

[Dexter Paris]

Wegen URL's?

So eine ähnliche Frage habe ich schon erwartet … ^^

Kurze Hintergrundgeschichte:

Ich hab seit fünf Jahren eine gewachsene statische Seite, die ich (gezwungenermaßen) immer noch mit Dreamweaver pflege. Diese ist aber mittlerweile recht umfangreich und dadurch auch inhaltlich wie optisch mehr als inkonsistent.

Von einer Umstellung auf ein CMS erwarte ich mir, dass Dinge die zuvor viel Arbeitsaufwand verursachten, hinterher wesentlich einfacher über die Bühne gehen. Aber meine Liste an Dingen die ich out-of-the-box erwartet hätte, sich aber letztlich an solchen »Kleinigkeiten« aufhängen, wird immer länger. Und die für meinen Begriff »nicht sauberen« URL-Pfade gehören da eben auch dazu …

Irgendwie ist es zur Zeit so, das ich viele Probleme aus der statischen Website elegant lösen kann, dafür entstehen ein Haufen neue Probleme, die ich dann erst wieder nur manuell beheben kann.

BTW: Warum lässt sich in MetaModels das Attribut "Kombinierte Einträge" nicht für den Meta-Titel verwenden?

Willst du allen verbieten einen Alias Namen zu bilden der nur aus Zahlen besteht?

Überhaupt nicht, im Gegenteil. Genau das möchte ich ja erreichen …

[andreasisaak]

BTW: Warum lässt sich in MetaModels das Attribut "Kombinierte Einträge" nicht für den Meta-Titel verwenden?

Das gehört hier zwar überhaupt nicht hin aber: weil es einfach nicht dafür aufbereitet ist. Hat noch keiner bei uns angefragt und ein Ticket erstellt.

[Dexter Paris]

Aha, da bin ich ja beruhigt, dass es nicht an mir lag … ;-)

Ich pack das mal ins MM-Forum inkl. Erklärung warum ich das für sehr praktisch halten würde.

[andreasisaak]

Da bringt das wenig, schreib gleich ein Ticket im dafür passenden Repo auf Github.

[BugBuster]

Willst du allen verbieten einen Alias Namen zu bilden der nur aus Zahlen besteht?

Überhaupt nicht, im Gegenteil. Genau das möchte ich ja erreichen …

Du hast es immer noch nicht verstanden, oder? Wenn man das zulassen würde, könntest du ein Alias anlegen "1".
Und nun? Bei Aufruf von seite.de/1.html, würde Contao nun 2 Seiten finden, eine mit ID=1 und eine mit Alias=1, welche soll es anzeigen?
Wie oben gesagt, die kannst eine Seite immer mit beiden Varianten aufrufen.

[BugBuster]

Hier mal der Grund für das Ticket:
https://github.com/contao/core/issues/82

[Dexter Paris]

Vielen Dank @BugBuster, jetzt ist es zu mir durchgedrungen! Da werde ich mir wohl oder übel eine neue Struktur ausdenken müssen …

Zusammenfassend könnte man also sagen, dass man das Prefix id- aus einem Alias grundsätzlich entfernen könnte, solange keine gleichlautende ID in Verwendung ist. Andernfalls wären unvorhergesehene Komplikationen und Fehlfunktionen zu erwarten. Weiters kommt es bei unachtsamer Verwendung der Funktion Aliase generieren zum erneuten Hinzufügen des Prefix und kann daher zu nicht mehr erreichbaren Seiten führen!

Da bringt das wenig, schreib gleich ein Ticket im dafür passenden Repo auf Github.

Ich hoffe ich habe das richtig gemacht, GitHub ist komplettes Neuland für mich …

Zum Ticket: https://github.com/MetaModels/attrib...alues/issues/4

[Flex]

Aber dann müsstest du ja gleichzeitig die umgekehrte Prüfung einbauen - Contao verwendet hier den MySQL internen Zähler von MySQL. Den müsstest du dann deaktivieren.
Bsp:
Du bist gerade beim 20. Eintrag in der Datenbank und der soll den Alias 80 kriegen - Contao prüft - keine ID vorhanden, alles klar, eingetragen.
4 Wochen später bist du beim 80. Eintrag - und dein 20. Eintrag ist kaputt.

Erstelle dir lieber Umleitungen dafür als zwanghaft ein URL Schema zu übernehmen.

[Spooky]

Dass eine Page über die URL auch über deren ID aufgerufen werden kann muss ja nicht unbedingt notwendig sein. @Dexter Paris: du könntest dir die PageModel Klasse extenden und die Funktion PageModel::findPublishedByIdOrAlias überschreiben (und dahingehend ändern, dass nur mehr auf den Alias abgefragt wird).

Extra mit Umleitungen zu hantieren sollte nicht notwendig sein.

Hier mal der Grund für das Ticket:
https://github.com/contao/core/issues/82

Da ging es ja urpsrünglich um das Problem, dass bei einem Alias der zB "64Bit" lautet in einem MySQL query für die Abfrage mit "id = '...'" der entsprechende Parameter von MySQL automatisch zu einem Integer gecastet wurde - und dadurch lieferte der query, je nach dem was zuerst in der Datenbank vorkommt, die Page mit der ID 64, anstatt mit dem Alias "64Bit". Das wurde damals gefixed - der Fix sieht in der heutigen Version von Contao so aus (Zeile #296, PageModel.php):

        $arrValues = array((is_numeric($varId) ? $varId : 0), $varId); 

Dadurch wird sichergestellt, dass immer nur der Alias in der Abfrage "id=? OR alias=?" verwendet wird, wenn der Parameter nicht numerisch ist (was bei '64Bit' der Fall wäre).

[BugBuster]

Dass eine Page über die URL auch über deren ID aufgerufen werden kann muss ja nicht unbedingt notwendig sein.

Doch, muss es, da es ein Feature ist. Ich kann den Alias ja auch mal ändern, wenn die Links (z.B. bei Insert Tags) alle auf die ID zeigen hat das keine weitere Auswirkung.
Würde man da nun gezwungen sein Alias Namen einzutragen macht man sich die Flexibilität kaputt.
Außerdem gibt es noch das Feature, die Alias Verwendung ganz abzuschalten, so dass alles nur noch über IDs läuft.
Absoluter BC Break würde man da was dran ändern. Auch intern wird oft mit IDs gearbeitet z.b. im TinyMCE bei der internen Verlinkung.

Mein Ticktet von damals hat einen Nebeneffekt beseitigt, das stimmt. Das ist aber auch nicht der "id-" Patch. Aber so fing das damals an.
Aber das Haupteigenschaft, dass bei einer reinen ID als Alias nach beidem gesucht wird, bleibt.

[Flex]

@BugBuster: Ich denke Spooky meint hier spezifisch auf das Projekt bezogen, nicht allgemein auf Contao.

[BugBuster]

Wenn man die dort genannten Änderungen umsetzen würde, dann funktioniert Contao nicht mehr, siehe mein Beispiel mit der Verlinkung.
Diese wäre dann wesentlich aufwändiger, da diese manuell eingepflegt werden müssten. Und es gibt bestimmt noch mehr woran ich grad nicht denke.

[BugBuster]

Übrigens, zumindest in der Contao 3.2, kann ich den generierten Alias "id-42" durch "42" überschreiben. Muss ich mal testen ob das schiefgehen könnte.

[Spooky]

Ich kann den Alias ja auch mal ändern, wenn die Links (z.B. bei Insert Tags) alle auf die ID zeigen hat das keine weitere Auswirkung.
Würde man da nun gezwungen sein Alias Namen einzutragen macht man sich die Flexibilität kaputt.

Mit der von mir genannten Änderung würde da im speziellen nichts kaputt gehen, weil die replaceInsertTags Methode PageModel::findByIdOrAlias nimmt und nicht PageModel::findPublishedByIdOrAlias . Letztere Funktion wird aktuell nur von der index.php verwendet, um die über den GET Parameter angegebene Page zu finden. Natürlich wird dann aber für den Insert Tag evt. die falsche Page geholt, in Fällen wo Alias und ID gleich sind.

Außerdem gibt es noch das Feature, die Alias Verwendung ganz abzuschalten, so dass alles nur noch über IDs läuft.

Ja, damit wäre eine solche Änderung auf jeden Fall nicht kompatibel.

Absoluter BC Break würde man da was dran ändern.

Mein Vorschlag des Extendens einer Klasse galt ja Dexter, damit er das Verhalten individuell für seine Bedürfnisse aushebeln kann, nicht für Contao generell. Aber selbst im Core könnte man sowas möglicherweise ohne BC Break umsetzen - es müsste halt dementsprechend auf die Alias Einstellung Rücksicht genommen werden.

Auch intern wird oft mit IDs gearbeitet z.b. im TinyMCE bei der internen Verlinkung.

Das TinyMCE Plugin fügt ja auch einfach nur Insert-Tags mit ID ein, wäre also auch nicht betroffen davon. (Vom ursprünglichen Problem abgesehen.)


Es geht ja hier nur konkret um die Möglichkeit Seiten über URLs aufrufen zu können - also ob es dabei möglich sein soll, kann oder muss die entsprechenden Seiten per ID und/oder Alias aufrufen zu können.

Übrigens, zumindest in der Contao 3.2, kann ich den generierten Alias "id-42" durch "42" überschreiben. Muss ich mal testen ob das schiefgehen könnte.

Beim Alias Feld sollte da vielleicht zusätzlich auf !is_numeric validiert werden. Ein normaler Redakteur weiß ja nichts von Contaos Verhalten, dass Seiten per "id = ? OR alias = ?" abgefragt werden.

[BugBuster]

Jetzt bin ich grad selbst überrascht, denn die URL contaotest.lan/34.html ruft tatsächlich die Seite mit dem Alias 34 auf (und der ID35) und nicht die Seite mit ID34, also alles OK.
Das ist es doch was gewollt ist, oder?

Nachtrag: könnte Zufall sein. Ich vermeide daher solche Aliase.
Nachtrag2: konnte den Zufall beweisen.

[zonky]

Vielen Dank @BugBuster, jetzt ist es zu mir durchgedrungen! Da werde ich mir wohl oder übel eine neue Struktur ausdenken müssen …

Idee:

* leg Deine Seiten mit dem Datum an
* ändere in der DB das "id-" zu z.B. "d-" oder "datum-", "date-"
* mach in der htaccess eine Umleitung per regex von 06-08-2014.html auf datum-06-08-2014.html - damit Google und Bookmarks weiterhin funktionieren...

ggf. in einem Rutsch anlegen per [websitebuilder]