web-dev-qa-db-fra.com

Différences de meilleures pratiques dans les options de base de données et wp-config entre les environnements en direct, intermédiaires et locaux WordPress?

J'utilise des sites de transit depuis des années. Je ne demande donc pas la différence nécessaire pour configurer un site de transit fonctionnel tel que recherche remplaçant URL, branches de contrôle de version de dev, modification des préfixes de table, etc.

Je demande des différences qui améliorent la sécurité, le flux de travail ou la qualité de vie. Différences d'options ou wp-config.php établi lors de la création de l'environnement initial ou lors du transfert entre différents environnements. Voici quelques exemples que j'établis actuellement:

  • blog_public option db - Autoriser les robots des moteurs de recherche en direct, bloquer les robots des moteurs de recherche dans le transfert.
  • plugin LiteSpeed ​​Cache (ou équivalent) - Activez le cache en direct, désactivez le cache dans le transfert.
  • JETPACK_DEV_DEBUG - Défini sur faux en direct, défini vrai en mise en scène.
  • WP_DEBUG dans wp-config.php - Mis à faux en direct, mis vrai dans la mise en scène (en fait, je ne le fais pas car mes sites de mise en scène sont accessibles au public, mais c'est un exemple plausible)
  • DISALLOW_FILE_MODS in wp-config.php - Défini sur vrai en direct, défini faux en mise en scène.
  • AUTOMATIC_UPDATER_DISABLED - Défini sur true dans live , défini false dans la mise en scène.

Choses que j'ai l'intention de configurer mais que je n'ai pas encore:

  • Passerelles de paiement WooCommerce - Activez le mode test dans le transfert, désactivez-le en direct.
  • Message de la boutique de test WooCommerce - Activez la notification de la boutique WooCommerce sur la mise en scène, désactivez-la en direct.

En a encore? Parallèlement au noyau, je recherche des différences qui huilent les engrenages des plugins populaires tels que WooCommerce, Wordfence, Yoast SEO, Jetpack, etc.

J'ai essayé de faire des recherches sur ce sujet, mais les résultats de la recherche sont étouffés par la pléthore de didacticiels de configuration de site de préparation de données standard. J'ai essayé de publier sur Reddit, mais cela a également été noyé par les messages suivants. Si désireux d'entendre vos idées!

optionswp-configstagingdevelopment-strategy
2
James Jones

Quelques uns que je désactive ou modifie sur la mise en scène et le développement WP sites:

  • Redis cache
  • CDN
  • E-mails de notification de commande WooCommerce - passant de celui qui les remplit sur prod à l'équipe de développement.
1
KGreene

Il semble que vous ayez une bonne liste ... Quelques-unes qui me viennent à l'esprit:

  • SCRIPT_DEBUG à faux en direct et vrai à la mise en scène.
  • WP_CACHE à vrai en direct et faux à la mise en scène.
  • ping_sites à vider lors du transfert pour désactiver les services de ping.
  • default_pingback_flag à 0 lors du transfert pour ne pas envoyer de pingbacks sortants.
  • Peut-être installer un plugin Password Protect sur la mise en scène (dans les plugins mu?)

Si vous faites le dernier, il ne sera pas accessible au public et vous pouvez définir WP_DEBUG à true lors de la mise en scène (et éventuellement même) WP_DEBUG_DISPLAY

Ajout - Module complémentaire Stripe pour Gravity Forms, mode de test API pour la mise en scène:

add_filter('gform_stripe_api_mode', function() {return 'test';} );
1
majick