Je me suis rendu compte, en rédigeant mes articles sur l’installation d’un serveur dédié, que certains blocs de code Bash ne passaient pas automatiquement à la ligne.
Résultat : une longue commande pouvait s’afficher sur une seule ligne, dépasser de son conteneur, puis créer une barre de défilement horizontale peu élégante. Ce n’est pas dramatique, mais ce n’est pas très agréable à lire, surtout sur mobile.
Le code est généralement affiché avec la balise <pre>, qui sert à afficher du texte préformaté. Elle conserve les espaces, les tabulations et les retours à la ligne. Cependant, par défaut, elle ne replie pas toujours les longues lignes comme un paragraphe classique.
Voici donc plusieurs façons de forcer, contrôler ou éviter le retour à la ligne dans les blocs pre, selon le rendu souhaité.
Pourquoi les blocs pre ne vont pas toujours à la ligne
La balise <pre> signifie “preformatted text”. Elle respecte donc la mise en forme originale du texte. C’est précisément ce qu’on veut pour du code : indentation, espaces, retours à la ligne et alignements restent intacts.
Mais cette fidélité a un effet secondaire : les longues lignes peuvent dépasser horizontalement.
Par exemple, une commande comme celle-ci peut rapidement casser la mise en page :
rsync -avh --delete --progress --exclude="cache/" --exclude="uploads/cache/" /home/www/example.com/public_html/ user@backup-server:/volume1/backups/example.com/public_html/Code language: JavaScript (javascript)
Sur ordinateur, une barre de défilement horizontale peut rester acceptable. Sur mobile, en revanche, elle devient vite pénible. On peut donc choisir de forcer le retour à la ligne.
Solution simple : white-space: pre-wrap
La solution la plus simple consiste à utiliser white-space: pre-wrap. Cette valeur conserve les espaces et les retours à la ligne, tout en autorisant le repli automatique des longues lignes.
pre {
white-space: pre-wrap;
}Code language: CSS (css)
C’est le comportement le plus utile quand on veut garder l’indentation du code, mais éviter les débordements horizontaux.
En clair :
- les retours à la ligne existants sont conservés ;
- les espaces multiples restent visibles ;
- les lignes trop longues peuvent être repliées ;
- le bloc reste lisible sur mobile.
C’est souvent le meilleur compromis pour les articles de blog techniques.
Version moderne recommandée
Pour un site actuel, je recommande généralement cette base :
pre,
pre code {
white-space: pre-wrap;
overflow-wrap: anywhere;
}Code language: CSS (css)
white-space: pre-wrap autorise le retour à la ligne tout en conservant la mise en forme. Ensuite, overflow-wrap: anywhere permet au navigateur de couper une chaîne très longue si elle ne contient aucun espace naturel.
C’est utile pour les URLs, les chemins de fichiers interminables, les tokens, les commandes longues, ou les chaînes générées automatiquement.
La propriété overflow-wrap sert justement à éviter qu’une chaîne autrement insécable dépasse de sa boîte. MDN précise aussi que l’ancien nom word-wrap reste un alias historique largement reconnu.
Variante plus prudente : overflow-wrap: break-word
Si vous trouvez que anywhere coupe parfois les chaînes de manière trop agressive, utilisez plutôt break-word.
pre,
pre code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Cette version reste très pratique, mais elle se montre un peu moins brutale. Le navigateur essaie d’abord de couper aux endroits naturels, puis il casse la chaîne si elle dépasse vraiment.
Pour un blog technique, c’est souvent le réglage que je préfère. Il évite les débordements sans transformer le code en puzzle.
Faut-il utiliser word-break?
On voit souvent des snippets avec word-break: break-all. Personnellement, je l’éviterais pour des blocs de code.
pre {
word-break: break-all;
}Code language: CSS (css)
Cette règle force des coupures très agressives. Elle peut casser les mots, les commandes, les chemins et les options au milieu d’un segment. Le résultat devient vite difficile à lire.
word-break contrôle la manière dont les sauts de ligne apparaissent quand le texte dépasse son conteneur. Mais, pour les longues chaînes dans du code, overflow-wrap donne souvent un résultat plus propre.
Je réserverais word-break: break-all à des cas très spécifiques, par exemple une colonne très étroite ou une interface d’administration où il faut absolument empêcher tout débordement.
Alternative : garder le scroll horizontal
Forcer le retour à la ligne n’est pas toujours le meilleur choix. Pour certains langages, un scroll horizontal peut mieux préserver la lisibilité du code.
Par exemple, dans un extrait de PHP, JavaScript ou SQL, une ligne coupée peut devenir ambiguë. On peut alors garder le comportement naturel de pre et simplement rendre le débordement plus propre.
pre {
overflow-x: auto;
max-width: 100%;
}Code language: CSS (css)
Cette approche laisse les lignes intactes, mais elle empêche le bloc de casser la mise en page globale.
C’est souvent le bon choix pour :
- des extraits de code longs ;
- du SQL ;
- des tableaux en texte brut ;
- des logs alignés ;
- des commandes où chaque espace compte ;
- du code que le lecteur va copier-coller.
Le scroll horizontal n’est donc pas forcément un défaut. Parfois, c’est même le comportement le plus fidèle au code.
La meilleure approche : choisir selon le type de contenu
Sur un blog technique, tous les blocs de code ne méritent pas le même traitement. Une commande Bash longue peut être repliée sans trop de problème. En revanche, un extrait de code structuré peut perdre en clarté s’il se replie automatiquement.
On peut donc définir deux styles différents.
Option 1 : code avec retour automatique à la ligne
.code-wrap pre,
pre.code-wrap {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Cette option convient bien aux commandes Bash, aux URLs, aux chemins de fichiers et aux snippets courts.
Option 2 : code avec scroll horizontal
.code-scroll pre,
pre.code-scroll {
white-space: pre;
overflow-x: auto;
max-width: 100%;
}Code language: CSS (css)
Cette option convient mieux aux extraits de code plus longs, où l’indentation et la structure comptent davantage.
Dans Gutenberg, on peut ajouter une classe CSS personnalisée au bloc Code depuis le panneau “Avancé”. Par exemple : code-wrap ou code-scroll.
Cibler les blocs Code de Gutenberg
Dans WordPress, les blocs Code de Gutenberg utilisent généralement la classe .wp-block-code. On peut donc cibler les blocs de code sans toucher à tous les éléments pre du site.
.wp-block-code {
max-width: 100%;
overflow-x: auto;
}Code language: CSS (css)
Si l’on veut forcer le retour à la ligne uniquement dans les blocs Gutenberg :
.wp-block-code code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Et si le thème ou le plugin de coloration syntaxique applique ses styles directement sur pre, on peut être un peu plus explicite :
.wp-block-code,
.wp-block-code code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
C’est souvent nécessaire avec les plugins de syntax highlighting, car ils ajoutent parfois plusieurs balises autour du code.
Cas particulier : Syntax Highlighting Code Block
Si vous utilisez un plugin comme Syntax Highlighting Code Block, le HTML peut ressembler à ceci :
<pre class="wp-block-code">
<span>
<code class="hljs language-css">...</code>
</span>
</pre>Code language: HTML, XML (xml)
Dans ce cas, il peut être utile de cibler à la fois pre, span et code à l’intérieur du bloc :
.wp-block-code,
.wp-block-code span,
.wp-block-code code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Si le plugin ajoute une barre horizontale, un style inline, ou une règle plus spécifique, il faudra peut-être adapter le sélecteur. Dans la majorité des cas, la règle ci-dessus suffit.
Une version propre pour les blogs techniques
Voici une base moderne, simple et plutôt sûre pour un blog WordPress technique :
.entry-content pre,
.entry-content .wp-block-code {
max-width: 100%;
overflow-x: auto;
}
.entry-content pre code,
.entry-content .wp-block-code code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Cette version combine les deux protections : le bloc ne dépasse pas de son conteneur, et le code peut revenir à la ligne si nécessaire.
Si vous préférez préserver les lignes longues et garder le scroll horizontal, utilisez plutôt :
.entry-content pre,
.entry-content .wp-block-code {
max-width: 100%;
overflow-x: auto;
}
.entry-content pre code,
.entry-content .wp-block-code code {
white-space: pre;
}Code language: CSS (css)
Cette variante est plus fidèle au code original. Elle convient mieux aux extraits complexes.
Et white-space: break-spaces ?
CSS propose aussi white-space: break-spaces. Cette valeur ressemble à pre-wrap, mais elle gère les espaces conservés de manière encore plus stricte.
pre {
white-space: break-spaces;
}Code language: CSS (css)
Elle peut être utile si vous affichez du texte où chaque espace doit vraiment compter. Cependant, pour des blocs de code classiques dans un article WordPress, pre-wrap reste généralement plus prévisible.
Anciennes syntaxes spécifiques aux navigateurs
À l’époque, on ajoutait souvent plusieurs propriétés spécifiques pour gérer les anciens navigateurs :
pre {
white-space: -moz-pre-wrap; /* Anciens navigateurs Mozilla */
white-space: -pre-wrap; /* Opera 4-6 */
white-space: -o-pre-wrap; /* Opera 7 */
word-wrap: break-word; /* Anciennes versions d’Internet Explorer */
}Code language: CSS (css)
Aujourd’hui, ces variantes n’ont plus vraiment d’intérêt pour un site moderne. white-space: pre-wrap est largement établi, et overflow-wrap remplace proprement l’ancien word-wrap.
Mémo rapide
/* Retour à la ligne dans pre, en conservant l'indentation. */
pre {
white-space: pre-wrap;
}
/* Retour à la ligne + longues chaînes cassées si nécessaire. */
pre,
pre code {
white-space: pre-wrap;
overflow-wrap: break-word;
}
/* Variante plus agressive pour URLs, tokens et chemins très longs. */
pre,
pre code {
white-space: pre-wrap;
overflow-wrap: anywhere;
}
/* Conserver les lignes intactes avec scroll horizontal. */
pre {
white-space: pre;
overflow-x: auto;
max-width: 100%;
}
/* Blocs Code Gutenberg. */
.wp-block-code,
.wp-block-code code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Conclusion
Pour forcer le retour à la ligne dans une balise pre, la règle de base reste très simple :
pre {
white-space: pre-wrap;
}Code language: CSS (css)
Pour un site moderne, j’ajouterais toutefois overflow-wrap: break-word, surtout si vous publiez des commandes longues, des URLs, des chemins de fichiers ou des logs.
pre,
pre code {
white-space: pre-wrap;
overflow-wrap: break-word;
}Code language: CSS (css)
Enfin, gardez en tête qu’un retour à la ligne forcé n’est pas toujours souhaitable. Pour du code complexe, un scroll horizontal propre peut parfois être plus lisible. Le bon choix dépend donc du contenu : commande Bash courte, logs, extrait PHP, SQL, configuration serveur ou simple mémo technique.
Comme souvent en CSS, la meilleure solution n’est pas la plus agressive. C’est celle qui respecte le contenu tout en évitant de massacrer la mise en page. Charmant programme.
Des obstacles techniques ? Je trouve des solutions sur-mesure pour que votre site WordPress/WooCommerce fonctionne sans accroc.
Tiens, j’aurais juré avoir posté un commentaire hier… Bon, le voila :
Récemment j’ai du administrer un serveur dédié et j’ai bloqué le SSH… Enfin j’ai autorisé le mauvais port sous iptables. Du coup j’ai pensé à toi :D
Ah les joies d’iptables… maintenant je laisse toujours une fenêtre de terminal ouverte pour tester si je n’ai pas fait d’âneries. Il me semble que l’on peut effectuer un “net boot” en cas de problèmes (cela éviterait de tout refaire si j’ai bien compris ?).
Dedibox propose un rescue mode, un service gratuit qui boot une distribution live ubuntu minimal dans un coin du serveur, et on peut s’y connecter via le port par défaut (22) et des identifiants générés spécialement pour le coup (donc niveau sécurité, c’est pas dérangeant). Après, vu qu’on est sur un autre OS, il faut passer en root et monter toutes les partitions pour pouvoir éditer les fichiers qu’on souhaite – qui se retrouvent souvent avec des noms barbares, genre /mnt/sda2/etc/rc2.d/K14firewall. C’est un peu barbare mais pas compliqué et surtout ça évite de tout reinstaller.
Plus d’infos ici pour dédibox, et apparemment OVH propose la même chose ici.
Merci Stéphane !
De rien ! Ça m’a moi-même évité de perdre de précieuses nuits…