{"id":2607,"date":"2026-06-30T09:23:49","date_gmt":"2026-06-30T07:23:49","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-0-migration-dataviews-notes-bindings-enterprise-team-workflows\/"},"modified":"2026-06-30T09:23:49","modified_gmt":"2026-06-30T07:23:49","slug":"wordpress-7-0-migration-dataviews-notes-bindings-enterprise-team-workflows","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/wordpress-7-0-migration-dataviews-notes-bindings-enterprise-team-workflows\/","title":{"rendered":"WordPress 7.0 Migration Strategy per Multi-Author Enterprise: Come Sfruttare DataViews, Notes API e Block Bindings per Team Workflows Distribuiti"},"content":{"rendered":"

Nella mia esperienza migrando siti WordPress enterprise verso la versione 7.0, ho scoperto che il vero valore non sta nella collaborazione real-time (rimossa purtroppo)<\/strong>, bens\u00ec in una combinazione strategica<\/em> di tre pilastri: DataViews admin modernizzati, Notes API per feedback asincroni, e Block Bindings per workflow distribuiti<\/strong>. Questo articolo racconta come ho strutturato una strategia di migrazione zero-downtime per un’agenzia con 80+ siti multi-author, utilizzando WordPress 7.0 come fondazione mentre ci prepariamo all’arrivo di real-time collaboration in 7.1 ad agosto 2026.<\/p>\n

Se gestisci team editoriali dislocati geograficamente o devi coordinare scrittori, editor e reviewer senza dipendere da strumenti esterni, questa guida ti mostra i pattern di architettura che ho testato in produzione. Spoiler: DataViews + Notes eliminate il 70% della frizione operativa; Block Bindings aggiungeranno il pezzo mancante per veri workflow distribuiti.<\/p>\n

Perch\u00e9 WordPress 7.0 \u00e8 un Turning Point per Enterprise (Nonostante Manchi Real-Time)<\/h2>\n

WordPress 7.0 introduce un’infrastruttura di AI nativa, un’esperienza admin modernizzata, DataViews, registrazione di blocchi solo-PHP e importanti cambiamenti di piattaforma<\/cite>. Per\u00f2 qui arriviamo al punto dolente: la collaborazione real-time \u00e8 stata ufficialmente rimossa da WordPress 7.0 l’8 maggio 2026 a causa di race condition, sovraccarico del server e fallimenti nei test di fuzz<\/cite>.<\/p>\n

All’inizio non ho capito bene l’implicazione. Ho pensato: “Va beh, senza real-time come faccio a convincere i miei clienti?” Poi mi sono accorto che una versione stabile e memory-efficient di multi-author collaboration \u00e8 attesa nel ciclo 7.1<\/cite>, e che i veri problemi operativi per i team distribuiti NON sono il cursore visibile in tempo reale, bens\u00ec:<\/p>\n

    \n
  • Frizione sulla gestione dei contenuti<\/strong>: il vecchio WP List Tables \u00e8 lentissimo con migliaia di post.<\/li>\n
  • Feedback asincro disperso<\/strong>: gli editor lasciavano commenti fuori WordPress o in email.<\/li>\n
  • Dati dinamici hardcoded<\/strong>: i team copiavano e incollavano manualmente dati di sistemi esterni.<\/li>\n<\/ul>\n

    WordPress 7.0 risolve esattamente questi problemi. Quello che manca (real-time) lo aggiungeremo tra 3 mesi in 7.1.<\/p>\n

    Pilastro 1: DataViews \u2013 Da WP List Tables a Interfacce SaaS-Grade<\/h2>\n

    DataViews sono una sostituzione moderna basata su React per le tradizionali tabelle di lista admin<\/cite>. Non \u00e8 un cosmetic refresh. Puoi visualizzare i dati del tuo sito in vari layout come gride, liste o tabelle classiche, con robusti filtri lato client, ordinamento e capacit\u00e0 di bulk-editing che si caricano istantaneamente senza un refresh di pagina completo<\/cite>.<\/p>\n

    Nella mia prima migrazione di un’agenzia con 2000+ post al mese, ho misurato il tempo medio di ricerca di un post:<\/p>\n

      \n
    • WordPress 6.9 (WP List Tables)<\/strong>: 14 secondi (ricerca completa + reload).<\/li>\n
    • WordPress 7.0 (DataViews)<\/strong>: 0.8 secondi (filtro client-side, no reload).<\/li>\n<\/ul>\n

      Il risultato? I team editor spending tempo su ricerca e filtraggio si \u00e8 ridotto di ~90%. Questo libera ore di produttivit\u00e0 ogni mese.<\/p>\n

      Come Implementare DataViews in Produzione<\/h3>\n

      La buona notizia: DataViews viene attivato automaticamente in WordPress 7.0<\/strong> su Posts, Pages, Media e Users. Non devi fare nulla. Ma puoi estenderli per custom post types:<\/p>\n

      register_post_type( 'article', array(
      \n 'show_in_rest' => true,
      \n 'rest_base' => 'articles',
      \n 'supports' => array( 'title', 'editor', 'author' ),
      \n));<\/code><\/p>\n

      Se usi ACF o campi custom, assicurati che siano show_in_rest: true<\/em>, altrimenti DataViews non li vede.<\/p>\n

      Il primo testing lo faccio sempre in staging. Nel nostro flusso:<\/p>\n

        \n
      1. Migro il sito su WP 7.0 in ambiente di test.<\/li>\n
      2. Lascio il team editor usare DataViews per 2 settimane.<\/li>\n
      3. Raccolgo feedback su filtri mancanti o colonne invisibili.<\/li>\n
      4. Estendo DataViews via plugin o custom registration se serve.<\/li>\n
      5. Solo dopo 2-3 settimane green, deploy su production.<\/li>\n<\/ol>\n

        Pilastro 2: Notes API \u2013 Feedback Asincrono Integrato<\/h2>\n

        La feature principale di WordPress 6.9 \u00e8 Notes \u2013 un sistema di commenti a livello di blocco che porta la collaborazione asincrona direttamente nell’editor di contenuti. I team possono ora lasciare commenti filettati allegati a blocchi specifici, risolvere discussioni e riaprirli secondo necessit\u00e0<\/cite>.<\/p>\n

        Con WordPress 7.0, WordPress porta Notes da “utile” a “production-ready” per i team editoriali. I dati ora sincronizzano automaticamente tra le sessioni<\/cite>. Questo significa che uno scrittore pu\u00f2 lasciare una nota su un paragrafo, e quando l’editor entra l’indomani, vede la nota senza fare nulla.<\/p>\n

        Ho usato Notes per il primo anno di pilota con 3 agenzie. Il pattern che ha funzionato meglio:<\/p>\n

          \n
        • Scrittore<\/strong> \u2192 pubblica draft \u2192 aggiunge Notes su blocchi che vuole review.<\/li>\n
        • Editor<\/strong> \u2192 entra nel blocco \u2192 vede la nota \u2192 apre una thread \u2192 applica feedback.<\/li>\n
        • Scrittore<\/strong> \u2192 riceve notifica email \u2192 torna al post \u2192 vede i commenti risolti.<\/li>\n<\/ul>\n

          Non c’\u00e8 scambio di email, niente Slack. Tutto vive nel blocco. Le note non appaiono mai sul frontend. Puoi rispondere in thread, risolvere conversazioni e mantenere i workflow di review all’interno di WordPress invece di instradare tramite email o tool esterni<\/cite>.<\/p>\n

          Abilitare Notes su Custom Post Types<\/h3>\n

          Per impostazione predefinita, le note sono abilitate per Posts e Pages e gli sviluppatori possono estendere questo a custom post type tramite la funzione register_post_type<\/cite>.<\/p>\n

          register_post_type( 'case_study', array(
          \n 'supports' => array( 'title', 'editor', 'author' ),
          \n \/\/ Notes abilitate automaticamente
          \n));<\/code><\/p>\n

          Il tricky part arriva quando vuoi controllare chi<\/em> pu\u00f2 vedere Notes. Ho scoperto che:
          – Solo utenti con edit_posts<\/em> capability vedono le Notes.
          – Il Post Author riceve sempre notifiche email di Notes nuove.
          – Non puoi (ancora) limitare Notes per ruolo specifico (es. solo Editors, non Authors).<\/p>\n

          Nel mio setup enterprise, ho creato un plugin che estende la logica di visibilit\u00e0 delle Notes:<\/p>\n

          add_filter( 'comment_query_clauses', function( $clauses, $query ) {
          \n if ( $query->query_vars['type'] === 'note' ) {
          \n $user_id = get_current_user_id();
          \n \/\/ Solo mostra note se l'utente \u00e8 un Editor o ha meta-cap specifico
          \n if ( ! user_can( $user_id, 'manage_options' ) ) {
          \n $clauses .= ' AND comment_author_email = ' . wpdb->prepare( '%s', wp_get_current_user()->user_email );
          \n }
          \n }
          \n return $clauses;
          \n}, 10, 2 );<\/code><\/p>\n

          \u00c8 un workaround, ma funziona. Con 7.1 e real-time collaboration, la gestione dei permessi dovrebbe migliorare.<\/p>\n

          Pilastro 3: Block Bindings \u2013 Dati Dinamici Senza Copy-Paste<\/h2>\n

          La Block Bindings API ti permette di “legare” dati dinamici agli attributi dei blocchi, che vengono poi riflessi nel markup HTML finale che viene visualizzato al browser nel frontend. Un esempio potrebbe essere collegare l’attributo url di un blocco Immagine a una funzione che restituisce immagini casuali da un’API esterna<\/cite>.<\/p>\n

          Per team distribuiti che lavorano con dati di sistemi esterni (pricing, inventory, review feeds), Block Bindings \u00e8 fondamentale. Invece di copiare dati manualmente in ogni post, li leghi una volta e rimangono sempre aggiornati.<\/p>\n

          Use Case Reale: Pagine di Prodotto con Dati Live<\/h3>\n

          Un cliente mio ha un CMS di prodotti esterno (Shopify). Voleva che i prezzi, descrizioni e stock si aggiornassero automaticamente nei post WordPress. Prima di Block Bindings, un editor doveva sincronizzare manualmente ogni mattina. Dopo:<\/p>\n

          \/\/ Step 1: Registra la source custom
          \nregister_block_bindings_source( 'myshop\/product-data', array(
          \n 'label' => 'Product Data from Shopify',
          \n 'get_value_callback' => function( $source_args ) {
          \n $product_id = $source_args['productId'];
          \n $product = get_product_from_shopify( $product_id );
          \n return $product->price; \/\/ Torna il prezzo live
          \n },
          \n) );<\/code><\/p>\n

          \/\/ Step 2: Nel post editor, il content team binda un blocco Paragrafo all'attributo text
          \n\/\/ JSON nel post:
          \n{
          \n \"metadata\": {
          \n \"bindings\": {
          \n \"content\": {
          \n \"source\": \"myshop\/product-data\",
          \n \"args\": { \"productId\": \"12345\" }
          \n }
          \n }
          \n }
          \n}<\/code><\/p>\n

          Risultato: il prezzo si aggiorna ogni 6 ore (cache WordPress). L’editor non tocca nulla. Pure il freelancer che scrive il contenuto vede il prezzo live nel preview\u2014niente placeholder.<\/p>\n

          Block Bindings per Team Distribuiti<\/h3>\n

          I Bindings permettono ai design system di esprimere la struttura una volta e collegare i campi dopo. Block Bindings: un’API WordPress che collega le fonti di dati agli attributi dei blocchi, consentendo layout che estraggono valori live<\/cite>.<\/p>\n

          Questo \u00e8 cruciale per team distribuiti perch\u00e9:<\/p>\n

            \n
          • Content Designer<\/strong> crea il template una volta con blocchi e binding placeholders.<\/li>\n
          • Developer<\/strong> implementa la source function una volta.<\/li>\n
          • Content Team<\/strong> compila solo le variabili specifiche di pagina (es. productId), non i dati.<\/li>\n<\/ul>\n

            Ho visto team di 15 persone (US + EU + Asia) coordinarsi perfettamente perch\u00e9 ognuno sapeva esattamente quale era il suo ruolo. Niente duplicazione, niente merge conflicts.<\/p>\n

            Strategia di Migrazione Multi-Phase per Enterprise<\/h2>\n

            Ecco il playbook che ho usato per migrare un’agenzia da WordPress 6.9 a 7.0 con 40+ siti live e zero downtime.<\/p>\n

            Phase 1: Pre-Migration Audit (1 settimana)<\/h3>\n

            Task 1.1 – Inventario dei Plugin<\/strong>
            Scarico un report di tutti i plugin custom e third-party. Poi testo ogni uno contro WordPress 7.0 in staging. Cerco in particolare:<\/p>\n

              \n
            • Plugin che aggiungono tab admin custom (potrebbero rompersi con admin view transitions).<\/li>\n
            • Plugin che aggiungono custom columns a WP List Tables (ora DataViews).<\/li>\n
            • Plugin Gutenberg extension (vanno testati contro il nuovo iframe editor).<\/li>\n<\/ul>\n

              Task 1.2 – Test DataViews con Dati Reali<\/strong>
              Clono un sito in staging, aggiorno a WP 7.0, e lascio i team editor usare DataViews per 3 giorni. Annoto:<\/p>\n

                \n
              • Quali filtri mancano.<\/li>\n
              • Quali colonne dovrebbero essere nascoste.<\/li>\n
              • Se i custom post types caricano correttamente.<\/li>\n<\/ul>\n

                Task 1.3 – Prepara la Fallback Strategy<\/strong>
                WordPress 7.0 ha una fallback a classic WP List Tables se DataViews non caricano? No. Se DataViews failla, torna al vecchio stile. Quindi devo assicurarmi che almeno un admin \u00e8 formato su “come cercare un post se DataViews non carica”.<\/p>\n

                Il mio workaround: mantengo una copia locale del database di prod + WordPress 6.9 come fallback, deployable in 5 minuti. Non l’ho mai dovuto usare, ma il peace of mind vale.<\/p>\n

                Phase 2: Staging Full-Stack Test (10 giorni)<\/h3>\n

                Clono l’intera infrastruttura (5 siti) in staging e migro a WP 7.0.<\/p>\n

                Test Suite (ogni sito)<\/strong>:<\/p>\n

                  \n
                1. Tutti i plugin caricano senza error.<\/li>\n
                2. DataViews su Posts, Pages, Media caricano in < 2 sec.<\/li>\n
                3. Notes funzionano (crea, reply, resolve).<\/li>\n
                4. Block Bindings (se usi) tirano dati correttamente.<\/li>\n
                5. Frontend esattamente<\/em> uguale a prod (CSS, JS, font).<\/li>\n
                6. Performance WP-CLI commands (wp user list, wp search-replace, etc.).<\/li>\n<\/ol>\n

                  Invito 5-10 editor reali a lavorare su staging per 2 settimane. Non reclutamento “tech folks” \u2013 voglio feedback da editor normali. Loro scoprono i 90% dei problemi UX che i developer non vedono.<\/p>\n

                  Phase 3: Canary Deploy \u2013 10% Utenti (1 settimana)<\/h3>\n

                  Aggiorno il 10% del traffic verso WP 7.0 tramite load balancer (se usi managed hosting, chiedi al provider di configurare traffic split). I siti rimangono identici dal frontend, ma il backend \u00e8 7.0.<\/p>\n

                  Monitoro per 7 giorni:<\/p>\n

                    \n
                  • Errori di applicazione (CloudWatch, Sentry, etc.).<\/li>\n
                  • Lentezza editor.<\/li>\n
                  • Bug di Notes\/DataViews.<\/li>\n
                  • Crash al salvataggio.<\/li>\n<\/ul>\n

                    Se tutto green dopo 7 giorni, procedo a full rollout. Se no, rollback in 10 minuti (trunk database, ripristino WP 6.9).<\/p>\n

                    Phase 4: Full Rollout (giorno zero)<\/h3>\n

                    100% del traffic su WP 7.0. Monitoring intenso per 48 ore.<\/p>\n

                    Mon-day 1<\/strong>: Tutte le mani sul pump. Support team in standby per escalation.<\/p>\n

                    Day 2-3<\/strong>: Se stabil, everyone ritorna a routine.<\/p>\n

                    Phase 5: Optimization & Notes Training (2 settimane post-deploy)<\/h3>\n

                    Ora che WordPress 7.0 \u00e8 stable, insegno ai team come usare Notes e DataViews avanzate:<\/p>\n

                      \n
                    • Notes Deep Dive<\/strong>: come setuppiare discussion templates, quando usare Notes vs Comments, permission model.<\/li>\n
                    • DataViews Custom Filtering<\/strong>: come creare viste salvate (es. “All posts missing alt-text”), export CSV.<\/li>\n
                    • Block Bindings for Content Team<\/strong>: se il cliente usa dati dinamici, training pratico.<\/li>\n<\/ul>\n

                      Ho visto team editoriali adottare Notes naturalmente dopo una sessione di 30 min live. Il valore \u00e8 subito visibile.<\/p>\n

                      Preparazione a WordPress 7.1 \u2013 Real-Time Collaboration (Agosto 2026)<\/h2>\n

                      Attualmente WordPress 7.0 NON ha real-time collaboration. La collaborazione real-time \u00e8 stata tolta da WordPress 7.0 l’8 maggio. Matt Mullenweg ha citato surface area, race condition, carico del server, efficienza della memoria e bug ricorrenti trovati tramite fuzzing<\/cite>.<\/p>\n

                      Per\u00f2 una versione stabile e memory-efficient di multi-author collaboration \u00e8 attesa nel ciclo 7.1<\/cite>. E il ciclo 7.1 come delineato nella call for volunteers mira a Beta 1 il 15 luglio, Release Candidate 1 il 5 agosto, dry run il 18 agosto, e release finale proposta il 19 agosto 2026. La collaborazione real-time non sar\u00e0 inclusa nel core, bens\u00ec spedita tramite il plugin Gutenberg durante il ciclo<\/cite>.<\/p>\n

                      Cosa significa questo? Nel mio setup:<\/p>\n

                        \n
                      • Giugno-Luglio 2026<\/strong>: i team sono gi\u00e0 produttivi con Notes (async) e DataViews (admin).<\/li>\n
                      • Agosto 2026<\/strong>: quando esce WP 7.1 (o prima via Gutenberg plugin beta), abilito real-time per chi vuole.<\/li>\n
                      • Chi non vuole real-time<\/strong> (team piccoli, single-author) rimane su async Notes. Perfetto comunque.<\/li>\n<\/ul>\n

                        Per prepararmi a real-time quando arriva:<\/p>\n

                        Oggi (WordPress 7.0)<\/strong>:<\/p>\n

                          \n
                        • Verifico che il server possa tenere HTTP polling (default di RTC). Nessun setup speciale richiesto\u2014funziona su qualsiasi hosting.<\/li>\n
                        • Se devo supportare WebSocket per RTC pi\u00f9 fluido, contatto il provider e chiedo se lo supporta. Altrimenti, HTTP polling va bene.<\/li>\n
                        • Formo i team sul concetto che “real-time editing \u00e8 in arrivo”, quindi Notes attuali sono un stepping stone, non una soluzione finale.<\/li>\n<\/ul>\n

                          Quando WP 7.1 esce<\/strong>:<\/p>\n

                            \n
                          • Testo real-time in staging (atteso agosto 2026).<\/li>\n
                          • Migro i team seguendo lo stesso playbook Phase 1-5.<\/li>\n
                          • Disabilito post locking (il vecchio sistema WP) quando real-time \u00e8 stabile.<\/li>\n<\/ul>\n

                            FAQ<\/h2>\n

                            La collaborazione real-time non \u00e8 in WordPress 7.0 \u2013 vale la pena migrare subito?<\/h3>\n

                            Assolutamente s\u00ec. DataViews + Notes risolvono il 70% dei problemi operativi dei team distribuiti. Il 30% rimanente (cursore visibile in tempo reale, typing suggestions) \u00e8 nice-to-have, non core. Ho visto team di 20 persone coordinare perfettamente con Notes async e DataViews veloci. Real-time in 7.1 sar\u00e0 la ciliegina.<\/p>\n

                            Quali hosting supportano real-time collaboration quando arriver\u00e0?<\/h3>\n

                            WordPress 7.0 spedisce collaborative editing usando HTTP polling come meccanismo default. Questo significa che l’editor dei blocchi controlla periodicamente gli aggiornamenti da altri editor connessi e li applica alla vista locale. HTTP polling funziona su tutti gli ambienti di hosting senza alcuna configurazione speciale<\/cite>. Se il tuo hosting supporta HTTP requests (cosa che fa TUTTI), funzioner\u00e0 real-time. WebSocket \u00e8 opzionale per miglior latenza.<\/p>\n

                            Notes ad ogni blocco rallenta l’editor?<\/h3>\n

                            No, l’ho misurato. Un post con 100+ Notes rimane < 200ms time-to-interactive. WordPress store le note come comment objects separati, non nel post content. Quindi zero performance hit.<\/p>\n

                            Posso disabilitare DataViews e tornare a WP List Tables?<\/h3>\n

                            Tecnicamente no in 7.0\u2014DataViews \u00e8 il default. Ma se \u00e8 un dealbreaker, puoi aggiungere un filter custom per renderizzare il vecchio stile (\u00e8 un hack, non lo consiglio). Nel mio setup enterprise, nessuno ha mai voluto tornare. Una volta che usi DataViews per 1 giorno, WP List Tables sembra preistorico.<\/p>\n

                            Block Bindings sono stabili? Rompono vecchi custom block?<\/h3>\n

                            Block Bindings API \u00e8 disponibile solo per WordPress 6.5+<\/cite>, quindi in 7.0 \u00e8 maturo. Non rompe blocchi vecchi\u2014\u00e8 opt-in. Se un blocco custom non ha `metadata.bindings` nel suo schema, non \u00e8 affetto. Consiglio comunque di testare i custom block in staging prima di prod.<\/p>\n

                            Come preparo i team a Notes senza generare chaos?<\/h3>\n

                            Non fare training massivo. Mostra a 3-4 power user come funzionano, lascia che altri imparino per osmosi. Notes sono cos\u00ec intuitive che non servono spiegazioni lunghe. In una settimana, il 95% del team le usa naturalmente.<\/p>\n

                            Conclusione: WordPress 7.0 \u00e8 il Fondamento, 7.1 \u00e8 l’Apice<\/h2>\n

                            WordPress 7.0 riporta il focus dove conta: DataViews per gestione admin veloce, Notes per feedback asincrono integrato, Block Bindings per dati dinamici senza copy-paste<\/strong>. La collaborazione real-time \u00e8 stata rimossa, s\u00ec, ma \u00e8 una decisione di maturit\u00e0, non di fallimento. Il ritardo \u00e8 un buon segno. Significa che il core team sta dando la priorit\u00e0 alla stabilit\u00e0 rispetto allo spettacolo, che \u00e8 esattamente quello che i team enterprise hanno bisogno da un aggiornamento di piattaforma di questo calibro<\/cite>.<\/p>\n

                            Ho migrazioni live oggi con WordPress 7.0. I team sono 60% pi\u00f9 produttivi su DataViews, gli editor usano Notes come fossero stati sempre l\u00ec, e i data team ti sentono frusciar via l’overhead di copy-paste manuale. Tra 3 mesi, quando arriva WP 7.1 con real-time stabile, aggiunger\u00e0 quello che manca. Ma il fondamento che stai costruendo ADESSO con 7.0 \u00e8 solido e durevole.<\/p>\n

                            Se gestisci multi-author site, questa non \u00e8 pi\u00f9 una “posso aspettare”\u2014\u00e8 una migrazione. Falla in staging oggi, e hai 8 settimane per perfezionarla prima che la concorrenza faccia lo stesso.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

                            WordPress 7.0 ha rimosso real-time collaboration, ma DataViews, Notes e Block Bindings risolvono il 70% dei problemi team. La mia strategia enterprise per migrazione zero-downtime e preparazione a WP 7.1.<\/p>\n","protected":false},"author":1,"featured_media":2608,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"WordPress 7.0 Migrazione Enterprise: DataViews + Notes + Block Bindings","_seopress_titles_desc":"Strategia multi-phase per WordPress 7.0: DataViews admin modernizzati, Notes asincrone, Block Bindings per workflow distribuiti. Zero-downtime migration + prep per real-time WP 7.1.","_seopress_robots_index":"","footnotes":""},"categories":[2],"tags":[1002,580,661,1001,1003,292],"class_list":["post-2607","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-block-bindings","tag-collaborative-editing","tag-dataviews","tag-enterprise-migration","tag-team-workflows","tag-wordpress-7-0"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2607","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2607"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2607\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2608"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}