J’ai effectué une restauration et tous les liens internes ont le domaine d’URL de test, ce qui casse tous les liens, et je ne suis pas sûr pourquoi il n’a pas pris la bonne URL de site, sans entrer dans le code/la base de données pour faire un remplacement massif, y a-t-il des solutions pour faire cela autrement ?
Je pensais faire une nouvelle restauration ?
Vous devrez accéder à la base de données et effectuer une recherche/remplacement en masse.
Il existe un outil pour cela :
RAILS_ENV=production discourse remap //old.domain //new.domain
Vous pouvez le corriger comme décrit, mais cela ne devrait pas arriver.
Avez-vous effectué et restauré la sauvegarde à l’aide de /admin/backups ?
Les deux systèmes ont-ils le nom d’hôte correctement défini ?
Merci. Cela semblait assez facile. J’ai entré dans l’application et j’ai exécuté cela, mais il semble que cela n’ait pas modifié les instances des URL dans les publications.
Voici le remappage :
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Cela s’est exécuté et a terminé sur la base de données « default », cela a pris quelques minutes, puis a signalé « done » sans erreur.
J’ai regardé quelques publications choisies et rien ne semblait avoir changé sur les URL des publications.
J’ai reconstruit certaines pour tester où j’ai vu dev.domain.com au lieu de domain.com en direct dans les liens, mais ils sont restés les mêmes.
Ensuite, j’ai exécuté la même chose mais sans le https:// et j’ai obtenu cette erreur :
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
Je suppose qu’il y a un message de chat dans la base de données qui l’empêche de s’arrêter, mais je ne sais pas pourquoi. Je suppose que je dois le voir d’une manière ou d’une autre dans la base de données, car vous pouvez dire que mes incursions habituelles dans la gestion de Discourse ne se font jamais dans la base de données.
Enfin, j’ai réexécuté le remappage d’origine, cela a pris quelques minutes et a signalé « done » sans erreurs :
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Peut-être que je dois reconstruire les publications pour voir les résultats ?
Je pensais qu’une reconstruction de publication était la même action mais sur une base publication par publication.
Ou reconstruire l’application ?
Cela devrait être :
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
La raison de // est qu’il correspond à http://, https:// et aux URL sans protocole, et qu’il ne correspond pas aux domaines d’adresses e-mail.
Que se passe-t-il lorsque vous faites cela ?
Oui d’accord, puis la même erreur à nouveau :
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
Donc au moins j’utilise la bonne commande d’écriture, les choses s’améliorent ! 
Plus d’idées ?
Outre cette impasse de remappage de Rails, je me suis dit que peut-être si je sauvegardais la base de données et que je la restaurais à nouveau, cela pourrait remapper correctement les URL de liens pendant le processus de restauration ?
L’erreur que je rencontre toujours semble être répétée ou très similaire à l’erreur d’arrêt ici qui nécessitait une correction :
Error: ERROR: duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL: Key (post_id, md5(url::text))=...
Lors de la tentative de remappage :
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Peut-être que @david aurait une idée ici ?
Cela ressemble-t-il davantage à un bug ?
Cette table contient des liens avec ces deux domaines, donc lorsque vous essayez de les remapper, vous obtenez une clé en double. Ce n’est pas un bug. Vous essayez de créer une clé en double.
Vous pourriez supprimer les éléments de cette table qui ont le domaine racine. Une meilleure idée est d’utiliser www au lieu du domaine racine.
Merci. Ma seule préoccupation est que ce déploiement de discourse souffre également du problème non-www / SSL, par exemple How to add ssl to non-www domain? mais j’essaierai le remap que vous suggérez et si cela fonctionne, cela me forcera à résoudre le problème non-www aussi !
Le remappage a fonctionné comme suggéré par @pfaffman, mais il a en fait été le catalyseur de la solution, pas la solution en soi. Il m’a aidé à comprendre ce que je faisais de mal, il m’a remappé les yeux !
Si j’avais lu l’erreur correctement, c’est-à-dire en y prêtant attention, j’aurais résolu ce problème il y a longtemps, car j’aurais vu que l’information clé se trouvait dans le message d’erreur.
Tout ce que j’avais à faire était d’inclure le numéro de publication signalé par l’erreur d’arrêt …/p/123456789 dans l’URL pour naviguer directement et corriger chaque publication manuellement.
Cela s’est produit pour la majorité lors d’une deuxième exécution de remappage pour convertir le www du premier remappage en l’URL apex non-www, comme c’était le besoin initial.
Maintenant, les URL internes ne devraient inclure que des liens apex.
Cela résout certains problèmes de redirection SSL www où il y avait de nombreux liens internes www hérités. Cela ne résout pas un utilisateur tapant www dans la barre d’adresse ou un lien retour sur le WWW lui-même pour l’instant, mais cela devrait s’attaquer à tous ceux générés en interne. J’attends de voir comment cela affecte l’indexation par Google avant de faire quoi que ce soit d’autre sur ce problème.
Peut-être d’intérêt. Pour les développeurs.
J’ai trouvé beaucoup d’arrêts sur duplicate key value violates unique constraint “unique_post_links”, ceux-ci se produisaient lorsqu’une publication était déplacée et que discourse incluait le "Continued from …. " avec un lien hypertexte, mais si les publications divisées incluaient des blocs cités au même endroit, cela arrêtait le remappage.
Cela a causé la majorité des erreurs d’arrêt.
La solution était de supprimer l’un des liens internes dupliqués ou de les mettre entre crochets (cela n’a pas toujours fonctionné) et le remappage continuerait une fois relancé.
D’autres arrêts étaient causés par des utilisateurs créant manuellement les mêmes conditions sur une publication en re-publiant le même lien vers une publication sans réaliser que la citation liait également en retour, peut-être des habitudes historiques, des styles, etc. entrent en jeu ici, indiquant que de nombreux utilisateurs ne réalisent toujours pas à quel point discourse gère les liens pour faciliter la vie, oh l’ironie !
Après le remappage, j’aurais pu annuler les modifications, mais il n’y en avait pas tant que cela pour faire une différence et il y avait toujours un lien retour correct vers la source interne de la publication ou de la citation discourse.
J’espère que cela inversera la majorité de la désindexation par Google de 10 000 à 100 000 pages dans un limbo gris non indexé.
Un peu de connaissance est une chose dangereuse ! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.