Éditeurs et modération WP Registry
L'espace https://area.wpregistry.studiochampgauche.com/publish/ accueille les éditeurs externes. Un compte dont le courriel a été vérifié peut créer ses propres projets et publier leurs versions. Chaque publication rejoint la file de contrôle de l'opérateur ; ce contrôle intervient après publication. L'espace opérateur est https://area.wpregistry.studiochampgauche.com/moderate/.
Le portail https://wpregistry.studiochampgauche.com présente les projets publiés et disponibles, leurs téléchargements et le plugin de connexion WordPress. Son lien « Espace éditeur » mène à ce même espace de publication. Le portail et le registre sont livrés ensemble dans deux dossiers frères sous public_html, et partagent la base privée ; aucune seconde publication n'est nécessaire pour faire apparaître une version disponible dans le catalogue.
Préparer les comptes
Les interfaces sont organisées en trois espaces distincts, dans un visuel noir et blanc commun : Publications internes (/manage/) pour les projets attribués dans publishers, Espace éditeur (/publish/) pour les comptes inscrits, et Modération (/moderate/) pour les interventions opérateur. Les titres et les liens de section séparent projets, publications, historique et demandes. Dans la modération, les changements d'une version sont présentés avant l'examen et les actions de distribution. Les champs et les confirmations conservent leurs règles habituelles.
Après php cli.php init, exécuter php cli.php publishers-init. Cette commande prépare les tables supplémentaires, la clé d'authentification et les sessions privées. Sur une installation existante, conserver la base, signing.key, publisher.key et les archives. Les mots de passe et clés ne sont jamais fournis dans le kit.
Dans la configuration privée, renseigner publisher_mail_from avec une adresse autorisée par le serveur de messagerie local. Renseigner publisher_notice_to pour recevoir les avis de publication. Les messages passent par le transport local de PHP ; aucun compte SMTP n'est demandé aux éditeurs. Configurer et vérifier la délivrabilité réelle de ce transport sur l'hébergement. Un transport qui accepte le message ne prouve pas sa réception dans la boîte destinataire.
Protéger physiquement public_html/area.wpregistry.studiochampgauche.com/moderate/ avec Directory Privacy et inscrire ses utilisateurs autorisés dans le tableau operators. Le serveur exige une authentification Basic établie par Apache, une identité opérateur autorisée et HTTPS. Un compte éditeur ne devient jamais opérateur en modifiant un formulaire. Ne pas protéger /publish/ avec Directory Privacy : cet espace possède sa propre authentification.
Inscription et récupération
Le mot de passe comporte 8 à 25 caractères, dont une majuscule, un chiffre et un caractère spécial. La longueur est comptée en caractères Unicode, sans tronquer ni normaliser le mot de passe. Les caractères de contrôle sont refusés. Les mots de passe sont hachés avec Argon2id et ne sont jamais réaffichés.
Le code de validation reçu par courriel comporte 32 caractères hexadécimaux, expire après 15 minutes et ne sert qu'une fois. Le formulaire de validation doit être ouvert dans le navigateur ayant effectué l'inscription : la validation lie le courriel à cette tentative et au mot de passe choisi. Cela empêche une préinscription malveillante de faire activer le mot de passe d'un tiers. En cas de perte de cette session avant activation, recommencer l'inscription avec son propre mot de passe.
La récupération du mot de passe possède un code distinct. Une réinitialisation révoque les sessions ouvertes. Une session éditeur expire après 30 minutes d'inactivité ou huit heures au total. Les cookies sont protégés et les actions possèdent un jeton CSRF. Les tentatives de connexion, demandes de courriel et mutations sont limitées côté serveur.
La création des sessions anonymes est limitée avant écriture, par adresse et globalement. Les sessions des opérateurs authentifiés utilisent un répertoire distinct et ne consomment pas ce quota public : sa saturation ne doit pas empêcher l'accès aux outils d'intervention.
Créer un projet ou reprendre un projet existant
La création d'un nouveau nom devient disponible après le premier inventaire complet des fiches WordPress.org pour le type choisi. Cette précaution protège les noms déjà existants qui n'ont pas encore été importés. Les publications opérateur et les projets déjà attribués restent utilisables pendant l'import. La complétude des fiches est distincte du téléchargement de toutes les archives.
Un nouveau projet reçoit une identité de mise à jour sous le domaine du registre, par exemple https://area.wpregistry.studiochampgauche.com/plugins/mon-plugin. Reprendre exactement la valeur affichée dans l'en-tête Update URI du fichier principal. Pour un thème, elle se trouve dans style.css. Le dossier racine du ZIP doit correspondre à l'identifiant choisi. Les identités du fichier principal, de l'auteur et des mises à jour sont contrôlées puis conservées entre les versions.
Un éditeur ne peut pas prendre un projet parce qu'il connaît son nom. Pour un projet importé existant, il fournit une preuve publique et une explication ; l'opérateur vérifie cette preuve et confirme explicitement la propriété. Le serveur ne télécharge pas automatiquement l'adresse de preuve. Les versions historiques et l'identité de distribution existante sont conservées lors de cette attribution. Les projets déjà attribués à un autre compte ou réservés par la configuration ne peuvent pas être revendiqués librement.
Le nom plugin:wp-registry reste réservé aux opérateurs, même avant la première publication du client. Le kit cPanel réserve également les plugins Universal SMTP, Universal Legal Pages et le thème ReactWP à studio dans la configuration d'exemple ; adapter ces attributions si le nom opérateur change.
Publier une version
Ouvrir un projet attribué, remplir ses informations et transmettre son ZIP. Le serveur contrôle les champs, la propriété, les en-têtes et l'archive avant publication. Une version existante ne peut pas changer de contenu : utiliser un nouveau numéro de version pour modifier le code.
Les plugins et thèmes soumis ne sont jamais installés ni exécutés sur le serveur du registre. Leur PHP reste du contenu d'archive. Les fichiers sont conservés hors du dossier web et servis comme ZIP par leur empreinte SHA-256. Le nom du fichier envoyé ne choisit jamais son emplacement de stockage. Le comparateur lit les contenus comme des données et les affiche en texte échappé.
Les archives web sont limitées à 100 Mio, 30 000 entrées, 512 Mio décompressés et 64 Mio par fichier. Les chemins sont limités à 512 octets et 64 niveaux. Les contrôles refusent également une compression excessive, les chemins sortant du projet, les liens symboliques, les collisions de noms et les types ZIP non pris en charge. Le contrôle des parents utilise un index pour éviter que beaucoup de petits fichiers provoquent des recherches quadratiques. Un dépôt refusé ne remplace pas une version valide.
Les valeurs initiales de la configuration sont :
| Réglage | Limite |
|---|---|
publisher_storage_quota_bytes | 2 Gio par éditeur, historique conservé compris. |
publisher_daily_quota_bytes | 500 Mio par éditeur sur les dernières 24 heures. |
publisher_global_daily_quota_bytes | 10 Gio sur les dernières 24 heures pour les projets attribués aux comptes publics. |
storage_reserve_bytes | Conserver au moins 512 Mio disponibles lors du stockage d'une archive. |
Ces montants sont configurables en octets. Ils ne représentent pas la capacité mesurée de l'hébergement. La suppression d'une offre ou le retrait d'une version ne libère pas son quota : son archive reste dans l'historique. Ajuster les limites et la réserve avec les ressources réelles du compte, puis surveiller le stockage total du miroir et les fichiers temporaires. Les importations opérateur restent soumises à la réserve d'espace.
La vérification d'une archive protège le registre et l'intégrité de sa distribution. Elle ne certifie pas l'absence de code malveillant dans une extension qui serait ensuite exécutée sur les sites WordPress. La file de contrôle, les différences entre versions et les outils de modération servent à examiner ce contenu.
Examiner et modérer
L'espace opérateur présente les publications, leur auteur, leur état de contrôle et les demandes de propriété. L'historique peut être filtré par compte éditeur. Pour une version, le comparatif utilise l'archive courante avant publication et la nouvelle archive, avec leurs empreintes conservées.
Les fichiers ajoutés, retirés et modifiés apparaissent avec leur contenu avant/après lorsque la lecture est dans les limites du comparateur. Les fichiers binaires, volumineux ou non comparés sont signalés. Un comparatif tronqué n'est jamais présenté comme une revue exhaustive.
| Action | Effet |
|---|---|
| Marquer une version vérifiée | Enregistre le contrôle et la note opérateur. |
| Suspendre un compte | Révoque ses sessions et bloque ses nouvelles publications, y compris pour un compte encore non vérifié. Sa restauration reste en attente de vérification si le courriel n'avait pas été validé. Examiner séparément les projets déjà distribués. |
| Suspendre un projet | Bloque les nouvelles publications de son éditeur et retire ses offres et autorisations fraîches d'installation, y compris les traductions associées. |
| Réactiver un projet | Rétablit sa disponibilité selon l'état des versions conservées. |
| Publier un correctif de sécurité | Publie le ZIP fourni par l'opérateur sous une nouvelle version supérieure, avec justification et trace d'audit. |
| Restaurer une ancienne version | Reprend son code, ajuste l'en-tête de version et publie une nouvelle version corrective supérieure. |
La restauration conserve les archives d'origine et la version remplacée. Elle ne restaure pas automatiquement une base de données WordPress modifiée par une extension ; vérifier la compatibilité du code restauré sur un site de préproduction.
Par exemple, pour retirer les changements de 1.2.0 et revenir au code de 1.1.0, publier une restauration 1.2.1. WordPress peut alors détecter une version plus récente. Promouvoir simplement 1.1.0 ne fait pas rétrograder les installations 1.2.0.
Un correctif opérateur conserve l'identité canonique du projet. Il ne dépend pas d'une nouvelle soumission de l'éditeur et ne modifie pas les préférences de mises à jour automatiques des administrateurs WordPress. Pour arrêter également les publications de l'éditeur concerné, suspendre son compte ou son projet selon l'effet souhaité.
Lorsqu'un correctif opérateur remplace une version importée de WordPress.org, le projet passe en gestion locale. Son code corrigé ne sera pas remplacé automatiquement par la prochaine synchronisation amont. L'opérateur prend alors en charge ses publications suivantes.
Les anciennes archives immuables constituent l'historique conservé. Elles ne remplacent pas les sauvegardes externes de la base et des clés. Un ZIP déjà téléchargé ou mis en cache reste public ; la suspension n'efface pas les copies existantes et ne désinstalle pas le code d'un site distant.
La commande privée publisher-action permet aussi d'appliquer les actions sans fichier téléversé, avec les mêmes autorisations et validations. Par exemple, créer dans le dossier privé un fichier JSON contenant type, slug et operator_note, puis exécuter :
php cli.php publisher-action --operator=studio --action=suspend_project --input=../registry-private/action.json
Pour restaurer du code, le fichier comprend aussi restore_version et new_version, et l'action est restore_release. Le correctif à partir d'un nouveau ZIP utilise le formulaire de modération ou l'action CLI security_patch, avec new_version dans le JSON et --archive=/chemin/prive/correction.zip. L'option d'archive est réservée à cette action. Les identifiants de comptes, de demandes et de versions examinées se trouvent dans l'espace opérateur.
Isoler le service sur CloudLinux/cPanel
Utiliser un compte cPanel dédié au registre. Les autres sites ne doivent pas partager son identité Unix. Conserver registry-private en 0700, les clés et la configuration en 0600, les dossiers applicatifs en 0755 et leurs fichiers en 0644. Les sources applicatives ne doivent pas être modifiables par d'autres comptes. Les points d'entrée publics utilisent uniquement des chemins fixes vers l'application privée.
Limiter les ressources du compte dans CloudLinux et les connexions/bandes passantes au niveau du serveur : les limites PHP interviennent après une partie du traitement HTTP. Garder PHP, libzip et le serveur web à jour, ModSecurity actif, HTTPS obligatoire et les journaux hors du dossier public.
Pour ce domaine, régler notamment upload_max_filesize=100M, post_max_size=110M, max_file_uploads=1, display_errors=Off, log_errors=On et allow_url_include=Off. Le répertoire temporaire des téléversements peut être placé dans registry-private/tmp après initialisation ; PHP doit pouvoir y écrire. Appliquer ces réglages dans la configuration PHP effective du domaine, puis vérifier leur prise en compte. Les directives PHP-FPM peuvent être administrées dans les outils MultiPHP selon leur portée. Voir la configuration PHP-FPM de cPanel.
Avant ouverture publique, vérifier la chaîne réelle inscription → courriel → connexion → publication sur l'hébergement, avec deux comptes éditeurs distincts, et tester qu'un compte ne peut jamais agir sur les projets de l'autre. Vérifier aussi les réponses anonymes de /moderate/, la configuration des quotas et la restauration des sauvegardes. Les tests locaux ne configurent pas à distance le système CloudLinux, cPanel, TLS ou la messagerie.