Créer une ancre dans un article avec WordPress

Voici un exemple pris ici: http://pclinuxos-fr.org/2010/10/23/installer-pclinuxos-2010/

Ensuite, rendez-vous à la section « <a href="#grub">Installation du chargeur de démarrage</a> », quelques images plus bas.

et voici la section en question, précédée de l’ancre mentionnée ci-dessus

<a name="grub"></a>
<h4>Installation du chargeur de démarrage</h4>

Merci à grosbedos pour cette trouvaille.

Attention aux htaccess piégés

Cela s’est passé sur le site PCLinuxOS Fr, que j’administre, et qui est sous WordPress. C’était aujourd’hui. Il pleuvait à verse presque toute la journée, et une fête médiévale avait lieu non loin de chez moi. Je ne manquais pas d’y faire un tour, afin d’admirer les commerçants costumés derrière leurs stands en forme d’échoppes, regardant défiler les passants armés de parapluies, puis je me dis que je ferais aussi bien un tour sur un de «mes» blogs entre autres choses.

Un petit aparté, ne manquez pas de lire comment l’on bloguait au Moyen Âge, sur le blog de C’est bon pour ton poil… Oncques ne vit céans poindre la bobinette

Pour en revenir à mon mouton noir, la mésaventure que je viens de vivre n’a pas duré bien longtemps, grâce à une recherche sur le web et à ce fil sur le forum wordpress.org anglophone : brend-store.ru hijacked my site via a plugin. Le problème venait d’un .htaccess piégé.

Cependant, je ne me suis rendue compte du forfait que à l’occasion de mises à jour à faire, parce que quand je voulais accéder à l’administration de la section extensions, je me retrouvais immanquablement sur un site vers lequel mon navigateur était redirigé (mais qui a dû fermer depuis car une page blanche m’accueillait, au lieu de la page de mes «plugins»). De même, la page du Tableau de bord était redirigée vers ce site.

Un plugin défectueux, détecté quelques temps plus tôt grâce à l’aide des administrateurs de Tuxfamily, avait ouvert une faille et permis la mise en place de scripts divers, détectés depuis et supprimés, sauf un : le .htaccess utilisé à la racine du site comportait des redirections. L’astuce de l’attaquant avait été simple, il avait placé ses commandes à plusieurs dizaines de lignes du haut du fichier, quasiment en bas, et à droite. Il fallait simplement penser à regarder plus loin que les premières lignes.

Conclusion, si votre site internet se comporte d’une manière anormale, s’il vous envoie vers des pages de sites que vous n’avez à priori pas demandé, et que votre site emploi les .htaccess, pensez à les vérifier !

 

 

Passage à la version 3.1.3

Sur un des sites que j’administre, après avoir tenté de mettre WordPress à jour en mode automatique, je me suis retrouvée à la porte, avec ce message:

Fatal error: Call to undefined function is_multisite() in /data/web/fa/22/2b/pclinuxos-fr.org/htdocs/wp-includes/default-constants.php on line 20

Si cela vous arrive, la solution est simple. Je rappelle d’abord les règles de prudence avant de mettre à jour, pour tous les cas : faire une sauvegarde par le fichier xml (depuis l’administration : Outils > Exporter), par la base de données (phpmyadmin, et si vous l’avez installé, par le plugin pour WordPress « phpmyadmin »), et téléchargez le contenu complet du répertoire « wp-content », ainsi qu’une copie de votre fichier .htaccess et de votre fichier wp-config.php. (On n’est jamais trop prudent). Si vous l’avez déjà fait lors d’une précédente mise à jour et que vous n’avez par ajouté beaucoup de contenu à votre site, un simple export xml peut suffire.

Pour la mise à jour depuis une version neuve de WordPress, vous vous connecterez à votre site depuis un client FTP (File Transfer Protocol), par exemple, sftp, ou lftp (en console), ou encore Filezilla ou Gftp. (Filezilla est un des meilleurs client ftp en mode graphique).

Vous commencerez par désactiver tous vos plugins dans l’administration du site. Puis vous vous connecterez sur le site distant à l’aide de votre client ftp.

Une fois connecté, supprimez tout sauf : le répertoire wp-content, le fichier .htaccess et le fichier wp-config.php. Une fois les suppressions effectuées, positionnez-vous depuis votre disque dur (partie gauche du client ftp dans Filezilla) dans un répertoire wordpress fraîchement désarchivé (je dis bien positionnez-vous dedans !) et copiez tout vers la racine de votre site. Si vous recevez des messages demandant si le nouveau fichier doit écraser le fichier distant (il s’agit de fichiers identiques dans les répertoires local et distant « wp-content ») dites oui pour tous. (cochez les cases qui_vont_bien dans la fenêtre du message)

N’oubliez pas de réactiver vos extensions après l’opération. 🙂

 

Importer vos liens depuis un autre WordPress

Pour bien faire, l’idéal est de pouvoir emporter avec soi sa liste de liens, les catégories de liens et les relations qui existent entre eux. Depuis un site WordPress vers un autre site WordPress c’est possible sans trop de peine, en important juste les tables de la base de données dont vous avez besoin, et pas plus.

Imaginez que pour éviter de ramener avec vous tout un tas d’entrées inutiles dans la base de données, ou pour toute autre raison vous ayez importé vos articles, pages, commentaires, depuis un export au format xml. En ce cas il vous manque certaines données que vous n’avez sans doute pas envie de recréer fastidieusement à la main.

Pour importer uniquement les liens, il faut exporter les tables suivantes depuis le site d’origine : si votre préfixe de tables est wp_, ce seront les tables wp_links, wp_terms, wp_term_relationship et wp_term_taxonomy. Pour faire cela, dans phpMyadmin il faut se rendre dans la section « export », déselectionner toutes les tables sélectionnées par défaut et resélectionner juste les tables souhaitées (le maintien simultané de la touche Ctrl et de la sélection avec la souris peut aider à sélectionner une à plusieurs tables précises). Puis, exporter dans un format archivé (zip par exemple).

Une fois ces tables exportées, si par hasard le préfixe dans les sites source et site destination ne sont pas les mêmes, il faut les changer. Par exemple, sur le site source les noms sont du style abc123_terms et dans le site de destination, les noms de table sont plutôt xyz98_terms, il vous faut effectuer un remplacement à l’aide de la fonction « remplacer » de votre éditeur de textes.

Une fois les remplacements effectués, sauvegardez votre modification, supprimez les tables correspondantes (drop) dans l’interface mysql du site de destination (par exemple dans l’interface de gestion phpMyAdmin) avant d’importer les tables du site d’origine.

Si vous voulez importer d’autres tables dans lesquelles des liens en dur sont susceptibles d’être inscrits (par exemple, une galerie d’images), pensez à vérifier et si nécessaire faire les remplacements de la même manière.

Et voilà !

Sécurité par le .htaccess

Suite au précédent article, que faudrait-il ajouter à la racine du site, dans le fichier .htaccess ?

Options All -Indexes

<FilesMatch ^wp-config.php$>
deny from all
</FilesMatch>

La première ligne interdit l’accès aux listes des fichiers relatifs aux répertoires du moteur WordPress, les lignes suivantes protègent le fichier de configuration du site.

 

WordPress en multisites

Installer ou transformer, en résumé, ça se fait en deux temps. Pour le premier temps, éditez le fichier wp-config.php et ajoutez une ligne contenant

define('WP_ALLOW_MULTISITE', true);

avant

/* C'est tout, ne touchez pas à ce qui suit ! Bon blogging ! */

Une fois que c’est fait et que vous avez sauvegardé votre modification et renvoyé le fichier modifié à la racine du site, retournez dans l’administration.

(suite…)