Partilhar: WhatsApp
aulify
UC UC02832 · T. Desenv. Software, T. Sist. Comp. Redes

Ficha 02 · Plugins, hooks, headless e segurança

Estender WordPress, CMS headless, hardening
Versão · Aluno
Tempo · 60 minutos
Cotação · 100 pontos
Aluno(a)
Turma
Data
Objectivos da ficha

Parte I · Plugins e hooks

Exercício 1 · Escolher plugins (10 pts)

Indica um plugin adequado para cada necessidade:

a) Melhorar SEO. ___

b) Backup automático. ___

c) Firewall e bloqueio de bots. ___

d) Formulário de contacto. ___

e) Loja online. ___

a) Yoast SEO ou Rank Math. b) UpdraftPlus. c) Wordfence (ou Sucuri). d) Contact Form 7 ou WPForms. e) WooCommerce.

Exercício 2 · Action vs Filter (15 pts)

a) Qual a diferença entre uma action e um filter? (5 pts)

b) Escreve uma action que adiciona texto no rodapé. (5 pts)

c) Escreve um filter que põe "★ " antes de cada título de post. (5 pts)

a) Uma action executa código num determinado momento (não devolve nada — produz um efeito). Um filter recebe um valor, modifica-o e devolve-o (altera dados antes de serem usados).

b)

add_action('wp_footer', function () {
    echo '<p style="text-align:center">© 2026 Aulify</p>';
});

c)

add_filter('the_title', function ($titulo) {
    return '★ ' . $titulo;
});

Exercício 3 · Plugin simples (15 pts)

Escreve um plugin completo "Aviso Cookies" que mostra uma barra no rodapé de todas as páginas.

<?php
/*
Plugin Name: Aviso Cookies Aulify
Description: Mostra uma barra de aviso de cookies no rodapé.
Version: 1.0
Author: Aulify
*/

if (!defined('ABSPATH')) exit;   // impede acesso directo

add_action('wp_footer', function () {
    ?>
    <div style="position:fixed;bottom:0;left:0;right:0;
                background:#1a1a2e;color:#fff;padding:12px;
                text-align:center;font-size:14px;z-index:9999;">
        Este site usa cookies essenciais.
        <button onclick="this.parentElement.remove()"
                style="margin-left:12px;padding:4px 12px;">OK</button>
    </div>
    <?php
});

Colocar em wp-content/plugins/aviso-cookies/aviso-cookies.php e activar. O if (!defined('ABSPATH')) exit; é uma prática de segurança padrão.

Exercício 4 · Custom Post Type (15 pts)

A escola quer gerir "Eventos" no painel. Escreve o código que regista o custom post type.

add_action('init', function () {
    register_post_type('evento', [
        'label'        => 'Eventos',
        'public'       => true,
        'has_archive'  => true,
        'menu_icon'    => 'dashicons-calendar-alt',
        'supports'     => ['title', 'editor', 'thumbnail', 'excerpt'],
        'rewrite'      => ['slug' => 'eventos'],
        'show_in_rest' => true,   // editor de blocos + REST API
    ]);
});

Colocar no functions.php do child theme ou num plugin. Aparece "Eventos" no menu do painel, com arquivo em /eventos.

Parte II · Headless

Exercício 5 · Tradicional vs Headless (15 pts)

a) Explica a diferença entre CMS tradicional e headless. (5 pts)

b) Para cada caso, indica qual escolher: (10 pts) - Site institucional simples editado pela secretaria. - Conteúdo partilhado entre site Next.js, app móvel e ecrã informativo.

a) Tradicional: o CMS gere o conteúdo e gera o HTML que o visitante vê (tema). Headless: o CMS só gere conteúdo e expõe-no por API (REST/GraphQL); o frontend é separado e independente.

b) - Site institucional simples → Tradicional (WordPress com tema). Sem equipa técnica, secretaria edita, ecossistema resolve tudo. - Conteúdo multi-canal (Next.js + app + ecrã) → Headless. Uma fonte de conteúdo via API alimenta vários frontends.

Exercício 6 · REST API WP (10 pts)

a) Que endpoint devolve todos os posts via REST API do WordPress?

b) E um post específico com id 42?

c) Que vantagem isto traz?

a) GET /wp-json/wp/v2/posts

b) GET /wp-json/wp/v2/posts/42

c) Permite usar o WordPress como headless: o conteúdo editado no painel WP é consumido por um frontend separado (React, Next.js, app móvel). Reaproveita o editor familiar do WP com um frontend moderno e rápido.

Parte III · Segurança

Exercício 7 · Hardening (15 pts)

O site WordPress da escola foi invadido. Lista 5 medidas de segurança que deviam ter sido aplicadas.

  1. Manter actualizado — core, temas, plugins. A maioria dos ataques explora versões antigas com vulnerabilidades conhecidas.
  2. Senhas fortes + MFA no wp-admin; remover/renomear o utilizador "admin".
  3. Limitar tentativas de login (plugin) — bloqueia brute-force.
  4. Menos plugins, só de fontes confiáveis e mantidos.
  5. WAF (Wordfence ou Cloudflare) à frente do site.
  6. Backups automáticos e testados — para restaurar rapidamente.
  7. HTTPS obrigatório; DISALLOW_FILE_EDIT activo; permissões de ficheiros correctas.

Bónus: monitorização de integridade de ficheiros e alertas de login.