Site Restaurado - URLs precisam ser corrigidos, alguma ideia?

Fiz uma restauração e todos os links internos têm o domínio de URL de teste, quebrando todos os links e não tenho certeza por que ele não pegou o URL do site correto, sem entrar no código/db para fazer uma substituição em massa, alguma solução para fazer isso de outra forma?

Estava pensando em fazer uma Re-Restauração?

Você precisará acessar o banco de dados e fazer uma substituição em massa.

Existe uma ferramenta para isso:

RAILS_ENV=production discourse remap //old.domain //new.domain

4 curtidas

Você pode corrigi-lo como descrito, mas isso não deveria acontecer.

Você fez e restaurou o backup usando /admin/backups?

Ambos os sistemas têm o nome do host definido corretamente?

3 curtidas

Obrigado. Pareceu fácil o suficiente. Eu entrei no aplicativo e executei isso, mas parece que não alterou as instâncias dos URLs nas postagens.

Este foi o remapeamento:

RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com

Isso foi executado e concluído no banco de dados “default”, levou alguns minutos e depois relatou “done” sem erros.

Eu olhei algumas postagens escolhidas e nada parecia ter mudado nos URLs de nenhuma postagem.

Eu reconstruí algumas para testar onde eu via dev.domain.com em vez do domain.com ativo nos links, mas elas permaneceram as mesmas.

Então, executei o mesmo, mas sem o https:// e obtive este erro:

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.

Acho que há uma mensagem de chat no banco de dados que está fazendo com que ele pare, mas não tenho certeza do porquê. Suponho que eu precise ver isso de alguma forma no banco de dados, pois, como você pode imaginar, meu usual envolvimento no gerenciamento do Discourse nunca é no banco de dados.

Finalmente, reexecutei o remapeamento original, levou alguns minutos e relatou como “done” sem erros:

RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com

:thinking:

Talvez eu precise reconstruir as postagens para ver os resultados?

Pensei que uma reconstrução de postagem fosse a mesma ação, mas em uma base de postagem por postagem.

Ou reconstruir o aplicativo?

Isso deveria ser

RAILS_ENV=production discourse remap //sub.domain.com //domain.com

A razão para // é que ele corresponde a http://, https:// e URLs sem protocolo, e não corresponde a domínios de endereço de e-mail.

O que acontece quando você faz isso?

2 curtidas

Sim, ok, então o mesmo erro novamente:

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.

Então, pelo menos estou usando o comando de gravação correto, as coisas estão melhorando! :slight_smile:

Mais alguma ideia?

Além desse impasse no remapeamento do Rails, pensei que talvez se eu fizesse backup do banco de dados e o restaurasse novamente, isso poderia remapear os Link-urls corretamente durante o processo de restauração?

O erro que ainda estou encontrando parece ser repetido ou muito semelhante ao erro de parada aqui que precisava de uma correção:

Erro: ERROR:  duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL:  Key (post_id, md5(url::text))=...

Ao tentar o remap:

RAILS_ENV=production discourse remap //sub.domain.com //domain.com

Talvez @david possa ter uma ideia aqui?

Isso parece mais um bug?

Essa tabela possui links com ambos os domínios, então ao tentar remapear, você acaba obtendo uma chave duplicada. Não é um erro. Você está tentando criar uma chave duplicada.

Você poderia remover os itens dessa tabela que têm o domínio apex. Uma ideia melhor é usar www em vez do domínio apex.

1 curtida

Obrigado. Minha única preocupação é que esta implantação do Discourse também sofra com o problema de não-www / SSL, por exemplo, How to add ssl to non-www domain?, mas tentarei o remap que você sugere e, se funcionar, isso me forçará a resolver o problema de não-www também! :slight_smile:

O remapeamento de reflexão funcionou como sugerido por @pfaffman, mas na verdade foi o catalisador para a solução, não a solução em si. Ajudou-me a perceber o que estava a fazer de errado, fez-me reavaliar tudo!

Se eu tivesse lido o erro corretamente, ou seja, prestado atenção, teria resolvido isso há muito tempo, pois teria visto que a informação chave estava na mensagem de erro.

Tudo o que tive de fazer foi incluir o número da publicação assinalado pelo erro de paragem …/p/123456789 no URL para navegar diretamente e corrigir cada publicação manualmente.

Isto ocorreu na maioria dos casos numa segunda execução de remapeamento para converter o www do primeiro remapeamento para o URL apex não-www, como era a necessidade original.

Agora os URLs internos só devem incluir links apex.

Isto resolve alguns dos redirecionamentos SSL do www onde havia muitos links internos antigos do www. Não resolve um utilizador a digitar www na barra de endereços ou um link de retorno no próprio WWW por agora, mas deve resolver todos os gerados internamente. Aguardando para ver como afeta a indexação do Google antes de fazer mais alguma coisa sobre este problema.

Talvez de interesse para os desenvolvedores.

Encontrei muitas paragens em duplicate key value violates unique constraint “unique_post_links”, estas ocorreram quando uma publicação foi movida e o discourse incluiu o “Continuado de …. “ com link direto, mas se as publicações divididas incluíssem blocos citados para o mesmo local, isso pararia o remapeamento.

Isto causou a maioria dos erros de paragem.

A solução foi remover um dos links internos duplicados ou colocar em código (nem sempre funcionou) e o remapeamento continuaria após ser reexecutado.

Outras paragens foram causadas por utilizadores a criarem as mesmas condições de publicação manualmente, republicando o mesmo link para uma publicação sem perceber que a Citação também criava um link, talvez hábitos históricos, estilos, etc. entrem em jogo aqui, indicando que muitos utilizadores ainda não percebem o quanto o discourse lida com links para facilitar a vida, oh a ironia!

Após o remapeamento, eu poderia ter revertido as edições, mas não eram tantas para fazer diferença e ainda havia um link correto de volta à origem interna do discourse da publicação ou citação.

Espero que isto inverta a maior parte da desindexação do Google de dezenas de milhares de páginas para um limbo cinzento não indexado.

Um pouco de conhecimento é uma coisa perigosa! :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.