Quelle est la différence entre get_home_path()
et ABSPATH
? N'est-ce pas l'intérêt des deux de pointer vers la racine d'installation de WordPress?
Quelle est la différence entre get_home_path()
et ABSPATH
? N'est-ce pas l'intérêt des deux de pointer vers la racine d'installation de WordPress?
Réponses:
Ils devraient faire la même chose, mais dans certaines conditions, ils pourraient ne pas le faire.
Tout d'abord, notez:
wp-admin/includes/file.php
doit être inclus dans le contexte sinon l'appel get_home_path()
conduira à l'appel d'une fonction non définie.Concernant l'entrée du codex,
La description
Obtenez le chemin absolu du système de fichiers à la racine de l'installation de WordPress.
Valeur de retour
Chemin d'accès complet du système de fichiers à la racine de l'installation de WordPress. Si vous installez wordpress dans un sous-dossier, il affichera l'emplacement du sous-dossier
Exemples
$path = get_home_path(); print "Path: ".$path; // Return "Path: /var/www/htdocs/" or "Path: /var/www/htdocs/wordpress/" if it is subfolder
Il indique que la valeur de retour renverra le chemin du sous-dossier si vous avez installé WordPress dans un sous-répertoire. C'est en fait incorrect.
get_home_path()
retournera le répertoire racine de votre installation WordPress, même s'il est installé dans un sous-répertoire. C'est le but de la fonction.
Supposons que votre installation WordPress se trouve dans un sous-répertoire appelé /dev
,
site_url
) (par exemple / var / www / htdocs / dev)home_url
)Si vous connectez un appel à ABSPATH
, alors le résultat sera, /var/www/htdocs/dev
qui n'est pas la racine de votre installation. La racine de votre installation est /var/www/htdocs
.
ABSPATH
est d'abord défini dans wp-load.php
lequel sera situé à d' /var/www/htdocs/dev/wp-load.php
où c'est d'où ABSPATH
prendra sa définition.
Si vous inspectez get_home_path()
plus loin, vous remarquerez que si le site_url
et home_url
diffèrent, alors une sous-chaîne est prise du chemin régi par la position (première occurrence) du sous-répertoire trouvé dans la chaîne.
function get_home_path() {
$home = set_url_scheme( get_option( 'home' ), 'http' );
$siteurl = set_url_scheme( get_option( 'siteurl' ), 'http' );
if ( ! empty( $home ) && 0 !== strcasecmp( $home, $siteurl ) ) {
$wp_path_rel_to_home = str_ireplace( $home, '', $siteurl ); /* $siteurl - $home */
$pos = strripos( str_replace( '\\', '/', $_SERVER['SCRIPT_FILENAME'] ), trailingslashit( $wp_path_rel_to_home ) );
$home_path = substr( $_SERVER['SCRIPT_FILENAME'], 0, $pos );
$home_path = trailingslashit( $home_path );
} else {
$home_path = ABSPATH;
}
return str_replace( '\\', '/', $home_path );
}
Par conséquent, à la suite de cela, get_home_path()
et ABSPATH
peut retourner des résultats différents si WordPress est installé dans un sous-répertoire.
Deuxièmement, l'appel get_home_path()
doit se faire dans un contexte où ce qui précède wp-admin/includes/file.php
a déjà été inclus.
À titre d'exemple, utiliser get_home_path()
dans le admin_init
crochet est très bien là où ne pas l'utiliser init
.
Étant donné que ce fichier n'est inclus qu'à partir du contexte d'administration (tableau de bord), si vous en avez absolument besoin en dehors de ce contexte, vous devrez inclure le fichier vous-même avant d'appeler la fonction,
require_once(ABSPATH . 'wp-admin/includes/file.php');
Ironiquement (ou non) qui utilise ABSPATH
: D
$_SERVER['DOCUMENT_ROOT']
ses problèmes ... par exemple, peut ne pas être défini ou défini correctement et ainsi de suite. Il y a d'autres moyens auxquels je peux penser aussi pour gérer cela ... Chacun avec ses propres mises en garde. Beaucoup de plaisir :)
/var/apps/wordpress
au lieu de/var/www/htdocs
. Utilisez plutôt$_SERVER['DOCUMENT_ROOT']
, au moins si vous pouvez vous assurer que la racine du document ne changera pas.