Ce qui me gêne parfois dans WordPress c’est sa structure de fichiers.
Je pense que les urls vers certains fichiers sont moches.
Parfois ça me chagrine d’avoir à faire des pans entiers de redirections lors d’une refonte d’un site lambda vers un site WordPress.
Parfois, j’ai peur en regardant des logs serveurs, entre les tentative d’acces à certains fichiers et d’autres tentative de connexion à l’administration.
Cela me met plus particulièrement en rogne quand ces tentatives font fonctionner toute l’armada en consommant un max de ressources …
Du coups, je me dis qu’au lieu de m’adapter à WordPress, pourquoi je n’adapterais pas WordPress à mes besoins …
Chaque problème sa solution
WordPress prévoit les cas où l’installation serait personnalisé.
Cela se passe via des constantes php à définir dans le fichier wp-config.
Les indications de wp-config sont dans le codex : http://codex.wordpress.org/fr:Modifier_wp-config.php
Mais je me suis heurté à quelques limitations.
Tout d’abord, il faut savoir où l’on se trouve :
WP_HOME vous permet de définir l’adresse url de votre site, c’est l’adresse qui sera visible dans votre navigateur.
WP_SITEURL permet d’indiquer l’adresse ou est physiquement installé WordPress.
On retrouve ces informations dans l’administration, dans Réglage -> Général.
Mais écrire ces constantes permet de prendre le pas sur les autres réglages en base de donnée, vous constaterez après enregistrement de wp-config que les informations ne sont plus modifiables depuis l’administration.
Cela limite le risque que votre client ou vos utilisateurs fassent des bêtises involontaires (ou pas … #faille)
Ensuite une autre constante utile :
WP_CONTENT_DIR vous permet d’indiquer le nom et le chemin du dossier wp-content.
habituellement placé à la racine sous le nom wp-content … Libre à vous donc de le renommer en ‘content’ ou ‘contenu’ ou autre chose.
WP_CONTENT_URL pour l’url …
WP_PLUGIN_DIR et WP_PLUGIN_URL pour le dossier des plugins.
UPLOADS qui permet de définir le chemin relatif à la constante ABSPATH pour accéder au dossier de vos médias.
ABSPATH étant une constante défini par wordpress dans d’autres fichiers, il y’a donc une petite subtilité dans l’écriture du chemin.
Mon projet
En fait, cela fait écho à l’idée de vouloir créer un pack de démarrage.
Quand mon projet neccessite les mêmes actions de départ — Hop Copié-collé — il me suffirait de déployer ma version perso, avec mes préréglages, accessoires, thèmes, plugins etc. …
Premièrement ce que je souhaite c’est mettre les fichiers de WordPress dans un dossier tout en ayant des Urls à la racine.
C’est prévu : http://codex.wordpress.org/fr:Donner_à_WordPress_son_Propre_Dossier
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
define('WP_HOME','http://exemple.fr/');
define('WP_SITEURL','http://exemple.fr/app/');[/pastacode]
Je n’oublie pas de modifier le fichier index.php à la racine pour pointer vers le dossier app/
Question sécurité, on limite les effets de scripts automatiques, qui scannent les répertoires par défauts, et les tentatives de connexions à l’administration. Mais n’importe qui peut voir dans les sources les dossiers …
D’autant plus que certains « motifs » restent et peuvent se retrouvés indexés par des moteurs de recherches, donc de nouveau des scripts automatiques peuvent fonctionner …
Je me mets à modifier le dossier wp-content en ‘content’ que je place également à la racine.
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
define( 'WP_CONTENT_URL', 'http://deg.li/agency/content' );
define( 'WP_CONTENT_DIR', ABSPATH.'/../content/' );[/pastacode]
Petite subtilité, le chemin est relatif à ABSPATH ( dans le dossier app … )
Je change également le dossier des plugins en ‘plugs’ ou ‘add-ons’ à la racine.
Pas vraiment une neccéssité, mais d’un coté je pense me faciliter une possible refonte d’un autre site … et puis d’un autre coté certains plugins font appel à des fichiers que je préfère à cet endroit à défaut d’un autre …
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
define('WP_PLUGIN_URL', 'http://deg.li/agency/plugs');
define('WP_PLUGIN_DIR', ABSPATH.'/../plugs');[/pastacode]
encore une fois le chemin est relatif à ABSPATH …
Par commodité je préfère avoir mon dossier médias à la racine et tant qu’à faire le nommer ‘medias’ plutôt que uploads :
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
define( 'UPLOADS', 'medias' );[/pastacode]
ça ne passe pas — encore la petite subtilité — je rappelle que le chemin est relatif à ABSPATH.
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
define( 'UPLOADS', '../medias' );[/pastacode]
cela me semble bon, pas d’erreur, le dossier est bien crée par WP et les fichier uploadés sont bien dedans … Ce n’est que plus tard que je m’aperçois d’un soucis … Moi qui voulais des urls propre et simplifié me voila avec des urls farfelu : http://exemple.fr/app/../medias/2014/06/chaussettes-vertes.png
En soit ça fonctionne, mais c’est moche et je suis sur que l’on peut trouver d’autres inconvénients …
Je remarque que je me retrouve avec une seule constante, alors que jusqu’à présent les constantes fonctionnait par pairs. J’ai beau chercher je ne trouve pas, je ressort le ebook de Julio Potier (http://boiteaweb.fr/livres-wordpress/tous-les-secrets-wordpress-1-wp-config-php/ — twitter @boiteaweb) Je cherche sur internet, rien, …
Pourtant avant WordPress 3.5 il y’avait dans l’administration deux champs à remplir pour cette fonctionnalité, qu’il n’y a plus maintenant.
Cette option n’a pas vraiment disparu, on peut toujours le réactiver avec un plugin, par exemple : Upload Url and Path Enabler de Grégory Viguier alias Screenfeed ou WP Original Media Path — je n’ai pas cherché si il y en avais d’autre de ce type, ceux-là font le boulot — ils nécessitent d’être activé puis configurer les chemins des dossiers, après ils sont inutiles et peuvent être désactivés …
Pour autant cela ne me convient pas, j’aurais préféré que l’option ne soit pas modifiable via l’administration, d’ailleurs je ne devrais pas avoir à me connecter et devoir activer un plugin ( quoique je pourrais utiliser le dossier mu-plugins pour ne pas avoir à l’activer ) mais aussi ne pas devoir faire appel à la base de donnée …
Concernant le dossier des thèmes, il y’a un petit hic, d’après le codex le chemin d’accès est hardcodé et par conséquent ne peut pas être modifié. Il est défini par rapport au dossier wp-content ( ou son équivalent si modifié via les constantes ).
J’aurais préféré également rapprocher ce dossier de la racine.
On ne peut pas le changer, cependant une fonction permet de déclarer un autre dossier de thèmes :
[pastacode lang= »php » message= » » highlight= » » provider= »manual »]
Dans wp-includes/theme.php
/**
* Register a directory that contains themes.
*
* @since 2.9.0
*
* @param string $directory Either the full filesystem path to a theme folder or a folder within WP_CONTENT_DIR
* @return bool
*/
function register_theme_directory( $directory ) {
global $wp_theme_directories;
if ( ! file_exists( $directory ) ) {
// Try prepending as the theme directory could be relative to the content directory
$directory = WP_CONTENT_DIR . '/' . $directory;
// If this directory does not exist, return and do not register
if ( ! file_exists( $directory ) )
return false;
}
$wp_theme_directories[] = $directory;
return true;
}
/* dans mon cas */
register_theme_directory( ABSPATH.'..'. '/themes' );
[/pastacode]
c’est encore là une sorte de béquille, il ne se substitue pas au dossier originel, d’ailleurs si on le supprime ou le renomme — afin de ne garder que celui que l’on vient de déclarer —Les thèmes disponibles dans le nouveau dossier s’affichent mais il y’a une erreur à l’activation des thèmes…
Là aussi j’aurais préféré une simple constante dans wp-config, plutôt qu’une fonction à placer dans un mu-plugin …
Une remarque sur le sujet ?