Traduire son thème WordPress correctement

Ce post concerne plutôt les développeurs WordPress, les explications sont valables pour les thèmes, les child thèmes, et les plugins WordPress.

La première chose à faire est de bien définir le Text-domain dans le fichier style.css du thème.

Ensuite je propose d’utiliser le plugin LocoTranslate qui permet de créer des .mo et .po (fichiers stockant les traductions) et de traduire les chaines de caractères définit avec « _( » ou « _e( » dans les fichiers PHP du thème.

Je recommande d’enregistrer les fichiers .mo dans le répertoire « wp-content/languages/thème/text-domain-fr_FR.mo ».

Dans LocoTranslate, on définit ceci lors de la création des fichiers de langues. On choisis également si on créé un modèle de base ou si on recherche toutes les chaines de caractères lorsqu’on clique sur synchronisation.

Comment utiliser mes propres flags sur le switcher de langue de Polylang ?

Comme vous surement vous avez pu trouver la documentation officiel pour faire cette modification dans le plugin WordPress Polylang.

Can I use my own flags for the language switcher?

Cependant en Français et mieux expliqué ça donne quoi ?

Vous devez créer un répertoire nommé « polylang » dans le répertoire « wp-content » de WordPress, puis uploader vos images nommées correctement.

Exemple pour le flag Français fr_FR.png ou fr_FR.jpg

Ensuite il faut mettre à jour les réglages de la langue concernée (même sans rien modifier) pour que le plugin prends en compte cette ajout.

Aussi pour ma part je vous conseille de créer un fichier index.php vide pour des raisons de sécurité dans ce nouveau répertoire.

Woocommerce Product_Categories

Les shortcodes du célèbre plugin de WooCommerce pour le CMS WordPress sont bien souvent peu documentés…

Voici la documentation officielle des shortcodes :
https://docs.woocommerce.com/document/woocommerce-shortcodes/

Heureusement quand on est développeur on réussir à deviner ou trouver les attributs les plus complexes.

Parfois, on est même obliger de créer des nouveaux shorcodes pour pouvoir nous offrir plus de possibilités.

Justement, j’ai fait pas mal de recherche sur le shortcode [product_categories]. En effet j’utilise sur un de mes projets le thème Legenda de 8theme.
Impossible de trouver comment ordonner les catégories selon la meta « Order » du terme. Cette meta est modifiée lorsqu’on drag & drop sur l’administration des catégories de produits sur le plugin WooCommerce.

Finalement j’ai trouvé 2 solutions :

  • l’attribut meta_key, permet de définir la meta sur laquel il faut baser le orderby de la requête. [product_categories meta_key= »order » ]
  • soit créer son propre shortcode, pour ça il faut savoir qu’il est possible de définir le orderby, et la meta de la fonction get_terms comme si-dessous :
    (pour les développeurs ou si aucune autre solution fonctionne)$args = array(    ‘taxonomy’ => $taxonomy,
    ‘parent’ => $parent,
    ‘meta_key’ => ‘order’,
    ‘orderby’ => ‘meta_value’,
    ‘order’ => ‘ASC’,
    ‘hide_empty’ => false,
    ‘number’ => 2
    );
    $terms = get_terms($args);

J’espère que ce post pourra vous aider, sinon vous pouvez aussi nous contacter pour nous demander un devis.

WordPress hacké, infecté par un malware SEO

Grâce à Sucuri scan je me suis aperçu que le site WordPress de mon client était infecté par un malware (SEO SPAM).

En cherchant un peu dans le code source, on trouve un fichier javascript chargé à partir d’une url inconnu. En recherchant cette URL, j’ai trouvé le fichier de malware dans le theme premium « flatbox ».
=> wp-content/themes/flatbox/images/cache/xxxxx/cache.php
=> wp-content/themes/flatbox/images/cache/xxxxx/links.db
=> wp-content/themes/flatbox/images/settings.php

Ces fichiers était inclus dans toutes les page grâce à la ligne stocké dans footer.php du thème.

<?php include(« images/settings.php »); ?>

Voici ci-dessus tous les fichiers à supprimer pour ce malware précis. Par contre le travail désormais est de trouver la porte d’entrée du hacker, c’est ce qui lui a permis de modifier le fichier footer.php.

Mesures de protection pour protéger son plugin WordPress

1 – Empêcher l’accès direct à vos fichiers

La plupart des hébergeurs permettent l’accès direct aux fichiers sur votre serveur.
Lorsqu’on accède directement aux fichiers PHP d’un plugin, cela va surement afficher une erreur mais risque de divulguer malgré tous des informations aux hackers.

Pour éviter l’affichage des erreurs, vous pouvez ajouter le contrôle d’une constante au début du fichier PHP.

[php]
if ( ! defined( ‘ABSPATH’ ) ) {
exit; // don’t access directly
};
[/php]

2. Sanitize toutes les variables GET, POST, REQUEST

Ne jamais faire confiance à une variable entrée par l’utilisateur ou le navigateur et même envoyé depuis l’administration.

Sinon vous serez vulnérable ou attaques XSS. Des scripts Javascript seront injectés dans votre code et exécuteront du code malveillant (popup, modification des liens etc..)

Il faut toujours utiliser les fonctions « sanitize » de WordPress pour nettoyer les variables de possibles codes dangereux. Exemple de fonction : sanitize_text_field

De plus, il est recommandé de vérifier et valider que les valeurs reçues sont des valeurs conformes avant de les utiliser dans votre code. Des fonctions sont également disponibles sur WordPress.

3. Échapper (Escape en anglais) quand vous diffusez des données provenant de vos tables

Lorsque vous affichez des données provenant de vos tables (BDD MySQL par exmeple), il est aussi résonnable de nettoyer vos données, car les utilisateurs ont très bien pu écrire du code malveillant dans un champs texte. Worpdress fournies également quelques fonctions pour nous aider :

  • wp_kses et wp_kses_post which strip out untrusted HTML.
  • esc_js which escapes and correctly encodes characters in text strings which you intend to echo for JavaScript.
  • esc_textarea which encodes text for use inside textarea elements.
  • esc_url which correctly encodes URLs and rejects invalid URLs.
  • esc_html which encodes < > & " ' when outputting HTML.
  • esc_attr which encodes text like esc_html for use in HTML attributes.

Par exemple si votre plugin génére et affiche du code HTML il est recommandé d’échapper les liens comme ceci :

[php]<a href=”<?php echo esc_url( $url ); ?>”><?php echo esc_html( $text ); ?></a>[/php]

C’est très simple à coder mais il faut penser à le faire partout.

SNAP error bug pour publier un post

-=ERROR=- Server can’t access it’s own images.

Voici l’erreur que j’ai reçue à chaque publication manuelle d’un post avec le plugin « NextScripts: Social Networks Auto-Poster ».

Suite à quelques recherches je me suis vite rendu compte que je ne trouverai pas la solution facilement.

En effet de nombreuses personnes ont le même problème mais n’obtiennent pas de réponses concluantes.

Le développeur du plugin indique que ce message d’erreur provient du retour d’une fonction de WordPress : wp_remote_get 

Il se décharge donc de toutes responsabilités et indique qu’il faut voir avec son hébergeur…

En faisant des tests, je me suis rendu compte que le problème était causé tout simplement par un autre plugin : « Wordfence ».

Suite à une mise à jour, ce plugin de sécurité bloque les accès à SNAP grace à leur « firewall » pour faire simple. J’ai donc désactivé cette fonctionnalité et la publication de mes posts sur Facebook ont fonctionné de nouveau !

Bug meet with Simple Ads Manager

After several months where the plugin Simple Ads Manager works.
I’ve got 403 error for each ajax request on this files :

  • wp-content/plugins/simple-ads-manager/sam-ajax.php
  • wp-content/plugins/simple-ads-manager/sam-ajax-loader.php

I found finally alone the problem, some security plugin like Sucuri Security allow you to protect wp-content folder.

Sucuri Security plugin generate .htaccess in the wp-content with :
<Files *.php>
deny from all
</Files>

That was the problem !

I resolve it with an other .htaccess in wp-content/plugins/simple-ads-manager/ where i put :
<FilesMatch « sam-ajax.php|sam-ajax-loader.php »>
Allow from all
</FilesMatch>

I was thinking about desactive this plugin to test, but protection .htaccess was not clear when you uninstall or delete the plugin.

I hope my messages will help someone else.

Joomla 2.5 en localhost Error 404 sur Administrator

Si vous avez l’erreur  « Error 404″ sur /administrator/ en localhost avec Joomla 2.5, et que vous venez d’installer une sauvegarde du site en ligne, c’est normal.

L’erreur est simple à résoudre pourtant, sa résolution n’est pas simple à trouver sur internet parmi le nombre important de bugs possible avec Joomla lors d’une migration ou d’une installation.

Il faut simplement mettre à vide la variable suivante dans configuration.php à la racine du CMS Joomla :

public $live_site =  »;