{"id":233900,"date":"2023-02-24T18:15:00","date_gmt":"2023-02-24T15:15:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=233900"},"modified":"2022-11-11T13:04:41","modified_gmt":"2022-11-11T10:04:41","slug":"guia-completo-em-configurando-um-ambiente-de-desenvolvimento-para-gutenberg","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/pt-pt\/guia-completo-em-configurando-um-ambiente-de-desenvolvimento-para-gutenberg\/","title":{"rendered":"Guia Completo em Configurando um Ambiente de Desenvolvimento para Gutenberg"},"content":{"rendered":"\n

Este guia \u00e9 para voc\u00ea que deseja escrever c\u00f3digo para Gutenberg com sintaxes ES6, ESNext e JSX e precisa configurar webpack e babel para transform\u00e1-los em arquivos que voc\u00ea pode usar no editor Gutenberg. Veremos o que voc\u00ea precisa fazer, por que e como podemos usar e estender os padr\u00f5es do WordPress e personaliz\u00e1-los para atender \u00e0s nossas necessidades.<\/p>\n

Se voc\u00ea \u00e9 novo em todos os conceitos de npm, webpcak e Babel, voc\u00ea deve ler a se\u00e7\u00e3o a seguir que visa explicar o b\u00e1sico de como essas ferramentas funcionam e como voc\u00ea as usa. No entanto, se voc\u00ea j\u00e1 fez isso antes e est\u00e1 familiarizado com o processo, talvez desenvolvendo com React, pule para a pr\u00f3xima se\u00e7\u00e3o onde realmente configuraremos as coisas.<\/p>\n

Para iniciantes: npm, webpack e babel<\/h2>\n

Se voc\u00ea n\u00e3o tiver certeza de por que precisamos fazer tudo isso para escrever Javascript para Gutenberg, recomendo que voc\u00ea leia meu post<\/a> que explora os fundamentos do desenvolvimento para Gutenberg \u2013 onde explico a diferen\u00e7a nas vers\u00f5es de Javascript e por que vale a pena.<\/p>\n

Se voc\u00ea nunca fez isso antes, primeiro voc\u00ea precisar\u00e1 instalar o Node.js<\/a> em seu computador. Clique no link, baixe e instale. Inclu\u00eddo no Node.js, voc\u00ea ter\u00e1 uma ferramenta que usaremos para definir a maior parte da configura\u00e7\u00e3o. Esta ferramenta \u00e9 npm<\/code>, que permite instalar bibliotecas Javascript e executar scripts atrav\u00e9s de linha de comando\/terminal. Voc\u00ea pode usar alternativamente yarn<\/code>se preferir, mas para este guia usaremos npm<\/code>.<\/p>\n

npm<\/h3>\n

Este guia n\u00e3o entrar\u00e1 em detalhes sobre todas as coisas que voc\u00ea pode fazer com npm<\/code>o, mas explicar\u00e1 o conceito b\u00e1sico dele e as coisas que s\u00e3o relevantes para nossos prop\u00f3sitos. Usaremos npm<\/code>para duas coisas; para instalar as bibliotecas necess\u00e1rias em nosso projeto e para executar comandos para construir (compilar) nossos arquivos Javascript.<\/p>\n

Com npm<\/code>voc\u00ea pode instalar qualquer pacote Javascript de c\u00f3digo aberto p\u00fablico. Se f\u00f4ssemos desenvolver com React (fora do WordPress), precisar\u00edamos instalar bibliotecas React e bibliotecas webpack. O WordPress oferece toda uma gama de bibliotecas (principalmente para Gutenberg) que voc\u00ea pode instalar, mas estamos realmente interessados \u200b\u200bem apenas uma: @wordpress\/scripts<\/code>\u2013 o que nos ajuda a simplificar nossa configura\u00e7\u00e3o.<\/p>\n

Sempre que voc\u00ea instalar uma biblioteca, npm<\/code>ir\u00e1 criar uma subpasta ” node_modules<\/code>" onde est\u00e3o armazenadas as bibliotecas instaladas. Voc\u00ea nunca precisar\u00e1 entrar nesta pasta ou alterar nada aqui, mas tenha em mente que esta pasta conter\u00e1 facilmente (literalmente!) dezenas de milhares de Esta \u00e9 uma pasta que voc\u00ea nunca deve colocar no git ou incluir em qualquer tema ou plugin finalizado. As bibliotecas s\u00e3o necess\u00e1rias apenas durante o desenvolvimento.<\/p>\n

Quando seu ambiente est\u00e1 configurado, voc\u00ea pode usar npm<\/code>para executar scripts definidos em seu package.json<\/code>arquivo. Dependendo do projeto, voc\u00ea normalmente teria pelo menos dois scripts; um para construir os scripts e outro para iniciar o “modo de observa\u00e7\u00e3o". No “modo de observa\u00e7\u00e3o” npm<\/code>inicia um processo no terminal que espera e ouve as altera\u00e7\u00f5es feitas em qualquer arquivo e as compila em tempo de execu\u00e7\u00e3o sempre que voc\u00ea clicar em salvar. Voc\u00ea pode estar familiarizado com esse conceito se j\u00e1 usou programas compiladores SCSS ou LESS antes. \u00c9 muito mais eficiente executar um script “watch” em segundo plano que recompila toda vez que voc\u00ea salva, em vez de ir ao terminal e executar o comando build ap\u00f3s cada altera\u00e7\u00e3o.<\/p>\n

webpack e babel<\/h3>\n

Voc\u00ea pode desenvolver para Gutenberg sem fazer qualquer configura\u00e7\u00e3o de webpack ou babel. Como usamos as bibliotecas do WordPress, eles cuidar\u00e3o disso para n\u00f3s. No entanto, isso tem uma desvantagem – o padr\u00e3o \u00e9 um local e nome de arquivo fixos para seus arquivos de origem e de sa\u00edda. Todo o seu desenvolvimento Javascript precisa ser escrito dentro de um arquivo, em project-folder\/src\/index.js<\/code>, e a compila\u00e7\u00e3o sempre terminar\u00e1 em project-folder\/build\/index.js<\/code>. Se voc\u00ea estiver bem com isso, voc\u00ea pode pular toda a parte sobre a configura\u00e7\u00e3o do webpack. No entanto, se voc\u00ea estiver desenvolvendo um tema ou plug-in com v\u00e1rios recursos do Gutenberg (blocos personalizados, filtros, etc.), talvez queira pelo menos um nome de arquivo e local de sa\u00edda diferentes, al\u00e9m de permitir v\u00e1rios arquivos.<\/p>\n

Se voc\u00ea usa o pacote do WordPress para lidar com a configura\u00e7\u00e3o (@wordpress\/scripts<\/code>), o Babel j\u00e1 est\u00e1 configurado. Mas voc\u00ea deve estar ciente de que o pacote do WordPress pode n\u00e3o incluir plugins que voc\u00ea queira usar. Existe, por exemplo, um pacote que permite usar as novas chamadas “fun\u00e7\u00f5es de seta” (myFunction = (param) => { }<\/code>), para definir fun\u00e7\u00f5es sem a necessidade de vincular this<\/code>. Se voc\u00ea realmente deseja usar esses recursos do ESNext, precisar\u00e1 configurar o Babel por conta pr\u00f3pria em vez de usar os padr\u00f5es do WordPress. Vou passar como abaixo.<\/p>\n

O processo<\/h3>\n

O processo de desenvolvimento com o webpack, uma vez que tudo esteja configurado e instalado, \u00e9 navegar at\u00e9 a pasta do seu projeto no terminal e iniciar o script “watch”. Ele permanecer\u00e1 aberto e ouvir\u00e1 as altera\u00e7\u00f5es feitas em seus arquivos JS. Sempre que voc\u00ea clicar em salvar em seus arquivos Javascript, o terminal exibir\u00e1 informa\u00e7\u00f5es (espero) de que recompilou o arquivo com sucesso. Se houver algum erro de compila\u00e7\u00e3o, ele aparecer\u00e1 no terminal. Para interromper o processo de “observa\u00e7\u00e3o”, pressione CTRL + C.<\/p>\n

Configurando o ambiente<\/h2>\n

Eu suponho que voc\u00ea j\u00e1 tenha um WordPress local rodando em alguma pilha LAMP (programas como WampServer, XAMPP, Docker ou similares), e que voc\u00ea tenha um plugin ou tema pronto para come\u00e7ar a codificar seu Javascript.<\/p>\n

Eu recomendo criar uma subpasta dedicada ao seu desenvolvimento Javascript, pois voc\u00ea pode acabar com v\u00e1rios arquivos e pastas de configura\u00e7\u00e3o. Isso facilita a separa\u00e7\u00e3o de arquivos e pastas (por exemplo node_modules\/<\/code>) que voc\u00ea n\u00e3o deseja incluir em git commits ou compila\u00e7\u00f5es finais. Mas n\u00e3o h\u00e1 problema em usar seu tema principal ou pasta de plugins como pasta de projeto para desenvolvimento Javascript.<\/p>\n

No terminal (terminal do Mac OS ou prompt de comando do Windows ambos funcionam bem), navegue at\u00e9 a pasta do projeto. Quanto a este tutorial, vou assumir que estamos em um tema e criamos uma subpasta vazia gutenberg-dev\/<\/code>como nossa pasta de projeto.<\/p>\n

O primeiro passo \u00e9 inicializar um projeto npm \u2013 que \u00e9 basicamente apenas dizer npm<\/code>para gerar um package.json<\/code>arquivo. Este package.json<\/code>arquivo informa npm<\/code>sobre quais pacotes s\u00e3o necess\u00e1rios e quais scripts est\u00e3o dispon\u00edveis para execu\u00e7\u00e3o. Digite isso no terminal;<\/p>\n

npm init -y<\/code><\/pre>\n
Isso gera um package.json<\/code>arquivo com conte\u00fado padr\u00e3o na pasta do seu projeto.<\/p>\n
Em seguida, instalaremos o pacote do WordPress que nos ajudar\u00e1 a reduzir a quantidade de configura\u00e7\u00e3o que precisaremos fazer. Execute este comando:<\/p>\n
npm install --save-dev --save-exact @wordpress\/scripts<\/code><\/pre>\n
A tag --save-dev<\/code>est\u00e1 informando npm<\/code>que as bibliotecas fornecidas s\u00e3o necess\u00e1rias apenas para desenvolvimento, e --save-exact<\/code>est\u00e1 certificando-se de npm<\/code>instalar apenas uma vers\u00e3o, a mais recente.<\/p>\n
Abra o package.json<\/code>arquivo em seu editor. (npm<\/code>tamb\u00e9m ter\u00e1 gerado um package-lock.json<\/code>ao instalar os pacotes, voc\u00ea pode simplesmente ignorar este arquivo, \u00e9 nele package.json<\/code>que voc\u00ea far\u00e1 altera\u00e7\u00f5es). Ele deve ser preenchido com a configura\u00e7\u00e3o padr\u00e3o, e voc\u00ea pode notar que a instala\u00e7\u00e3o do pacote que fizemos anteriormente adicionou uma entrada @wordpress\/scripts<\/code>de uma determinada vers\u00e3o no devDependencies<\/code>. \u00c0 medida que voc\u00ea instalar mais pacotes, npm<\/code>atualizar\u00e1 package.json<\/code>com entradas para cada pacote. Tudo o que precisamos nos preocupar neste arquivo \u00e9 a scripts<\/code>propriedade, que s\u00e3o os scripts (comandos) que voc\u00ea pode usar npm<\/code>para executar. Atualize a propriedade scripts para isso (voc\u00ea pode remover o “teste” padr\u00e3o):<\/p>\n
\"scripts\": {\n    \"build\": \"wp-scripts build\",\n    \"start\": \"wp-scripts start\"\n},<\/code><\/pre>\n
Este trecho de c\u00f3digo informa npm<\/code>que temos dois scripts que podemos executar nesta pasta do projeto; “construir” e “come\u00e7ar”. Executamos um script com o comando npm run <scriptname><\/code>, no qual npm<\/code>iremos pesquisar package.json<\/code>e executar o comando definido como seu valor. Usamos a ferramenta wp-scripts<\/code>que veio no pacote que instalamos agora para compilar nosso Javascript uma vez (\"build\"<\/code>) ou iniciar o modo “watch” \/ “listen” para compilar sempre que salvarmos as altera\u00e7\u00f5es (\"start\"<\/code>).<\/p>\n
Isso tamb\u00e9m nos permite usar o webpack do WordPress e a configura\u00e7\u00e3o do Babel, para que n\u00e3o precisemos fazer isso sozinhos.<\/p>\n
Na pasta do seu projeto crie uma subpasta chamada src\/<\/code>. Dentro desta pasta crie um index.js<\/code>arquivo.<\/p>\n
Se voc\u00ea est\u00e1 bem com os padr\u00f5es do webpack, agora est\u00e1 feito! Escreva seu c\u00f3digo ES6 e JSX em index.js<\/code>e diga npm<\/code>para compil\u00e1-los executando o comando build:<\/p>\n
npm run build<\/code><\/pre>\n
ou inicie um processo de “observa\u00e7\u00e3o” no terminal que escute as altera\u00e7\u00f5es feitas com este comando (use CTRL+C para interromper o processo de observa\u00e7\u00e3o):<\/p>\n
npm run start<\/code><\/pre>\n
A execu\u00e7\u00e3o de qualquer um deles gerar\u00e1 uma build\/<\/code>subpasta no diret\u00f3rio do projeto com o resultado compilado em build\/index.js<\/code>.<\/p>\n
Isso \u00e9 tudo para a configura\u00e7\u00e3o de ambiente mais b\u00e1sica! Agora voc\u00ea est\u00e1 pronto para escrever Javascript ES6 para Gutenberg!<\/strong><\/p>\n
Se voc\u00ea deseja alterar o local e os nomes dos arquivos de origem ou de sa\u00edda, continue lendo.<\/p>\n
Configurando nomes e caminhos de arquivos de origem e sa\u00edda<\/h3>\n
Se voc\u00ea, como eu, n\u00e3o estiver satisfeito com o nome e a estrutura do arquivo padr\u00e3o \u2013 especialmente para o(s) arquivo(s) de sa\u00edda, voc\u00ea precisa verificar a configura\u00e7\u00e3o do webpack. Normalmente, por exemplo, se voc\u00ea estivesse desenvolvendo para React fora do WordPress, voc\u00ea precisaria definir uma configura\u00e7\u00e3o completa de webpack com o plugin Babel. Felizmente, o WordPress cuida disso para n\u00f3s e nos permite estender a configura\u00e7\u00e3o do pr\u00f3prio pacote de web do WordPress e ajustar apenas as partes que queremos alterar.<\/p>\n
Na pasta do seu projeto (mesma pasta que package.json<\/code>) crie um arquivo chamado webpack.config.js<\/code>e abra-o em seu editor. Escreva o seguinte neste arquivo:<\/p>\n
const defaultConfig = require(\"@wordpress\/scripts\/config\/webpack.config\");\nconst path = require('path');\nmodule.exports = {\n    ...defaultConfig,\n    entry: {\n        'block-mynamespace-myblock': '.\/src\/block-mynamespace-myblock.js'\n    },\n    output: {\n        path: path.join(__dirname, '..\/assets\/js\/gutenberg'),\n        filename: '[name].js'\n    }\n}<\/code><\/pre>\n
A primeira coisa que fazemos \u00e9 buscar @wordpress\/scripts<\/code>a configura\u00e7\u00e3o do webpack na vari\u00e1vel defaultConfig<\/code>. Dentro da configura\u00e7\u00e3o do webpack module.exports<\/code>, a primeira coisa que fazemos \u00e9 aplicar tudo defaultConfig<\/code>usando o operador spread (...<\/code>). Essas duas partes garantem que estendemos a configura\u00e7\u00e3o do webpack do WordPress, incluindo tudo dentro dele. Ap\u00f3s o operador de spread podemos ajustar ou adicionar qualquer propriedade que desejamos alterar; no nosso caso, o local de origem e o local de sa\u00edda.<\/p>\n
A entry<\/code>propriedade define os arquivos de origem, que por padr\u00e3o s\u00e3o .\/src\/index.js<\/code>. Cada entrada na entry<\/code>propriedade \u00e9 um par chave + valor que o webpack compilar\u00e1 (e assistir\u00e1). No exemplo acima eu defini ‘ block-mynamespace-myblock<\/code>‘ localizado src\/block-mynamespace-myblock.js<\/code>como um ponto de entrada. Voc\u00ea pode adicionar quantos pares de chave + valor aqui para cada arquivo de origem que deseja compilar.<\/p>\n
A output<\/code>propriedade decide a localiza\u00e7\u00e3o dos arquivos compilados. Em path<\/code>voc\u00ea define a pasta de destino para todos os arquivos compilados. Estou usando um auxiliar de caminho para poder navegar nos diret\u00f3rios corretamente na minha configura\u00e7\u00e3o. No exemplo acima, estou dizendo ao webpack que todos os arquivos compilados devem terminar na minha theme-folder\/assets\/js\/gutenberg\/<\/code>pasta. O importante \u00e9 usar ..\/<\/code>para percorrer a \u00e1rvore de diret\u00f3rios, sair da pasta do projeto e entrar em outra pasta onde quero que todos os arquivos Javascript do meu tema estejam. Ajuste o caminho para se adequar \u00e0 estrutura do seu projeto.<\/p>\n
Em segundo lugar, estou dizendo ao webpack que todos os nomes de arquivos devem ser nomeados como seus entry<\/code>nomes de chave correspondentes. theme-folder\/gutenberg-dev\/src\/block-mynamespace-myblock.js<\/code>Esta configura\u00e7\u00e3o do webpack compilar\u00e1 meu arquivo theme-folder\/assets\/js\/gutenberg\/block-mynamespace-myblock.js<\/code>. Se eu adicionasse outro arquivo de origem como par chave + valor em entry<\/code>, ele seria compilado na mesma pasta com a chave como seu nome de arquivo.<\/p>\n
Fa\u00e7a os ajustes desejados em seu webpack.config.js<\/code>arquivo e salve. Execute novamente qualquer um dos npm<\/code>comandos de compila\u00e7\u00e3o para gerar arquivos em seus novos locais.<\/p>\n
\u00c9 isso! Agora voc\u00ea estendeu a configura\u00e7\u00e3o do webpack do WordPress e agora controla onde sua fonte e seus arquivos de sa\u00edda devem ir.<\/strong><\/p>\n
No entanto, quero incluir uma \u00faltima dica neste guia. A configura\u00e7\u00e3o padr\u00e3o do WordPress para Babel pode estar faltando certos plugins Babel para certos novos recursos no ESNext. Por exemplo, com o padr\u00e3o acima e os padr\u00f5es do WordPress, voc\u00ea n\u00e3o poder\u00e1 usar fun\u00e7\u00f5es de seta em seu c\u00f3digo. Se isso \u00e9 importante para voc\u00ea, continue lendo.<\/p>\n
Adicione suporte para as sintaxes ESNext mais recentes com o Babel<\/h3>\n
No momento da reda\u00e7\u00e3o deste artigo, a configura\u00e7\u00e3o padr\u00e3o do Babel do WordPress n\u00e3o tem suporte para “sintaxes experimentais”, que inclui, por exemplo, fun\u00e7\u00f5es de seta. Para adicionar suporte para isso, voc\u00ea precisa fornecer seu arquivo de configura\u00e7\u00e3o do Babel, e ainda n\u00e3o encontrei uma maneira de estender a configura\u00e7\u00e3o do Babel do WordPress como fizemos com a configura\u00e7\u00e3o do webpack acima. Portanto, precisamos redefinir as predefini\u00e7\u00f5es do Babel, al\u00e9m de adicionar o plug-in “sintaxes experimentais”. Mas n\u00e3o se preocupe, \u00e9 um arquivo muito pequeno.<\/p>\n
O primeiro passo \u00e9 instalar alguns pacotes que precisamos para as predefini\u00e7\u00f5es do Babel \u2013 precisamos instalar os mesmos definidos na configura\u00e7\u00e3o do Babel do WordPress. Execute este comando para instalar @babel\/preset-env<\/code>e @babel\/preset-react<\/code>, assim como o pacote em que estamos interessados; @babel\/plugin-proposal-class-properties<\/code>:<\/p>\n
npm install --save-dev @babel\/preset-env @babel\/preset-react @babel\/plugin-proposal-class-properties<\/code><\/pre>\n
A segunda etapa \u00e9 adicionar o arquivo de configura\u00e7\u00e3o do Babel. Na pasta do seu projeto, crie um arquivo chamado .babelrc<\/code>(sem extens\u00e3o de arquivo).<\/p>\n
Nota para Windows: Se voc\u00ea estiver sentado em uma m\u00e1quina Windows, n\u00e3o poder\u00e1 criar arquivos sem extens\u00f5es de arquivo. Para contornar isso, voc\u00ea pode criar este arquivo usando o terminal\/prompt de comando. Execute este comando:<\/p>\n
echo hi > .babelrc<\/code><\/pre>\n
Este comando produzir\u00e1 “hi” no arquivo .babelrc<\/code>na pasta atual. Agora voc\u00ea pode abrir este arquivo em seu editor, remover o “oi” e adicionar o conte\u00fado real abaixo.<\/p>\n
O seu .babelrc<\/code>deve ficar mais ou menos assim:<\/p>\n
{\n    \"presets\": [\"@babel\/preset-env\", \"@babel\/preset-react\"],\n    \"plugins\": [\n        [\n            \"@babel\/plugin-proposal-class-properties\"\n        ]\n    ]\n}<\/code><\/pre>\n
Definimos as mesmas predefini\u00e7\u00f5es que voc\u00ea normalmente faria em um projeto React, e o mesmo que o WordPress faz. O que estamos adicionando \u00e9 a plugins<\/code>propriedade. Dentro do array de plugins<\/code>adicionamos o @babel\/plugin-proposal-class-properties<\/code>plugin Babel necess\u00e1rio para “sintaxes experimentais”, como fun\u00e7\u00f5es de seta.<\/p>\n
Conclus\u00e3o<\/h2>\n
Tenha em mente que o WordPress pode mudar sua configura\u00e7\u00e3o a qualquer momento, isso \u00e9 especialmente prov\u00e1vel de acontecer porque o Gutenberg \u00e9 relativamente novo. Como estendemos a configura\u00e7\u00e3o do WordPress, podemos em um ponto precisar atualizar nossa configura\u00e7\u00e3o novamente para atender \u00e0s nossas necessidades. Talvez o WordPress decida incluir suporte para sintaxes experimentais para que n\u00e3o tenhamos que fazer toda a configura\u00e7\u00e3o do Babel.<\/p>\n
Este n\u00e3o \u00e9 de forma alguma um guia exaustivo para configurar o Webpack e o Babel, mas o resultado de muitas experi\u00eancias e descobertas. Espero que isso tenha ajudado voc\u00ea a aprender como configurar seu pr\u00f3prio ambiente de desenvolvimento Gutenberg, e facilitou o suficiente para que isso n\u00e3o seja um grande obst\u00e1culo para come\u00e7ar a aprender ES6, ESNext, JSX e todas essas coisas boas ben\u00e9ficas para o desenvolvimento para Gutemberg!<\/p>\n
Fonte de grava\u00e7\u00e3o:  awhitepixel.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"
Este \u00e9 um guia completo sobre como configurar npm, webpack e babel para escrever c\u00f3digo para Gutenberg com sintaxes ES6, ESNext e JSX.<\/p>\n","protected":false},"author":1,"featured_media":151834,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[837,941,941,920,1110,920,816,816,837,846,846,867,867],"tags":[1170],"class_list":["post-233900","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guia-para-iniciantes","category-gutenberg-8","category-outro","category-n-a","category-plug-ins","category-tutoriais","category-wordpress-8","tag-affiai-pt-pt"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/posts\/233900","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/comments?post=233900"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/posts\/233900\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/media\/151834"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/media?parent=233900"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/categories?post=233900"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/pt-pt\/wp-json\/wp\/v2\/tags?post=233900"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}