Nach dem Upgrade von 2.8.x auf 3.1.1 werden alle meine alten Vorlagen, die %{base_url}%{url} verwenden, um einen Link zu einem Thema einzufügen, jetzt als ungültig hervorgehoben, wobei die GUI sagt Der folgende Interpolationsschlüssel ist ungültig: base_url
Aber er ist tatsächlich gültig, denn wenn ich ihn entferne und nur %{url} belasse, ist der Link defekt (enthält nur den Pfad, ohne die Domain) und wenn ich ihn einfüge, ist der Link gültig und vollständig.
Da Sie die Basis-URL Ihrer Website bereits kennen, bin ich mir nicht sicher, ob der Schlüssel benötigt wird. Verwenden Sie anstelle von %{base_url}%{url} einfach die URL Ihrer Website. Zum Beispiel https://forum.example.com%{url}
Aber es funktioniert, d.h. %{base_url} wird problemlos erweitert, also ist es nicht ungültig (nur die GUI beschwert sich). Außerdem kann man ohne sie keinen voll funktionsfähigen Link erstellen (es sei denn, man kodiert die vollständige Basis-URL fest, was ein No-Go ist).
Der Zweck von Platzhaltern im Allgemeinen ist es, robuste Software zu erstellen, was auch die Vermeidung von Hardcoding beinhaltet. Wenn ich den Domainnamen, Hostnamen oder Pfad zu meiner Discourse-Installation ändere (jedes Element von base_url), müsste ich alle Vorlagen bearbeiten, in denen ich es fest kodiert habe. Das ist schlechte Programmierpraxis.
Da ich weiß, dass die Discourse-Entwicklung ansonsten sehr gesunde und robuste Programmierpraktiken befolgt, kann ich nur davon ausgehen, dass es ein Versehen/Fehler war, (1) base_url bei der Validierung der Vorlage zu entfernen, aber (2) sie tatsächlich noch zu interpretieren, wenn sie vorhanden ist, und (3) keine Alternative anzubieten, um eine voll funktionsfähige URL zu erstellen, ohne auf schlechte Programmierpraktiken zurückzugreifen…
Außerdem wäre dies eine große abwärtskompatible Änderung, für die ich keinen wirklichen Nutzen sehe, die aber viel manuelle Arbeit für die Benutzer verursacht … ein weiterer Grund, von einem Fehler/Versehen auszugehen.
(Ich habe auch andere Fehler in 3.x im Zusammenhang mit Textvorlagen gesehen, also noch mehr ein Grund, von einem Versehen auszugehen)
Wenn ich dies teste, kann ich %{base_url} nicht speichern, sodass es nicht verwendet wird.
Vielleicht ist es ein Versehen. Ich stimme zu, dass dies bestehende E-Mail-Vorlagen von älteren Websites brechen könnte. Ich werde dies zurück in die Kategorie Bug verschieben und dem Team die Möglichkeit geben zu entscheiden, was damit geschehen soll.
Wie ich anfangs erwähnt wurde, spreche ich von bestehenden benutzerdefinierten Vorlagen, die nach dem Upgrade auf 3.x fälschlicherweise als ungültig gekennzeichnet sind, d. h. Vorlagen, die unter 2.x bearbeitet wurden und nach dem Upgrade noch vorhanden sind und %{base_url} enthalten. Das Entfernen dieses Platzhalters macht es unmöglich, vollständige URLs zu erstellen, ohne auf hartcodierte URLs zurückzugreifen. Wenn man es nicht entfernt, ist es offensichtlich, dass es unter 3.1.1 immer noch einwandfrei erweitert wird. Ich habe den ersten Beitrag erneut gelesen und finde ihn nicht unklar.
Sie könnten es wahrscheinlich selbst testen, indem Sie die Datenbank direkt bearbeiten (oder möglicherweise auch in einer Rails-Konsole, wenn der Code nicht dieselbe Validierung ausführt).
Das klingt tatsächlich nach einem Fehler. Vielleicht soll %{url} den Hostnamen enthalten. In einer Endo-Vorlage ist eine URL ohne diesen Hostnamen ziemlich nutzlos (es sei denn, es gibt eine HTML-Möglichkeit, die relative Basis global zu ändern?).
Das Team ist diese Woche auf einer Konferenz, daher wird es eine Weile dauern, bis sie sich dazu äußern können.
Ich würde nicht denken, dass das eine gute Praxis ist, denn dann gibt es keine Möglichkeit, auf die Website-Stammverzeichnis zu verweisen. %{base_url} spielt aus gutem Grund eine wichtige Rolle, um URLs erstellen zu können. Im Allgemeinen bieten Templating-Systeme für URLs 3 Platzhalter: base, path, full_url, wobei letzteres nur zur Bequemlichkeit angeboten wird (es ist die Verkettung der ersten beiden).
@pfaffman Dies ist auch in 3.2.1 noch nicht behoben. Seit meiner ursprünglichen Meldung hat sich nichts geändert. Könnte dies bitte zur Behebung hochgestuft werden? Kurz gesagt, so ziemlich JEDE Vorlage sollte %{base_url} zulassen, da %{url} nur den Pfad nach der Basis-URL enthält.
Verhindern Sie zumindest nicht, dass der Benutzer ihn verwendet (obwohl er nicht in der Liste der verfügbaren Schlüssel angezeigt wird).
Nun, was würden Sie in diesem Fall vorschlagen? Ich weiß nicht, wen ich anpingen soll oder ob noch etwas getan werden kann, um die Aufmerksamkeit relevanter Personen darauf zu lenken.
Kann mir jemand mit dem Rails-Objektnamen oder dem Rails-Konsolenbefehl helfen, %{base_url} in einer Vorlage zu erzwingen, von der ich weiß, dass sie sie akzeptiert und erweitert (es ist nur die GUI, die sagt, dass sie ungültig ist)?
Könnten Sie bitte weitere Informationen bereitstellen, wie z. B. einen Screenshot und den Schlüssel der Vorlage, die Sie zu aktualisieren versuchen. Ich habe keine Probleme mit der Verwendung von base_url in meiner Instanz, aber das Problem könnte mit einer bestimmten Vorlage zusammenhängen.
Es gibt auch viele andere (die meisten E-Mail-Vorlagen zum Beispiel).
Jede einzelne E-Mail-Vorlage (wenn nicht jede Textvorlage!) sollte %{base_url} zulassen, da dies die Stammwebsite ist, auf die man von überall verweisen sollte. Ich verstehe die Entscheidung, sie selektiv aus einigen Vorlagen zu entfernen, nicht … es sei denn, es war irgendwie ein Versehen.