Pense com antecedência sobre o dimensionamento, aproveite ao máximo as soluções padrão do Wordpress, crie um tema WP com suas próprias mãos, cuide da conveniência de um designer de layout, concentre-se na mobilidade - e atualize o blog da empresa para que leitores, editores e executivos o amem. Nós conseguimos.
O blog da Promopult tem 9 anos. Durante esse tempo, ele passou por várias transformações. Sergey Glazov , o tecnólogo do nosso blog e outras coisas importantes no sistema Promopult, fala sobre o último.
Isso não é mais discutido, porque se tornou a norma: um padrão rápido e simples para o blog de uma empresa, uma pessoa, um pessoal, sim, o que for, WordPress. Você pode argumentar, mas o fato permanece.
Quero falar sobre o que descobri em termos de organização de código, trabalhando com o blog WordPress e seu suporte. Esta história é sobre o processo, porque o estado atual é o último ponto desse processo e parece que o estado atual é o mais bem-sucedido em comparação com todas as iterações passadas nas abordagens da organização.
O que aconteceu no (meu) início - em 2016
É raro quando um desenvolvedor cria e pensa em tudo do zero. Mais frequentemente, verifica-se que já ( mais frequentemente, mesmo por muito tempo, com um histórico separado ) existe um projeto que precisa ser apoiado. Redesenho, edições, enorme TK e requisitos. E nas condições do tudo existente, é necessário, de alguma forma, navegar rapidamente e resolver problemas.
Aceitei o blog em 2016, quando ele já tinha uma longa história e nem tudo é tão bonito quanto eu queria.
- Design de blog antigo com uma história de nove anos.
- A falta de uma versão para celular / tablet de qualquer forma.
- Mais de 600 posts.
- Problemas estruturais com o conteúdo e sua organização: mais de 20 categorias e mais de nove centenas de tags (agora mais, mas já paramos).
- Os planos já foram renomeados e movidos para um novo domínio. Isso também se aplica ao blog.
- Uma longa cadeia de ações ao trabalhar com código.
- Trabalhar sem controle de versão (.git).
Primeiras tarefas: mobilização e design
A principal tarefa foi adicionar adaptabilidade ao tópico existente do blog: tornar os usuários móveis capazes de ler postagens e usar o site adequadamente - eles conversaram e escreveram sobre o Mobile First cada vez mais, e as estatísticas mostraram que eles liam o blog pelo celular.
Paralelamente a esses trabalhos, um novo design foi desenhado.
Como desenvolvedor, trabalhei em conjunto com o designer, sem uma cadeia desnecessária de mediadores na discussão, para que o processo de comunicação fosse mais rápido e animado. O fato óbvio, é claro, mas por algum motivo é negligenciado em muitos processos. E acontece que o designer está fazendo algo muito separado da realidade. Fale com a boca e discuta todos os pontos. Cada participante do processo está interessado em fazer o bem e o bem. Mas nem todo mundo entende que o processo é uma cadeia conectada e, se um artista perde ou não faz algo no local de trabalho, será difícil para as pessoas no próximo processo.
No decorrer do trabalho na versão móvel, vi os contras e as fraquezas da organização do processo de desenvolvimento. Eu queria acelerar e simplificar tudo.
Como fizemos com o trabalho sobre o código no blog
Havia uma versão DEV do blog com um banco de dados de teste separado. O trabalho com arquivos ocorreu em um servidor remoto, os testes foram realizados em um endereço separado, inacessível no mundo exterior. Após o trabalho, os testes e o nascimento de uma determinada unidade de significado - ela foi lançada no blog de batalha através de um apelo ao administrador. O que ele fez foi uma mágica separada.
Para um blog em que algo muda uma vez por ano, um ótimo processo. Mas com a nova edição e suas necessidades, esse processo seria uma grande dor.
O que eu queria, como se costuma dizer, "em um mundo ideal"
Todo o código está. repositórios git . A versão de combate do blog é o master deste repositório. Todo o trabalho com o código ocorre por meio de confirmações em uma filial ou em outras ramificações associadas a grandes tarefas individuais.
Após a conclusão da tarefa, um Pull Request (PR) e / ou Merge Request (MR) é criado com um conjunto de edições. O significado em MR e PR é o mesmo, mas em serviços diferentes - um nome diferente. Temos o GitLab , então Mesclar Pedido.
Ao criar o MR, um endereço temporário no formato -git--test.dev.blog.promopult.ru disponível, acessível apenas por IP para verificação ao vivo no ambiente de teste.
O código no MR criado é revisado e verificado automaticamente (código de código, que eu verifico a sintaxe de acordo com regras predefinidas) e no modo manual (a potência vertical da equipe, o timlid olha cuidadosamente para ele com seu olho atento convexo naval). Após passar na revisão - na interface do navegador do repositório .git, clica-se no botão Mesclar e todas as alterações aparecem no ar do blog de combate após um breve período de tempo óbvio.
Redesign, primeira abordagem
Blog redesenhar o plano de trabalho:
- Layout de um protótipo estático para os layouts de design de todas as páginas;
- Transformando o layout ("alongamento") em um tema WordPress.
Layout - uma etapa separada do trabalho. Para um trabalho conveniente com estilos (CSS), marcação e JS, o projeto usou um conjunto de plugins e módulos, que são montados através das tarefas Gulp descritas no construtor SPT (Start Project Template).
As palavras-chave usadas no coletor do tópico estático do blog são: HTML, CSS, JS, Babel, Gulp, PostCSS, SCSS, Nunjucks.
Após a conclusão do layout, a estrutura era a seguinte ( apenas os diretórios de primeiro nível são indicados ):
#── design # Design, layouts e tudo
App── app / # Fontes do projeto: módulos separados
Dist── dist / # A versão montada do projeto (arquivos html) e todas as estatísticas
G── gulpfile.js / # Config Gulp.js
Package── package.json # Arquivo de configuração do coletor: pacotes, scripts
Cada elemento semântico visual individual na página, por exemplo, um cartão postal ( /components/article_card/ ), era uma pasta na qual estava:
- arquivo de marcação ( article_card.html ),
- arquivo de estilos ( article_card.scss ),
- arquivo JS ( article_card.js ).
E cada página foi montada a partir de blocos de componentes separados. Os blocos são fáceis de manipular e quaisquer alterações não afetam os elementos vizinhos.
Na saída, o coletor criou a pasta dist , que continha arquivos html prontos para visualização visual no navegador no estágio de edição e coordenação, além de um arquivo de estilo, todos os temas e dois arquivos JS: um arquivo ( app.js ) descrevia a lógica e o comportamento site, o segundo ( vendor.js ) continha todas as bibliotecas usadas para o site (jQuery, fotorama, magnific-popup e outros).
Em seguida, você precisa transformar tudo isso em um tema WordPress e refletir sobre a estrutura do arquivo. Para que você possa trabalhar convenientemente com um layout estático e ao lado dele, coloque um tema WP.
Lista de layouts preparados pelo designer. Eles são iguais aos arquivos de tema do blog WordPress:
- Página inicial (arquivo
home.php ). - Postagem
single.php / página de postagem ( single.php ). - Visualização de uma única página de texto (
page.php ). - A página de inscrição no boletim informativo (
subscribe.php ). - Erro 404 (
404.php ). - Página de tags separada (
tag.php ). - Página de categoria separada (
category.php ). - Pesquisa e resultados da pesquisa (
search.php ).
Um fluxo de trabalho com essa abordagem e a separação entre a versão estática e a versão WordPress do tema é o seguinte: se você precisar corrigir algo na parte visual, as alterações serão feitas na versão estática e após o teste ser transferido para o tema. Se forem necessárias edições em alguma parte não visual, apenas os arquivos com tema WP serão alterados.
A pasta do tema do blog é bsp . Ele está localizado ao longo do caminho na pasta com os tópicos do próprio blog:
W── wp-content / # arquivos de sites personalizados do WordPress
Temas do site / # Themes do site
App │ ├── app / # Fontes de um tema estático
Exemplo de tarefa gulpfile.js / # Gulp-tasks for assembly
Dist │ ├── dist / # Criar um tópico estático
│ │ │ ├── assets / # Recursos: JS, CSS e gráficos
B │ ├── bsp / # WP-PromoPult Tema do blog
Assets │ │ ├── assets / # Recursos: JS, CSS e gráficos, copiando de `/ dist /`
Home │ │ ─── home.php # A página principal do blog e outros arquivos na raiz do tópico
O local do tema wordpress é óbvio e predeterminado pela estrutura de arquivos do próprio WordPress.
Não há outros tópicos no diretório de temas - tudo padrão foi excluído. Existe um mito sobre o aumento da produtividade dessa maneira, mas não percebemos isso. Isso é feito mais por ordem no código. Não é necessário armazenar o que não é usado e definitivamente não será usado.
Também no .git estão todos os plugins WP usados. Em nosso site, são Google Sitemaps XML do Google, RSS para Yandex Turbo, RusToLat e WP-PostViews.
O protótipo estático e compilado das páginas do blog e dos arquivos de origem foi movido para o diretório de temas do blog: para interagir convenientemente com a parte lógica do modelo e com tudo o que é responsável pela aparência e pelo comportamento dos elementos na página.
Uma versão estática da montagem do projeto - com a fonte e todas as dependências na primeira tentativa de organizar a estrutura - foi colocada no diretório de temas.
Ou seja, próximo ao tema principal do bsp , foi adicionado o diretório /app , no qual estão localizados o código fonte do layout do tema e o gulp-collector. Mas nesta versão houve um momento difícil: os arquivos estáticos foram gerados em um diretório separado e, para que as alterações estivessem no tema WP, era necessário copiar o estilo estático e os arquivos de script para a pasta de assets dentro do tema.
Segunda abordagem: uma nova versão da estrutura
Nas primeiras semanas, isso foi decidido por um script de console simples que copiava os arquivos coletados de um tema estático para um tema WP. Ação excessiva leva a erros. Portanto, a opção era apenas corrigir a estrutura.
Temos três diretórios importantes (desde a raiz):
- Tema do WP:
/wp-content/themes/bsp - Fontes de um tema estático:
/app - Tópico estático coletado:
/dist
E dentro dele existem assets com arquivos de estilos, gráficos e JS
Você precisa organizar tudo para que os arquivos de estilos e scripts estáticos sejam coletados na pasta desejada ( /wp-content/themes/bsp/assets ).
A nova versão da estrutura era a seguinte:
G── gulpfile.js / # Gulp-tarefas para montagem
W── wp-content / # arquivos de sites personalizados do WordPress
├ ├── plugins / # WP-plugins
Temas do site / # Themes do site
Sp │ ├── bsp / # PromoPult Blog Tópico
App S │ topic── app / # Fontes de um tópico estático
│ │ │ ├── assets / # Recursos: JS, CSS e gráficos (geração automática)
Home │ │ ─── home.php # A página principal do blog e outros arquivos na raiz do tópico
W── wp-admin / # arquivos WP para o painel de administração
W── wp-includes / # arquivos WP do sistema
Na raiz de todo o projeto estão as tarefas gulp - e são executadas a partir da raiz. A configuração do gulp-tasks descreve a estrutura em que os arquivos estáticos são coletados do diretório wp-content/themes/bsp/app para wp-content/themes/bsp/assets sem nenhuma ação adicional, como copiar etc.
Os arquivos com tema WP permanecem inalterados e o trabalho prossegue de acordo com o cenário antigo: edições em estática → transferir para arquivos WP. As estatísticas CSS e JS são geradas imediatamente na pasta do tema e tudo funciona.
Tudo isso foi sobre o processo de trabalho. Agora, sobre como o blog está organizado.
Blog PromoPult: como funciona
O principal poder do blog é a equipe. Editor, autores, designers de layout.
A grande tarefa é facilitar o trabalho com o conteúdo do blog na área de administração. E levando em conta o fato de que o tema do nosso blog foi criado especificamente para tarefas de conteúdo e solicitações editoriais, o painel de administração foi modificado de acordo.
Lista de verificação antes da publicação
Qualquer trabalho é importante para controlar. O layout do artigo é um processo formalizado padrão, que pode ser facilmente apresentado na forma de uma lista de verificação.
Os caras viram a ideia da EmailSoldiers . Decidimos aplicá-lo em casa.
Se algum item não estiver marcado, o sistema o alertará antes da publicação.
Ao clicar nos links, links sublinhados no item da lista - realce um item específico.
A lista de verificação é compilada na mesma ordem que as configurações de postagem adicionais no painel de administração.
Configurações de postagem do blog
Intimamente entrelaçada com a lista de verificação de publicação descrita acima.
Ao desenvolver o tópico, tentei não usar plug-ins, mas criar uma solução simples e fácil para as tarefas do tópico. Destaques:
- Descrições para meta tags de SEO.
- Descrições para tags OpenGraph que usam redes sociais para compartilhar material e formar bons cartões de artigos.
- Trabalho conveniente com fotos de capa para posts. É necessária uma imagem - ela é adicionada ao cartão postal no bloco de publicação, exibido na página principal e na página de cabeçalho ou tag.
- Configurações adicionais de tema: uma postagem pode ser com ou sem capa, há um breve texto de anúncio que mostramos no cabeçalho com uma capa e também é usado na descrição do artigo na lista de discussão resumida.
A seção de configurações de postagem é implementada através de meta-caixas e campos personalizados no WordPress.
Através da meta-caixa, a lista de verificação da publicação também foi adicionada.
Nos modelos, trabalhar com campos é simples: se o campo não estiver vazio e preenchido, obtemos o valor e o mostramos. Por exemplo, é assim que a reação do bloco à postagem é exibida:
<?php if (get_post_meta($post->ID, 'postreaction', true)) { ?> <div class="article_reaction"> <div class="label-reaction"><span><?php echo get_post_meta($post->ID, 'postreaction', true); ?></span></div> </div><!-- /.article_reaction --> <?php } ?>
Um exemplo de uma saída de reação em um cartão postal:
Nice little things
Há algumas pequenas coisas legais que talvez ninguém veja. Mas se alguém percebeu - bom.
Por exemplo, as datas de publicação de uma postagem em cartões e em uma postagem separada em nosso alfabeto cirílico e como se curvar. Por alguma razão, isso não está na caixa do WordPress. Se a data de publicação estiver no ano atual, o ano não será mostrado conosco. Se o ano for diferente do atual, a data será exibida junto com o ano de publicação.
Publicar comentário contador. Eles argumentaram por um longo tempo que “0 comentários” ou “nenhum comentário” é muito confuso. A solução é muito simples: não mostre o contador de comentários, se houver menos de um comentário.
Em geral, estamos trabalhando em um sistema de comentários separadamente e gostaríamos de falar sobre isso em um grande post separado. Fazemos um sistema de comentários simples e conveniente, com autorização simples através das redes sociais.
Gostos próprios: comentar ou compartilhar links em redes sociais é uma questão longa pela taxa de consumo de conteúdo, mas clique em "curtir" e deixe claro que o artigo é interessante - simples e rápido. Fizemos nossos gostos simples e colocamos o contador no cartão postal. E os gostos chegam bem rápido. E, como eles estão no final do artigo, também é um sinal de que o texto foi lido.
Eles criaram um tema sombrio para o blog - agora está na moda. Levando em conta a estrutura modular (de fato, o site é um conjunto de blocos que são de alguma forma combinados entre si) e a organização dos estilos, acabou sendo feito muito rapidamente.
Sobre uma técnica interessante
O tópico possui uma minificação do código de marcação, CSS e JS. CSS e JS são compactados por meio de tarefas de gulp no coletor de estática, mas a minificação da marcação é feita através do gancho do WordPress WP_HTML_Compression .
E nos comentários da marcação, adicionamos um código promocional para aqueles que estão interessados em como o site é organizado por dentro e que, em primeiro lugar, procura o código-fonte:
Cache CSS e JS. Para armazenar em cache estilos e arquivos de script, mas sempre seja relevante, se refizermos algo, usamos filemtime (). Muitos nesse caso usam ?<?php echo time(); ?> ?<?php echo time(); ?> . Mas essa opção baixa o arquivo e faz uma solicitação a cada chamada.
Melhor usar esse truque:
<link rel="stylesheet" type="text/css" href="<?php echo get_template_directory_uri(); ?>/assets/styles/style.css?t=<?php echo filemtime(get_theme_file_path().'/assets/styles/style.css'); ?>" />
Nesse caso, os arquivos serão baixados se tiverem sido alterados e a data em que o arquivo foi modificado será adicionada ao parâmetro de solicitação.
Quais plugins usamos
Apesar da possibilidade e do desejo, em alguns casos, de seguir com sua decisão, ainda usamos plugins. Nossa lista é a seguinte:
Dicas de conclusão para quem trabalha no blog de uma empresa
- Aconselho no início do trabalho no projeto a pensar imediatamente sobre o dimensionamento.
- Certifique-se de usar
.git no seu trabalho. Para 2019, é claro, conselhos estranhos, mas esse conselho pode salvar alguém de cabelos grisalhos e repreender quando algo der errado. - É melhor dividir o desenvolvimento e trabalhar em um tema do WordPress em dois estágios: primeiro, invente algo estático e já faça "puxar" algo como um tema do WordPress.
- Se houver uma oportunidade - tempo, equipe e compreensão de por que você precisa de tudo isso - faça você mesmo, sem usar opções prontas. Ganhe em ordem e entenda como tudo funciona. Você não produzirá muletas.
- Use ganchos e recursos padrão do WordPress se o seu blog for construído sobre ele. Personalizar e criar uma solução conveniente é rápido e fácil.
- Torne conveniente para o usuário e os editores.
- Não se esqueça das redes sociais e do micro-layout.
- Não se esqueça das versões móveis.
- Não se esqueça das atualizações regulares de plugins e sistemas.
- Selecione apenas plugins comprovados.
O trabalho no blog continua - fique conosco.