Pas mal de bonnes pratiques PHP.
tl;dr
Un gros topo sur OPCache et comment bien le configurer.
C'est en effet toujours utile d'apprendre à réécrire du code de zéro et sans framework.
Ensuite, la bonne alternative est selon moi l'utilisation des micro-frameworks (comme Slim Framework ou Silex) où vous avez le strict minimum pour exposer des pages et ensuite vous ajoutez simplement ce dont vous avez besoin.
Comment bien configurer une installation de PHP (que ce soit mod_php ou php-fpm).
Une discussion intéressante sur les méthodes pour invalider OPcache après un déploiement effectué par un switch de symlink. En pratique, ça permet d'éviter un restart du web server (même graceful) et de minimiser l'impact d'un déploiement.
Tout le problème se situe au niveau de la gestion des requêtes actuellement traitées par le web server au moment du déploiement. L'idée est d'éviter qu'elles commencent avec l'ancienne version du code et passent sur la nouvelle version en cours de route.
Un article assez long mais qui donne quelques pistes pour intégrer l'utilisation de Vue.js + Webpack dans une application PHP.
Les problèmes soulevés dans l'article sont bien réels mais malgré tout j'aime le PHP parce qu'il n'a pas ce côté black box qu'a Java par exemple. En gros, on sait ce qu'il se passe dans le code à tout instant et ça évite les effets de bords.
Et depuis plusieurs années maintenant il y a beaucoup de framework et d'initiatives qui rendent les choses beaucoup plus solides, stables et inter-opérables (PSR par exemple).
En utilisant le client HTTP Guzzle en PHP, je me suis aperçu que parfois le retour d'une requête GET n'est pas encodé en UTF-8. Et ça semble dépendre de l'environnement. Dans mon cas ça ne marchait pas en local mais sur le serveur oui. Et si vous vous contentez simplement de ne pas en tenir compte et d'ajouter utf8_encode sur la payload de la réponse, ça donne des choses bizarre.
Du coup voici une vérification que vous pouvez faire :
$body = (string) $res->getBody();
if (!preg_match('!!u', $body)) {
$body = utf8_encode($body);
}Une regex pour valider un hashtag. Implémentation en PHP.
<?php
/**
* PHP Regex to validate a Twitter hashtag
*
* Useful for validating a text input (an HTML form in your CMS or custom application) that must be a valid Twitter hashtag.
* Valid examples: #a, #_, #_1, #_a, #1a, #áéìôü, #123hàsh_täg446
* Invalid examples: #1, ##hashtag, #hash-tag, #hash.tag, #hash tag, #hashtag!, (any hashtag that is more than 140 characters long, hash symbol included)
*
* Regex explanation:
* First, the lookahead assertion (?=.{2,140}$) checks the minimum and max length, as explained here http://stackoverflow.com/a/4223213/1441613
* A hash symbol must be the first character. The allowed values for the hash symbol can be expressed with any of the following subpatterns: (#|\\uff0){1}, (#|\x{ff03}){1}, or (#|＃){1}.
* A hashtag can contain any UTF-8 alphanumeric character, plus the underscore symbol. That's expressed with the character class [0-9_\p{L}]*, based on http://stackoverflow.com/a/5767106/1441613
* A hashtag can't be only numeric, it must have at least one alpahanumeric character or the underscore symbol. That condition is checked by ([0-9_\p{L}]*[_\p{L}][0-9_\p{L}]*), similar to http://stackoverflow.com/a/1051998/1441613
* Finally, the modifier 'u' is added to ensure that the strings are treated as UTF-8.
*
* More info:
* https://github.com/twitter/twitter-text-conformance
* https://github.com/nojimage/twitter-text-php
* https://github.com/ngnpope/twitter-text-php
*/
preg_match('/^(?=.{2,140}$)(#|\x{ff03}){1}([0-9_\p{L}]*[_\p{L}][0-9_\p{L}]*)$/u', '#hashtag');Un CMS sans base de données codé en PHP.
Assez standard en terme de fonctionnalités mais il a l'air assez propre.
Un outil pour tester les différentes fonctions utilisant les regex de PHP.
Une lib d'abstraction de base de données. C'est une alternative à FluentPDO.
Utiliser Webpack et PHP en parallèle.