Bonjour et veuillez nous excuser si cela a déjà été répondu, mais nous devons vraiment nous en assurer.
Nous avons développé un site Web sous l'un de nos domaines, puis l'avons transféré sur le site actif du client. Nous avons exécuté quelques requêtes SQL dans la base de données afin de mettre à jour la nouvelle URL, mais lorsque nous recherchons notre nom de domaine dans la base de données, nous obtenons: plus de 600 correspondances dans la table wp_posts (principalement des révisions, mais également des pièces jointes et des publications). .
Nous lisons dans le codex de WP que nous ne devrions PAS mettre à jour cette colonne, mais nous ne savons pas vraiment comment cela affectera le site si nous le faisons. Les fichiers sont toujours dans notre domaine et nous devons les supprimer, mais nous pensons qu'étant donné qu'il existe encore des instances dans la base de données qui appellent notre domaine, quelque chose pourrait se casser si nous le faisions.
Si quelqu'un peut fournir plus d'informations sur l'utilisation des indications et des suggestions dans la situation ci-dessus, nous vous en serions vraiment reconnaissants.
merci d'avance
Le GUID ne devrait pas être utilisé pour générer des URL pour le site (mise en garde ci-dessous), il ne devrait donc pas être gênant de les laisser en l'état ... sauf si un plugin mal conçu décide que les GUID sont un excellent raccourci pour obtenir une URL.
Le GUID est un identifiant global unique - global comme dans "dans tout l'espace et le temps". Les lecteurs de flux l’utilisent pour savoir si un élément a été affiché ou non. Si vous modifiez le GUID, tout semble nouveau pour un lecteur de flux et tous vos abonnés sont potentiellement inondés. J'aimerais que WordPress bascule vers un autre format pour ce champ - un hachage peut-être - pour éviter ceci "Est-ce une URL?" confusion. Ce n'est pas une URL ... eh bien, sauf pour le support de pièce jointe, qui est ... o_0
Une exception est le média en pièce jointe: les emplacements de média en pièce jointe sont stockés sous forme d'URL dans le GUID. Si le dossier de téléchargement par défaut doit être changé à un emplacement différent, l'URL du média devra être modifié dans les colonnes post_content et guid de la table posts.
C'est tout dans le WordPress Codex . Je ne sais pas si quelque chose a changé dans les dernières versions que le Codex n'a pas rattrapé.
Comme indiqué ci-dessus, vous devez modifier vos identificateurs globaux uniques de support de pièce jointe.
Maintenant, si votre site a été jusqu'ici sur un serveur de développement et n'a jamais publié publiquement ses flux , la modification de tous les GUID ne devrait poser aucun problème. Aucun lecteur de flux n'a vu le contenu et par conséquent, aucun d'entre eux ne devrait suivre quoi que ce soit. Je dirais que le Codex devrait spécifier que ne pas changer le GUID s'applique au déplacement d'un domaine actif à un autre et ne pose pas de problème lors du passage d'un serveur privé (localhost) à un serveur public.
S'il s'agissait d'un site client sur mon serveur de développement que je passais sur un domaine actif, j'aurais tendance à changer les GUID. Cela devrait aider à éviter la perplexité à l'avenir si quelqu'un commençait à fouiller dans la base de données.