Assista a este vídeo para uma introdução ao plugin:
Como começar
Primeiro, habilite o diário para uma categoria nas configurações da categoria. Clique em "Configurações" à esquerda, role para baixo até o final, marque "Habilitar diário nesta categoria", clique em "Salvar Categoria" e atualize a página. O botão "Novo Tópico" na categoria agora lerá "Criar Diário", clique nele para criar seu primeiro diário.
Obrigado por postar! Pela nossa experiência prática, o formato de categoria diário/agenda/registro é uma das categorias mais poderosas que você pode adicionar à sua comunidade.
Estamos ansiosos pelo desenvolvimento futuro do plugin.
O Discourse não possui ganchos de desativação de plugin como o Wordpress, portanto, isso não acontecerá automaticamente, mas há um botão nas configurações da categoria que permite restaurar as postagens em uma categoria à sua ordem normal. Portanto, enquanto o plugin ainda estiver ativado, você faria:
Desativar a funcionalidade do diário na categoria.
Alguns pontos de melhoria potencial para uma possível v2.0 futura do plugin de diário. Considere isso apenas como ideias iniciais e não como solicitações de recursos reais. Eu só quero discuti-las publicamente e ver o que outros usuários acham.
“Motor” de comentários melhor ou diferente
Em vez de posts regulares, os comentários (também conhecidos como respostas a entradas de diário) devem funcionar de forma semelhante ao plugin de votação de posts. Tenho que referenciar o “Big Brother” Facebook aqui, onde a experiência de postar comentários é o melhor exemplo.
A questão é se esses comentários são contados na atividade do usuário ou devem ser contados em primeiro lugar.
Dessa forma, a linha do tempo também não ficará tão bugada, pois apenas os posts do proprietário do tópico serão contados nela.
Sugestão/rascunho de especificação:
Motor de comentários de votação de posts
Comentários não contam para atividade (possível configuração de plugin ligar/desligar)
Exibir avatar de usuário e nome de usuário em meio tamanho ao lado dos comentários (mas ocultar o flair do avatar)
Diários compartilhados (mais um “nice-to-have”)
Isso é mais um exagero e não é super crucial. Mas tivemos alguns usuários solicitando tópicos de diário onde você tem basicamente dois proprietários de tópico. A questão é quão viável é em primeiro lugar?
Ideias de especificação:
O proprietário do tópico pode adicionar coautores
O coautor pode fazer uma nova entrada no diário
(Se viável) Avatar do proprietário do tópico e do coautor exibido empilhado um sobre o outro na lista de tópicos
Recomendo uma melhoria para o plug-in (que é incrível!). O botão de comentário deveria ser mais visível, por exemplo, em instâncias que usam Reactions, o botão nem sequer é visível a menos que se role horizontalmente. Como esta é uma nova funcionalidade, para fins de UI/UX, eu colocaria o botão de comentário de forma clara e visível.
Só para ter certeza… Eu não permito mega-tópicos e, após 50 posts, o tópico será fechado e um novo tópico será criado.
Tais criações automáticas são do sistema, então eu tenho que mudar o proprietário, certo?
No meu caso, o limite de 50 posts ainda é válido e, como o Journal é “apenas” um tópico com esteroides, até os comentários das entradas são contados para o limite de 50 porque tecnicamente são comentários de um post quando as entradas são comentários do tópico, certo?
Esta é mais uma área do Discourse, mas posso alterar um comentário que agora é uma entrada em vez de ser um comentário de uma entrada? Não consegui encontrar essa opção na interface do usuário. Se eu tiver que usar o Rails, então não me importo. Muito trabalho por causa de uma coisa tão pequena.
Tenho muitos tópicos do tipo journal e os mudei para este sistema, mas todos comentaram no tópico, e agora eles aparecem como entradas. Bem, o tópico antigo e poucos novos membros os leem mesmo, e tenho certeza absoluta de que eles não se importam com a forma como o conteúdo é exibido.
Obrigado pelo plugin! Comecei a usá-lo não faz muito tempo, mas ele tinha uma vibe de “abandonado”, então eu não tinha certeza sobre ele. Parece funcionar bem, no entanto! (Aqui está um exemplo que o utiliza, modifiquei o CSS para ocultar detalhes e otimizar a aparência)
Acho que a única coisa que eu poderia recomendar altamente para melhorar é como ele pula para novos comentários quando você revisita o tópico. É difícil explicar, mas às vezes é instável/pouco claro onde o novo comentário está quando você está se atualizando.
Você poderia ser mais específico sobre isso? Você acha que deveria ser idêntico?
Observe que o plugin Post Voting era originalmente o Question Answer Plugin, do qual o Journal Plugin foi derivado (veja mais). Trazer este para acompanhar as mudanças de comentários no Post Voting é factível.
Interessante. Não tenho certeza se isso é um problema com este plugin ou com o próprio menu de posts, mas sim, isso precisaria ser resolvido. É no celular ou no desktop? Qual navegador é?
hm, sistema interessante que você tem. A resposta dependerá de como você configurou esse sistema automatizado de divisão de tópicos. As entradas são distinguidas dos comentários com base se o post tem um reply_to_post_number, ou seja,
Bem, estou usando o recurso do core, então provavelmente não vou ajustar nada. Como sempre
Estou apenas tentando entender o que acontecerá no futuro. Mas, se entendi corretamente, as entradas são contadas para o limite máximo de postagens, mas os comentários não. Se for o caso, é esplêndido.
Fora do tópico principal, mas os mega tópicos são geralmente aceitos como norma São horríveis de ler para qualquer novo membro e terríveis para encontrar algo para os mais antigos. Agora começo a entender por que os resumos são um recurso tão desejado. É inevitável que os mega tópicos levem a repetições intermináveis e a uma grande quantidade de conteúdo fora do tópico.
No estado atual, tanto as entradas quanto os comentários serão contados para o limite. Eu poderia possivelmente ajustar isso para que apenas as entradas contassem. Mas eu teria que analisar isso mais de perto.
Eu começo a perder o foco aqui, e estou fazendo perguntas de nível 101, mas se posts.where e posts.where.not fazem a mesma coisa, qual é a diferença então? Mas eu assumo que nil foi apenas um exemplo e o valor real é usado
Mas de qualquer forma. Esta pergunta de comprimento limitado não é realmente importante, então se você quiser olhar, faça-o quando estiver entediado e não tiver nada mais importante para fazer. Porque em algum momento eu saberei como funciona no ambiente real.
Eles não significam a mesma coisa. nil é o valor real.
posts.where(reply_to_post_number: nil)
significa posts onde reply_to_post_number é nil, o que significa que é um post que não é uma resposta a outro post (ou seja, é uma entrada).
posts.where.not(reply_to_post_number: nil)
significa posts onde reply_to_post_number não é nil, o que significa que é um post em resposta a outro post (ou seja, um comentário).
De qualquer forma, você provavelmente não precisa se preocupar com consultas rails. Eu avisarei se adicionarmos suporte para não contar comentários na divisão automática de tópicos principal.
Olá @angus, muito obrigado, realmente agradeço. Consegui localizar as configurações adicionais ao configurar uma categoria e agora está funcionando como esperado. Muito obrigado pela sua adição e trabalho neste excelente plugin
Olá pessoal, uma especificação de trabalho está sendo finalizada para este plugin. Se você estiver interessado em estender / usar este plugin e quiser saber mais, por favor me envie uma mensagem no coop.pavilion.tech.
São horríveis de ler para qualquer novo membro e terríveis para encontrar algo para os mais antigos. Agora começo a entender por que os resumos são um recurso tão desejado. É inevitável que os mega tópicos levem a repetições intermináveis e a uma grande quantidade de conteúdo fora do tópico.
