submitter:username — rechercher les publications d'un utilisateur domain:example.com — rechercher les liens d'un domaine
submitter:username
domain:example.com
OK. Moi je pense toujours à l'utilisation par le grand public, donc PHP + MySQL éventuellement ou juste PHP (+ SQLite ou autre). Ruby, Node.JS, etc. c'est impossible ou presque sur du mutualisé ! Mais heureusement le langage n'enlève iren à la qualité, juste rajoute de la difficulté ;)
Le pire, c'est que la méthode est référencée officiellement dans la documentation de ce système de gestion de dépendances pour PHP…
Bon, c'est du PHP ;-)
Une autre solution, quand on s'auto-héberge et avons la possibilité de maîtriser sa configuration c'est de bloquer l'accès au fichier xmlrpc.php :
<IfModule mod_alias.c> RedirectMatch 403 (.*)/xmlrpc\.php$ </IfModule>
Voilà !
Cette semaine je ne travaille pas, alors je vais essayer d'en profiter pour me mettre un peu sur mon blog :
Dans le même temps, j'essayerai de mettre en œuvre une réelle implémentation d'un moteur de templates en PHP.
Salute,
Oui bien-sûr je suis capable d'installer ce dont il y a besoin ce sont les Requirements qui font fuir : To install Cyca, you will need: - a webserver - cURL - PHP > 5.6.4 with the following extensions: (Cyca is built and tested against PHP 7) OpenSSL, PDO, Mbstring, Tokenizer, XML, GD/Imagick, cURL, intl, zip - composer - node - a database server, which can be either: MySQL/MariaDB, Postgres, SQLite, SQL Server - redis - ImageMagick - wkhtmltopdf (Cyca ships with a composer dependency but you are free to install your own version) - xvfb (under GNU-Linux)
Tcho !
<script>
eval()
su
sudo
/etc
La méthode pour afficher les noms de fichiers avec grep m'a littéralement choqué.
Un petit coup de man grep et hop : find . -name "*.php" -exec grep -H "<?php" {} \;.
man grep
find . -name "*.php" -exec grep -H "<?php" {} \;
C'est quand même mieux qu'un trick, je trouve ^^
EDIT : Ah tiens, c'est déjà dit dans les commentaires sur l'article. Ça m'apprendra à garder des trucs en réserve et à réagir sans vérifier ça.
Je suis à l'origine dev PHP et merci de rétablir un peu de vérité.
Depuis bientôt 2 ans, je fais du jQuery et de l'Angular… La liberté qu'offre PHP me manque… et le JS me fait vomir :)
Oui mais justement il ne s’agissait ni de critique de couleur de peau ou de genre. C’est comme si quelqu’un déclare « php c’est de la merde ». C’est irrespectueux envers les devs php, mais il a le droit de l’exprimer même si ce n’est pas fait avec des pincettes.
Placer des limites peut être une bonne chose (on ne vas pas permettre le racisme ou l’homophobie par exemple), en revanche, exprimer avec véhémence un désaccord, parfois ça a du bon. La tolérance, c’est aussi accepter de laisser les gens s’exprimer, même si ça ne nous plait pas et peut choquer.
C’est cool que tu sois passé, j’attendais ton passage pour poser une question ^^
J’ai parcouru le changelog : “PHP 7.2 is no longer supported due to upstream not supporting this version for the entire lifecycle of the 20.09 release”. Concrètement ça veut dire qu’il n’est pas possible de construire php 7.2 ou juste que ce n’est pas “maintenu” ?
Merci, Tcho !
Et comme on ne peut pas migrer tous les anciens projet (et ceux en cours) vers PHP 8 à court termes, on a aussi un article pour le faire quand même en PHP 5 et 7. (je dis ça en commentaire pour éviter de polluer le flux avec deux articles des arsouyes le même jour).
Je suis d’accord concernant bon nombre de choses. Beaucoup peut être reproché à Wordpress (et aux autres) et j’avoue que le code c’est le bordel. Cependant, on profite d’un logiciel fonctionnel, stable et relativement performant (avant qu’un installe tout et n’importe quoi en plugin), tout en gardant une bonne compatibilité depuis presque 20 ans ! C’est plus facile de garder un code clean et à la dernière mode quand on peut faire table raze assez souvent.
PHP c’est dégueu, y’a même pas de conventions de nomage et les paramètres sont passés sans cohérence d’une fonction à l’autre. À l’inverse, Python 3 c’est clean, mais ils ont du tout casser.
Ce serait pareil pour WordPress. Perso, je n’affectionne pas particulièrement PHP et je préfère tout développer from scatch. Mais WordPress + WooCommerce permet de faire de belles choses, qui fonctionnent assez rapidement.
Ça me permet de passer le plus clair de mon temps sur le front, tout en profitant de bonnes fonctionalités de base et de ne pas avoir à réinventer la roue. Et quand il manque un truc, en général il y a un plugin sur lequel je peux me reposer (à nouveau, j’utilise juste sa logique back-office et fait ma sauce pour le front).
Bref, tout dépend de ce que l’on veut faire. Je déplore pour ma part l’absence de framework e-commerce reconnu en Node.js et j’utilise WordPress/WooCommerce un peu comme un framework. Il faut admettre que si tu dois tout reprendre from scratch : un programme fidélité, la gestion des clients, des promos et j’en passe, ça devient vite très long.
J’ai plusieurs ptites machines pour l’autohébergement :
Le tout est interconnecté avec du wireguard avec uniquement du logiciel libre et sans dépendances à des services extérieurs sauf pour le VPS (mais c’est fait par du gentil).
En parlant de chiffrement sur PHP, il est difficile de ne pas citer libsodium, et avec un très bon article : https://jolicode.com/blog/libsodium-pour-les-nuls-ou-la-cryptographie-en-php
