{"id":622,"date":"2016-06-08T13:39:59","date_gmt":"2016-06-08T11:39:59","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/gestire-il-cms\/"},"modified":"2016-06-08T13:39:59","modified_gmt":"2016-06-08T11:39:59","slug":"gestire-il-cms","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/gestire-il-cms\/","title":{"rendered":"Gestire il CMS"},"content":{"rendered":"
\n

La prima regola dei content management system \u00e8 che state usando quello sbagliato. Usate WordPress? Siete un bambino di quinta elementare che ha un blog sulle competizioni dei disegni da colorare. Drupal? Dovreste usare WordPress. Una soluzione a pagamento? Siete il Giuda dell’open source.<\/p>\n

Questo \u00e8 l’apparenza, perlomeno se passate del tempo dalle parti dei pi\u00f9 coriacei web-dev su Twitter o se gironzolate tra i commenti dei blog. Ma la prima vera regola dei content management system \u00e8 che non \u00e8 tanto quale CMS usate quanto in che modo<\/em> lo usate. Uno dei content management system meno noti, implementato con cura, spesso sar\u00e0 molto pi\u00f9 utile di un sistema molto noto scaricato cos\u00ec com’\u00e8 e buttato sul proprio server.<\/p>\n

Come testo guida per l’implementazione dei content management system, vi roviner\u00f2 la giornata presentandovi una citazione da I Fratelli Karamazov<\/cite> di Fyodor Dostoyevsky:<\/p>\n

\n

Io ti dico che non vi \u00e8 per l’uomo affanno pi\u00f9 grande che quello di trovare al pi\u00f9 presto qualcuno a cui rendere il dono della libert\u00e0 che quell’infelice ha avuto nascendo.<\/p><\/blockquote>\n<\/figure>\n

Adattando la citazione ai nostri fini, Dostoyevsky intendeva che la cosa pi\u00f9 bella che potete dire ai vostri utenti del CMS \u00e8 che non hanno la libert\u00e0 di fare casini. Quando implementate un CMS, cercate di dare ai vostri utenti l’esatto livello di libert\u00e0 di cui hanno bisogno, ma, se avete dei dubbi, sbagliate pure dando loro leggermente<\/em> troppo.<\/p>\n

Questa \u00e8 la visione ad ampio spettro della situazione, quando ci si addentra nei dettagli, le cose si complicano: i campi, i WYSIWYG e i permessi. Quello che rende tutto ancor pi\u00f9 delicato \u00e8 che, se pensate all’implementazione del CMS, probabilmente vi trovate in una di queste due situazioni diversissime tra loro:<\/p>\n

    \n
  1. state creando un nuovo sito e il mondo \u00e8 la vostra ostrica per l’implementazione del CMS,<\/li>\n
  2. state gestendo o rinnovando un sito esistente e il setup del content management system vi mette addosso una grande tristezza.<\/li>\n<\/ol>\n

    Sebbene ciascuna di queste situazioni abbia i suoi peculiari problemi, che vedremo pi\u00f9 avanti, sono entrambe governate non solo dalla prima regola dei CMS, ma anche dalla seconda: due implementazioni di CMS non dovrebbero mai essere esattamente uguali. Ogni sito avr\u00e0 i suoi bisogni e il CMS dovrebbe essere personalizzato per soddisfare quei bisogni.<\/p>\n

    Tenendo presente questo, invece di un insieme di prescrizioni, vi offro una serie di domande che dovreste porvi per limitare la libert\u00e0 dei vostri utenti.<\/p>\n<\/div>\n

    \n

    Questo elemento pu\u00f2 avere il suo campo?<\/h2>\n

    In molti content management system (mi vengono in mente WordPress e Drupal) i tipi di contenuto hanno di default dei grandi campi di testo in cui si pu\u00f2 inserire di tutto. Tutto quello che volete! Prendete in considerazione di limitare questa libert\u00e0 quanto pi\u00f9 possibile dando ad elementi discreti input discreti.<\/p>\n

    Ogni elemento sulla vostra pagina che ha uno scopo diverso da altri elementi dovrebbe avere un suo input field. Nell’elenco dello staff, la professione di una persona e il nome dovrebbero avere dei campi di input separati, anche se appaiono l’uno accanto all’altro sulla pagina. La foto dovrebbe avere un campo separato per caricare l’immagine. L’orario dell’ufficio nella sidebar dovrebbe avere un suo proprio campo. Le informazioni di contatto al di fuori dell’orario dell’ufficio dovrebbero anch’esse avere un proprio campo. Ricordate: solo perch\u00e9 due oggetti sono uno accanto all’altro visivamente non vuol necessariamente dire che siano cos\u00ec collegati l’uno all’altro dal dover condividere un campo.<\/p>\n

    Per tutti quelli che pensano che suddividere ogni elemento nel suo campo sia eccessivo e inutile: ricordate che vi d\u00e0 flessibilit\u00e0 per il futuro. Come ha sottolineato Karen McGrane<\/a>, suddividere in pezzi il contenuto d\u00e0 struttura a questo, che a sua volta d\u00e0 libert\u00e0 a voi web developer. Vi d\u00e0 la libert\u00e0 di fare dei piccoli cambiamenti nel design, come spostare le informazioni di contatto sopra agli orari dell’ufficio, semplicemente con un po’ di lavoro di back-end. E vi d\u00e0 anche la libert\u00e0 di fare grandi cambiamenti nel modo in cui viene visualizzato il contenuto, che sia sul sito su cui state lavorando, su una nuova iterazione di quel sito o in un prodotto completamente diverso che si aggancia ai contenuti di tale sito. Questo \u00e8 il tipo di libert\u00e0 che volete.<\/p>\n<\/div>\n

    \n

    Questo campo pu\u00f2 essere pi\u00f9 restrittivo?<\/h2>\n

    \u00c8 una buona idea usare il campo pi\u00f9 restrittivo possibile per un dato elemento. Se usate un grande campo di testo, chiedetevi: posso rendere questo campo semplicemente testo invece di HTML in cui si pu\u00f2 infilare di tutto? Se \u00e8 un’immagine, considerate l’uso di un campo image-uploader piuttosto che un media field generico. Se \u00e8 il nome di una persona, usate un campo di testo semplice. Se \u00e8 un giorno della settimana, fate scegliere agli utenti uno dei sette giorni della settimana, non fategli inventare il loro.<\/p>\n

    Restringere i campi rende pi\u00f9 semplice l’utilizzo del CMS per fare correttamente e rapidamente il proprio lavoro e pu\u00f2 anche essere d’aiuto nel portare consistenza editoriale e visuale al sito. Far scegliere agli utenti il giorno della settimana da un array invece che inserirlo a mano nel campo di testo assicura che tutti i giorni della settimana saranno sempre scritti correttamente e fa s\u00ec che le persone non si debbano fermare e ricordare se lo stile dell’azienda \u00e8 di abbreviare i giorni della settimana o di scriverli per intero. Inoltre, se dovesse cambiare lo stile aziendale, potrete fare dei piccoli aggiustamenti sul backend invece di cambiare il testo in ogni input \u201cgiorno della settimana\u201d sul sito.<\/p>\n

    Restringere i campi \u00e8 anche uno dei modi pi\u00f9 significativi in cui potete far sapere agli utenti del CMS che non possono fare disastri. Usando un campo immagine ristretto, rassicurate implicitamente le persone che se dovessero cercare di caricare il tipo sbagliato di file immagine, il CMS lo rifiuter\u00e0. In maniera simile, usare semplice testo invece di un WYSIWYG o del rich text \u00e8 un modo per far sapere agli utenti che possono copiare il testo da qualunque fonte e incollarlo senza che si creino problemi e che non devono preoccuparsi degli stili del testo.<\/p>\n

    Tuttavia, ci sono alcune aree in cui essere restrittivi probabilmente fa pi\u00f9 male che bene. Per esempio, far\u00e0 probabilmente pi\u00f9 danni di quel che vale l’avere un limite vincolante di caratteri su un campo di testo. Anche se, supponiamo, si tratta di un campo per il nome di una persona nell’elenco dello staff, non causerete molti problemi mettendo il limite dei caratteri a 200 invece che a 40. Inoltre, non guadagnerete granch\u00e9 essendo molto vincolanti con i cosiddetti caratteri speciali. Permetterli potrebbe significare un font file leggermente pi\u00f9 grande, ma per la maggior parte dei siti non \u00e8 possibile o non \u00e8 consigliabile evitare parole con i diacritici.<\/p>\n<\/div>\n

    \n

    Serve questo pulsante nel WYSIWYG?<\/h2>\n

    Cos\u00ec come sono, gli editor WYSIWYG a volte hanno alcune dozzine di pulsanti. Alcuni sono i classici grassetto<\/i>, corsivo<\/i> e strikethrough<\/i>. Alcuni sono degli avanzi provenienti dai giorni dei word processor, come testo giustificato<\/i> e colore di sfondo<\/i>. Alcuni sono imperscrutabili: osservando l’intero insieme di pulsanti di CKEditor, vedo un pulsante che ha l’aspetto di una T<\/i> che porta a spasso una piccola x<\/i> al guinzaglio, un globo e tre varianti di un blocco per appunti.<\/p>\n

    La maggior parte dei content management system vi permettono di editare quali pulsanti debbano apparire nel WYSIWYG. Fatelo! Se il campo \u00e8 un campo di testo che avr\u00e0 bisogno di un link di tanto in tanto, liberatevi di tutti i pulsanti tranne del pulsante del link. Se una text area ha bisogno solo della formattazione base del testo, lasciate i pulsanti per il grassetto e l’italico e magari le liste ordinate e non ordinate e i link, se \u00e8 possibile che verranno usati.<\/p>\n

    Per i campi di testo generici, come le descrizioni dei prodotti o i riepiloghi degli eventi, mi piace tenere quelle stesse opzioni di formattazione. Io spesso tralascio il pulsante per la sottolineatura perch\u00e9 \u00e8 meglio restringere questo stile ai link, ma includo sempre il pulsante dei link perch\u00e9 i link fanno girare il web.<\/p>\n

    Per i testi pi\u00f9 lunghi, come gli articoli, includo anche i pulsanti per formattare le citazioni, la punteggiatura come il trattino lungo (em dash – non tutti conoscono la scorciatoia da tastiera) e magari le opzione indent e outdent se \u00e8 possibile che gli utenti abbiano bisogno di creare liste all’interno di liste. Solitamente creo anche dei pulsanti che permettano agli utenti di applicare del markup come gli heading e li etichetto con qualcosa come \u201cHeading 2\u201d piuttosto che \u201ch2\u201d, dal momento che la maggior parte degli utenti di CMS conosce meglio l’Inglese dell’HTML. Generalmente, evito i pulsanti per cambiare font, dimensione, colore o colore di sfondo, che conviene impostare via CSS per tenere separati forma e contenuto.<\/p>\n

    Questi sono solo alcuni punti di partenza. Oltre a questo dovete conoscere il vostro team editoriale. Se agli scrittori piace usare sarcasticamente lo strikethrough, dategli il pulsante per farlo. O se volete che solo gli editori siano in grado di barrare sarcasticamente le cose che i loro scrittori scrivono, permettete solo agli autori con permesso da editor di avere il pulsante strikethrough.<\/p>\n

    I pulsanti \u201cvedi sorgente\u201d possono essere complessi. In generale, la mia regola pratica \u00e8 che gli utenti a livello editore o amministratore dovrebbero avere un pulsante \u201cvedi sorgente\u201d se conoscono HTML. A volte nei WYSIWYG succedono delle cose un po’ bizzarre (rendete qualcosa un heading e l’intero paragrafo diventa un heading) e gli utenti che conoscono HTML troveranno pi\u00f9 semplice osservare il codice sorgente e sistemare il markup.<\/p>\n

    Dovreste usare i WYSIWYG come dei tool di formattazione di base, non come degli strumenti di design. I WYSIWYG a volte hanno una brutta fama<\/a> perch\u00e9 gli utenti e i clienti li vogliono usare come word processor, uno strumento che d\u00e0 alla persone il pieno controllo (sebbene un po’ goffo) sull’aspetto delle cose. Dopo tutto, si chiamano \u201cWhat you see is what you get\u201d. Ma se restringete il WYSIWYG alle sue funzioni essenziali, potete assicurare agli utenti che quello che verr\u00e0 visualizzato sul sito web andr\u00e0 bene ogni volta e che non devono preoccuparsi di quello che vedono o di quello che otterranno.<\/p>\n<\/div>\n

    \n

    L’utente ha bisogno di questo permesso?<\/h2>\n

    Restringere i permessi di un utente \u00e8 il modo pi\u00f9 semplice per essere sicuri che non possa accidentalmente distruggere il sito. La maggior parte delle persone che aggiorna i contenuti o gli editor non avranno bisogno di trafficare con i permalink, quindi non dategli il permesso di farlo. Se un utente edita solo contenuti esistenti, dovreste evitare di dargli il permesso di creare o cancellare pagine. E cos\u00ec via.<\/p>\n

    Ecco qualcosa che potete fare per capire di che permessi avr\u00e0 effettivamente bisogno un utente: quando create un nuovo utente, toglietegli tutti i permessi. Fate login come quell’utente in un browser e come admin in un altro. Nell’account non-admin, cercate di fare tutte le operazioni di cui avr\u00e0 bisogno quell’utente e aggiungete via via pi\u00f9 permessi dall’account admin se ce n’\u00e8 bisogno.<\/p>\n<\/div>\n

    \n

    Come posso cablare l’accessibilit\u00e0 nel sito?<\/h2>\n

    Che cosa c’entra l’accessibilit\u00e0 in un articolo sull’implementazione dei content management system e sui romanzieri russi del XIX secolo? Bene: potete rendere il codice del vostro sito il pi\u00f9 accessibile possibile utilizzando gli ARIA roles pi\u00f9 cool e testando tutto su uno screen reader, ma se chi aggiorna il contenuto crea un testo grigio su uno sfondo grigio scuro o non si cura del testo dell’alt<\/code>, il vostro duro lavoro va in fumo. Non potete prevenire tutto ci\u00f2, ma potete almeno rendere un po’ pi\u00f9 difficile incasinare tutta l’accessibilit\u00e0 del sito.<\/p>\n

    Anche se non siete alla fine la persona che caricher\u00e0 un’immagine, per esempio, potete spesso inserire un testo di default per l’attributo alt<\/code> da back-end. Se state progettando l’elenco dello staff, per esempio, potete prendere il testo di alt<\/code> da altri campi, in questo modo:<\/p>\n

    \n<img src=\"cool-guy-optimized.jpg\" alt=\"<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC\" \/ >\n<\/code>\n<\/pre>\n
    In questo modo, l’alt<\/code> text ci sar\u00e0 sempre (e sar\u00e0 anche pi\u00f9 utile e accurato) e chi aggiorna i contenuti non dovr\u00e0 preoccuparsene.<\/p>\n
    Oppure, se avete dato elementi discreti a campi di inserimento discreti, potete garantire che tutto abbia una struttura appropriata e accessibile. La maggior parte dei content management system fa questo naturalmente per gli headings h1<\/code>: mettono il titolo della pagina in un h1<\/code> a meno che non specifichiate diversamente. Potete estendere questa funzionalit\u00e0 ad altri oggetti. Mettete quel testo callout in un aside<\/code>. Mettete quell’orario in un time<\/code>.<\/p>\n<\/div>\n
    \n
    Quanto devo rendere facile l’upload di un’immagine?<\/h2>\n
    Come web developer, siete probabilmente aggiornati su tutte le ultime tecnologie delle immagini. Sapete quando dovreste usare img srcset<\/code> (la maggior parte delle volte) e quando dovreste usare picture<\/code> (solo quando dovete fare qualcosa che ricada vagamente nell’art direction). Conoscete i migliori plugin di ottimizzazione delle immagini che sono disponibili solo su quel sito di plugin che avete trovato quella volta. Quando qualcuno vi chiede di creare un SVG in Photoshop, gli direte che non si chiama Vectorshop e riderete della vostra stessa battuta e deciderete di passare un po’ di tempo all’aria aperta questo week-end.<\/p>\n
    La persona che aggiorna i contenuti probabilmente non conosce queste cose. Anche se siete voi stessi una persona che aggiorna il contenuto, non dovrete ricordarvi questo quando starete semplicemente cercando di caricare una foto della vostra rucola. Questo \u00e8 il motivo per cui dovreste programmare tutto questo nel vostro sistema. Quando \u00e8 possibile, ogni immagine sul vostro sito dovrebbe avere il suo campo image-uploader e voi dovreste essere in grado di inserirvi un’immagine di qualunque dimensione in quel campo uploader e far s\u00ec che si ridimensioni, ottimizzi e venga inserita nell’appropriato markup responsive.<\/p>\n
    Tutte queste cose dei content management system richiedono un po’ di lavoro, ma potete farcela. Io credo in voi. Ho visto quanto \u00e8 robusta la vostra rucola.<\/p>\n<\/div>\n
    \n
    Alcune altre domande che potreste ritrovarvi a fare<\/h2>\n
    Ho un problema di implementazione di CMS assolutamente impossibile. Qualche idea?<\/h3>\n
    Fatemi indovinare: state gestendo degli articoli che hanno delle immagini e dei Tweet integrati e magari anche un grafico interattivo. Inoltre, la persona che crea l’articolo avr\u00e0 bisogno di riposizionare quegli elementi in ogni articolo. Questo \u00e8 uno dei problemi pi\u00f9 delicati e pi\u00f9 comuni dei CMS. Lasciate che vi indichi \u201cLa battaglia per il campo body<\/a>\u201d di Jeff Eaton per avere alcune risposte. Questo tipo di problema \u00e8 totalmente risolvibile con un CMS e, mentre la mia linea guida vi manda nella giusta direzione, Jeff sottolinea alcuni modi in cui si pu\u00f2 affrontare questo caso specifico.<\/p>\n
    Se il problema che vi trovate di fronte \u00e8 che volete che l’implementazione finale del vostro CMS faccia s\u00ec che chiunque la usi ne proclami la sua genialit\u00e0, \u201cAddestrare il CMS<\/a>\u201d di Eileen Webb fa al caso vostro. Tra le altre cose, ha alcune idee magnifiche per rendere utile il setup delle vostre pagine editoriali e per renderle semplici da usare.<\/p>\n
    A volte, quando vi imbattete in quello che sembra un problema ingestibile con un CMS \u00e8 perch\u00e9 state pensando a come apparir\u00e0 il vostro contenuto in una pagina particolare e non all’interno della struttura complessiva contenuti\/dati. Per questo, guardate la talk di Karen McGrane \u201cContent in a Zombie Apocalypse<\/a>\u201d. Vi aiuter\u00e0 a ripensare al modello del contenuto e fa anche delle battute divertenti sui WYSIWYG.<\/p>\n
    Ok, ottimo, ma da dove comincio?<\/h3>\n
    All’inizio, ho detto che le implementazioni dei CMS sono di due tipi: con la prima, cominciate da zero, il mondo \u00e8 la vostra piccola, delicata, fredda ostrica: non farete gli stessi errori questa volta; con la seconda, state rinnovando un CMS, le cose non funzionano, l’amore non \u00e8 vero, Dio \u00e8 morto, eccetera. Da dove cominciare a porvi queste domande dipende dalla situazione in cui vi trovate.<\/p>\n
    Se vi trovate nella prima situazione, per certi aspetti la vita \u00e8 molto pi\u00f9 semplice. Tenere a mente quelle domande quando state mettendo il vostro design nei template del CMS render\u00e0 pi\u00f9 semplice la parte relativa ai campi, e cominciare con dei pulsanti WYSIWYG ragionevoli, con un sistema di caricamento immagini funzionale e con l’accessibilit\u00e0 built-in dar\u00e0 al sito una base solida con cui trafficare in seguito.<\/p>\n
    La parte difficile \u00e8 prevedere esattamente in che modo verr\u00e0 usato il sito. \u00c8 facile pensare che potrete sostituire il campo della sidebar con un location field e un campo per le informazioni di contatto, ma cosa succede se qualcuno vuole mettere un messaggio speciale riguardante la chiusura festiva nella sidebar ma non ha un posto per farlo? Se state facendo il redesign di un nuovo sito, raccomando di usare come contenuto di esempio il contenuto pi\u00f9 fastidioso e pi\u00f9 caso limite possibile che trovate sull’attuale sito. Questo di solito vi eviter\u00e0 di porre troppi limiti. Se il sito non ha ancora contenuti, questo non \u00e8 un buon modo per costruire un sito web, ma se vivete nel mondo reale e dovete comunque farlo, dovrete avventurarvi nel dare agli utenti troppa libert\u00e0 e poi restringere pi\u00f9 tardi se potete.<\/p>\n
    Se vi trovate nella seconda situazione, rallegratevi. Non dovete demolire il vostro sito attuale per implementare tutto questo, potete scivolarci dentro gradualmente. Alcune parti sono pi\u00f9 semplici da fare di altre e alcune sono pi\u00f9 importanti. Se avete un pomeriggio libero, potete sistemare in maniera appropriata tutti i permessi utente e rimuovere i pulsanti dal WYSIWYG. Potreste addirittura essere in grado di aggiustare il vostro sistema di caricamento immagini senza distruggere le immagini gi\u00e0 presenti sul sito. Ma probabilmente sar\u00e0 pi\u00f9 difficile dividere gli elementi discreti in campi discreti o restringere i tipi dei campi. I database sono cos\u00ec sensibili! Ma la prossima volta che creerete un nuovo tipo di contenuto, potrete assicurarvi che abbia dei campi discreti e che li avrete ristretti appropriatamente. Anche facendo solo dei pezzetti di queste cose potrete rendere il vostro CMS pi\u00f9 efficace.<\/p>\n
    E le politiche?<\/h3>\n
    Per entrambe le situazioni, in realt\u00e0 per la maggior parte delle situazioni di web development, la parte tecnica sar\u00e0 pi\u00f9 semplice della parte politica. Come vendete al cliente o al vostro capo le due settimane o poco pi\u00f9 extra che passerete a rendere migliore il CMS? Avete scelto un pessimo CMS o cosa?<\/p>\n
    Nella mia esperienza, non solo \u00e8 possibile ottenere l’approvazione per il tempo speso in questo modo, ma potete anche ottenere assoluta gratitudine. Raccomando di farne un caso finanziario: passare un certo numero di ore x<\/i> sul CMS adesso vi far\u00e0 risparmiare cinque volte tanto lo stesso numero di ore in seguito. Pi\u00f9 sarete specifici, pi\u00f9 sarete persuasivi. Per esempio, se stimate 16 ore di lavoro per implementare un sistema di caricamento immagini che si occupi dietro le quinte di tutte le dimensioni delle immagini, potete stimare quanto tempo impiegherebbe il content editor per salvare tre diverse dimensioni di immagini, ottimizzarle e caricarle ogni volta che un’immagine deve essere cambiata.<\/p>\n
    Se questo non dovesse funzionare, ecco alcune frasi sicure che potete usare:<\/p>\n
      \n
    • \u201cQuesta \u00e8 un’organizzazione speciale, unica nel suo genere, quindi ci vuole un po’ pi\u00f9 di tempo per essere sicuri che il CMS soddisfi i suoi bisogni unici.\u201d<\/li>\n
    • \u201cAvete uno staff di talenti che fanno un lavoro importante e noi non vogliamo che passino il loro prezioso tempo a risolvere errori sul sito web.\u201d<\/li>\n
    • \u201cVogliamo essere sicuri che non ci sia un modo in cui possiate fare disastri sul sito. In questo modo non dovrete pi\u00f9 pagarci di nuovo.\u201d<\/li>\n
    • \u201cVedete questa pagina in cui qualcuno ha caricato una GIF di un cane e ha scritto del testo rosso lampeggiante? Posso impedire che accada di nuovo.\u201d<\/li>\n<\/ul>\n
      Basta non citare Dostoyevsky e pensare che sia sufficiente.<\/p>\n
      Illustrazioni: {carlok}<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
      Dal momento che ogni sito ha bisogni unici, i content management system dovrebbero essere tutti diversi. Quando si implementa e personalizza un nuovo CMS, scrive Rory Douglas, dovete dare ai vostri utenti solo ed esclusivamente la libert\u00e0 di cui hanno bisogno, ma non tale da poter fare disastri. Vi ameranno per questo.<\/p>\n","protected":false},"author":818,"featured_media":7000796,"comment_status":"open","ping_status":"open","template":"","categories":[254,146,278],"tags":[],"coauthors":[476],"class_list":["post-622","article","type-article","status-publish","has-post-thumbnail","hentry","category-content-strategy","category-numero-129-8-giugno-2016","category-workflow-tools"],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article\/622","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/users\/818"}],"replies":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/comments?post=622"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media\/7000796"}],"wp:attachment":[{"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/media?parent=622"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/categories?post=622"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/tags?post=622"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/alistapart.com\/it\/wp-json\/wp\/v2\/coauthors?post=622"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}