Did a restore and all the internal links have the test URL domain, breaking all the links and I am not sure why it did not take up the correct site URL, without going into the code/db to do a mass find & replace any solutions on how to do this another way?
I was thinking do a Re-Restore?
You’ll need to go into the db and do a mass search/replace.
There is a tool for that:
RAILS_ENV=production discourse remap //old.domain //new.domain
You can fix it as described, but that shouldn’t happen.
Did you make and restore the backup using /admin/backups?
Do both systems have the hostname set correctly?
Thanks. That looked easy enough. I entered the app and I ran that but it seems not to have changed the instances of the URLs in the posts.
This was the remap:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
This ran and competed on the “default” DB it took a few mins and then reported “done” with no error.
I looked at a few choice posts and nothing seemed to have changed on any posts URLs link.
I rebuilt some to test where I saw the dev.domain.com instead of the live domain.com in the links, but they remain the same.
Then I ran the same but sans the https:// and got this error
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.
I’m guessing there is a chat message in the DB that’s causing it to stop but not sure why. I suppose I need to somehow see that in the DB, as you can tell no my usual foray in managing discourse is never in the DB.
Finally, I re-ran the original remap, it took a few mins and reported as “done” with no errors:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Maybe I need to rebake posts to see the fruits?
I thought a post rebuild was the same action on but on a post by post basis.
Or rebuild the app?
That should be
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
The reason for // is that it matches http://, https:// and protocol-less URLs, and it does not match e-mail address domains.
What happens when you do that?
Yea ok, then same error again:
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.
So at least I’m using the right write command, things are looking up! 
No further ideas?
Apart from this rails remap impasse I thought maybe if I backup the db and do a restore again it might remap the Link-urls correctly during the restore process?
아직 발생하고 있는 에러는 여기에서 수정이 필요했던 stop 에러와 동일하거나 매우 유사해 보입니다:
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))=...
리맵을 시도할 때:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
@david 님이 이 문제에 대해 통찰을 주실 수 있을까요?
이건 더 버그처럼 보이나요?
해당 테이블에는 두 도메인 모두에 대한 링크가 포함되어 있어, 리맵을 시도하면 중복 키가 발생합니다. 이는 버그가 아닙니다. 중복 키를 생성하려는 시도이기 때문입니다.
해당 테이블에서 아펙스 도메인을 가진 항목을 삭제할 수 있습니다. 더 나은 방법은 아펙스 도메인 대신 www를 사용하는 것입니다.
감사합니다. 제 유일한 우려는 이 디스코urs 배포 환경에서도 non-www / SSL 문제가 발생한다는 점입니다. 예를 들어 How to add ssl to non-www domain? 링크를 참고해 주세요. 하지만 제안해 주신 리맵을 시도해 보겠습니다. 만약 작동한다면 non-www 문제도 해결해야 할 상황이 될 테니까요!
Remap 재구상이 @pfaffman이 제안한 대로 작동했지만, 실제로는 해결책 그 자체라기보다 해결의 촉매제 역할을 했습니다. 제가 어디를 잘못하고 있었는지 파악하는 데 도움을 주었고, 마치 제 눈을 다시 매핑해준 셈이죠.
만약 에러 메시지를 제대로 읽었다면, 즉 주의를 기울였다면, 핵심 정보가 에러 메시지에 들어 있다는 것을 알아채고 훨씬 전에 이 문제를 해결했을 것입니다.
해야 할 일은 stop 에러로 표시된 게시글 번호 …/p/123456789를 URL에 포함시켜 해당 페이지로 직접 이동한 뒤, 각 게시글을 수동으로 수정하는 것이었습니다.
대부분의 문제는 www를 처음 remap에서 apex non-www URL로 변환하기 위해 두 번째 remap을 실행할 때 발생했습니다. 이는 원래의 필요 사항이기도 했습니다.
이제 내부 URL은 apex 링크만 포함해야 합니다.
이것은 이전의 많은 legacy www 내부 링크로 인해 발생했던 www SSL 리다이렉션 문제를 일부 해결합니다. 사용자가 주소창에 www를 직접 입력하거나 WWW 자체에서 링크백을 사용하는 경우는 해결하지 않지만, 내부에서 생성되는 링크들은 모두 처리할 수 있을 것입니다. 이 문제가 구글 인덱싱에 어떤 영향을 미치는지 지켜본 후 추가 조치를 결정할 예정입니다.
개발자분들에게 흥미로울 수 있는 내용입니다.
duplicate key value violates unique constraint “unique_post_links”라는 stop 에러가 많이 발생했습니다. 이는 게시글이 이동될 때 discourse가 “Continued from …. “ 텍스트와 함께 핫링크를 포함시켰을 때 발생했으며, 분할된 게시글들이 동일한 위치를 인용 블록으로 포함하고 있으면 remap이 중단되었습니다.
이것이 stop 에러의 대부분을 차지했습니다.
해결 방법은 중복된 내부 링크백이나 코드 브래킷 중 하나를 제거하는 것이었습니다(항상 성공하지는 않았습니다). 이렇게 하면 remap을 다시 실행했을 때 진행되었습니다.
다른 stop 에러들은 사용자가 같은 게시글 조건을 수동으로 생성할 때 발생했습니다. 같은 링크를 다시 게시하면서 인용(Quote)도 자동으로 링크백을 생성한다는 사실을 인지하지 못했기 때문입니다. 아마도 과거의 습관이나 스타일 등이 작용한 것 같으며, 이는 여전히 많은 사용자가 discourse가 얼마나 많은 링크를 자동으로 처리하여 사용성을 높여주는지 인식하지 못하고 있음을 시사합니다. 아이러니하죠!
Remap 이후 편집을 되돌릴 수도 있었지만, 차이가 크지 않을 정도로 개수가 적었고, 게시글 또는 인용의 내부 discourse 소스로의 올바른 링크백이 하나 남아 있었기 때문에 그대로 두었습니다.
이로 인해 구글에서 인덱싱이 해제된 수백에서 수천 페이지가 비인덱싱된 회색 무법지대로 밀려드는 현상을 대거 되돌릴 수 있기를 바랍니다.
조금 아는 것이 위험할 수 있습니다! 