Total : 90 résultats trouvés.
Page 1 sur 5
Enlever l'extension d'un nom de fichier avec php
On crée une variable avec le nom du fichier :
$file = 'filename.jpg';
On récupère uniquement le nom du fichier sans l'extension :
$filename = pathinfo($file, PATHINFO_FILENAME);
On peut ensuite afficher le résultat :
echo $filename;
Comment vérifier si l'utilisateur est connecté en tant que client avec PrestaShop 1.7?
On peut parfois (voire souvent) avoir besoin de vérifier que l'utilisateur est connecté ou non en tant que client pour lui apporter un affichage ciblé.
Dans un module ou Controller :
if ($this->context->customer->isLogged()) {
// L'utilisateur est connecté
} else {
// L'utilisateur n'est pas connecté
}
Dans un fichier template (.tpl) :
{if $customer.is_logged}
// L'utilisateur est connecté
{else}
// L'utilisateur n'est pas connecté
{/if}
An error has occurred while processing your request. 0 Could not create session directory "/var/lib/php/session" à l'installation de Joomla! 4
Joomla! n'a pas encore donné de dates pour la version 4.x de son CMS, mais le projet étant au stade Alpha3, il est temps de tester tout ça !
Pour bien démarrer, on commence par une erreur dés la première page d'installation !
Error
An error has occurred while processing your request.
0 Could not create session directory "/var/lib/php/session"
Cette erreur apparaît sous Plesk, un souci au niveau de la valeur d'open_basedir.
Pour la résoudre, on accède au panneau Plesk, puis au domaine en question, puis aux paramètres php.
En bas de page, on retrouve un champ de formulaire sous le titre Directives supplémentaires.
On ajoute dans ce champ la ligne :
open_basedir = {WEBSPACEROOT}{/}{:}{TMP}{/}{:}{/}var{/}lib{/}php{/}session{/}
On applique le changement, et on peut recharger la page où l'erreur est apparue pour procéder à l'installation de Joomla! 4.
Je viens juste de le faire, et je m'apprête juste à ouvrir le panneau d'administration, donc je risque de rencontrer d'autres surprises que je pourrais bien poster ici également.
Pour information, on peut retrouver le roadmap des différentes versions sur le site officiel du projet Joomla!.
Using $this when not in object context au passage de Joomla! vers php 7.2.x
Les administrateurs de sites Joomla! ont pu remarquer depuis les dernières mises à jour des notifications indiquant que les versions de php 7.0.x devenaient obsolètes.
Alerte
Votre version de PHP, 7.0.32, ne reçoit en ce moment que des correctifs de sécurité du projet PHP. Cela signifie que votre version de PHP ne sera bientôt plus prise en charge. Nous vous recommandons de planifier la mise à niveau vers une nouvelle version de PHP avant d'atteindre la fin du support le 3/09/18. Joomla sera plus rapide et plus sûr si vous passez à une version plus récente de PHP (PHP 7.x est recommandé). Merci de contacter votre hôte pour obtenir des instructions de mise à niveau.
Il est donc temps de passer à php 7.1.x ou 7.2.x !
En général, ce passage se fait sans encombres, mais il faut bien quelques exceptions pour compliquer un peu les choses et générer quelques sueurs.
Aujourd'hui j'ai pu rencontrer l'erreur fatale (500) Using $this when not in object context en passant de php 7.1.x à 7.2.x, plus aucun accès au frontend !
En faisant quelques recherches, j'ai pu voir que les appels
JSite::getMenu()
dans mon template (qui a déjà un certain vécu) causaient le problème.
Il faut donc remplacer ces appels par :
JFactory::getApplication()->getMenu()
Et le souci est réglé !
Vérifier si un module existe et est publié dans une position donnée sur une page Joomla!
On peut avoir besoin de vérifier si un module est présent dans une position donnée d'une page pour savoir si l'on a besoin ou non d'afficher une partie du template ou d'exécuter du code. On utilise souvent cette fonction si on veut ajouter du code html autour du module.
Il suffit d'écrire une condition avec la fonction countModules et la position voulue.
<?php if($this->countModules('position_du_module')) : ?>
<!-- Afficher la position / le module -->
<!-- Code à exécuter -->
<?php endif; ?>
La fonction countModules va se charger de vérifier si un module s'est vu attribuer cette position, si ce module est publié, et si ce module doit être affiché sur la page actuelle.
Parcourir un dossier pour récupérer les images et les trier par nom de fichier
Je me sers régulièrement de ce bout de script, très simple mais très utile, pour afficher un slider, une galerie d'images... C'est une base à travailler pour un affichage abouti.
<?php
$dir = "chemin_vers/images";
$repo = opendir($dir);
while (false !== ($filename = readdir($repo))) {
$files[] = $filename;
}
sort($files);
$images=preg_grep ('/\.jpg$/i', $files);
foreach($images as $image)
{
echo "<img src='$dir/$image'><br>\n";
}
?>
1. La variable $dir indique le chemin vers le dossier d'images.
2. La fonction opendir() ouvre un flux répertoire correspondant au répertoire et renvoie un pointeur sur ce flux. Le flux est positionné sur la première entrée du répertoire.
3. La fonction readdir() retourne le nom de la prochaine entrée du dossier. Les entrées sont retournées dans l'ordre dans lequel elles sont enregistrées dans le système de fichiers.
4. La fonction sort() trie le tableau array. Les éléments seront triés du plus petit au plus grand.
5. La fonction preg_grep() retourne un tableau avec les résultats de la recherche.
6. La fonction foreach() parcourt le tableau.
Ici on recherche des images avec l'extension jpg, mais on peut également modifier ce code pour récupérer tous types de fichiers.
Transférer le JavaScript vers le footer avec WordPress
Pour des questions de temps de chargement et de référencement, il est aujourd'hui régulièrement conseillé de passer tout le JavaScript (ou le maximum) dans le footer des pages. Les codes JavaScripts sont connus pour bloquer l'affichage de certaines pages, le code de la page se chargeant de haut en bas, les déplacer dans le footer peut contribuer à afficher les éléments plus rapidement, même si tout n'est pas encore chargé, et ainsi garder les visiteurs sur votre site.
En résumé, cela permet de charger le contenu, le visuel en premier pour que le visiteur puisse tout voir, puis les fonctions JavaScript.
Mais tous les CMS et extensions ne suivent pas encore cette pratique. Malheureusement, de nombreuses extensions font des appels JavaScript dans la balise <head> ou le contenu de la page, donc avant le contenu à proprement parler en bloquant son chargement.
On va voir ici comment procéder avec WordPress. Le but est d'améliorer les temps de chargement, ce qui sera appréciable autant côté visiteurs que Google via votre score PageSpeed.
La première méthode consiste à tout bouger en bloc dans la balise <footer> de votre site. Elle ne s'applique pas forcément à tout le monde, en fonction du thème, des extensions qu'on a installées et/ou des fonctions qu'on a pu ajouter, elle pourrait nuire au bon fonctionnement de l'ensemble. Il faut donc bien tout tester après l'avoir appliquée. On va ici désinscrire le chargement des JavaScripts dans la balise <head> pour les ré-inscrire dans la balise <footer>.
Pour cela, il faut modifier le fichier functions.php qui se trouve à la racine du dossier du thème utilisé (/wp-content/themes/theme).
On va ajouter les lignes suivantes en fin de fichier (si le fichier se termine par une balise de fermeture de code php ?>, on inscrit le code juste avant cette balise) :
// Script pour déplacer les JS dans le footer
function remove_head_scripts() {
remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
remove_action('wp_head', 'wp_enqueue_scripts', 1);
add_action('wp_footer', 'wp_print_scripts', 5);
add_action('wp_footer', 'wp_enqueue_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);
}
add_action( 'wp_enqueue_scripts', 'remove_head_scripts' );
// Script pour déplacer les JS dans le footer
Après cette modification, on teste bien le fonctionnement du site avec plusieurs appareils (ordinateurs, tablettes, téléphones...), plusieurs OS (Mac OS, Windows...) et plusieurs navigateurs (Chrome, Safari, Firefox, Internet Explorer, Microsoft Edge...). Si tout fonctionne, c'est parfait, si ce n'est pas le cas, on supprime ces lignes et il va falloir envisager une seconde méthode, qui sera plus longue et compliquée, bouger les scripts un par en dans le footer afin de déterminer celui ou ceux qui ne peuvent pas être déplacé pour le bon fonctionnement du site..
ATTENTION, ces opérations pourraient nuire au bon fonctionnement de votre site en fonction de l'environnement, des plugins installés, et de la manière dont les changements ont été faits. Si la tâche vous paraît compliquée, mieux vaut faire appel à un développeur. Il est également très fortement conseillé de faire un backup avant de se lancer dans ces modifications.
Changer la source ou la version de jQuery chargée par WordPress
Il y a un certain nombre de scripts inclus dans le core de WordPress, souvent utilisés pour le fonctionnement des thèmes et extensions. jQuery fait partie des scripts les plus utilisés.
Mais pourquoi changer la source ou la version jQuery ?
1. On peut vouloir faire appel à la "Google Hosted Libraries", un réseau de distribution de contenu stable, fiable, rapide et disponible dans le monde entier pour les bibliothèques JavaScript open source les plus populaires. Google travaille directement avec les principaux intervenants et propose les dernières versions au fur et à mesure de leur publication.
2. Google Hosted Libraries est devenu un des standards pour les inclusions de scripts, il y a des chances pour que le visiteur ait déjà visité d'autres sites ayant les mêmes inclusions, et donc déjà la fichier dans le cache du navigateur, ce qui réduira les temps de chargement.
3. On peut vouloir intégrer un autre script dépendant de jQuery (Slideshow, galerie d'images, masonry...) qui a besoin d'une version donnée pour bien fonctionner.
La modification est plutôt simple, et comme souvent avec WordPress, tout se passe dans le fichier functions.php qui se trouve à la racine du dossier du thème utilisé (/wp-content/themes/theme).
// Appeler jQuery par l'API Google
function modify_jquery() {
if (!is_admin()) {
// comment out the next two lines to load the local copy of jQuery
wp_deregister_script('jquery');
wp_register_script('jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js', false, '1.8.1');
wp_enqueue_script('jquery');
}
}
add_action('init', 'modify_jquery');
// Appeler jQuery par l'API Google
Après cette modification, on teste bien le fonctionnement du site avec plusieurs appareils (ordinateurs, tablettes, téléphones...), plusieurs OS (Mac OS, Windows...) et plusieurs navigateurs (Chrome, Safari, Firefox, Internet Explorer, Microsoft Edge...). Si tout fonctionne, c'est parfait, si ce n'est pas le cas, on supprime ces lignes et il va falloir envisager une seconde méthode. Il faudra également bien vérifier le bon fonctionnement du site suite aux diverses mises à jour avec de tels changements.
En 2ème méthode, on peut faire appel à un plugin WordPress dédié qui s'occupe de ce travail, et qui maintiendra les versions du CDN de Google à jour tant qu'il est lui même à jour.
Pour aller plus loin dans le gain de temps des chargements JavaScript de WordPress, cet article pourrait compléter les changements ci-dessous.
Intégrer RESPONSIVE filemanager à l'éditeur de texte TinyMCE de Joomla!
RESPONSIVE filemanager est un gestionnaire Open Source d'upload de fichiers basé sur jQuery, css3, php et html5. Il peut être intégré à Joomla! par son éditeur de texte TinyMCE assez facilement, ce qui permettra ensuite aux rédacteurs du site d'uploader plus de formats de fichiers comme du .pdf par exemple.
Pour démarrer, on installe le plugin.
1. Télécharger le plugin sur le site officiel de RESPONSIVE Filemanager.
2. Dézipper l'archive.
3. Uploader le dossier "filemanager" vers /media/editors/tinymce/
3. Uploader le dossier "tinymce/plugins/responsivefilemanager" vers /media/editors/tinymce/plugins/
4. Éditer le fichier /media/editors/tinymce/filemanager/config/config.php pour modifier les variables :
'upload_dir' => '/images/downloads/',
'current_path' => '../../../../images/downloads/',
'thumbs_base_path' => '../../../../images/thumbs/'
À partir de Joomla 3.7 & Tinymce 4.5.6, après l'installation du plugin, il faut modifier un fichier de TinyMCE : /plugins/editors/tinymce/tinymce.php.
On remplace :
'external_plugins' => empty($externalPlugins) ? null : $externalPlugins,
par
'external_plugins' => empty($externalPlugins) ? JUri::root().'/media/editors/tinymce/filemanager/plugin.min.js' : $externalPlugins,
Puis on ajoute juste à la suite de 'external_plugins' :
'external_filemanager_path' => JUri::root()."/media/editors/tinymce/filemanager/",
'filemanager_title' => 'Responsive Filemanager',
Ensuite, dans la configuration du plugin TinyMCE de l'administration Joomla!, pour chaque set du panneaux d'édition, ajouter responsivefilemanager dans les champs Plug-in personnalisé et Bouton personnalisé.
Le panneau d'édition TinyMCE devrait maintenant afficher un bouton supplémentaire ouvrant une fenêtre modale vers RESPONSIVE filemanager.
Rafraîchir le CSS dans les simulateurs iOS
J'utilise les simulateurs iOS fournis avec xCode pour affiner mon responsive layout et vérifier l'affichage sur de multiples appareils. Depuis quelques temps, j'ai quelques soucis pour rafraîchir le CSS dans leurs navigateurs, sûrement suite à une mise à jour, et sûrement pour une raison précise, mais pas vraiment pratique pour travailler.
Pour forcer le navigateur a recharger les fichiers, j'ai ajouté un petit bout de php pour "l'induire en erreur". Grâce à la fonction rand() qui génère une valeur aléatoire au chargement de la page, il voit qu'il a affaire à une nouvelle version du fichier et il le met donc à jour.
Par exemple, pour un appel de type :
<link rel="stylesheet" type="text/css" href="/style.css">
Ça donne :
<link rel="stylesheet" type="text/css" href="/style.css?rand=<?php echo rand(); ?>">
Cette technique doit pouvoir s'appliquer à d'autres environnements de tests, et avec d'autres types de fichiers tels que les .js.
Elle fonctionne assez bien pour le navigateur Chrome également, avec lequel on a parfois du mal à recharger le css suite à des modifications.
Il suffit d'enlever ce bout de php au passage en production pour profiter pleinement de la mise en cache des assets.
Redirection basée sur l'adresse IP avec htaccess
Il peut parfois être bien pratique de créer une redirection basée sur l'adresse IP du visiteur, pour un site en construction par exemple, ou une maintenance. Sur les CMS et solutions panier, il existe souvent des plugins dédiés, mais quelques lignes dans le fichier htaccess peuvent éviter l'installation d'une extension tierce.
## REDIRECTION MAINTENANCE
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !=VOTRE.ADRESSE.IP
RewriteRule index.php$ /index.html [R=302,L]
Ici, tous les visiteurs sauf votre adresse IP seront redirigés depuis l'index.php de votre CMS ou solution panier vers un index.html en racine de serveur.
On peut aussi rediriger toutes les requètes en racine vers un autre dossier :
## REDIRECTION MAINTENANCE
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !=VOTRE.ADRESSE.IP
RewriteRule ^$ /enconstruction/index.html [R=302,L]
ou encore une autre url, comme la page facebook :
RewriteRule ^$ http://www.facebook.com/mapagefacebook [R=302,L]
On peut multiplier les lignes RewriteCond %{REMOTE_ADDR} !IP pour autoriser l'accès à plusieurs personnes, chef de project, client, etc...
## REDIRECTION MAINTENANCE
Options +FollowSymlinks
RewriteEngine on
## MON ADRESSE
RewriteCond %{REMOTE_ADDR} !=VOTRE.ADRESSE.IP
## CHEF DE PROJET
RewriteCond %{REMOTE_ADDR} !=ADRESSE.IP.CHEF.DE.PROJET
## CLIENT
RewriteCond %{REMOTE_ADDR} !=VADRESSE.IP.CLIENT
RewriteRule index.php$ /index.html [R=302,L]
Le code 302 indique au navigateur web et aux robots des moteurs de recherche que la redirection est temporaire.
Effacer toutes les données de commandes dans Magento 2
ATTENTION, CET ARTICLE EST DESTINÉ AUX ADMINISTRATEURS AYANT UN MINIMUM DE CONNAISSANCES MYSQL.
La phase de test est terminée, et vous êtes prêt à ouvrir votre boutique sous Magento 2, mais les tests ont laissé pas mal de traces dans la base de données ? Magento 2 ne dispose malheureusement pas d'outil admin pour effacer cela, à moins d'installer des composants tierces.
Lorsque votre phase de tests est terminée, vous pouvez néanmoins effacer le tout, après avoir effectué un backup par sécurité, en vous connectant directement via phpMyAdmin et en exécutant la requête (remplacer prfx par le préfixe de vos tables dans la base de données) :
SET FOREIGN_KEY_CHECKS=0;
# Nettoyage de l'historique des commandes
TRUNCATE TABLE `prfx_sales_bestsellers_aggregated_daily`;
TRUNCATE TABLE `prfx_sales_bestsellers_aggregated_monthly`;
TRUNCATE TABLE `prfx_sales_bestsellers_aggregated_yearly`;
# Nettoyage des infos de commandes
TRUNCATE TABLE `prfx_sales_creditmemo`;
TRUNCATE TABLE `prfx_sales_creditmemo_comment`;
TRUNCATE TABLE `prfx_sales_creditmemo_grid`;
TRUNCATE TABLE `prfx_sales_creditmemo_item`;
TRUNCATE TABLE `prfx_sales_invoice`;
TRUNCATE TABLE `prfx_sales_invoiced_aggregated`;
TRUNCATE TABLE `prfx_sales_invoiced_aggregated_order`;
TRUNCATE TABLE `prfx_sales_invoice_comment`;
TRUNCATE TABLE `prfx_sales_invoice_grid`;
TRUNCATE TABLE `prfx_sales_invoice_item`;
TRUNCATE TABLE `prfx_sales_order`;
TRUNCATE TABLE `prfx_sales_order_address`;
TRUNCATE TABLE `prfx_sales_order_aggregated_created`;
TRUNCATE TABLE `prfx_sales_order_aggregated_updated`;
TRUNCATE TABLE `prfx_sales_order_grid`;
TRUNCATE TABLE `prfx_sales_order_item`;
TRUNCATE TABLE `prfx_sales_order_payment`;
TRUNCATE TABLE `prfx_sales_order_status_history`;
TRUNCATE TABLE `prfx_sales_order_tax`;
TRUNCATE TABLE `prfx_sales_order_tax_item`;
TRUNCATE TABLE `prfx_sales_payment_transaction`;
TRUNCATE TABLE `prfx_sales_refunded_aggregated`;
TRUNCATE TABLE `prfx_sales_refunded_aggregated_order`;
TRUNCATE TABLE `prfx_sales_shipment`;
TRUNCATE TABLE `prfx_sales_shipment_comment`;
TRUNCATE TABLE `prfx_sales_shipment_grid`;
TRUNCATE TABLE `prfx_sales_shipment_item`;
TRUNCATE TABLE `prfx_sales_shipment_track`;
TRUNCATE TABLE `prfx_sales_shipping_aggregated`;
TRUNCATE TABLE `prfx_sales_shipping_aggregated_order`;
# Nettoyage des infos panier
TRUNCATE TABLE `prfx_quote`;
TRUNCATE TABLE `prfx_quote_address`;
TRUNCATE TABLE `prfx_quote_address_item`;
TRUNCATE TABLE `prfx_quote_id_mask`;
TRUNCATE TABLE `prfx_quote_item`;
TRUNCATE TABLE `prfx_quote_item_option`;
TRUNCATE TABLE `prfx_quote_payment`;
TRUNCATE TABLE `prfx_quote_shipping_rate`;
# Remise à zéro des indexs (pour que les numéros de commandes démarrent à 1)
TRUNCATE TABLE `prfx_sequence_invoice_1`;
TRUNCATE TABLE `prfx_sequence_order_1`;
TRUNCATE TABLE `prfx_sequence_shipment_1`;
TRUNCATE TABLE `prfx_sequence_creditmemo_1`;
SET FOREIGN_KEY_CHECKS=1;
Ces tables peuvent également être vidées une par une sur l'inteface phpMyAdmin.
Cette requête a été testée sous la dernière version de Magento 2 (2.1.7) mais il est toujours préférable de faire un backup avant de la lancer.
Retrouver la taille d'une image avec php
Il peut parfois être très pratique de pouvoir retrouver la taille d'une image avec php, pour pouvoir affiner les calages, régler la taille des conteneurs en conséquence, placer des images centrées les unes sur les autres...
La fonction php getimagesize s'en occupe très facilement. On peut alors retrouver toutes les informations avec :
<?php $imageSize = getimagesize("http://www.mon-domaine.fr/mon-image.jpg"); ?>
ou
<?php
$image = chemin_vers_mon_image
$imageSize = getimagesize($image);
?>
Le résultat peut alors s'afficher sous forme d'array :
<?php print_r($imageSize); ?>
qui donne par exemple :
Array ( [0] => 367 [1] => 250 [2] => 3 [3] => width="367" height="250" [bits] => 8 [mime] => image/png )
On peut voir qu'on obtient même plus d'informations que l'on en a besoin ici.
On peut alors obtenir la largeur et la hauteur séparément avec :
<?php
$imageWidth = getimagesize($image)[0];
$imageHeight = getimagesize($image)[1]; ?>
Ou encore appeler :
<?php echo getimagesize($image)[3]; ?>
pour obtenir :
width="367" height="250"
Bloquer les tentatives d'inscription et de connexion indésirables sous Joomla!
Nos systèmes CMS préférés sont malheureusement victimes de leur succès lorsqu'il s'agit de tentatives d'intrusion malveillantes. Une des "portes d'entrées" utilisées est l'inscription d'utilisateur pour tenter ensuite d'élever les droits utilisateur sur le site (Joomla! 3.6.4 vient de régler une telle faille). En effet, les schémas d'inscription sont les mêmes pour tous les sites Joomla! et toute les versions du CMS, on peut ainsi voir dans les logs de certains sites ciblés :
/index.php/component/user/?task=register
/index.php/component/users/?view=registration
/index.php?option=com_user&view=register
/index.php/registration?option=com_users&view=register
/index.php/component/users/?view=login
/index.php/component/users/?view=reset
Et j'en passe sûrement...
Qui correspondent aux urls où l'ont peut retrouver les formulaires d'inscription et de connexion en frontend du site et qui sont accessibles même si aucun lien de menu n'y mène.
Si le site ne requiert pas de donner la possibilité aux visiteurs de pouvoir créer un compte ou de se connecter, on peut dans un premier temps désactiver les inscriptions dans les paramètres utilisateurs : Autoriser l'inscription des utilisateurs > Non. Le formulaire d'inscription ne sera alors plus plus affiché sur une url de type /index.php/component/user/?task=register mais vous pourrez toujours y retrouver le lien de connexion, et les liens de réinitialisation de mot de passe.
Pour aller un peu plus loin, et couper l'accès à ces pages, on peut jeter un œil au composant com_users de Joomla! pour modifier les fichiers. La meilleure solution est alors de créer des overrides pour les fichiers en les copiant dans le dossier de template du site. Les fichiers originaux à copier et modifier se trouvent dans:
components/com_users/views/login/tmpl
components/com_users/views/profile/tmpl
components/com_users/views/registration/tmpl
components/com_users/views/remind/tmpl
components/com_users/views/reset/tmpl
Il faut tout d'abord les copier vers :
templates/TemplateDuSite/html/com_users/login
templates/TemplateDuSite/html/com_users/profile
templates/TemplateDuSite/html/com_users/registration
templates/TemplateDuSite/html/com_users/remind
templates/TemplateDuSite/html/com_users/reset
On peut ainsi garder ces modifications lors des différentes mises à jour du système.
Il existe ensuite plusieurs solutions pour modifier ces fichiers, supprimer les formulaires et liens, afficher un message dédié pourrait aussi faire sourire, on peut encore tout simplement créer une redirection automatique en php en ne gardant dans ces fichiers que :
<?php header('Location: http://www.nom-de-domaine.fr'); exit(); ?>
On pourra alors voir dans les logs des codes http de redirection 302 pour les urls listées plus haut.
L'url d'administration sera toujours accessible à n'importe qui car commune à toutes les configurations Joomla! :
www.nom-de-domaine.fr/administrator
mais cela peut être évité avec l'extension jSecure ou sa version gratuite jSecure Lite. Cette extension permet de rajouter une variable unique choisie au bout de l'url
www.nom-de-domaine.fr/administrator?VariableChoisie
Google annonce officiellement l'évolution de l'indexation vers le mobile-first
Après le mobile friendly, Google fait encore un pas vers les utilisateurs mobiles avec le mobile-first. C'est un concept qui a déjà été traité depuis quelques temps dans la littérature dédiée aux webdesigners (voir Mobile first, Guide stratégique de design web mobile de Luke Wroblewski dans l'excellent collection A Book Apart chez Eyrolles) qui a pour but d'orienter le design d'un site web en mettant le mobile au cœur des préoccupations : on pense d'abord au mobile pour servir le contenu important d'une manière optimale, puis on peut rajouter des "couches" d'expérience utilisateur supplémentaires en fonction de l'appareil et de la taille de l'écran utilisé. En réponse aux chiffres indiquant que la majorité (56%) des requêtes Google se font maintenant depuis des appareils mobiles, le moteur de recherche reprend ce concept pour son indexation.
Google va donc faire évoluer son mode d'opération pour indexer en priorité le contenu affiché pour les mobiles. Pas de panique pour les sites utilisant les techniques de responsive design (l'affichage est géré par les feuilles de style pour être optimisé pour chaque écran) ou de dynamic serving (le code source du site peut varier pour optimiser l'affichage), ou encore un peu des 2 ! Google indique que l'indexation ne devrait pas changer. Si le contenu diffère en fonction du support, il faudra bien veiller à ce que les balises correspondent, et que les crawlers puissent accéder à toutes les ressources nécessaires pour une bonne indexation.
Par contre pour les sites ne disposant pas de version mobile, n'utilisant pas de technique d'optimisation, le moteur de recherche annonce qu'il continuera à indexer le contenu, mais on peut facilement imaginer que le classement pourra s'en ressentir, comme on a déjà pu le voir avec le mobile friendly.
Le responsive design se présente donc encore d'avantage comme une étape cruciale dans un projet web, aussi bien pour la satisfaction des utilisateurs que pour le référencement.
Le lancement officiel de l'indexation mobile-first ne devrait se faire qu'en début Janvier, mais Google annonce déjà que les résultats pourraient déjà s'en ressentir, car les phases de tests ont été lancées.
Retrouvez plus dinformations sur le Google Webmaster Central Blog.
Filtrer les médias Wordpress par utilisateur
La gestion des médias Wordpress se fait sans aucun filtre, ce qui peut poser quelques problèmes tant au niveau organisation que au niveau sécurité et droits d'usage sur des sites avec plusieurs rédacteurs. Chaque rédacteur peut donc voir et utiliser les médias des autres sans restriction.
Comme souvent, il existe des plugins à installer sur votre site Wordpress pour régler cela, mais quelques lignes de code peuvent suffire également et donc éviter d'installer un plugin supplémentaire et ne pas multiplier les extensions externes.
Pour filtrer l'accès par utilisateur, il suffit d'ajouter au fichier functions.php de votre thème :
add_filter( 'ajax_query_attachments_args', 'show_current_user_attachments' );
function show_current_user_attachments( $query ) {
$user_id = get_current_user_id();
if ( $user_id ) {
$query['author'] = $user_id;
}
return $query;
}
Chaque utilisateur ne verra alors plus que les medias qu'il a ajouté lui-même. En l'état, cela peut poser un autre problème, pour la modération, si l'administrateur peut avoir besoin de modérer le contenu du site, il ne pourra plus accéder aux médias des autres rédacteurs.
On peut donc régler ça en détectant le rôle de l'utilisateur avant d'imposer le filtre pour donner le plein accès aux administrateurs :
$user = wp_get_current_user();
if ( in_array( 'administrator', (array) $user->roles ) ) { }
else {
add_filter( 'ajax_query_attachments_args', 'show_current_user_attachments' );
function show_current_user_attachments( $query ) {
$user_id = get_current_user_id();
if ( $user_id ) {
$query['author'] = $user_id;
}
return $query;
}
}
Limiter les révisions d'articles Wordpress
Votre base de données sauvegarde tout ce qui concerne votre site Wordpress, les pages, les posts, les commentaires, les menus... Elle peut donc assez vite devenir très conséquente, et il peut s'avérer très utile de la nettoyer de temps en temps pour l'optimiser et donc optimiser les performances de votre site.
Les révisions d'article ont un impact important sur la taille de la base de données. Il s'agit d'une sauvegarde de chaque édition / enregistrement des posts pour pouvoir les restaurer. Une fonction qui peut s'avérer très pratique, mais aussi très gourmande en ressources.
Surtout, ces révisions sont illimitées, donc la base de données peut contenir énormément d'informations obsolètes et totalement inutiles.
On peut limiter ces révisions en éditant le fichier wp-config.php en ajoutant la ligne :
define('WP_POST_REVISIONS', 3);
Ici, on limite le nombre de révisions à 3 par exemple.
Pour ceux qui ne désirent pas utiliser la fonction de révision de posts, il suffit d'écrire :
define('WP_POST_REVISIONS', false);
Les performances de votre serveur devraient grandement s'en ressentir, surtout si vous êtes très actif sur le contenu de votre site.
Le système de sauvegarde automatique de Wordpress multiplie également le nombre de révisions, elle se fait toutes les minutes. On peut aussi changer cette configuration en ajoutant une ligne au fichier wp-config.php :
define('AUTOSAVE_INTERVAL', 300 );
Ici, la sauvegarde automatique se fera toutes les 5 minutes.
Enfin, pour un grand ménage de printemps, on peut effacer toutes les révisions de posts en notant tout de même qu'à partir de ce point, il sera plus possible de restaurer aucun post. Pour cela, il faut se connecter à la base de données avec phpMyAdmin et entrer la requête :
DELETE FROM wp_posts WHERE post_type = "revision";
Il est bien sûr important de noter qu'une sauvegarde de base de données avant de faire ces opérations peut être une bonne règle de sécurité pour anticiper toute mauvaise manipulation. Une sauvegarde automatisée de votre base de données avec un petit plugin dédié est aussi une excellente sécurité.
Supprimer les commentaires Wordpress via mysql ou ssh
Les commentaires sur les sites internet peuvent souvent être problématiques pour diverses raisons et il peut s'avérer également plus fréquemment de se trouver face à un très grand nombre de spams que de commentaires légitimes et appréciables. Les systèmes CMS tels que Joomla! et Wordpress sont régulièrement la cible de spams dans les commentaires, qui peuvent rapidement représenter plusieurs milliers voire plusieurs dizaines de milliers de commentaires indésirable.
La première sécurité à mettre en place sous Wordpress est la modération des commentaires, qui fait que seul l'administrateur du site pourra les publier. On peut également limiter la possibilité de poster des commentaires aux utilisateurs inscrits, ou opter pour les solutions type reCaptcha, ou encore les divers plugins disponibles pour lutter contre le spam, mais ces solutions peuvent être également des freins au bon fonctionnement des commentaires, et on peut alors se trouver avec un désert de commentaires alors que l'on essaye juste d'éviter le spam.
On peut aussi opter pour des système de commentaires externalisés type Disqus.
Une fois le spam fait sur votre site Wordpress, on peut bien sûr les supprimer depuis la console d'administration, mais à raison de 20 par 20, la tâche peut vite s'avérer plus que fastidieuse. Ici aussi on peut avoir recours à des plugins pour se débarrasser de ce spam, mais pour ceux qui veulent éviter d'augmenter leur collection de plugin, il peut être très facile et rapide de nettoyer tout ça avec quelques bases au niveau mysql ou ssh.
Le plus facile serait de se connecter à la base de données avec phpMyAdmin. Une ligne de commande suffira à se débarrasser de tous les commentaires non approuvés.
DELETE from wp_comments WHERE comment_approved = '0'
On peut également de la même manière supprimer tous les commentaires marqués comme indésirables :
DELETE from wp_comments WHERE comment_approved = 'spam'
Ou encore ceux placés dans la corbeille :
DELETE from wp_comments WHERE comment_approved = 'trash'
Il se peut qu'à l'installation de votre Wordpress vous ayez demandé un préfixe de tables custom pour votre base de données, dans ce cas il faudra remplacer wp_ par votre préfixe.
Pour la deuxième méthode, il vous faudra vous connecter à votre serveur en ssh si votre hébergeur le permet.
La commande pour supprimer tous les commentaires non approuvés est alors :
mysql -uDB_USER_NAME -pDB_USER_PASSWORD -DB_NAME -e "DELETE FROM wp_comments WHERE comment_approved = '0';"
en remplaçant :
_ DB_USER_NAME par le nom d'utilisateur de la base de données
_ DB_USER_PASSWORD par le mot de passe
_ DB_NAME par le nom de la base de données
On peut ainsi aussi supprimer les commentaires marqués comme indésirables ou les commentaires placés dans la corbeille en remplaçant :
_ comment_approved = '0' par comment_approved = 'spam'
ou
_ comment_approved = '0' par comment_approved = 'trash'
Il est bien sûr important de noter qu'une sauvegarde de base de données avant de faire ces opérations peut être une bonne règle de sécurité pour anticiper toute mauvaise manipulation.
Afficher un élément aléatoire avec JavaScript
Un petit script tout simple qui permet d'afficher un élément différent à chaque chargement dans une même position.
On commence par le JavaScript à mettre avant la balise </head> :
<script type='text/javascript'>//<![CDATA[
window.onload=function(){
var E=document.getElementsByClassName("element-variable");
var m=E.length;
var n=parseInt(Math.random()*m);
for(var i=m-1;
i>=0;i--){var e=E[i];
e.style.display='none';
}E[n].style.display='';
}//]]>
</script>
Pour l'exemple, l'élément ciblé par getElementsByClassName est un div avec la classe element-variable (cela peut aussi être tout autre élément avec cette classe).
Il suffit ensuite de mettre autant de divs avec cette classe à l'endroit désiré :
<div class="element-variable"></div>
<div class="element-variable"></div>
<div class="element-variable"></div>
...
Créer un lien tracké pour Google Analytics
Google Analytics est très pratique et très complet lorsqu'il s'agit de visualiser et d'analyser le trafic d'un site.
Pour une campagne publicitaire spécifique, l'outil de création d'URL permet de créer des liens traqués pour retrouver plus facilement l'impact de cet apport de visibilité. Il suffit de se rendre à l'adresse de l'outil en ligne, et de remplir le formulaire pour obtenir une url spécifique à une campagne ou un événement. On peut entre autres indiquer la source de la campagne, le support, le nom... toutes les instructions sont fournies sur la page.
