[quote=“david, post:1, topic:373574”]você será solicitado a remover a linha relevante do seu arquivo app.yml antes da sua próxima reconstrução
[/quote]
Não recebi este aviso. Mas segui o log de erros e removi as linhas. Reconstruindo novamente agora.
Editar: Além de introduzir falhas e 20 minutos offline, se estas linhas de plugins não forem removidas antes da atualização; Por que realmente precisamos desse acréscimo de plugins pré-instalados?
Estou curioso sobre o quadro geral. Qual é o raciocínio para agrupar esses plugins por padrão?
Pessoalmente, parece um pouco com a direção que o Windows, os sistemas operacionais móveis e alguns softwares tomaram, adicionando mais componentes pré-instalados por padrão (BLOAT) que muitos de nós geralmente tentamos evitar.
Tenho certeza de que essa mudança provavelmente foi discutida com a comunidade antes de ser implementada. Se sim, não há necessidade de uma resposta repetitiva, apenas inclua um link para a discussão ou anúncio relevante para que eu possa ler como e por que essa decisão foi tomada.
O agrupamento de plugins mais comuns também permite que mais sites aproveitem não precisar compilar seu próprio JS, reduzindo tempos de compilação e custos de recursos.
Portanto, ainda não toquei no botão de atualização porque uso alguns dos plugins que agora estão incluídos. Não estou com medo, sobrevivi à atualização do banco de dados há alguns meses.
É melhor atualizar meu app.yml da lista no post (feito backup primeiro, claro) ou receberei uma mensagem de erro significativa na interface que me dirá quais remover e parar de fazer isso?
Isso é meio que respondido no título do tópico. Popular geralmente significa comumente instalado e usado. Agrupá-los para Self Hipsters significa que você não precisa perder tempo instalando-os. Muitos plugins e TC eventualmente foram mesclados com o programa principal.
O benefício de ter esses plugins começando como plugins permite tempo de desenvolvimento para testar as preferências dos consumidores e desenvolvê-los completamente.
Claro, haverá uma variedade de comunidades que não usam nenhum dos recém-agrupados com o núcleo. Mas a métrica maior provavelmente mostra que estes são frequentemente os que são instalados após a configuração. Então, é claro, eles também têm as métricas de sua hospedagem paga de plugins usados e não usados no nível básico.
Perdi 2 plugins antes da minha reconstrução. O log de erros, no entanto, foi muito melhorado para identificar isso facilmente em comparação com antes, onde você tinha que rolar para cima e identificar o problema.
Acho que o prompt que David mencionou é ou o erro de reconstrução ou pode estar na sua página de plugins para atualização pela web.
Sem problemas, nem sempre é fácil ver uma resposta antes de postar a pergunta.
Eu mesmo atualizei meu app.yml
Usando comentários, organizei o meu por provedores de plugins para facilitar a ordenação. Dito isso, ainda foi um pouco chato. Alguns posts acima, acredito que alguém postou um método para verificar antes de reconstruir.
Para ser sincero, como este era o tópico de anúncio, vim aqui e comecei a comentar, pois a atualização falhou e eu não recebi uma notificação sobre a necessidade de editar primeiro. Então, assim que isso foi resolvido, editei a postagem. Mas se esta é a única discussão pública, obrigado.
Posso entender os prós, mas definitivamente há contras. Portanto, acho que nem todo proprietário de fórum Discourse vai gostar de plugins. Então, teria sido bom talvez oferecê-lo como uma opção. Talvez durante a atualização um único prompt, ou talvez na área de administração uma configuração ou notificação que o lembre de definir sua preferência antes da próxima atualização.
Existe uma página que lista quais plugins foram incorporados por data. Não gosto de atualizar pelo administrador da web apenas para falhar. Estou na versão 3.5.0.beta9-dev (04dbc622ab).
Talvez eu tenha perdido a página com datas/versões que têm as atualizações instaladas. Obrigado.
{“content”:“[quote="haydenjames, post:103, topic:373574"]\nEstou curioso sobre o quadro geral. Qual é o raciocínio para empacotar esses plugins por padrão?\n\nPessoalmente, parece um pouco com a direção que o Windows, os sistemas operacionais móveis e alguns softwares tomaram, adicionando mais componentes pré-instalados por padrão (BLOAT), o que muitos de nós geralmente tentamos evitar. \n\nTenho certeza de que essa mudança provavelmente foi discutida com a comunidade antes de ser implementada. Se for o caso, não há necessidade de uma resposta repetitiva, basta incluir um link para a discussão ou anúncio relevante para que eu possa ler como e por que essa decisão foi tomada.\n\nObrigado, pessoal!\n\n[/quote]\n\nA ideia é provavelmente que eles são os plugins mais populares, e a maioria das pessoas já está usando alguma combinação deles (como você mesmo está). Não é realmente “bloat”, porque eles não têm praticamente nenhum impacto, e você não precisa usar nenhum deles para nada. Isso é muito diferente de ter 20 programas que não quero instalados no Windows, estes são alternadores de ligar/desligar (a maioria das pessoas não verá, e você como administrador terá em uma lista de 300 outras coisas que você já não está usando/mudando) não algo que está constantemente aparecendo/ocupando espaço real/definido para fazer coisas por padrão. Ter um programa de notas instalado por padrão que eu não quero significa que acabarei tendo dois. Ter um plugin que eu não quero significa que há apenas uma opção sentada em um painel\n\nTambém é muito mais fácil ter interruptores de ligar/desligar do que ter que procurar em um fórum de terceiros (ou infinitos githubs) procurando algo que você nem sabe que existe em primeiro lugar. Esta foi, na verdade, a primeira vez que eu estava ciente de um punhado desses”,“target_locale”:“en”}
Finalmente tive tempo para atualizar para 3.5.0.beta9-dev (df03ef6d05)
Sou uma instalação padrão auto-hospedada
Editei meu app.yml para remover as linhas de plugin (conforme o conselho de Dan acima) e depois prossegui para iniciar o processo de atualização. Tive que atualizar o gerenciador do docker antes de todo o resto, como de costume, e isso correu normalmente. Assim que o gerenciador do docker foi atualizado, fui recebido por uma nova mensagem (para mim).
Eu já tinha feito uma reconstrução anteriormente, então sabia como e como o putty ainda estava aberto no meu servidor, não foi um inconveniente, mas fiquei um pouco surpreso por não poder usar a interface do usuário para fazer a atualização. Estou apenas postando isso como um aviso para outros noobs de auto-hospedagem como eu. Fora isso, a atualização correu bem, tudo funciona. Obrigado equipe e comunidade.
Para solved, topic-voting e templates, você está certo de que os plugins em si estão ativados. Mas esses plugins não fazem nada até que os recursos sejam ativados para uma categoria específica.
Eu gostaria que vocês se importassem mais em manter a compatibilidade e não nos fizessem perder meio dia toda vez que atualizamos nossos sites. Organizar um pouco o código de vocês não vale a pena quebrar os sites das pessoas e perder o tempo delas.
Francamente, estou começando a procurar alternativas ao Discourse, pois estou cansado de todo o meu site quebrar a cada poucos meses e ter que descobrir como consertá-lo quando nada disso está no meu domínio.
Lamento saber da sua frustração - embora eu não tenha certeza de quais problemas você encontrou especificamente com plugins agrupados aqui?
Tentamos tornar as atualizações o mais fáceis/diretas possível, mas com grandes mudanças como esta, às vezes é inevitavelmente que cause algum atrito. Neste caso, adicionamos saídas de erro específicas de como modificar a configuração do seu site para torná-la o mais simples possível de corrigir.
Um problema que acredito estar em jogo é que o Discourse_docker não é muito bom em saber quando uma reconstrução da linha de comando é necessária. E isso torna fácil quebrar seu site clicando em atualizar no painel de administração. (pelo menos é o que acho que estou vendo as pessoas reclamando)
Acho que costumava ver commits que diziam que faziam isso e acho que não os vejo tanto agora. Eu não uso discourse_docker (muito?) eu mesmo, então não prestei muita atenção.
Se este usuário tivesse executado uma reconstrução e não a atualização da interface do usuário, eles poderiam ter simplesmente feito um
./launcher start app
E esperado para lidar com a atualização quando fosse conveniente.
