PHP

PHP8

WordPress : tester la compatibilité avec PHP 8

by · Lecture: 3 minutes

Aujourd’hui, nous allons tester la compatibilité avec PHP 8 de tous les sites WordPress du serveur, en ligne de commande et de manière automatisée.

Fin du support pour PHP 7.4 pour novembre 2022

Le cycle de vie de PHP 7.4 est atteint et il n’y aura plus de mises à jour ni de support à la fin du mois de novembre 2022. Cela signifie qu’il est désormais temps de passer sous PHP 8 pour bénéficier des dernières améliorations techniques de PHP et des mises à jour de sécurité.

Et mieux vaut s’y prendre un peu plus tôt, notamment si vous possédez une boutique WooCommerce pour ne pas être pris au dépourvu en pleine période de fêtes (Black Friday, Noël…).

Tester votre code avec php-parallel-lint

Nous allons créer un nouveau projet composer avec php-parallel-lint qui se chargera de scanner notre code et de remonter toutes les incompatibilités, fonctions obsolètes ou problématiques susceptibles de donner des avertissements ou des erreurs lors du basculement vers PHP 8.

Commençons par installer php-parallel-lint:

composer create-project php-parallel-lint/php-parallel-lint php-parallel-lint --no-dev

# ou avec un user :
# sudo su -l www-data -s /bin/bash -c "composer create-project php-parallel-lint/php-parallel-lint php-parallel-lint --no-dev"

Résultat de la commande:

Creating a "php-parallel-lint/php-parallel-lint" project at "./php-parallel-lint"
Installing php-parallel-lint/php-parallel-lint (v1.3.2)
  - Installing php-parallel-lint/php-parallel-lint (v1.3.2): Extracting archive
Created project in /Users/matt/Downloads/project-ACTAGIS-php8-202208/php-parallel-lint
Loading composer repositories with package information
Updating dependencies
Lock file operations: 4 installs, 0 updates, 0 removals
  - Locking nette/tester (v2.4.2)
  - Locking php-parallel-lint/php-console-color (v1.0.1)
  - Locking php-parallel-lint/php-console-highlighter (v1.0.0)
  - Locking squizlabs/php_codesniffer (3.7.1)
Writing lock file
Installing dependencies from lock file
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files

Installons maintenant l’outil qui permet de coloriser le code dans notre console:

composer require --dev php-parallel-lint/php-console-highlighter

Résultat:

Info from https://repo.packagist.org: #StandWithUkraine
Using version ^1.0 for php-parallel-lint/php-console-highlighter
./composer.json has been created
Running composer update php-parallel-lint/php-console-highlighter
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking php-parallel-lint/php-console-color (v1.0.1)
  - Locking php-parallel-lint/php-console-highlighter (v1.0.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Downloading php-parallel-lint/php-console-color (v1.0.1)
  - Downloading php-parallel-lint/php-console-highlighter (v1.0.0)
  - Installing php-parallel-lint/php-console-color (v1.0.1): Extracting archive
  - Installing php-parallel-lint/php-console-highlighter (v1.0.0): Extracting archive
Generating autoload files

Scanner le code avec php-parallel-lint

Voici la syntaxe pour scanner votre code:

 ./php-parallel-lint/parallel-lint FOLDER_TO_SCAN -p PHP_VERSION

Lire la suite

PHP Composer Banner

PHP : installer Composer sous Ubuntu Server

by · Lecture: 2 minutes

Voici comment installer Composer, le gestionnaire de paquets PHP qui va grandement vous simplifier la vie en installant toutes les dépendances dont vous avez besoin en une seule commande, sous Ubuntu Server.

Composer est installé sur ma machine mais j’ai besoin en ce moment de vérifier si le code des sites hébergés par le serveur est compatible avec PHP 8. Je peux tout rapatrier sur ma machine et tester tout cela localement mais cela me semble quand même beaucoup plus simple de le faire depuis le serveur, sans transfert de fichiers.

Composer est un outil populaire de gestion des dépendances pour PHP, créé principalement pour faciliter l’installation et les mises à jour des dépendances des projets. Il vérifiera de quels autres paquets un projet spécifique dépend et les installera pour vous en utilisant les versions appropriées selon les exigences du projet. Composer est également couramment utilisé pour lancer de nouveaux projets basés sur des cadres PHP populaires tels que Symfony et Laravel.

Paquets pré-requis

On commence par vérifier que tout est à jour:

apt update && apt upgrade

Ensuite, on vérifie que les paquets pré-requis sont bien installés:

apt install curl unzip php-cli

Installer composer sur le serveur

On télécharge le fichier d’installation, soit avec php, soit avec curl : 

# avec php 

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" 

# ou alors avec curl

curl -sS https://getcomposer.org/installer -o composer-setup.php

On installe ensuite composer très simplement avec PHP. On installe :

php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Voici le résultat de la commande:

All settings correct for using Composer
Downloading...

Composer (version 2.4.1) successfully installed to: /usr/local/bin/composer
Use it: php /usr/local/bin/composer

Cela l’installe sous /usr/local/bin/composer de manière globale.

Mettre à jour composer

Pour mettre à jour composer, il suffit d’un simple:

composer update

Et voilà, composerest maintenant installé sur le serveur. Cela nous simplifiera grandement le travail dans quelques jours. Stay tuned!

WordPress : rediriger la page d'attachement vers l'article auquel les fichiers médias appartiennent photo

WordPress : rediriger la page d’attachement vers l’article parent

by · Lecture: 3 minutes

WordPress publie par défaut une page d’attachement pour chaque fichier média que vous publiez sur votre site.

En règle générale, un fichier média (image, vidéo, autre) appartient à un article: on attache souvent ce type de fichier lors de la rédaction des articles, pour les insérer dans le corps des billets.

Le problème est donc que WordPress crée gentiment une page dédiée à chaque média publié. Cette page ne contient aucun contenu, à part afficher le média en question, ce qui n’est pas vraiment idéal au point de vue SEO puisque l’on se retrouve avec énormément de pages mais qui ne seront jamais indexées au vu du contenu inexistant. S’il est donc superflu d’avoir ces pages, autant s’en séparer!

C’est là que nous allons tenter d’être malin : pourquoi ne pas rediriger ces pages d’attachement vers l’article auquel ces fichiers media appartiennent?

Jusqu’à très récemment, j’utilisais le module Origin de The SEO Framework, qui fonctionne très bien si le média a été uploadé sur un article. La page d’attachement est alors automatiquement redirigée vers l’article.

Le hic, c’est que si le fichier média a été uploadé directement depuis la page WP Admin > Média, alors nous sommes redirigé vers /wp-admin, ce qui ne fait aucun sens.

Voici donc la solution que j’utilise sur le site:

<?php
/*
Script Name: Redirect attachment page to parent post.
Script URI: https://www.skyminds.net/?p=32314
Description: Redirects attachment to parent post (if it exists), or redirects to the homepage otherwise.
Version: 2.6.0
Author: Matt Biscay
Author URI: https://mattbiscay.com
*/
add_action( 'template_redirect', 'sky_redirect_attachment_to_post' );
function sky_redirect_attachment_to_post(){
  // if not an attchment, bail out early
  if( !is_attachment() ) {
    return;
  }
  // check if parent post is defined
  if( isset( $post ) && isset( $post->post_parent ) && is_numeric( $post->post_parent ) && ( $post->post_parent != 0 ) ) :
    // redirect to parent post
    wp_redirect( esc_url( get_permalink( $post->post_parent ) ) ); exit;
  else: // media has been uploaded through the Media page or is unattached to a specific post
    // redirect to homepage
    wp_redirect( esc_url( home_url( '/' ) ) ); exit;
    // or redirect to the media itself
    // wp_redirect( esc_url( wp_get_attachment_url() ) ); exit;
  endif;
}

Ce code est à copier-coller dans le fichier functions.php de votre thème enfant. Vous pouvez également l’enregistrer en tant que plugin.

Une fois activé, si vous visionnez l’adresse d’une page d’attachement, vous devriez être redirigé sur l’article parent.

Notez que je vous ai mis 2 possibilités pour la redirection lorsque le media n’a pas été attaché à un article: une redirection vers la page d’accueil ou alors vers le fichier média directement.

A vous de choisir ce qui vous correspond le mieux :)

macos monterey wallpaper

Installer composer et PHP sous MacOS Monterey

by · Lecture: 5 minutes

Depuis la mise à jour MacOS Monterey (v12+) et pour toutes les versions à venir, Apple ne fournit plus de binaire PHP installé par défaut.

Si vous utilisez composer par exemple pour l’un de vos scripts ou plugin, voici le message d’erreur que vous pouvez obtenir:

composer update --no-plugins --no-scripts
env: php: No such file or directory

J’ai tenté pas mal de solutions, comme installer PHP avec brew mais cela n’a pas résolu le problème.

Error: Permission denied @ apply2files

C’est l’une des erreurs obtenues lors de l’installation de paquets avec brew, directement après la mise à jour vers Monterey:

Error: Permission denied @ apply2files - /usr/local/lib/node_modules/npm/node_modules/.bin/node-gyp

Si cela vous arrive, c’est un problème de permissions sur le répertoire /user/local, la solution est simple, il faut redonner les bonnes permissions à votre utilisateur avec cette commande:

sudo chown -R $(whoami):admin /usr/local/* \
&& sudo chmod -R g+rwx /usr/local/*

Voilà déjà un problème réglé.

Installer composer sous MacOS Monterey

La véritable solution, toute simple finalement, est de réinstaller composer, qui se charge alors d’installer la version idoine de PHP.

On installe composer avec brew:

brew install composer

Résultat:


==> Downloading https://ghcr.io/v2/homebrew/core/php/manifests/8.1.0
Already downloaded: /Users/matt/Library/Caches/Homebrew/downloads/6dba7b955c116a258cc340994e9e9ed7dfdfe3ab7668f0f9adb5dfcdaaf303a2--php-8.1.0.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/php/blobs/sha256:dbbf3f0e595af9a72f6dcf7fef1890c6152bf9fb1be83f166b467393176c4aa5
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:dbbf3f0e595af9a72f6dcf7fef1890c6152bf9fb1be83f166b4
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/composer/manifests/2.1.14
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/composer/blobs/sha256:02f5fed3d67b82fb827078ffcd486a4a455d1f94e94d0701d779238d4e10903e
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:02f5fed3d67b82fb827078ffcd486a4a455d1f94e94d0701d77
######################################################################## 100.0%
==> Installing dependencies for composer: php
==> Installing composer dependency: php
==> Pouring php--8.1.0.monterey.bottle.tar.gz
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_ini /usr/local/etc/php/8.1/php.ini system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_dir /usr/local/share/pear system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set doc_dir /usr/local/share/pear/doc system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set ext_dir /usr/local/lib/php/pecl/20210902 system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set bin_dir /usr/local/opt/php/bin system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set data_dir /usr/local/share/pear/data system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set cfg_dir /usr/local/share/pear/cfg system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set www_dir /usr/local/share/pear/htdocs system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set man_dir /usr/local/share/man system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set test_dir /usr/local/share/pear/test system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_bin /usr/local/opt/php/bin/php system
==> /usr/local/Cellar/php/8.1.0/bin/pear update-channels
🍺  /usr/local/Cellar/php/8.1.0: 512 files, 79.9MB
==> Installing composer
==> Pouring composer--2.1.14.monterey.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/composer
Target /usr/local/bin/composer
already exists. You may want to remove it:
  rm '/usr/local/bin/composer'

To force the link and overwrite all conflicting files:
  brew link --overwrite composer

To list all files that would be deleted:
  brew link --overwrite --dry-run composer

Possible conflicting files are:
/usr/local/bin/composer
==> Summary
🍺  /usr/local/Cellar/composer/2.1.14: 3 files, 2.2MB
==> Running `brew cleanup composer`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

Comme vous pouvez le constater dans les résultats précédents, le lien symbolique n’a pas été créé correctement donc nous allons le corriger à la main.

On teste notre commande avec --dr-run d’abord:

brew link --overwrite --dry-run composer
Would remove:
/usr/local/bin/composer

Tout semble bon, on crée le lien symbolique:

brew link --overwrite composer
Linking /usr/local/Cellar/composer/2.1.14... 1 symlinks created.

On reteste maintenant notre mise à jour de plugin via composer:

composer update --no-plugins --no-scripts

Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
Generating autoload files

Impeccable, composer et php sont de nouveau opérationnels sous Monterey.

PHP: résoudre l'erreur

PHP: résoudre l’erreur “file_get_contents(): SSL operation failed with code 1”

by · Lecture: 2 minutes

J’ai récemment joué avec l’API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d’ajouter au site les données structurées idoines.

Il se trouve qu’en local, lorsque l’on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n’est pas configuré avec le bundle de certificats OpenSSL:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2

Warning: file_get_contents(): Failed to enable crypto in ...php on line 2

Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2

Si cela vous arrive, plusieurs solutions s’offrent à vous.

Méthode 1: configuration de PHP côté machine/serveur

1. Vérifiez qu’OpenSSL est bien installé sur votre machine (il devrait l’être sur le serveur!).

2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:

openssl.cafile=/usr/local/etc/openssl/cert.pem

3. Redémarrez le service PHP.

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Au lieu de m’embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l’on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.

Voici la fonction en question:

/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
	$c = curl_init();
	curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $c, CURLOPT_URL, $URL );
	$contents = curl_exec( $c );
	curl_close( $c );
	if( $contents ) :
		return $contents;
	else:
		return false;
	endif;
}

La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d’un tableau qui n’existe pas.

On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c’est un sujet à aborder une autre fois).

Gravity Forms : activer l'anti-spam honeypot sur tous les formulaires photo

Gravity Forms : supprimer les entrées mais garder les fichiers uploadés sur le site

by · Lecture: 2 minutes

Gravity Forms garde en base de données toutes les entrées des formulaires. Sur un site qui génère énormément de demandes (formulaire de contact, demandes d’informations, formulaire de commande ou pré-commande…).

Cela signifie des milliers d’enregistrements dans la base de données, ce qui n’est pas toujours souhaitable, pour des raisons de stockage et de performance.

Supprimer les entrées des formulaires Gravity Forms

Si vous avez besoin de supprimer les entrées créées par Gravity Forms une fois que le message a été envoyé, vous pouvez utiliser cette fonction:

// Delete all entries from form ID  1.
add_action( 'gform_after_submission_1', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
    GFAPI::delete_entry( $entry['id'] );
}

Dans l’exemple ci-dessus, on ne supprime que les entrées du formulaire qui a l’ID 1. Si vous souhaitez supprimer toutes les entrées de tous les formulaires Gravity Forms d’un site, il suffit d’enlever le _1de la cible de l’action gform_after_submission:

// Delete all entries from all forms.
add_action( 'gform_after_submission', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
    GFAPI::delete_entry( $entry['id'] );
}

Garder les fichiers uploadés lors de la suppression des entrées

Attention: supprimer les entrées Gravity Forms revient également à supprimer les fichiers qui auront été uploadés via les formulaires. C’est tout à fait normal puisqu’ils font partie des champs du formulaire.

Pour garder les fichiers uploadés, même si les entrées associées sont supprimées, il faut utiliser le filtre gform_field_types_delete_files:

add_filter( 'gform_field_types_delete_files', '__return_empty_array' );

Supprimer les fichiers associés à un champ upload particulier

Si vous souhaitez supprimer tous les fichiers qui auront été uploadés via un champ upload particulier, il suffit de préciser ce champ dans le tableau $field_types avant de le passer à gform_field_types_delete_files:

add_filter( 'gform_field_types_delete_files', 'sky_delete_custom_upload_field' );
function sky_delete_custom_upload_field( $field_types ) {
    $field_types[] = 'my_custom_upload_field';
    return $field_types;
}

Dans cet exemple, notre champ upload s’appelle my_custom_upload_field.

Gravity Forms : activer l'anti-spam honeypot sur tous les formulaires photo

Gravity Forms : activer l’anti-spam honeypot sur tous les formulaires

by · Lecture: 1 minutes

Gravity Forms permet de créer rapidement des formulaires avec des logiques conditionnelles sous WordPress.

Dans les options de Gravity Forms, il existe une option qui ajoute un champ caché au formulaire, “honeypot”, qui permet d’éviter le spam mais qui doit être activé manuellement pour chaque formulaire, ce qui peut être rapidement fastidieux selon le nombre de formulaires que vous avez sur le site.

Voici comment activer et ajouter le champ honeypot à tous vos formulaires, automatiquement: 

<?php
/**
 * Enforce anti-spam honeypot on all Gravity forms.
 *
 * @param array $form The current form to be filtered.
 * 
 * @return array
 */
add_filter( 'gform_form_post_get_meta', __NAMESPACE__ . '\\sky_enforce_gravity_forms_anti_spam_honeypot' );
function sky_enforce_gravity_forms_anti_spam_honeypot( $form ): array {
	$form['enableHoneypot'] = true;
	return $form;
}

Et voilà, une protection supplémentaire et automatique pour tous vos formulaires !

PHP : solution pour l'erreur

PHP : solution pour l’erreur “preg_match(): Compilation failed: invalid range in character class”

by · Lecture: 1 minutes

Lors de la mise à jour d’un site vers PHP 7.4, je suis tombé sur cette erreur :

preg_match(): Compilation failed: invalid range in character class at offset 20 session.php on line 278

Depuis PHP 7.3, le moteur PCRE – qui est responsable de la gestion des expressions régulières – a été migré vers PCRE2.

Or, il s’avère que PCRE2 est plus strict dans la validation des pattern et c’est la raison pour laquelle, après la mise à jour de PHP, certaines expressions régulières ne peuvent plus être compilées correctement.

Voici un exemple d’expression régulière qui fonctionnait avant PHP7.3:

preg_match('/[\w-.]+/', ''); // this will not work in PHP7.3

Voici maintenant le même exemple mais qui sera désormais valide sous PHP 7.3 et les versions ultérieures :

preg_match('/[\w\-.]+/', ''); // the hyphen needs to be escaped

Comme vous pouvez le constater dans le deuxième exemple, il faut maintenant échapper le tiret (hyphen) avec un backslash.

Une fois la modification faite, plus d’erreur à ce niveau.

Serveur dédié: passage à PHP 7.4 photo

Serveur dédié: passage à PHP 7.4

by · Lecture: 2 minutes

C’est Noël avant l’heure : PHP version 7.4 est désormais disponible! Ni une ni deux, elle est déjà installée sur le serveur.

Je vous conseille de jeter un petit coup d’oeil aux nouveautés de PHP 7.4, cela se modernise!

Si vous souhaitez sauter le pas, voici un petit tuto pour l’installation.

Étape 1 : installer le dépôt d’Ondrej

Dans le terminal, installez le dépôt d’Ondrej. Il est très souvent mis à jour et permet de bénéficier de pas mal de paquets à jour, même sur des distributions anciennes:

add-apt-repository ppa:ondrej/php

Étape 2 : installation de PHP 7.4

J’ai juste repris la liste des paquets PHP7.3 déjà installés puis changé le numéro de version.

Cela nous donne donc:

apt install php-igbinary php-imagick php-redis php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip

Note: il vous reste ensuite à modifier php.iniainsi que votre pool PHP selon vos besoins.

Étape 3: modification du server block

L’étape finale est la modification de votre server block. Sous NginX, éditez le fichier de configuration de votre site pour pointer vers le socket de PHP7.4:

#fastcgi_pass unix:/run/php/php7.3-fpm.sock;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;

Il suffit ensuite de relancer NginX et PHP:

service php7.4-fpm start && service nginx restart

Et voilà! Bonnes mises à jour !

NginX : résoudre

NginX : résoudre “upstream sent too big header while reading response header from upstream”

by · Lecture: 1 minutes

Nginx: des entêtes trop larges

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:

upstream sent too big header while reading response header from upstream

Solution: augmenter la taille des entêtes

Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.

Il ne reste plus ensuite qu’à relancer le serveur NginX:

service nginx restart

Hop, problème réglé.

PHP : ajouter les directives

PHP : ajouter les directives “HttpOnly” et “Secure” aux cookies de session

by · Lecture: 1 minutes

Les directives “HttpOnly” et “Secure”

A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives “HttpOnly” et “Secure”.

Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.

Edition de php.ini

On édite donc notre fichier php.ini:

nano /etc/php/7.2/fpm/php.ini

Et on modifie ces valeurs :

session.cookie_httponly 1
session.cookie_secure 1
session.use_only_cookies 1

Enregistrez le fichier et relancez PHP:

service php7.2-fpm restart

Testez votre site de nouveau : les cookies de session contiennent maintenant les deux nouvelles directives :

set-cookie: PHPSESSID=7d5h81tfiuna3p2p00o1v7b13q; path=/; secure; HttpOnly

Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site.

Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.

WordPress : corriger l'erreur

WordPress : corriger l’erreur “Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given”

by · Lecture: 1 minutes

Je travaille actuellement sur un projet Codeable qui nécessite de passer de PHP5.6 à PHP7.2. Le site en question est une boutique WooCommerce avec un thème custom qui est hébergé chez WPEngine. Jusque là, tout va bien.

Lors de la migration sur un serveur PHP 7.4, le site de developpement (Staging) affiche alors un message d’avertissement sur toutes les pages :

Parameter 1 to wp_default_styles() expected to be a reference, value given
Parameter 1 to wp_default_scripts() expected to be a reference, value given

Après avoir passé un bon moment à éliminer les causes (plugins et thème), il se trouve que c’est un bug de WordPress 4.9.8 (la dernière version en date) dont il est question dans le ticket #44979.

Voici la solution temporaire à ce problème :

  1. éditez /wp-includes/script-loader.php
  2. retirez le caractère & de l’argument des fonctions wp_default_scripts() et wp_default_styles()
  3. sauvegardez le fichier
  4. rechargez le site, les deux messages d’avertissement ont disparu.

Voilà, ce n’est qu’un hotfix mais ce bug devrait être corrigé dans la prochaine version de WordPress – version 4.9.9 – qui sortira prochainement.