Plugin Devenia instalado e testado em emanuelalmeida.pt (19-08-2026): 89 abilities elementor/* via WordPress Abilities API nativa. Confirmado nao acessivel por MCP nesta sessao (sem servidor MCP proprio) - testado via wp eval-file + WP_Ability::execute(). Achados reais: camada de auditoria de design funcional (evaluate-design score 88/100 em pagina real), delete-template funcional (preenche gap do EMCP), gate template-first em authoring primitives, bug de poluicao de settings em add-heading, bug de PHP warning em list-experiments, update-element exige objecto completo (nao merge parcial como EMCP). Artefactos de teste removidos (post 18166, template 18168).
74 lines
11 KiB
Markdown
74 lines
11 KiB
Markdown
---
|
|
name: mcp-abilities-elementor
|
|
description: Plugin WordPress de terceiros (Devenia, GPLv2) que expõe 89 abilities Elementor via a WordPress Abilities API nativa (core 6.9+) — CRUD de páginas/elementos/templates, gestão de kits, e uma camada de auditoria de qualidade de design sem equivalente no EMCP Tools. Instalado e testado ao vivo em emanuelalmeida.pt (19-08-2026). Usar quando "mcp-abilities-elementor", "wordpress abilities api elementor", "evaluate-design elementor", "audit generic layout", "delete-template elementor", "kit settings elementor mcp", "score-distinctiveness".
|
|
layer: wiki
|
|
---
|
|
|
|
# /mcp-abilities-elementor — Plugin de Abilities Elementor (Devenia)
|
|
|
|
Instalado e testado ao vivo em `emanuelalmeida.pt` (19-08-2026): download `https://downloads.devenia.com/mcp-abilities-elementor.zip` → `wp plugin install ... --activate`. Fonte: `github.com/bjornfix/mcp-abilities-elementor` (GPLv2, 24★). Requer WP 6.9+ (confirmado: site em 7.0.4), PHP 8.0+, Elementor activo; Elementor Pro opcional (Theme Builder/Custom Code/Form Submissions ficam indisponíveis sem Pro — confirmado: `list-custom-code` devolveu `{"success":false,"message":"Elementor custom code post type is not available"}` mesmo com Elementor Pro 4.0.0 activo, porque essa funcionalidade Pro específica não está disponível nesta versão/licença).
|
|
|
|
## 🔴 Arquitectura — NÃO está acessível por MCP nesta sessão, só por wp-cli/PHP
|
|
|
|
Este plugin regista abilities na **WordPress Abilities API nativa** (`wp_register_ability()`, ver skill genérica sobre a API). Ele **não** cria o próprio servidor MCP nem se liga ao adapter interno do EMCP Tools — o seu `mcp-abilities-elementor.php` (228KB) não tem uma única referência a `mcp_adapter`/`McpServer`/`register_server`. Confirmado ao vivo: depois de activo, `wp mcp-adapter list` continua a mostrar só os 3 servidores de sempre (`elementskit-mcp-server`, `mcp-adapter-default-server`, `emcp-tools-server`) — nenhum servidor novo apareceu, e as 89 abilities `elementor/*` **não** entraram em nenhum deles (o `mcp-adapter-default-server` é configurado explicitamente pelo EMCP Tools via o filtro `mcp_adapter_default_server_config`, não expõe automaticamente tudo o que está no registry core).
|
|
|
|
O README do plugin assume que existe uma instalação separada do **WordPress MCP Adapter oficial** (`github.com/WordPress/mcp-adapter`) como plugin próprio — que **não está instalado** neste site. Instalar esse segundo plugin não foi tentado nesta sessão (risco de colisão de classes com a cópia que o EMCP Tools já bundla internamente, por confirmar antes de tentar).
|
|
|
|
**Caminho de teste usado, funcional e reproduzível:** chamar a ability directamente via `WP_Ability::execute()` por `wp eval-file`, sem transporte MCP nenhum — o mesmo caminho de código que um cliente MCP acabaria por invocar:
|
|
|
|
```bash
|
|
# harness reutilizável (criar uma vez em /tmp/ability-test.php no servidor):
|
|
cat > /tmp/ability-test.php << 'PHPEOF'
|
|
<?php
|
|
$name = $args[0] ?? '';
|
|
$input = isset($args[1]) ? json_decode($args[1], true) : [];
|
|
$ability = wp_get_ability($name);
|
|
if (!$ability) { echo json_encode(['error' => 'ability not found', 'name' => $name]); return; }
|
|
try {
|
|
echo json_encode($ability->execute($input ?: []), JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);
|
|
} catch (\Throwable $e) {
|
|
echo json_encode(['error' => 'exception', 'message' => $e->getMessage()]);
|
|
}
|
|
PHPEOF
|
|
|
|
# chamar uma ability:
|
|
wp eval-file /tmp/ability-test.php 'elementor/get-theme-context' '{}' --path=/caminho/do/site --allow-root --user=1
|
|
```
|
|
|
|
**`--user=1` é obrigatório** — sem utilizador definido, `current_user_can()` dentro do `permission_callback` de cada ability falha silenciosamente/nega acesso, porque o wp-cli corre sem contexto de utilizador autenticado por omissão.
|
|
|
|
## Catálogo (89 abilities, 7 categorias)
|
|
|
|
Ver `references/catalogo.md` para a tabela completa com descrição de cada uma. Resumo por categoria: Page/Post Data (43), Authoring Primitives (12), Template Management (11), Theme Builder (2), Custom Code/Pro (5), Form Submissions/Pro (3), Site Tools & Settings (11) — soma o namespace `elementor/*` completo confirmado ao vivo (`wp eval 'count(array_filter(array_keys(wp_get_abilities()), fn($k)=>str_starts_with($k,"elementor/")))'` → 89).
|
|
|
|
## O que isto tem que o EMCP Tools não tem
|
|
|
|
- **Camada de auditoria de qualidade de design** — `evaluate-design`, `audit-generic-layout-patterns`, `score-distinctiveness`, `audit-generic-component-repetition`, `audit-surface-overuse`, `audit-emphasis-drift`, `audit-section-rivalry`, `audit-composition-rhythm`, `audit-separator-discipline`, `audit-column-*` (5 variantes), `extract-design-tokens`, `apply-text-hierarchy`, `normalize-section-spacing-rhythm`, `normalize-responsive-values`, `sync-component-variant`. **Testado ao vivo** em `emanuelalmeida.pt` post_id 9 ("Sobre mim"): `evaluate-design` devolveu `score: 88`, `recommendations: ["Top-level section composition is repeating. Increase compositional contrast between adjacent sections."]`, com breakdown por categoria (`generic_layout`, `distinctiveness`, `component_overuse`, etc.) incluindo assinaturas de secção e penalizações concretas. Genuinamente útil — sem equivalente algum no EMCP.
|
|
- **CRUD de templates completo**, incluindo `delete-template` — **testado ao vivo**: criei um template de secção (`create-template`, id 18168), depois `delete-template({id:18168, force:true})` apagou-o em definitivo com sucesso. Isto preenche exactamente o gap que documentei em `emcp-page-building` ("Não há tool de eliminação de template no conjunto comummente activo").
|
|
- **Multi-kit** — `list-kits`/`get-kit-settings`/`set-active-kit`. Testado: `emanuelalmeida.pt` tem 2 kits (`Kit Padrão` id 14 inactivo, `Default Kit` id 11 activo) — EMCP só expõe o kit activo via `get-global-settings`.
|
|
- **`get-official-widget-catalog`/`get-official-pattern-guidance`** — vai buscar o catálogo/orientação oficiais a elementor.com em tempo real, em vez de uma lista estática mantida à mão.
|
|
- **Form Submissions CRUD (Pro)** e **Custom Code CRUD (Pro)** completos — EMCP só tem fragmentos, maioritariamente desligados por omissão.
|
|
|
|
## O que isto NÃO tem / é pior que o EMCP
|
|
|
|
- **Não suporta elementos atómicos Elementor 4.0** — confirmado ao vivo: `add-container`/`add-heading` neste site (Elementor 4.2.2, atomic-capable) produzem `elType: "container"`/`widgetType: "heading"` **legacy**, nunca `e-flexbox`/`e-heading`. Para construção atómica v4, usar `emcp-page-building` (EMCP), não este plugin.
|
|
- **Nenhuma gestão de conteúdo WordPress genérico** — sem posts/pages/CPTs/media/menus/utilizadores/plugins fora do âmbito Elementor. Complementa, não substitui, `emcp-content-ops`.
|
|
|
|
## 🔴 Armadilhas e bugs confirmados ao vivo
|
|
|
|
1. **Gate "template-first" em todas as abilities de "Authoring Primitives"** — `add-container`/`add-heading`/etc. recusam-se a correr sem `template_lookup_status` explícito (ou uma chamada prévia a `find-template-for-pattern`). Testado: `add-container` sem esse campo devolveu `{"success":false,"message":"Raw Elementor container authoring requires template lookup status. Call elementor/find-template-for-pattern first...","required_next_step":"elementor/find-template-for-pattern"}`. Para edições pontuais legítimas (não um padrão reutilizável), passar `"template_lookup_status":"not_a_reusable_pattern"` — confirmado a destravar a chamada.
|
|
2. **`update-element` espera o elemento COMPLETO em `element_data` (com `id`), não um merge parcial de `settings`.** Diferente da convenção do EMCP (`update-element`/`update-atomic-widget` fazem merge parcial por omissão). Testado: `{"element_id":"x","settings":{...}}` falha ("element_data é obrigatório"); `{"element_data":{"settings":{...}}}` falha de novo ("Element data must include a string 'id'") — só funciona com o objecto completo `{"element_data":{"id":"x","elType":"widget","widgetType":"...","settings":{...}}}`. Confirmado também no changelog (v2.2.9): "guardrails... incomplete replacement payloads do not silently wipe populated Elementor containers/widgets unless `force_replace=true`" — o comportamento por omissão é substituição total, não merge.
|
|
3. **`delete-element` recusa apagar sem `force_delete:true`** mesmo num elemento aninhado (não literalmente top-level da página) — testado, mensagem "Refusing to delete a top-level Elementor element without force_delete=true". Passar sempre `force_delete:true` quando a intenção é mesmo apagar.
|
|
4. **🐛 Bug confirmado — `add-heading` (e provavelmente as outras "Authoring Primitives") grava os parâmetros de controlo da própria ability dentro do `settings` persistido do widget Elementor.** Testado: depois de `add-heading({..., "template_lookup_status":"not_a_reusable_pattern"})`, `get-element` devolveu `settings: {"parent_id":"980c94d","title":"...","template_lookup_status":"not_a_reusable_pattern","header_size":"h2"}` — `parent_id` e `template_lookup_status` **não são controlos Elementor válidos**, ficaram poluindo os dados reais do widget. Reportável ao autor; entretanto, não confiar cegamente no `settings` devolvido por `get-element`/`get-data` para saber quais chaves são controlos genuínos.
|
|
5. **🐛 Bug confirmado — `list-experiments` emite `PHP Warning: Array to string conversion` em `register-site-tools.php:632`.** Não é fatal (a chamada ainda devolve `success:true` com os dados), mas polui stderr/logs.
|
|
6. **Aplicação de estilo global (documentada no changelog, não testada nesta sessão):** desde a v2.3.6, escritas rejeitam cores/tipografia locais que não correspondam a um token global do Kit — cores hex locais são normalizadas para o token global correspondente quando possível, senão a escrita é rejeitada com "structured violations". `apply-text-hierarchy` desde então usa por omissão referências de tipografia global do kit em vez de overrides locais. **Verificar isto ao vivo antes de confiar cegamente** — não reproduzi este comportamento nesta sessão (só toquei em `title`, não em cor/tipografia).
|
|
7. **`elementor/update-data`, `elementor/clone-data`, `elementor/patch-data`** exigem confirmação explícita por ability antes de escrever dados brutos do documento Elementor (desde v2.3.11) — não testado nesta sessão, mas documentado no changelog; esperar um campo `confirm`-like obrigatório.
|
|
|
|
## Estado no site (19-08-2026)
|
|
|
|
Instalado e **activo** em `emanuelalmeida.pt` (`mcp-abilities-elementor` v2.3.36). Todos os artefactos de teste foram removidos (página de rascunho `#18166` apagada em definitivo via `wp post delete --force`; template de secção `#18168` apagado via `elementor/delete-template`). **Decisão em aberto:** o plugin fica activo mas **inacessível por MCP** até se instalar o WordPress MCP Adapter oficial separado ou se estender a config do servidor MCP do EMCP Tools — nenhuma das duas foi feita nesta sessão. Só chamável via `wp eval-file` (padrão acima) até essa decisão ser tomada.
|
|
|
|
## Skills relacionadas
|
|
- `emcp-page-building` — construção atómica Elementor 4.0 via EMCP (este plugin não suporta atómico).
|
|
- `emcp-content-ops` / `emcp-site-audit` — gestão de conteúdo WordPress genérico e segurança/performance (fora do âmbito deste plugin).
|