WordCamp Polónia 2023 - Gliwice relatório e resumo

O WordCamp Polónia 2023 em Gliwice, oficialmente WordCamp Gliwice 2023, decorreu de 12 a 14 de maio de 2023 no Centro Educativo e de Congressos da Universidade de Tecnologia da Silésia, na rua Konarskiego 18B (página do evento, localização). A sexta-feira foi o dia de contribuição, e o sábado e o domingo ficaram para as palestras, os workshops e o mastermind de negócio.

Este relatório segue o programa oficial. Todos os nomes e temas abaixo vêm da agenda e das descrições das sessões publicadas pela organização. Quando descrevemos o conteúdo de uma intervenção, baseamo-nos na descrição da sessão ou na gravação, e não em memórias de conversas de corredor. Os excertos de código são exemplos nossos sobre os temas tratados em palco, e estão assinalados como tal.

Se a sua empresa precisa de apoio técnico experiente ou está a planear uma migração complexa, veja o que fazemos como WordPress developer na WPPoland.

#Programa do WordCamp Gliwice 2023 dia a dia

A organização dividiu o programa em sete percursos. No sábado e no domingo as sessões decorriam em paralelo em várias salas, por isso ninguém conseguia ver tudo ao vivo.

O sábado foi aberto por Tomasz Karwatka, e a seguir Krzysztof Dyszczyk falou sobre a vida na era da IA. Os dois dias terminaram com uma sessão de perguntas e respostas. A lista completa de sessões está na página Sessions.

#O que acontece no WordCamp Contributor Day

A conferência arrancou na sexta-feira, 12 de maio, com o Contributor Day. Em vez de assistirem a palestras, neste dia os participantes juntam-se em grupos de trabalho que desenvolvem o ecossistema WordPress.

Segundo a página do Contributor Day, o dia decorreu assim:

• 9:30-10:00: registo, café e chá.
• 10:00-10:30: boas-vindas, divisão em equipas e início do trabalho nas mesas, com um pequeno workshop introdutório para quem participava pela primeira vez.
• 10:30-12:30: trabalho (contributing), depois pausa para almoço e segunda ronda de trabalho.
• No fim, balanço do dia e apresentação dos resultados.

A organização sublinhou que este dia é para todos, e não só para programadores: para designers gráficos, profissionais de marketing, tradutores e fotógrafos, com qualquer nível de experiência. A descrição mencionava a correção de erros, o preenchimento de traduções em falta, a criação de conteúdos e o envio de fotografias para a biblioteca aberta de multimédia. A participação exigia bilhete para a conferência e uma inscrição separada.

Para uma agência, este dia tem um sentido prático. Quem reporta um erro ou corrige uma tradução percebe melhor como as alterações chegam ao núcleo e quanto tempo demora o caminho entre o reporte e a versão publicada. Os guias de Full Site Editing e do editor de blocos nascem exatamente desta forma.

#Palestras de negócio no WordCamp Gliwice 2023

O percurso Business de sábado tratou da gestão de empresas que vivem do WordPress. As descrições das sessões são concretas, por isso resumimo-las com proximidade à fonte.

#De empresa de serviços a empresa de produto (Tomasz Karwatka)

Tomasz Karwatka foi cofundador, entre outras, da Divante, da Vue Storefront, da Callstack e da Open Loyalty, e dirige atualmente a Catch The Tornado, uma empresa que investe em empreendedores tecnológicos (biografia do orador). Na descrição da palestra explicou que na Divante e na Callstack foi possível criar produtos, entre eles o Vue Storefront, que passou pela aceleradora Y Combinator.

Temas anunciados: porque é que tão poucas empresas de serviços têm sucesso a criar produtos, que erros cometem com mais frequência, quanto custa realmente, como transformar um projeto numa empresa a sério, como obter financiamento externo e como o dono de uma empresa de serviços pode maximizar o valor para si próprio. A gravação está no WordPress.tv.

#Dois anos de OKR numa equipa WordPress (Michał Kaźmierczak)

Michał Kaźmierczak falou sobre o método OKR (Objectives and Key Results). A intervenção foi um balanço de mais de dois anos a aplicar OKR numa equipa de desenvolvimento WordPress: o que correu bem, o que não correu e a quem este método faz realmente falta. A descrição da sessão não indica métricas concretas, por isso não as acrescentamos aqui. Os detalhes estão na gravação.

#WooCommerce como coração do negócio (Łukasz Wilczak)

Łukasz Wilczak apresentou o case study de uma loja em WooCommerce cujas vendas anuais se contam em milhões de zlótis. A loja vende produtos únicos e feitos por encomenda, e o WooCommerce liga pagamentos, envios, faturas e CRM. A palestra mostrou o configurador de produto, o carrinho, a gestão de encomendas e a forma como a loja mudou o trabalho da equipa e o contacto com os clientes (gravação).

#Outras intervenções sobre negócio

No mesmo percurso intervieram: Ola Gościniak (escada de produtos digitais), Aleksander Misky (modelo de subscrição em WordPress), Izabela Karkocha (terminar projetos de forma a que o cliente recomende o trabalho), Adrian Kałamajski (venda de cursos e ebooks), Tomasz Kołkiewicz (a permuta como forma de gerar procura quando os clientes cortam custos), Dariusz Pichalski (o caminho até ao maior canal polaco sobre WordPress), Krzysiek Dróżdż, Dominik Kawula (uma empresa à qual os clientes regressam) e Marta Domasz (investir no desenvolvimento dos colaboradores). No domingo, Przemysław Hernik apresentou cinco regras para estimar tarefas, úteis tanto para developers como para gestores.

#Headless WordPress com Astro no WordCamp Gliwice

Maciek Palmowski tinha no programa duas intervenções sobre o mesmo tema, vistas de dois lados.

No sábado conduziu um workshop sobre a integração do WordPress com o Astro (sala J). Segundo a descrição, os participantes aprenderam os fundamentos do Astro: estrutura de ficheiros, componentes, layouts e routing, e no fim ligaram o WordPress ao Astro nos dois modos, SSG e SSR. É uma distinção importante: no modo SSG as páginas são geradas durante o build, no modo SSR a pedido, por isso a escolha depende da frequência com que o conteúdo muda.

No domingo, no percurso Technology, Palmowski perguntou se o headless WordPress faz mesmo sentido. Na descrição observou que, a julgar por muitos artigos e por muitas empresas, fica a impressão de que o headless é o único caminho certo, e perguntou diretamente se não será apenas mais uma forma de ganhar dinheiro (gravação). No mesmo dia, Adam Kanigowski mostrou um case study de Astro e WordPress como headless CMS: em que projetos funciona, como integrar o framework JS preferido (por exemplo, Vue.js) e que erros surgem durante a programação (gravação).

Abaixo está o nosso esquema desta arquitetura, e não um diapositivo da conferência:

DECOUPLED HEADLESS WORDPRESS ARCHITECTURE:
+-------------------------------+      REST API / GraphQL      +-------------------------------+
|     WordPress Backend         | ---------------------------> |     Astro                     |
| (wp-admin, editorial workflow,|       JSON Data Payloads     | (SSG at build time or SSR     |
|  custom post types, ACF)      |                              |  on request, component islands)|
+-------------------------------+                              +-------------------------------+
                |                                                              |
                v                                                              v
+-------------------------------+                              +-------------------------------+
| MySQL / MariaDB Database      |                              | CDN or edge hosting           |
| (not exposed to visitors)     |                              | (serves the generated HTML)   |
+-------------------------------+                              +-------------------------------+

#Porque é que um frontend em Astro envia menos JavaScript do que uma SPA típica

Numa instalação clássica de WordPress, cada pedido HTTP obriga o PHP a carregar os plugins, executar consultas a wp_posts e wp_postmeta, percorrer a hierarquia de templates e montar o HTML final. A cache de páginas atenua este custo, mas não o elimina.

No modo SSG, o Astro gera o HTML na fase de build. Por omissão, os componentes são renderizados sem JavaScript do lado do cliente, e a interatividade só é ativada onde a indicar com uma diretiva, por exemplo client:idle ou client:visible (documentação das diretivas do Astro). O painel do WordPress pode então funcionar num subdomínio separado, e os visitantes recebem HTML pronto, sem contacto com o PHP nem com a base de dados. Se compensa ou não depende do projeto, e era exatamente isso que Palmowski perguntava no domingo.

#Exemplo de getStaticPaths no Astro com a WP REST API

---
// src/pages/blog/[slug].astro
export async function getStaticPaths() {
  const response = await fetch("https://cms.example.com/wp-json/wp/v2/posts?_embed&per_page=100");
  const posts = await response.json();

  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
const featuredImage = post._embedded?.['wp:featuredmedia']?.[0]?.source_url;
---

<article class="prose max-w-3xl mx-auto py-12">
  <h1>{post.title.rendered}</h1>
  {featuredImage && <img src={featuredImage} alt={post.title.rendered} loading="eager" />}
  <div set:html={post.content.rendered} />
</article>

#WP-CLI: técnicas avançadas e search-replace seguro

No sábado, Marcin Krzemiński conduziu um workshop de técnicas avançadas de WP-CLI para quem já domina o básico. Segundo a descrição, os participantes instalaram e usaram extensões do WP-CLI, geraram código de plugins e temas e trabalharam com o WP-CLI num servidor remoto através de SSH. Os workshops não foram gravados.

As equipas que mantêm vários ambientes acabam, mais cedo ou mais tarde, por mover a base de dados entre domínios. Este excerto é um complemento nosso, baseado na documentação de wp search-replace.

#Como substituir dados serializados em segurança

A catástrofe típica com scripts SQL manuais de search-and-replace é danificar arrays PHP serializados nas tabelas wp_options e wp_postmeta. Quando o comprimento do texto muda e o comprimento guardado não (por exemplo, s:21:"https://staging.local" substituído por s:19:"https://example.com"), o PHP não consegue reconstruir o objeto. O resultado são widgets estragados e definições do tema perdidas.

A documentação do WP-CLI indica que o comando trata de forma inteligente os dados PHP serializados e não altera os valores das chaves primárias. Por omissão usa consultas SQL rápidas e passa para PHP nas colunas com dados serializados, e a flag --precise força o PHP em todas as colunas, o que é mais lento, mas mais fiável em estruturas complexas:

# Step 1: dry run to preview affected tables and matching rows
wp search-replace "https://staging.example.com" "https://example.com" \
  --all-tables \
  --dry-run \
  --precise

# Step 2: export a backup, then run the replacement
wp db export pre-migration-backup.sql
wp search-replace "https://staging.example.com" "https://example.com" \
  --all-tables \
  --precise \
  --recurse-objects

#Automatizar atualizações de plugins e do núcleo em scripts

# Verify file checksums against official WordPress.org releases
wp core verify-checksums
wp plugin verify-checksums --all

# Update every plugin that has an update available
wp plugin update --all

# Flush object cache and regenerate rewrite rules
wp cache flush
wp rewrite flush --hard

#Injeção de dependências em plugins WordPress

No sábado, Bartek Jaskulski conduziu um workshop sobre o contentor de injeção de dependências em plugins WordPress (sala F). Segundo a descrição, os participantes reconstruíram ao vivo um plugin de exemplo, e a sessão centrou-se na configuração do PHP-DI, um dos contentores DI mais populares em PHP. Temas abordados: o princípio da inversão de dependências como ponto de partida, evitar o padrão Service Locator, o papel das interfaces na programação orientada a objetos e a criação de serviços sem estado.

O problema que isto resolve é conhecido de quem mantém plugins mais antigos: centenas de funções num único ficheiro, variáveis globais (global $wpdb) e chamadas à base de dados misturadas com a lógica. O exemplo abaixo é nosso. Mostra uma classe que recebe as dependências pelo construtor, em vez de as criar ela própria:

<?php
declare(strict_types=1);

namespace WPPoland\Plugin;

interface CacheInterface {
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl = 3600): bool;
}

final class ObjectCacheService implements CacheInterface {
    public function get(string $key): mixed {
        return wp_cache_get($key, 'wppoland_group');
    }

    public function set(string $key, mixed $value, int $ttl = 3600): bool {
        return wp_cache_set($key, $value, 'wppoland_group', $ttl);
    }
}

final class CustomerReportManager {
    public function __construct(
        private readonly CacheInterface $cache,
        private readonly \wpdb $db
    ) {}

    public function generateReport(int $customerId): array {
        $cacheKey = "customer_report_{$customerId}";
        $cached = $this->cache->get($cacheKey);

        if ($cached !== false) {
            return $cached;
        }

        $query = $this->db->prepare(
            "SELECT * FROM {$this->db->prefix}customer_orders WHERE customer_id = %d",
            $customerId
        );
        $data = $this->db->get_results($query, ARRAY_A);

        $this->cache->set($cacheKey, $data, 1800);
        return $data;
    }
}

Esta estrutura permite substituir CacheInterface por um duplo de teste em PHPUnit ou Pest, sem uma base de dados WordPress a funcionar. Um contentor como o PHP-DI monta estes objetos automaticamente, por isso o new manual desaparece do código de arranque do plugin.

#Testes, ambientes locais e email: sessões para developers

Várias sessões de domingo no percurso Technology e workshops de sábado trataram do trabalho diário de um developer.

• Sebastian Kurzynowski interveio duas vezes. No sábado conduziu um workshop de TDD com React: primeiro os testes, depois o código que os cumpre e, no fim, a refatoração apoiada nesses testes, com ênfase na separação entre a lógica de negócio e a camada visual. No domingo falou sobre a forma como o TDD e outras abordagens orientadas para a qualidade poupam dinheiro, e sobre como introduzir TDD numa equipa composta sobretudo por pessoas que estão a começar a trabalhar em TI (gravação).
• Piotr Niewiadomski mostrou um ambiente local leve para WordPress, construído com Docker, Composer, o servidor web integrado do PHP e uma base de dados SQLite.
• Bartosz Nowak apresentou o Juniper, um boilerplate aberto desenvolvido depois dos workshops do WordCamp de 2022. A nova versão acrescentou scripts .sh para montar o projeto, uma abordagem orientada a objetos no tema e a gestão de plugins através de composer.json (repositório no GitHub).
• Kamil Porembiński respondeu à questão de saber porque é que os emails enviados pelo WordPress vão parar ao spam e se um plugin de envio resolve, por si só, o problema (gravação).
• O workshop de segurança de sábado, na sala J, destinava-se a profissionais de marketing, bloggers e empresários: política de palavras-passe e de acessos ao WordPress, verificação de fugas de dados e o que fazer depois de uma fuga.

#Desempenho do WordPress no WordCamp Gliwice 2023: TTFB, Core Web Vitals e imagens

Várias pessoas falaram de desempenho, cada uma de um ângulo diferente.

• Aneta Rutkowska perguntou se o TTFB depende apenas do alojamento. Na descrição anunciou o case study de um site em que o TTFB foi reduzido de mais de 3 s para 110 ms, uma análise de 65 000 instalações WordPress no alojamento LH.pl e dos dez plugins mais instalados, e uma comparação do impacto do alojamento e dos plugins no TTFB (gravação).
• Krystian Wójcik conduziu um workshop sobre as recomendações de Core Web Vitals: como melhorar cada parâmetro, a que ter atenção e quando não vale a pena perseguir a pontuação 100/100. Explicamos a nossa abordagem no guia de Core Web Vitals.
• Mateusz Gbiorczyk comparou os formatos WebP e AVIF com base na experiência com um plugin de conversão de imagens usado por centenas de milhares de sites (gravação).
• Jakub Józwiak mostrou a implementação do Algolia em WordPress, ou seja, levar a pesquisa de uma base de dados grande para fora da base de dados do WordPress.
• Piotr Pantkowski conduziu um workshop sobre a escolha de servidor para WordPress: os erros mais comuns na compra de alojamento e a verificação prática das funcionalidades essenciais.
• Maciej Kuchnik falou sobre migrações de dados difíceis entre instalações WordPress e sobre a forma de as planear.

#Como aliviar o WP-Cron no servidor

Há um tema que regressa sempre que se fala de TTFB, por isso acrescentamo-lo com base no manual de plugins do WordPress. O WP-Cron verifica a lista de tarefas agendadas a cada carregamento de página e executa as que já passaram do prazo. Não corre em segundo plano como o cron do sistema, por isso uma tarefa agendada para as 14:00 só é executada na primeira visualização depois dessa hora.

O manual descreve como passar o WP-Cron para o agendador de tarefas do sistema: primeiro cria-se a tarefa no sistema (em Linux, com crontab -e) e depois desativa-se a execução nas visualizações com a linha define( 'DISABLE_WP_CRON', true ); no wp-config.php. Segundo a documentação, executar o WP-Cron a cada visualização deixa então de ser necessário e só acrescenta trabalho ao servidor.

#Gutenberg e Full Site Editing no programa

Magdalena Paciorek mostrou componentes prontos do Gutenberg que os programadores podem usar para expandir o editor: criar novos blocos e painéis laterais, com exemplos de projetos reais (gravação).

No domingo, Łukasz Wroński conduziu um workshop para quem constrói sites com page builders e quer começar a usar o Full Site Editing. O plano incluía um tema filho com a estrutura de ficheiros (theme.json, functions.php, ficheiros CSS e JS), a passagem de uma landing page simples do Figma para o WordPress, a adição de um tipo de letra próprio e novos estilos de botões e listas.

#O futuro do WordPress, a IA e o WordPress Playground

O percurso Future&Business levantou questões sobre o rumo de toda a plataforma.

• Krzysztof Dyszczyk, na intervenção de abertura de sábado, falou sobre as tendências da inteligência artificial e os desafios que a sua generalização vai trazer.
• Um painel sobre IA com Krzysztof Radzikowski, Marta Domasz e Maciej Kuchnik, moderado por Kasia Aleszczyk, discutiu se se deve usar a IA ou temer pelo emprego.
• Albert Nogala decompôs a questão do estado do WordPress em fatores de negócio, sociais e tecnológicos.
• Michał Strześniewski comparou as ferramentas no-code e low-code com a abordagem clássica à criação de sites em WordPress.
• Oskar Sajdak falou sobre o WordPress na cloud AWS e Azure e sobre os problemas que esperam aí o programador.
• Mariusz Jałyński e Dominik Charasim trataram do impacto da IA no SEO e do trabalho com o ChatGPT.

A intervenção tecnicamente mais concreta foi a de Adam Zieliński sobre o WordPress Playground, ou seja, o WordPress a correr no navegador sem configurar um servidor. Na descrição indicou três utilizações: uma demonstração do plugin no site, testar código em diferentes versões de WordPress e PHP, e cursos interativos (gravação). Segundo a documentação do Playground, o projeto corre inteiramente do lado do cliente em WebAssembly, sem backend, e o ambiente é controlado através da Query API, da Blueprints API (um ficheiro JSON) ou da JavaScript API.

#Onde ver as gravações do WordCamp Gliwice 2023

As gravações das palestras estão na página do evento no WordPress.tv. A lista conta 31 vídeos, quase todos publicados a 30 de maio de 2023. Os workshops (WP-CLI, Astro, injeção de dependências, TDD com React, Core Web Vitals, segurança, do Figma ao FSE, escolha de servidor) e as sessões de mastermind não têm gravação, por isso deles só se sabe o que dizem as descrições das sessões.

#Resumo

O WordCamp Gliwice 2023 reuniu em três dias um Contributor Day, dois dias de palestras em vários percursos, oito workshops e um mastermind. Do ponto de vista técnico, os pontos mais fortes foram os workshops sobre Astro, WP-CLI e injeção de dependências, e as palestras sobre TTFB e Playground. Foi bom ver o tema headless tratado de duas perspetivas, a prática no workshop e a cética em palco.

Se a sua empresa está a planear uma migração para headless WordPress, precisa de melhorar os Core Web Vitals ou procura uma equipa de desenvolvimento experiente, conheça os nossos serviços de WordPress developer.