Relative URLs in WordPress

Ich fand es in WordPress immer frustrierend, dass Bilder, Dateien, Links usw. mit einer absoluten URL anstelle einer relativen URL in WordPress eingefügt werden. Eine relative URL ist viel praktischer, um Domainnamen zu wechseln, zwischen http und https usw. zu wechseln. Heute habe ich entdeckt, dass, wenn Sie WP_CONTENT_URL mit einer relativen URL definieren, dann beim Einfügen von Dateien in Beiträge die relative URL für die Quelle anstelle der absoluten URL verwendet wird . Genau das, was ich schon immer wollte! Aber die offizielle WordPress-Dokumentation sagt, dass Sie a verwenden sollten Vollständiger URI wenn Sie WP_CONTENT_URL definieren.

WordPress-Codex sagt:

Setze WP_CONTENT_URL auf die Vollständiger URI dieses Verzeichnisses (kein abschließender Schrägstrich), zB

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');

Alles scheint gut zu funktionieren, wenn ich eine relative URL verwende, z

define( 'WP_CONTENT_URL', '/my-content-folder');

Aber gibt es ein Problem bei der Verwendung eines relativen URI? Ich denke nur, dass es einen Grund für WordPress geben muss, der besagt, dass es mit einem vollständigen URI definiert werden sollte.

Ich denke, das ist die Art von Frage, die nur ein Core-Entwickler beantworten könnte/sollte. Ich habe recherchiert und das Kernticket Nr. 17048 gefunden: An den Browser gelieferte URLs sollten root-relativ sein. Wo wir die Gründe finden können, die von Andrew Nacin, Lead Core Developer, erklärt wurden. Er verlinkt auch Das [wp-hackers] Gewinde. Auf diesen beiden Links sind dies die wichtigsten Zitate darüber, warum WP keine relativen URLs verwendet:

Kernticket:

• Root-relative URLs sind nicht wirklich richtig. /path/ möglicherweise nicht WordPress, möglicherweise außerhalb der Installation. Es ist also wirklich nicht viel anders als eine absolute URL.

• Jegliche relative URLs erschweren außerdem die Durchführung von Transformationen erheblich, wenn die Installation verschoben wird. Das Suchen-Ersetzen wird in den meisten Situationen notwendig sein, und aus diesen Gründen ist es ironischerweise besser, eine absolute URL zu haben.

• An zahlreichen anderen Stellen werden absolute URLs benötigt. Wenn Sie diese bedingt hinzufügen müssen, wird dies zur Verarbeitung beitragen und potenzielle Fehler (und Inkompatibilitäten mit Plugins) einführen.

[wp-hackers] Gewinde

• In Bezug auf was bin ich mir nicht sicher, da sich WordPress oft in einem Unterverzeichnis befindet, was bedeutet, dass wir den Inhalt immer verarbeiten müssen, um dann den Rest des Pfads hinzuzufügen. Dies führt zu Overhead.

• Denken Sie daran, dass es zwei Arten von relativen URLs gibt, mit und ohne führenden Schrägstrich. Beide haben Einschränkungen, die eine ordnungsgemäße Implementierung unmöglich machen.

• WordPress sollte (und tut) absolute URLs speichern. Dies erfordert keine Vorverarbeitung des Inhalts, keinen Overhead, keine Mehrdeutigkeit. Wenn Sie umziehen müssen, ist es ein globales Suchen-Ersetzen in der Datenbank.

Und persönlich habe ich mehr als einmal gefunden, dass Themes und Plugins schlecht codiert sind, wenn sie einfach kaputt gehen WP_CONTENT_URL ist definiert.
Sie weiß nicht Dies kann eingestellt werden und davon ausgehen, dass dies wahr ist: WP.URL/wp-content/WhatEver, und das ist nicht immer der Fall. Und unterwegs wird etwas kaputt gehen.

Das Plugin Relative URLs (verlinkt edse‘s Answer), wendet die Funktion an wp_make_link_relative in einem Reihe von Filtern im Aktionshaken template_redirect. Es ist ein ziemlich einfacher Code und scheint eine nette Option zu sein.

<?php wp_make_link_relative( $link ) ?>

Vollständige URL-Pfade in relative Pfade umwandeln.

Entfernt die http- oder https-Protokolle und die Domäne. Behält den Pfad „https://stackoverflow.com/“ am Anfang bei, also ist es kein echter relativer Link, sondern von der Web-Root-Basis.

Referenz: WordPress-Kodex

Ich habe es auf meiner Website gelöst, indem ich dies in functions.php gemacht habe

add_action("template_redirect", "start_buffer");
add_action("shutdown", "end_buffer", 999);

function filter_buffer($buffer) {
    $buffer = replace_insecure_links($buffer);
    return $buffer;
}
function start_buffer(){
    ob_start("filter_buffer");
}

function end_buffer(){
    if (ob_get_length()) ob_end_flush();
}

function replace_insecure_links($str) {

   $str = str_replace ( array("http://www.yoursite.com/", "https://www.yoursite.com/") , array("https://stackoverflow.com/", "https://stackoverflow.com/"), $str);

   return apply_filters("rsssl_fixer_output", $str);

}

Ich habe an einem Plugin teilgenommen, es in Stücke geschnitten und daraus gemacht. Es ersetzte ALLE Links auf meiner Seite (Menüs, CSS, Skripte etc.) und alles funktionierte.

Ich stimme Rupi zu. Ich denke, der Hauptgrund ist, Verwirrung bei relativen Pfaden zu vermeiden. Ich denke, WordPress kann mit relativen Pfaden von Grund auf neu arbeiten, aber das Problem kann auftreten, wenn mehrere Plugins verwendet werden, wie das Thema konfiguriert ist usw.

Ich habe dieses Plugin einmal für relative Pfade verwendet, als ich an Testservern gearbeitet habe:

Root-relative URLs
Wandelt alle URLs in Root-relative URLs um, um dieselbe Website auf mehreren IPs zu hosten, die Produktionsmigration zu vereinfachen und das Testen mobiler Geräte zu verbessern.

Ich habe immer nur verwendet get_site_url(). Zum Beispiel:

<img src="<?=get_site_url();%20?>/wp-content/uploads/2021/05/[email protected]" />

Unter Einstellungen => Medien gibt es eine Option für ‘Vollständiger URL-Pfad für Dateien’. Wenn Sie dies auf den standardmäßigen Medienverzeichnispfad „/wp-content/uploads“ anstelle von leer setzen, werden relative Pfade eingefügt, z. B. „/wp-content/uploads/2020/06/document.pdf“.

Ich bin mir nicht sicher, ob es alle Links relativ macht, zB zu Beiträgen, aber zumindest handhabt es Medien, was wahrscheinlich das ist, worüber sich die meisten Leute Sorgen machen.

sollte get_home_url() verwenden, dann sind Ihre Links absolut, aber es hat keinen Einfluss, wenn Sie die Site-URL ändern