Matt Biscay: développeur WordPress et WooCommerce pour SkyMinds
Ajouter un nouveau site WordPress dans un répertoire, sans conflit avec le site principal photo

Nginx : créer un nouveau site WordPress dans un sous-répertoire, sans conflit avec le site principal

Dernièrement, j’ai développé un nouveau site WordPress pour une cliente dont l’hébergement ne prévoit pas de staging site, ce qui est un peu ballot.

Plutôt que d’utiliser son hébergeur, je me suis dit que j’allais travailler sur la nouvelle version depuis un répertoire sous SkyMinds.

Le problème s’est assez rapidement posé : les diverses règles de configuration de SkyMinds (à la racine du domaine) entrent en conflit avec le nouveau site qui se trouve dans un répertoire. Il est donc nécessaire d’ajuster la configuration du bloc serveur NginX.

J’ai bien sûr effectué quelques recherches sur le net et après moults tests, il s’avère que la plupart des configurations nginx que l’on y trouve sont erronées. En relisant les docs, j’ai fini par trouver une solution satisfaisante.

Des erreurs 404, 403 ou 500

Je mentionnais à l’instant les configurations erronées – elles ne permettent pas au nouveau site d’afficher les pages correctement : erreur 404 pour les pages, erreur 404 pour la partie administration ou alors erreur 403 ou même 500…

Le plus surprenant est que l’on retrouve quasiment ces mêmes configurations dans tous les tutoriels. Cela fonctionnait peut-être à une époque mais plus maintenant avec les dernières versions de WordPress et NginX.

La configuration qui fonctionne

Voici donc la configuration que j’ai concoctée et qui permet d’avoir un autre site WordPress (comme par exemple https://example.com/nouveau-site/) lorsqu’un site WordPress (de type https://example.com) existe déjà à la racine du domaine. Le but est donc d’avoir deux sites fonctionnels qui n’entrent pas en conflit au niveau de la gestion des règles.

On édite le server block de notre domaine :

nano /etc/nginx/sites-available/example.com

Dans la partie server de la configuration, on ajoute :


# Script name : Add new WP site in subfolder
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=29604

# Add new location point with rewrite rule
location @nouveausite{
rewrite . /nouveau-site/index.php last;
}

# Add subfolder config
location  /nouveau-site {
         root /home/example/public_html/nouveau-site;
         index index.php;
         try_files $uri $uri/ @nouveausite;
}

Sauvegardez le fichier. On teste la nouvelle configuration:

nginx -t

et on relance nginx et PHP:

service nginx restart 
service php7.2-fpm restart

Et voilà, le nouveau site dans son répertoire devrait maintenant être fonctionnel, sans conflit avec le site principal.

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Lire la suite

Nouveau logo pour SkyMinds (version 2018) photo

Nouveau logo pour SkyMinds (version 2018)

Aujourd’hui, le logo de SkyMinds fait peau neuve ! Plus discret, plus moderne aussi. J’en ai profité pour mettre en place toute une liste de modifications cosmétiques que j’ai trop longtemps repoussées.

Nouveau logo pour SkyMinds (version 2018) photo
Nouveau logo !

Mise à jour des templates du thème enfant

L’avantage d’un thème enfant sous WordPress, c’est que l’on ne perd pas ses modifications lorsque le thème parent se met à jour. Le thème enfant, c’est tout simplement la base, l’étape qui vient juste après l’installation d’un nouveau thème.

Or, au fil des mois ans, il se trouve que le thème parent évolue et que les fichiers du thème enfant (modifiés) ne sont plus exactement à jour. J’en ai donc profité pour reprendre les nouveaux fichiers et y apporter mes modifications.

Concaténation des appels des fichiers de police

En analysant les fichiers du thème, je me suis rendu compte qu’on pouvait gagner pas mal de temps de chargement grâce à une épuration du nombre de polices utilisées sur le site. Au lieu d’en avoir deux (Open Sans et Droid Sans), il n’y en aura plus qu’une : Open Sans. Elle est légère, classique et facile à lire.

Le problème, c’est que Divi charge pas mal de versions de cette police par défaut : 300, 400, 700… en normal, italic et gras et avec des subsets exotiques comme le cyrillique, le grec ou le vietnamien. Clairement, on doit pouvoir mieux faire !

Divi : suppression des subsets Google Fonts

On commence par virer les subsets exotiques. Rendez-vous dans Divi > Theme options > General > désactivez Google Fonts subsets. Vous venez d’économisez 400KB.

Divi : suppression de toutes les Google Fonts et chargement de l’unique nécessaire

C’est pénible d’avoir tous les grammages d’une police chargés pour rien. Voici ce que j’utilise pour tout virer dans un premier temps, puis ajouter uniquement ce dont j’ai réellement besoin:

/*
|-----------------------------------------------------------------------
| Plugin Name: Sky Remove DIVI Google Fonts and add what we need
| Plugin URI:  https://www.skyminds.net/?p=29578
| Author:  Matt Biscay
| Author URI:  https://www.skyminds.net/
|-----------------------------------------------------------------------
*/

// remove all Divi fonts, we'll just load what we need
// @return: array
function et_builder_get_google_fonts() { return array(); }
function et_get_google_fonts() { return array(); }

// add fonts : logo (Comfortaa:700) and site (Open+Sans:400,700). No subsets.
add_action( 'wp_enqueue_scripts', 'sky_logo_add_google_fonts' );
function sky_logo_add_google_fonts() {
	wp_enqueue_style( 'sky-logo-google-fonts', 'https://fonts.googleapis.com/css?family=Comfortaa:700|Open+Sans:400,700', false ); 
}

Kaboom! On vient de se retirer une sacrée épine du pied. Il faudra juste relire la feuille de style pour être sûr que l’on utilise bien soit du font-weight 400 (regular), soit du 700 (bold). Pensez également à vérifier votre critical CSS.

Amélioration de la section Auteur

A la fin de chaque article se trouve la section de l’auteur, qui comprend une courte description ainsi que des liens vers ses profils sociaux. J’ai profité de la police du thème pour remplacer les noms des réseaux par des icônes. C’est purement cosmétique mais je trouve cela plus joli.

Cela m’a permis de me rendre compte que le site n’utilise absolument pas Font Awesome – ce que je trouve totalement fou. J’aime tellement cette police que j’ai acheté la version professionnelle pour mes développements… et ne l’utilise pas moi-même !

J’ai troqué le bleu clair pour un beige. A voir sur la durée.

Nouveau logo

Et enfin, last but not least, j’ai troqué mon logo image contre un logo font. Cela faisait pas mal de temps qu’il me trottait dans la tête l’idée de le changer. J’ai d’abord commencé, comme d’habitude, par tenter de créer des logos images avant de changer mon fusil d’épaule et considérer la possibilité d’utiliser une Google Font pour le générer à la volée.

Après quelques recherches, j’ai finalement opté pour la police Comfortaa en 700. C’est plutôt moderne par rapport au logo précédent qui avait la particularité d’être un dégradé de plusieurs couleurs (rose, violet, bleu, vert), avec des ligatures à certaines lettres.

Celui-ci sera donc beaucoup plus clean et professionnel. Je pense d’ailleurs le réutiliser sur d’autres supports de personal branding.

Lire la suite

WordPress : afficher des média oEmbed avec HTTPS photo

WordPress : forcer le chargement des média oEmbed en HTTPS

Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.

Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.

Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.

Servir les vidéos Youtube en HTTPS

Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.

J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.

Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.

Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).

Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :

<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) { 
  return preg_replace( '@src="https?:@', 'src="', $html );
}

Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :

<?php
//BEGIN Embed Video Fix - HTTPS and privacy mode
//https://wordpress.org/support/topic/forcing-ssl-return-for-youtube-oembed

add_filter('the_content', 'sky_add_secure_video_options', 10);
function sky_add_secure_video_options($html) {
   if (strpos($html, "<iframe" ) !== false) {
    	$search = array('src="http://www.youtube.com','src="http://youtube.com');
	$replace = array('src="https://www.youtube-nocookie.com','src="https://www.youtube-nocookie.com');
	$html = str_replace($search, $replace, $html);
   	return $html;
   } else {
        return $html;
   }
}

Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.

Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.

WordPress : changer le mot de passe d'un utilisateur depuis le serveur SQL photo

WordPress : changer le mot de passe d’un utilisateur depuis le serveur SQL

Il peut être nécessaire de changer le mot de passe d’un utilisateur WordPress par exemple lorsque l’on migre un compte, lorsque l’on repart de zéro avec une base de données vierge ou lorsque le mot de passe du site de développement diffère de celui du site de production.

Ou tout simplement pour en mettre un plus facile à retenir.

Voici donc comment changer le mot de passe d’un utilisateur WordPress directement depuis un terminal connecté sur le serveur de la base de données.

Changer le mot de passe d’un utilisateur WordPress depuis MariaDB

1. Connectez-vous au serveur de base de données :

mysql -u root -p

puis entrez votre mot de passe :

Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

2. Sélectionnez la base de données qui contient l’installation WordPress concernée :

USE wordpress_wpdb;

Résultat :

Database changed

3. Vérifiez que votre utilisateur (ici : matt) est bien présent dans la base :

SELECT ID, user_login, user_pass FROM wp_users WHERE user_login LIKE '%matt%';

Résultat:

+----+-------------+------------------------------------+
| ID | user_login  | user_pass                          |
+----+-------------+------------------------------------+
| 78 | matt                | $P$BUZ6Uvu8aie2tBEWqwTu07qfzlKXc80 |
+----+-------------+------------------------------------+
1 row in set (0.00 sec)

4. Choisissez un mot de passe (ici: q8U@jM5uNMa*R66R), qui sera automatiquement chiffré en MD5 :

UPDATE wp_users SET user_pass = MD5('q8U@jM5uNMa*R66R') WHERE ID=78 LIMIT 1;

Résultat:

Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Lire la suite

PoEdit : mettre à jour les fichiers de traduction de vos thèmes et plugins WordPress photo

PoEdit : mettre à jour les fichiers de traduction de vos thèmes et plugins WordPress

Sous WordPress, il est très simple de traduire les thèmes et plugins grâce au logiciel PoEdit et à un fichier de langue au format .pot ou .po – mais qu’advient-il de vos traductions lorsque le plugin ou thème est mis à jour avec de nouvelles chaînes?

Mettre à jour votre fichier de traduction avec PoEdit

Et bien, il suffit tout simplement de resynchroniser votre fichier de traduction avec le fichier de traduction modèle, généralement au format .pot pour ajouter à votre fichier les chaines manquantes.

1. Dans PoEdit, ouvrez votre fichier de traduction au format .po

2. Ouvrez le menu Catalog > Update from POT file et sélectionnez le fichier POT de votre thème ou plugin mis à jour.

Cela ajoute toutes les nouvelles chaines à traduire dans votre fichier de traduction et retire les chaines obsolètes.

3. Traduisez les nouvelles chaines qui viennent d’être ajoutées.

4. Sauvegardez votre fichier et pensez à exporter vos traductions en .mo également. Vous devriez toujours avoir vos traductions en .po et .mo

5. Pour ne pas que vos traductions soient écrasées à la prochaine mise à jour du thème ou plugin, elles sont à placer dans le dossier :

  • wp-content/languages/themes pour les thèmes
  • wp-content/languages/plugins pour les plugins

Voilà, les traductions de votre thème ou plugin sont maintenant à jour.

WordPress : résoudre l'erreur

WordPress : installer des plugins et thèmes sur un site de développement local

WordPress : récupérer la liste emails des membres et commentateurs photo

Lorsque vous installez WordPress en local sur votre machine, il est assez courant que les droits des fichiers et dossiers ne permettent pas d’entrée de jeu d’installer ou de mettre à jour des plugins ou des thèmes.

Voici comment résoudre ce problème en quelques minutes.

Passage au système de fichier direct

1. On commence par éditer notre fichier wp-config.php, qui contient pas mal de constantes primordiales pour WordPress:

nano wp-config.php

2. On y rajoute, vers le haut du fichier, une constante qui passe le système de fichier en mode direct:

define('FS_METHOD', 'direct');

Sauvegardez votre fichier wp-config.php. Les fichiers de thèmes et de plugins seront désormais directement installés sans que la popup demandant des informations FTP ou SSH ne s’affiche.

Vérification des droits des fichiers et répertoires

En local, par contre, ce sera un petit peu différent : l’utilisateur www-data (Apache ou NginX) doit pouvoir gérer les fichiers mais si vous souhaitez éditer des fichiers, ce qui est quand même le but d’une installation en locale, il faut que votre utilisateur puisse aussi gérer et avoir le droit d’écriture sur les fichiers.

1. Tout d’abord, on donne les droits à Apache à tous les fichiers et dossiers de l’installation WordPress :

sudo chown www-data:www-data -R /home/matt/www/

2. J’ajoute ensuite mon utilisateur de session, matt, dans le groupe www-data (Apache):

sudo usermod -aG www-data matt

3. On vérifie que l’utilisateur matt fait bien partie du groupe www-data :

groups matt

Cela nous retourne la liste de tous les groupes auquel j’appartiens :

matt : matt adm lp dialout fax cdrom floppy tape audio dip www-data video plugdev fuse lpadmin netdev admin sambashare vboxusers usb bluetooth scanner

4. On stipule que l’utilisateur matt est propriétaire de ces fichiers :

sudo chown matt:www-data -R /home/matt/www/

5. On assigne les permissions standard de WordPress, chmod 755 pour les répertoires et chmod 664 pour les fichiers, le tout en mode récursif pour n’oublier personne :

cd /home/matt/www
sudo find . -type d -exec chmod -R 750 {} \;
sudo find . -type f -exec chmod -R 640 {} \;

Vous pouvez maintenant installer thèmes et plugins en local et être en mesure d’éditer vos fichiers avec votre utilisateur linux, sans problèmes de droits.

Subversion : ajouter et mettre à jour un plugin WordPress sur le dépôt officiel photo

Subversion : ajouter et mettre à jour un plugin WordPress sur le dépôt officiel

wordpress-svn-logo

De temps en temps, je mets mes plugins WordPress sur le dépôt officiel mais j’utilise assez rarement subversion – connu également sous le doux nom svn – et j’ai tendance à en oublier la syntaxe.

Voici donc un petit aide-mémoire pour l’utilisation de subversion avec les plugins WordPress.

Ajouter un plugin sur le dépôt officiel WordPress

1. On crée un répertoire local sur notre machine pour y accueillir notre projet:

mkdir my-local-dir

2. On synchronise le dépôt avec un check-out en donnant le slug du plugin:

svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir

Résultat:

> A	my-local-dir/trunk
> A	my-local-dir/branches
> A	my-local-dir/tags
> Checked out revision 1135625.

Subversion vient d’ajouter ( “A” signifie “add” ) tous les répertoires du dépôt central à notre copie locale.

3. On copie tous les fichiers du plugin dans le répertoire trunk/:

cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt

4. On prépare l’ajout des fichiers du plugin au dépôt central:

my-local-dir/$ svn add trunk/* assets/*
> A	trunk/my-plugin.php
> A	trunk/readme.txt

5. On donne un message à notre check-in et on envoie les fichiers au dépôt central :

my-local-dir/$ svn ci -m 'Adding first version of my plugin'
> Adding	trunk/my-plugin.php
> Adding	trunk/readme.txt
> Transmitting file data .
> Committed revision 1135626.

Voilà, vous venez d’ajouter votre plugin au dépôt officiel de WordPress !

Supprimer un fichier sur le dépôt

Pour supprimer un fichier sur le dépôt, il faut supprimer le fichier avec svn delete puis commettre les changements avec svn commit. C’est lors du commit que le fichier est supprimé du dépôt :

svn delete myfile
> D         myfile

svn commit -m "Deleted file 'myfile'."
> Deleting       myfile
> Transmitting file data .
> Committed revision 1135629.

Lire la suite

WordPress : récupérer la liste emails des membres et commentateurs photo

Résoudre les lightbox vides dans l’administration WordPress

Le problème : des iframes entièrement vides dans l’interface d’administration WordPress

Wordpress icon

Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.

C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.

Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.

J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.

Et puis cette semaine, eurêka !

La solution : la configuration Apache du serveur

J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :

[quote class=”center”]Load denied by X-Frame-Options…. X-Frame-Options does not permit framing.[/quote]

Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :

Header always set X-Frame-Options DENY

Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).

Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.

Lire la suite

WordPress : afficher les accents dans des blocs texte colorisés par Crayon Syntax Highlighter photo

WordPress : afficher les accents dans des blocs texte colorisés par Crayon Syntax Highlighter

Jusqu’à très récemment, il m’était tout à fait possible d’avoir des caractères accentués dans des blocs de texte sous WordPress en utilisant le plugin Crayon Syntax Highlighter pour coloriser le code.

crayon-syntax-highlighter

Or depuis quelques temps tous les blocs en lang="text" ne permettent plus d’afficher les accents : je me retrouve avec des mots tronqués comme si le texte n’était pas encodé en UTF-8.

Problème : des caractères non-Unicode

Voici ce que donne la phrase “j’ai mangé une tarte à la crème à Noël” avec une colorisation par défaut avec Crayon Syntax Highlighter :

J'ai mangé une tarte à la crème à Noël.

Gloups! C’est totalement illisible, les accents deviennent un caractère mal encodé et certaines lettres adjacentes sont littéralement supprimées. Pas glop.

Solution : créer un alias

La solution que je propose est plus une rustine d’appoint qu’une véritable solution.

Je pense que le problème réside dans l’expression régulière des langages du plugin : certains langages (shell par exemple) n’acceptent pas les accents alors que d’autres (HTML par exemple) oui.

Je me suis rendu compte en changeant la langue du bloc que le langage batch affichait correctement les accents.

Comme je n’allais pas éditer tous mes articles pour changer le langage des blocs texte que j’ai utilisé jusqu’à maintenant, j’ai opté pour la création d’un alias.

Lire la suite

WordPress : valider le code des meta oEmbeds de YouTube, DailyMotion, Vimeo et SlideShare photo

WordPress : valider le code des meta oEmbeds de YouTube, DailyMotion, Vimeo et SlideShare

Allez, je continue ma petite série sur la gestion de l’intégration oEmbed sous WordPress.

WordPress gère nativement plusieurs services : copiez-collez l’adresse d’une vidéo YouTube dans un article et hop, vous obtenez une vidéo entièrement intégrée, avec un code plutôt propre mais pas entièrement valide.

oembed-all-service

Je vous propose donc de valider le code généré par WordPress lorsqu’il vient de sites tiers comme YouTube, DailyMotion, Vimeo ou SlideShare.

Valider le code oEmbed de YouTube

Il suffit de lancer les quatre requêtes SQL suivantes :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" allowfullscreen', 'style="border: none"');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" allowfullscreen', 'style="border: none"');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, "wmode=transparent' frameborder='0'", "wmode=transparent' style='border: none'");
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, "wmode=transparent' frameborder='0'", "wmode=transparent' style='border: none'");

Valider le code oEmbed de Dailymotion

Pour le code de Dailymotion, ces deux requêtes suffisent :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0">', 'style="border: none">');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0">', 'style="border: none">');

Valider le code oEmbed de Vimeo

Quatre requêtes pour Vimeo :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" title=', 'title=');
UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, ' webkitallowfullscreen mozallowfullscreen allowfullscreen', '');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" title=', 'title=');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, ' webkitallowfullscreen mozallowfullscreen allowfullscreen', '');

Valider le code oEmbed de SlideShare

Et deux requêtes pour SlideShare :

UPDATE wp_postmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen>', 'style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px;overflow:auto;border:none">');
UPDATE wp_commentmeta SET meta_value = REPLACE (meta_value, 'frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px" allowfullscreen webkitallowfullscreen mozallowfullscreen>', 'style="border:1px solid #CCC;border-width:1px 1px 0;margin-bottom:5px;overflow:auto;border:none">');

Et voilà, le code est plus propre, plus valide et utilise CSS plutôt que des balises propriétaires.

WordPress : remplacer le vieux code Dailymotion de vos articles par une URL oEmbed photo 1

WordPress : mettre à jour le code Dailymotion

Cet article est le pendant de l’article pour remplacer le vieux code YouTube de vos articles WordPress par une URL oEmbed mais pour Dailymotion.

Voici donc les manipulations à effectuer pour transformer les vieux codes d’intégration avec les URL oEmbed de WordPress.

Nous utilisons toujours le plugin Search Regex pour WordPress avec la case regex activée et le signe dièse (#) comme délimiteur pour les expressions régulières.

Remplacer les liens swf/video de Dailymotion

J’appelle ces liens “swf/video” parce qu’on retrouve cela dans l’URL de l’intégration Flash. Il vaut mieux lancer cette substitution en premier.

On recherche :

#<object data="http://www.dailymotion.com/swf/video/(.*)" width="300" height="150">(.*)</object>#

et on remplace par :

https://www.dailymotion.com/video/$2

Remplacer les liens swf de Dailymotion

On s’occupe maintenant des liens qui contiennent juste le terme “swf”.

On recherche :

#<object data="http://www.dailymotion.com/swf/(.*)" width="300" height="150">(.*)</object>#

et on remplace par :

https://www.dailymotion.com/video/$2

Voilà, vous venez de nettoyer les anciens codes d’intégration Flash pour les remplacer par des URI oEmbed natives. Propre.