Spread the love

Da Bruno Mancini a IA Claude

Per la serie

Esopo news

ottobre 2026

Bruno Mancini

IA Claude

IA Claude tra prove ed errori

Da Bruno Mancini a IA Claude

È vero che su Android WordPress genera automaticamente un iframe isolato che ignora gli stili inseriti nella pagina e si forza a 600px di larghezza.

Da IA Claude a Bruno Mancini

Cercato sul web

No, non è così in generale — dipende da cosa intendi per “pagina”: editor (backend) o sito pubblicato (frontend).

Editor Gutenberg (backend, dal WP 5.9)
Qui sì c’è un iframe reale: il canvas dell’editor viene renderizzato dentro un <iframe> per isolare gli stili dell’editor da quelli dell’admin. Questo iframe simula i breakpoint responsive e ha un comportamento documentato legato ai 600px: sotto quella soglia di larghezza viewport, in alcuni casi il canvas dell’editor sparisce o si comporta in modo anomalo su Android (bug segnalato, non feature intenzionale). Ma non “ignora” gli stili del tema — anzi, carica apposta gli editor-styles per farli assomigliare al frontend; il problema è che spesso non li applica correttamente (specificità CSS, !important necessario, ecc.).

Frontend (pagina pubblicata, vista da visitatore su Android)
Qui non c’è nessun iframe automatico generico per il contenuto della pagina. Se vedi un iframe isolato a 600px sul frontend, è quasi certamente uno di questi casi specifici, non un comportamento di WordPress core sulle pagine in generale:

un blocco Embed (oEmbed — YouTube, PDF, mappe, ecc.) che di default ha width fissa (spesso 600px) se non è impostato su “wide/full” o non riceve CSS responsive (iframe{width:100%} in un wrapper);
un plugin che usa iframe per incorporare contenuti esterni.

Se mi dici su quale pagina/blocco di emmegiischia.com stai vedendo il problema, verifico l’HTML e ti dico esattamente quale dei due casi è.

Da Bruno Mancini a IA Claude

https://www.emmegiischia.com/il-dispari-cultura-ventuno-settembre-2026-dila-aps/

Da IA Claude a Bruno Mancini

Impossibile leggere la pagina

Il sito blocca il fetch automatico (robots.txt), quindi non posso ispezionare l’HTML della pagina direttamente.

Per capire se è un blocco Embed con width fissa o altro, mi serve uno di questi:

il codice HTML/blocco incriminato (copia il markup del blocco da editor → “Modifica come HTML”, o l’output “Visualizza sorgente pagina” della sezione con l’iframe)
oppure dimmi che tipo di contenuto è incorporato lì (video, PDF, mappa, altro sito?)

Con quello ti dico esattamente se è il blocco Embed di WordPress (soluzione: allineamento “wide/full” + CSS iframe{width:100%!important}) o qualcos’altro.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Ho controllato il contenuto della pagina: non c’è nessun iframe. Zero tag <iframe> in tutto il markup.

Quello che c’è, in abbondanza, sono immagini con attributi HTML fissi width=”600″ height=”…” (es. 20260921-Il-Dispari-testata-ridim-600×281.jpg, width=”600″ height=”281″), oltre a un paio di shortcode .

Questo spiega il sintomo che stai osservando, ma la causa è diversa da quella che pensavi:

Le immagini caricate sono già ridimensionate/esportate a 600px di larghezza (nome file “ridim-600x…”) e portano width=”600″ height=”…” nell’HTML.
Se il CSS del tema non forza img{max-width:100%; height:auto} con priorità sufficiente, quegli attributi HTML fissi vincono e l’immagine non si restringe sotto i 600px, causando overflow orizzontale su schermi più stretti (tipico su smartphone Android in verticale, spesso 360-412px di larghezza CSS).
L’effetto visivo — un blocco “bloccato” a 600px che non risponde agli stili della pagina — assomiglia a un iframe isolato, ma è semplicemente un’immagine con dimensioni hard-coded che sovrascrivono il responsive.

Verifica rapida: apri la pagina da Android, tieni premuto su una delle immagini “incriminate” → se il browser la riconosce come immagine (opzioni tipo “salva immagine”, “apri immagine”) e non come frame, è confermato: non c’è iframe, è un problema di responsive delle <img>.

Correzione: nel CSS del tema (o Additional CSS del Customizer) assicurati che questa regola non venga sovrascritta da selettori più specifici:

css

.entry-content img { max-width: 100% !important; height: auto !important; }

Vuoi che controlli anche le altre pagine dell’audit SEO per lo stesso pattern di immagini a larghezza fissa?

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Questo è un fenomeno diverso, molto specifico di Android Chrome: si chiama font boosting / text-size-adjust automatico.

Cosa succede
Chrome per Android ha un algoritmo che ingrandisce automaticamente il testo che rileva come “blocco di testo denso senza altri elementi” per renderlo più leggibile su schermo piccolo. Il tuo elenco finale di URL nudi (senza tag <a>, senza essere in una lista <ul>, probabilmente solo righe di testo semplice una sotto l’altra) è il caso da manuale che lo scatena: righe corte, ripetitive, prive di markup ricco intorno. Il risultato è testo che appare enorme e sfora lo schermo, esattamente come descrivi — e questo non succede su desktop né spesso su iOS Safari, solo su Android Chrome.

Verifica rapida
Apri quella pagina su Android, fai doppio tap veloce su una delle righe URL: se il testo “scatta” a una dimensione diversa/si autoregola, è confermato il font-boosting.

Correzione (CSS, va nel foglio di stile del tema)

css

html {

-webkit-text-size-adjust: 100%;

text-size-adjust: 100%;

}

Questo disattiva il ridimensionamento automatico su tutto il sito — è la soluzione standard e sicura.

Correzione strutturale (consigliata in aggiunta)
Quell’elenco di URL nudi andrebbe comunque trasformato in una lista vera (<ul><li><a href=”…”>…</a></li></ul>) invece di righe di testo semplice: risolve anche il problema alla radice (il font-boosting si attiva più facilmente su testo “orfano” senza struttura), migliora la leggibilità e dà anche un beneficio SEO (link cliccabili invece di stringhe plain-text).

Se mi confermi che il tema non ha già text-size-adjust impostato da qualche parte in conflitto, ti preparo la regola CSS pronta da incollare in Aspetto → Personalizza → CSS aggiuntivo.

Da Bruno Mancini a IA Claude

Quei link su desktop compaiono come iframe e questa visualizzazione mi piace conservarla… Ma sul Cell il tutto sfora lo schermo e non va bene

Da IA Claude a Bruno Mancini

Questo cambia il quadro — e conferma parzialmente la tua intuizione iniziale.

Cosa sta succedendo davvero
Quegli URL nudi, essendo link a altri post dello stesso sito (emmegiischia.com) messi su una riga da soli, vengono convertiti automaticamente da WordPress nel suo embed nativo (wp-embed): un riquadro con titolo, estratto e miniatura, renderizzato dentro un <iframe class=”wp-embed”>. Questo iframe di default è fissato a width=”600″ (e un’altezza proporzionale) nell’HTML generato da WordPress core.

Su desktop il riquadro sta bene perché il contenitore è più largo di 600px. Su Android, essendo il viewport CSS spesso 360–412px, l’iframe a larghezza fissa sfora — è esattamente il comportamento “iframe isolato a 600px” che avevi descritto all’inizio, solo che ora sappiamo di preciso qual è: non è il font-boosting (quello era un problema diverso, sulle righe senza embed), è proprio l’iframe wp-embed.

La soluzione che tiene il desktop com’è e sistema solo il mobile

Nel functions.php del tema, verifica/aggiungi:

php

add_theme_support( ‘wp-embed-responsive’ );

Questo fa sì che WordPress avvolga l’iframe in un contenitore con padding-bottom proporzionale e lo renda fluido, mantenendo l’aspetto visivo del riquadro embed su ogni schermo (niente affatto un downgrade estetico, solo si adatta).

Se il tema ignora quella funzione o hai bisogno di un intervento più diretto, CSS aggiuntivo:

css

.wp-embed { max-width: 100%; }

.wp-embed iframe { max-width: 100%; }

Con wp-embed-responsive attivo lo scaling è automatico e proporzionale (il riquadro si restringe mantenendo le proporzioni, non taglia nulla) — quindi il “look” da iframe/preview che ti piace resta identico, solo si adatta alla larghezza dello schermo invece di sforare.

Vuoi che controlli se il tema attivo su emmegiischia.com ha già quel supporto abilitato?

Da Bruno Mancini a IA Claude

Vorrei una soluzione perché le ragioni della anomalia mi interessano poco. Puoi darmela. E se puoi darmela quali altre info ti occorrono?

Da IA Claude a Bruno Mancini

Soluzione (in ordine di priorità):

CSS — via Aspetto → Personalizza → CSS aggiuntivo (nessun accesso ai file necessario)

css

.wp-embed,

.wp-embed iframe,

embed, iframe, object {

max-width: 100% !important;

height: auto !important;

}

Questo da solo risolve lo sforamento su mobile in praticamente tutti i casi, senza toccare nulla sul desktop.

Se vuoi anche il fix “corretto” lato WordPress core (opzionale, più pulito)
Nel functions.php del tema attivo (o meglio, di un child theme):

php

add_theme_support( ‘wp-embed-responsive’ );

Cosa mi serve per darti l’istruzione esatta e operativa (non genericha):

Nome del tema attivo su emmegiischia.com (Aspetto → Temi, quello con la spunta) — mi serve per dirti se functions.php è sicuro da editare direttamente o se serve un child theme.
Hai accesso FTP/file manager o solo alla dashboard wp-admin? Se solo dashboard, resta solo l’opzione 1 (CSS via Customizer), che comunque basta.

Con queste due info ti do il passo-passo esatto senza margine di errore.

Da Bruno Mancini a IA Claude

Ho accesso a tutto

Da IA Claude a Bruno Mancini

Perfetto — allora ti do la soluzione più solida, che non dipende dal tema e non rischia di sparire al prossimo aggiornamento del tema (invece di infilarla nel functions.php del tema, che verrebbe cancellata a ogni update).

Passo 1 — CSS (immediato, via dashboard)
Aspetto → Personalizza → CSS aggiuntivo, incolla:

css

.wp-embed,

.wp-embed iframe,

embed, iframe, object {

max-width: 100% !important;

height: auto !important;

}

Salva e pubblica. Già da solo risolve lo sforamento su Android.

Passo 2 — wp-embed-responsive via mu-plugin (indipendente dal tema, permanente)

Via File Manager o FTP:

Vai in /wp-content/
Se non esiste, crea una cartella chiamata mu-plugins
Dentro mu-plugins, crea un file chiamato emmegiischia-embed-fix.php
Contenuto del file:

php

<?php

add_action( ‘after_setup_theme’, function() {

add_theme_support( ‘wp-embed-responsive’ );

} );

Salva.

Non serve attivare nulla: i file in mu-plugins (must-use plugins) si caricano automaticamente sempre, a prescindere dal tema attivo o da suoi aggiornamenti futuri.

Verifica
Apri una delle pagine con i link embeddati (es. il-dispari-20200127/) da un cellulare Android reale o dagli strumenti sviluppatore di Chrome desktop in modalità “toggle device” — il riquadro embed deve restare dentro i margini dello schermo.

Fatto questo, l’anomalia è chiusa su entrambi i fronti (CSS + comportamento nativo di WordPress).

Da Bruno Mancini a IA Claude

Ok grazie per ora, ho preso nota, domani adeguo e ti relaziono.

Da IA Claude a Bruno Mancini

Perfetto, a domani.

Da Bruno Mancini a IA Claude

Puoi indicarmi il percorso con maggiori dettagli? Nella dashboard di Aruba non trovo <aspetto> personalizza ecc x giungere a css

Da IA Claude a Bruno Mancini

Memoria letta

Aspetto → Personalizza non è nel pannello Aruba: è dentro l’area di amministrazione di WordPress, che è separata.

Accedere a WordPress

Apri nel browser https://www.emmegiischia.com/wp-admin
Entra con utente e password di WordPress (non quelle di Aruba).
Nel menu a sinistra clicca Aspetto → Personalizza → CSS aggiuntivo.
Incolla il codice, poi Pubblica.

Se “Personalizza” non compare
Il tema è a blocchi (Full Site Editing). Il percorso allora è: Aspetto → Editor → icona Stili (cerchio mezzo pieno, in alto a destra) → i tre puntini → CSS aggiuntivo → Salva.

Per il file del passo 2 (mu-plugin)
Questo sì si fa dal lato Aruba:

Pannello Aruba → Hosting Linux → File Manager (oppure FTP con FileZilla, se preferisci).
Entra nella cartella del sito emmegiischia.com, poi in wp-content.
Crea la cartella mu-plugins (se manca) e dentro il file emmegiischia-embed-fix.php con il contenuto che ti ho dato.

Se dopo il login su wp-admin non trovi nessuna delle due voci, dimmi cosa vedi nel menu a sinistra e ti indico il punto esatto.

Da Bruno Mancini a IA Claude

Quindi cosa significa Passo 1 — CSS (immediato, via dashboard)
Aspetto → Personalizza → CSS aggiuntivo, incolla:

Da IA Claude a Bruno Mancini

Significa questo: “dashboard” era la bacheca di WordPress (wp-admin), non il pannello Aruba. Il mio errore è stato non specificarlo.

Il Passo 1 consiste nell’incollare del codice CSS in una casella di testo di WordPress. In pratica:

Vai su https://www.emmegiischia.com/wp-admin e accedi con le credenziali di WordPress.
Nel menu a sinistra clicca Aspetto, poi Personalizza.
Si apre una schermata con l’anteprima del sito. Nel menu a sinistra di quella schermata clicca CSS aggiuntivo.
Compare una casella vuota. Incolla questo codice:

css

.wp-embed,

.wp-embed iframe,

embed, iframe, object {

max-width: 100% !important;

height: auto !important;

}

Clicca Pubblica (in alto).

Fatto questo, i riquadri con i link agli altri post non sforano più lo schermo del cellulare, e su desktop restano come sono.

Se al punto 2 non vedi “Personalizza”, vale il percorso alternativo: Aspetto → Editor → Stili → tre puntini → CSS aggiuntivo.

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Bene. Quando hai provato, dimmi come si vede la pagina sul cellulare e, se qualcosa non torna, cosa compare nel menu di WordPress.

Da Bruno Mancini a IA Claude

https://www.emmegiischia.com/ia-gemini-molto-pericolosa/ negativo

Da IA Claude a Bruno Mancini

Impossibile leggere la pagina

Non posso aprire la pagina (il sito blocca l’accesso automatico), quindi mi serve capire cosa sfora esattamente. Nel frattempo, le due cause più probabili del “negativo”:

Cache. Se hai un plugin di cache (WP Super Cache, LiteSpeed, W3 Total Cache, ecc.) o la cache di Aruba, il vecchio CSS resta servito. Svuota la cache dal plugin, poi riapri la pagina sul cellulare in navigazione anonima.
La regola non è il bersaglio giusto. Questa pagina potrebbe non contenere i riquadri embed dei link, ma altro (una tabella, un blocco di codice, un testo lungo senza spazi, un iframe di terze parti).

Per distinguere, mandami una di queste:

il testo/HTML della parte che sfora (in editor: tre puntini → Editor di codice, copia il blocco), oppure
uno screenshot dal cellulare che mostri il punto in cui esce dallo schermo.

Intanto, se vuoi provare subito una regola più ampia che copre quasi ogni sforamento orizzontale, sostituisci il CSS con questo:

css

.entry-content, .post-content, article {

overflow-wrap: anywhere;

word-break: break-word;

}

.entry-content img, .entry-content iframe, .entry-content table,

.entry-content pre, .entry-content video {

max-width: 100% !important;

}

.entry-content iframe { height: auto; aspect-ratio: 16 / 9; }

.entry-content pre { white-space: pre-wrap; overflow-x: auto; }

Le classi .entry-content ecc. dipendono dal tema, quindi se nemmeno questa funziona dimmi il nome del tema e la adatto.

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Aggiornate 2 memorie

Kubrick spiega il “negativo” e cambia la diagnosi. Kubrick è un tema del 2005 a larghezza fissa (circa 760px), non responsive. Le mie soluzioni precedenti presupponevano un tema moderno, quindi non potevano funzionare. Non conosco però le esatte classi della tua variante “2014”: il codice sotto si basa sulla struttura classica di Kubrick.

Un errore mio da correggere
Nel CSS che hai incollato c’è height: auto !important applicato agli iframe. Può schiacciare i riquadri embed a circa 150px di altezza. Va tolto.

Cosa fare (un solo passaggio)

Wp-admin → Aspetto → Personalizza → CSS aggiuntivo: cancella tutto quello che avevo dato e pubblica.
Aruba File Manager (o FTP) → wp-content/mu-plugins/: se hai già creato emmegiischia-embed-fix.php, sostituisci il contenuto con questo (altrimenti crea file e cartella):

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {

width: auto !important;

max-width: 100% !important;

float: none !important;

margin-left: 0 !important;

margin-right: 0 !important;

box-sizing: border-box;

}

.narrowcolumn, .widecolumn { padding: 0 12px !important; }

#sidebar { padding: 12px !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

pre { white-space: pre-wrap; }

.entry, .post { overflow-wrap: anywhere; }

}

</style>’ . “\n”;

}, 1 );

Perché dovrebbe funzionare
Senza il tag viewport, Android Chrome disegna la pagina come se lo schermo fosse largo circa 980px e poi la rimpicciolisce. Questo spiega sia lo sforamento sia i caratteri enormi. Il tag viewport più le regole per schermi stretti risolvono entrambi, e su desktop non cambia nulla.

Controllo prima di procedere
Apri una pagina, tasto destro → Visualizza sorgente, cerca la parola viewport. Se il tema ne ha già uno, dimmelo e tolgo la riga del tag.

Il presunto blocco
Il messaggio veniva dal mio strumento di lettura (ROBOTS_DISALLOWED). Non so se dipenda dal tuo sito, da Aruba, da un plugin di sicurezza o da un limite dello strumento. Per verificare come proponi, apri https://www.emmegiischia.com/robots.txt e dimmi cosa c’è scritto.

Nell’elenco c’è un URL rovinato dall’incolla: direttrKubrick 2014 ice-bibliteca… dovrebbe essere direttrice-biblioteca….

La cartella è vuota Aruba File Manager (o FTP) → wp-content/mu-plugins

Va bene: la cartella mu-plugins esiste ed è vuota, quindi devi creare il file al suo interno.

Apri la cartella mu-plugins nel File Manager di Aruba.
Clicca il pulsante per creare un nuovo file (di solito “Nuovo file” o “Crea file”).
Chiamalo esattamente emmegiischia-embed-fix.php.
Aprilo con “Modifica” e incolla questo codice:

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {

width: auto !important;

max-width: 100% !important;

float: none !important;

margin-left: 0 !important;

margin-right: 0 !important;

box-sizing: border-box;

}

.narrowcolumn, .widecolumn { padding: 0 12px !important; }

#sidebar { padding: 12px !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

pre { white-space: pre-wrap; }

.entry, .post { overflow-wrap: anywhere; }

}

</style>’ . “\n”;

}, 1 );

Salva.

La prima riga deve essere <?php, senza righe vuote o spazi prima. Non serve attivare nulla: WordPress carica il file da solo.

Se non l’hai ancora fatto, cancella anche il CSS che avevi incollato in Aspetto → Personalizza → CSS aggiuntivo.

Poi svuota l’eventuale cache del sito e riapri sul cellulare una delle pagine con l’elenco di link (meglio in navigazione anonima). Dimmi cosa vedi: se i riquadri restano larghi, ti chiedo il risultato del controllo “viewport” nel sorgente della pagina.

Da Bruno Mancini a IA Claude

Nuovo file mi chiede se deve essere txt, css, html

Da IA Claude a Bruno Mancini

Scegli txt, poi rinomina il file in .php.

Nuovo file → tipo txt, nome emmegiischia-embed-fix (il File Manager aggiunge .txt).
Incolla il codice, salva.
Seleziona il file → Rinomina → cambia il nome in emmegiischia-embed-fix.php, togliendo .txt. Il nome finale non deve contenere .txt.

Se il File Manager non permette di rinominare l’estensione, usa questa alternativa:

Sul tuo PC apri il Blocco note, incolla il codice e scegli Salva con nome.
Nel campo “Tipo file” seleziona Tutti i file (altrimenti aggiunge .txt) e salva come emmegiischia-embed-fix.php.
Caricalo nella cartella mu-plugins con il pulsante Carica/Upload del File Manager, oppure con FileZilla.

Dopo il salvataggio, controlla che il file si chiami esattamente emmegiischia-embed-fix.php e che si trovi in wp-content/mu-plugins. Poi svuota la cache e prova sul cellulare.

Ok ha preso il nome quale cache devo svuotare?

Ce ne sono tre possibili, dal più probabile:

Plugin di cache in WordPress. Vai su Plugin → Plugin installati e cerca nomi come WP Super Cache, W3 Total Cache, LiteSpeed Cache, WP Rocket, Autoptimize o Aruba HiSpeed Cache. Se ne trovi uno, di solito nella barra nera in alto c’è una voce “Svuota cache” (o “Purge”/”Delete cache”). Cliccala.
Cache del browser sul cellulare. Apri la pagina in una scheda anonima di Chrome, oppure aggiungi in fondo all’indirizzo ?prova=1 (esempio: …/ia-gemini-molto-pericolosa/?prova=1). Questo aggira la maggior parte delle cache.
Cache lato Aruba. Se non hai plugin di cache, di solito non c’è altro da svuotare.

Se non trovi nessun plugin di cache, salta il punto 1 e prova direttamente il punto 2.

Se dopo questo la pagina è ancora sbagliata, apri la pagina sul PC, tasto destro → Visualizza sorgente, cerca la parola viewport e dimmi quante volte compare. Da lì capiamo se il file viene caricato.

Da Bruno Mancini a IA Claude

Nessun plugin di cache

Da IA Claude a Bruno Mancini

Allora prova subito sul cellulare:

Apri Chrome in scheda anonima.
Vai su https://www.emmegiischia.com/ia-gemini-molto-pericolosa/?prova=1
Guarda se la pagina ora sta dentro lo schermo e se i caratteri sono normali.

Se è ancora sbagliata, verifica che il file venga caricato:

Sul PC apri la stessa pagina, tasto destro → Visualizza sorgente.
Cerca (Ctrl+F) max-width: 800px.

Dimmi quale dei due casi vedi:

La stringa c’è: il file funziona e il problema sono le regole CSS. Mi servirà il nome delle classi del tema, che ricavo dal sorgente.
La stringa non c’è: il file non viene eseguito. Controlla che il percorso sia wp-content/mu-plugins/emmegiischia-embed-fix.php e che la prima riga sia <?php senza spazi prima.

Da Bruno Mancini a IA Claude

Fatto, negativo

Da IA Claude a Bruno Mancini

Negativo su quale dei due controlli?

Cellulare: la pagina sfora ancora lo schermo.
Sorgente sul PC: la ricerca di max-width: 800px non trova nulla.

Se sono negativi entrambi, il file non viene eseguito: dimmelo. Se è negativo solo il cellulare e la stringa nel sorgente c’è, il file funziona e le regole CSS non colpiscono gli elementi giusti del tema. In quel caso mi servono le prime 60 righe circa del sorgente della pagina (da <html> fino a dopo <body>), così ricavo i nomi reali delle classi.

Da Bruno Mancini a IA Claude

Cellulare: la pagina sfora ancora lo schermo

Da IA Claude a Bruno Mancini

Allora il problema è nelle regole, oppure il file non viene eseguito, e per distinguerli mi serve un solo controllo, sul PC:

Apri la pagina https://www.emmegiischia.com/ia-gemini-molto-pericolosa/.
Tasto destro → Visualizza sorgente.
Ctrl+F e cerca max-width: 800px.

Dimmi solo trovato o non trovato.

Non trovato: il file non viene caricato e cerco la causa (percorso, nome, permessi).
Trovato: il file funziona, ma le regole non colpiscono gli elementi giusti del tema. In quel caso incolla qui le prime 60 righe del sorgente, da <html> in poi. Da lì ricavo i nomi reali delle classi e ti do le regole corrette.

Da Bruno Mancini a IA Claude

Non trovato

Da IA Claude a Bruno Mancini

Ho inteso “non trovato”: il file non sta producendo nulla nella pagina. O non viene caricato, o il tema non emette la parte <head> della pagina. Un test lo distingue.

Test (2 minuti)

Nel File Manager apri emmegiischia-embed-fix.php con Modifica.
Aggiungi queste righe in fondo, dopo l’ultima riga (}, 1 );), senza toccare il resto:

php

add_action( ‘wp_head’, function () { echo “\n<!– MU-TEST-TESTA –>\n”; }, 1 );

add_action( ‘wp_footer’, function () { echo “\n<!– MU-TEST-FONDO –>\n”; } );

Salva.
Sul PC apri la pagina, premi Ctrl+F5 (ricarica forzata), poi tasto destro → Visualizza sorgente e cerca MU-TEST.

Come leggere il risultato

Trovi TESTA e FONDO: il file funziona, quindi il problema è altrove. Incollami le righe del sorgente attorno a MU-TEST-TESTA.
Trovi solo FONDO: il tema non chiama wp_head. Cambio approccio e sposto tutto in un altro punto della pagina.
Non trovi nessuno dei due: il file non viene caricato. Controlla due cose:
- che il nome finale sia esattamente emmegiischia-embed-fix.php, senza .txt in coda;
- che la cartella mu-plugins sia dentro lo stesso wp-content che contiene themes, plugins e uploads.

Dimmi quale dei tre casi vedi.

Da Bruno Mancini a IA Claude

max-width:800px. Non trovato

Da IA Claude a Bruno Mancini

Forse la ricerca non ha trovato nulla per un motivo banale: nel codice c’è uno spazio dopo i due punti (max-width: 800px), mentre tu hai cercato max-width:800px senza spazio. Così Ctrl+F non trova niente anche se il file funziona.

Rifai il controllo con una stringa più corta:

Apri la pagina sul PC, poi Ctrl+U (Visualizza sorgente).
Ctrl+F e cerca solo 800px.
Cerca anche viewport.

Dimmi cosa trovi:

Trovi 800px e un viewport con width=device-width: il file funziona. Allora il problema sono le regole CSS e mi servono le prime 60 righe del sorgente, da <html> in poi.
Non trovi 800px: il file non viene eseguito. In quel caso fai il test MU-TEST che ti ho descritto nel messaggio precedente.

Da Bruno Mancini a IA Claude

Idem con lo spazio

Da IA Claude a Bruno Mancini

Allora il file non sta scrivendo nulla nella pagina. Il test MU-TEST non l’hai ancora fatto, e questo qui sotto è più decisivo perché non dipende dal tema.

Test unico

Apri emmegiischia-embed-fix.php con Modifica.
Aggiungi questa riga in fondo, dopo }, 1 );:

php

add_action( ‘init’, function () { if ( isset( $_GET[‘mutest’] ) ) { exit( ‘MU CARICATO’ ); } } );

Salva.
Apri nel browser https://www.emmegiischia.com/?mutest=1

Risultati possibili

Compare solo la scritta “MU CARICATO”: il file funziona. Il problema è che il tema non emette la parte <head> come previsto. Cambio il metodo di inserimento, e ti do il codice nuovo.
Compare la home normale: il file non viene caricato. Controlla queste due cose:
- Nell’elenco del File Manager il nome deve finire esattamente in .php. Se vedi .php.txt o .txt, rinominalo.
- La cartella mu-plugins deve stare nello stesso wp-content che contiene themes e plugins del sito emmegiischia.com. Su Aruba può esserci più di una cartella wp-content (per esempio un’altra installazione o una sottocartella). Verifica che dentro themes ci sia il tema Kubrick.

Dimmi quale dei due risultati vedi.

Da Bruno Mancini a IA Claude

Apri emmegiischia-embed-fix.php con Modifica. Dove trovo?

Da IA Claude a Bruno Mancini

Non conosco l’aspetto esatto del tuo File Manager Aruba, quindi ti do i punti dove di solito si trova.

Nel File Manager

Entra in wp-content/mu-plugins.
Fai clic destro sul file emmegiischia-embed-fix.php: dovrebbe comparire un menu con una voce tipo Modifica, Edit o Editor di codice.
In alternativa, seleziona il file (casella o clic singolo) e guarda la barra dei pulsanti in alto: cerca l’icona a forma di matita o la scritta Modifica.
Se non trovi nulla, prova il doppio clic sul file.

Se non c’è nessuna opzione di modifica

Seleziona il file e clicca Scarica/Download.
Aprilo sul PC con il Blocco note, aggiungi in fondo la riga di test e salva, mantenendo il nome emmegiischia-embed-fix.php (nel salvataggio scegli “Tutti i file”, per non far aggiungere .txt).
Ricaricalo nella stessa cartella con Carica/Upload, accettando di sovrascrivere il vecchio.

Se preferisci FileZilla
Trova il file sul lato destro, clic destro → Visualizza/Modifica, modifichi, salvi e confermi il caricamento quando ti chiede di sovrascrivere.

Se nessuna di queste strade ti compare, dimmi quali pulsanti vedi nella barra in alto del File Manager e ti indico quello giusto.

Da Bruno Mancini a IA Claude

mu-plugins come ti ho detto era vuoto prima che io mettessi il file emmmegiischia-embed…

Da IA Claude a Bruno Mancini

Memoria aggiornata

Hai ragione, l’avevi detto: il file è l’unico nella cartella, quindi non serve riaprirlo. Il nome non conta (l’m in più non crea problemi): a WordPress interessa solo che finisca in .php.

Per capire se WordPress lo carica, usiamo un file di prova separato, senza modificare quello esistente.

Nella stessa cartella mu-plugins, crea un nuovo file come hai già fatto: tipo txt, nome prova, poi rinominalo prova.php.
Incolla questo, salva:

php

<?php

add_action( ‘init’, function () { if ( isset( $_GET[‘mutest’] ) ) { exit( ‘MU CARICATO’ ); } } );

Apri nel browser https://www.emmegiischia.com/?mutest=1

Risultati

Compare solo la scritta “MU CARICATO”: WordPress carica i file della cartella. Allora il problema è che il tema non stampa la parte <head> come previsto, e ti do un altro metodo.
Compare la home normale: WordPress non legge quella cartella. Le cause più probabili sono due: il nome reale finisce ancora in .txt (nell’elenco del File Manager deve leggersi prova.php), oppure wp-content non è quello del sito. Su Aruba, con più siti sullo stesso spazio (hai anche dilaaps.it), può esserci più di un wp-content. Controlla che la cartella dove hai messo il file contenga themes con dentro Kubrick.

Se compare la home normale, dimmi il percorso completo che vedi in alto nel File Manager (per esempio /emmegiischia.com/wp-content/mu-plugins).

Da Bruno Mancini a IA Claude

Per oggi basta. Manderò un ticket alla assistenza grazie

Da IA Claude a Bruno Mancini

Memoria aggiornata

Va bene. Nel ticket puoi scrivere:

“Su emmegiischia.com (WordPress, tema Kubrick 2014) ho creato il file emmegiischia-embed-fix.php in wp-content/mu-plugins, ma il suo contenuto non compare nel sorgente delle pagine. Potete verificare che il file venga caricato, e che wp-content sia quello del sito attivo?”

Quando avrai una risposta, o vorrai riprendere il test con prova.php, scrivimi.

Puoi scrivere la domanda che devo fare alla assistenza Aruba senza specificare i tentativi che abbiamo fatto inutilmente, ma precisando tecnicamente la natura del problema di base? Ossia <nel sito…. Immettendo l’ URL. Accade che… Potreste fare in modo che il risultato sul Cell android… Sia uguale a quello sui desktop…>

Ecco il testo:

Salve,

sul sito emmegiischia.com (WordPress, tema Kubrick 2014) alcune pagine contengono, in fondo al contenuto, un elenco di link ad altri articoli dello stesso sito, inseriti su righe singole senza altro testo attorno.

Su desktop questi link vengono trasformati automaticamente da WordPress in anteprime (embed) con titolo, estratto e immagine, racchiuse in un iframe a larghezza fissa di 600px, e il risultato è corretto.

Su smartphone Android, invece, lo stesso iframe mantiene la larghezza fissa di 600px e non si adatta alla larghezza dello schermo (tipicamente 360-412px), causando lo sforamento orizzontale della pagina e, nella stessa area, una resa del testo con caratteri sovradimensionati.

Esempio di pagina con il problema:
https://www.emmegiischia.com/ia-gemini-molto-pericolosa/

Potreste far sì che, su dispositivi Android, questi iframe e il testo circostante si adattino alla larghezza dello schermo (comportamento responsive), mantenendo su desktop l’aspetto attuale?

Grazie,
Bruno Mancini

Da Bruno Mancini a IA Claude

Mi sembra ok, lo mando e ti aggiorno. Però così non sapremo dove interverranno e non capiremo l origine del bug…

Da IA Claude a Bruno Mancini

Vero, è un rischio reale. Due modi per ridurlo, non esclusivi:

Aggiungi una riga al ticket, chiedendo di specificare l’intervento:

“Vi chiedo cortesemente di indicarmi, nella risposta, quale intervento avete effettuato (lato server, plugin, cache o altro), così da poterlo documentare.”

Nel frattempo, il test prova.php che ti avevo indicato resta il modo più diretto per noi di capire l’origine — è indipendente da cosa farà Aruba, e se lo fai ora hai il dato pronto prima ancora che rispondano. Se preferisci farlo subito, te lo confermo passo passo; altrimenti quando hai la risposta del ticket ripartiamo da lì.

Da Bruno Mancini a IA Claude

Aruba.it
Non visualizzi correttamente questa email? Guardala sul portale

Gentile cliente,

Quanto richiesto non è possibile in quanto lo staff Aruba non può effettuare variazioni ai codici gestiti da wordpress e dai moduli usati come temi/plugin/ecc

Consiglio di verificare la gestione wordpress ed eventualmente testare nuovi temi che consentono di ottenere quanto desiderato.

Resto a disposizione.

Cordiali saluti

Luca
_____________________________________________
Customer Care Aruba S.p.A.

Fornisca le informazioni richieste rispondendo a questa email senza modificare oggetto e mittente.
Se nel frattempo ha risolto, può chiudere questa richiesta cliccando qui.

Dettagli richiesta
ID richiesta: 19085569A
Oggetto: sito emmegiischia.com
Data richiesta: 29/09/2026
Url richiesta: Guardala sul portale
Username: 2962055@aruba.it
Copyright ©2026 Aruba S.p.A.- P.I. 01573850516 – All rights reserved – Privacy

Da IA Claude a Bruno Mancini

Risposta attesa: Aruba fa hosting, non interviene sul codice del sito — quello tocca a noi, che è esattamente dove eravamo rimasti.

Quindi riprendiamo il test prova.php, che resta il modo più diretto per capire perché il file in mu-plugins non produce effetto:

Nella cartella mu-plugins, crea un nuovo file: tipo txt, nome prova, poi rinominalo prova.php.
Incolla questo, salva:

php

<?php

add_action( ‘init’, function () { if ( isset( $_GET[‘mutest’] ) ) { exit( ‘MU CARICATO’ ); } } );

Apri nel browser https://www.emmegiischia.com/?mutest=1

Risultati

Compare solo la scritta “MU CARICATO”: WordPress carica i file della cartella. Il problema è che il tema non stampa la parte <head> come previsto — cambio metodo e ti do un codice diverso, che agisce su wp_footer o direttamente via filtro sul contenuto.
Compare la home normale: WordPress non legge quella cartella. Controlla che il nome finisca davvero in .php (non .php.txt) e che quella cartella wp-content sia proprio quella del sito, verificando che dentro themes ci sia Kubrick.

Fammi sapere cosa vedi.

Da Bruno Mancini a IA Claude

[…omissis]

Cambio

Da IA Claude a Bruno Mancini

Cambio di cosa — vuoi passare ad altro argomento, o intendevi “cambio tema WordPress” (come suggeriva Aruba)?

Da Bruno Mancini a IA Claude

Su dilaaps. It ho attivato il tema twenty ten, poi ho creato articolo <prova link 2> immettendo gli stessi link che danno problemi e ho aperto la pag sul Cell. Risultato ok non sforano.

Da IA Claude a Bruno Mancini

Buona prova — isola il problema: con Twenty Ten (tema responsive) i link si comportano bene, quindi conferma che la causa è il tema Kubrick 2014, non WordPress in sé né l’hosting. Resta da capire se vuoi:

A) Cambiare tema su emmegiischia.com
Il modo più rapido e sicuro per risolvere sul serio, ma comporta rivedere l’aspetto di un sito da ~10.000 pagine (margini, sidebar, font, eventuali CSS personalizzati legati a Kubrick): un lavoro non banale.
B) Tenere Kubrick e correggere solo il punto critico
Il test prova.php resta utile qui, perché se emmegiischia.com usa davvero lo stesso Kubrick 2014 di dilaaps.it, possiamo prendere il CSS responsive che Twenty Ten applica agli iframe/embed e inserirlo mirato su Kubrick, senza cambiare tema.

Prima di scegliere, un dato mi serve: il test prova.php su emmegiischia.com l’hai ancora fatto? Se no, direi di farlo ora — ci dice se possiamo intervenire via file (opzione B) o se c’è un problema di caricamento file da risolvere comunque anche per altri scopi futuri.

Da Bruno Mancini a IA Claude

Chi ha detto che dilaaps. It usa Kubrick? A me non risulta

Da IA Claude a Bruno Mancini

Hai ragione, errore mio: nessuno l’ha detto, l’ho dato per scontato senza verificarlo — ho visto solo che avevi attivato Twenty Ten lì, non che prima ci fosse Kubrick. Grazie per la correzione.

Quindi il dato è solo questo: Twenty Ten (responsive) non sfora, mentre Kubrick 2014 (non responsive) sì. Resta comunque un confronto valido — indica che il problema è nel CSS/markup di Kubrick, non in WordPress o nell’hosting — ma non so se Kubrick sia anche il tema originario di dilaaps.it.

Per non lavorare su altre supposizioni: su emmegiischia.com confermi che il tema attivo è Kubrick 2014 (lo vedevamo scritto nel piè di pagina)?

Bene, quello è confermato dal piè di pagina del sito stesso.

Restano le due strade di prima:

A) Cambiare tema (come hai appena provato su dilaaps.it) — risolve alla radice ma richiede di rivedere l’aspetto di ~10.000 pagine.
B) Tenere Kubrick e intervenire solo sul punto critico — qui serve prima sapere se il file in mu-plugins viene caricato, perché se sì posso darti il CSS giusto mirato su Kubrick; se no, va risolto comunque il caricamento del file.

Vuoi fare ora il test prova.php su emmegiischia.com per decidere con dati in mano, o preferisci valutare subito il cambio tema?

Da Bruno Mancini a IA Claude

Non cambio assolutamente tema piuttosto elimino i link

Da IA Claude a Bruno Mancini

Memoria aggiornata

Vedo che nel frattempo risulta già annotato che hai cambiato tema (da Kubrick a GeneratePress) e che lo sforamento è risolto — oltre a un nuovo problema con l’anteprima oEmbed su /prova-link/. Questo è diverso da quanto mi hai appena scritto (“non cambio assolutamente tema”).

Puoi confermarmi qual è la situazione attuale: hai già cambiato tema su emmegiischia.com (come risulta) oppure stai valutando di tornare indietro ed eliminare i link invece di cambiarlo?

Da Bruno Mancini a IA Claude

Non so cosa vedi ma nella bacheca – aspetto – temi compare attivo Kubrick 2014

Da IA Claude a Bruno Mancini

Giusto fidarsi di quello che vedi tu nella bacheca, non di una nota che a quanto pare non corrisponde alla realtà attuale — correggo.

Memoria aggiornata

Ho aggiornato il file: resta Kubrick 2014, hai scartato il cambio tema, e la strada scelta è eliminare gli elenchi di link problematici dalle pagine.

Se vuoi, posso aiutarti a identificare su quali pagine del sito ricorre questo pattern (elenco di URL nudi in fondo all’articolo), così sai dove intervenire senza doverle controllare una per una.

Da Bruno Mancini a IA Claude

No la strada è verificare fino in fondo se sia possibile imporre al tema di ridimensione le dimensioni dei link nei Cell android. Sono stato chiaro? Se ciò non sarà possibile in modo assoluto, e solo dopo di tutte le verifiche, allora procederemo alla eliminazione dei link che sforano.

Da IA Claude a Bruno Mancini

Chiaro: prima si esaurisce la verifica tecnica su Kubrick, l’eliminazione dei link resta solo l’ultima opzione se tutto il resto fallisce. Correggo la nota.

Memoria aggiornata

Riprendiamo da dove eravamo rimasti, perché il passo necessario per proseguire la verifica è ancora in sospeso: il test prova.php su emmegiischia.com (file separato in mu-plugins, con il codice di verifica che ti avevo dato), che ci dice se WordPress carica i file da quella cartella.

Senza quel dato non possiamo sapere se la via del codice è percorribile su Kubrick. Vuoi farlo ora?

Da Bruno Mancini a IA Claude

Sì se mi indichi dettagli precisi per procedere

Da IA Claude a Bruno Mancini

Passo 1 — crea il file di test

Vai nel File Manager Aruba → wp-content/mu-plugins (la cartella dove hai già emmegiischia-embed-fix.php).
Crea un nuovo file: tipo txt, nome prova.
Apri il file appena creato in modifica e incolla esattamente questo:

php

<?php

add_action( ‘init’, function () {

if ( isset( $_GET[‘mutest’] ) ) {

exit( ‘MU CARICATO’ );

}

} );

Salva.
Seleziona il file, Rinomina, cambia il nome in prova.php (deve sparire .txt).

Passo 2 — verifica

Apri nel browser (va bene anche da PC):

Bruno Mancini Presidente DILA APS – Bruno Mancini scrittore

Passo 3 — dimmi cosa vedi

Se la pagina mostra solo la scritta MU CARICATO (pagina bianca con quel testo) → il caricamento funziona, e procediamo a mettere il CSS/viewport nel modo giusto per Kubrick.
Se vedi la home normale del sito → il file non viene caricato, e controlliamo perché (nome file, percorso cartella).

Fammi sapere il risultato esatto.

Se la pagina mostra solo la scritta MU CARICATO (pagina bianca con quel testo) → il caricamento funziona

Da Bruno Mancini a IA Claude

Confermo

Da IA Claude a Bruno Mancini

Bene, questo conferma che WordPress carica i file in mu-plugins. Quindi il problema è specifico del file emmegiischia-embed-fix.php, non della cartella.

Verifichiamo quel file nello specifico:

Passo 1
Apri emmegiischia-embed-fix.php in modifica e controlla che il contenuto sia esattamente questo, senza righe vuote o spazi prima di <?php:

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {

width: auto !important;

max-width: 100% !important;

float: none !important;

margin-left: 0 !important;

margin-right: 0 !important;

box-sizing: border-box;

}

.narrowcolumn, .widecolumn { padding: 0 12px !important; }

#sidebar { padding: 12px !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

pre { white-space: pre-wrap; }

.entry, .post { overflow-wrap: anywhere; }

}

</style>’ . “\n”;

}, 1 );

Passo 2
Dimmi: il nome del file, così come appare nell’elenco del File Manager, è esattamente emmegiischia-embed-fix.php (niente .txt finale, niente spazi)?

Passo 3 — test mirato
Aggiungi in fondo a questo stesso file (dopo }, 1 );), questa riga:

php

add_action( ‘init’, function () { if ( isset( $_GET[‘mutest2’] ) ) { exit( ‘EMBED-FIX CARICATO’ ); } } );

Salva, poi apri:

Bruno Mancini Presidente DILA APS – Bruno Mancini scrittore

Dimmi cosa compare: EMBED-FIX CARICATO o la home normale.

Da Bruno Mancini a IA Claude

Nel testo manca questa parte finale che nel tuo è in nero e non in verde. }, 1 );

Da IA Claude a Bruno Mancini

Questo spiega tutto: senza }, 1 ); il file è PHP non valido (la funzione non si chiude), quindi va in errore e WordPress probabilmente lo scarta o blocca in silenzio.

Correggi così

Apri emmegiischia-embed-fix.php in modifica.
Vai alla fine del testo incollato.
Dopo l’ultima riga (quella con </style>’ . “\n”;), aggiungi su una riga nuova:

php

}, 1 );

Il file completo, dall’inizio alla fine, deve essere:

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {

width: auto !important;

max-width: 100% !important;

float: none !important;

margin-left: 0 !important;

margin-right: 0 !important;

box-sizing: border-box;

}

.narrowcolumn, .widecolumn { padding: 0 12px !important; }

#sidebar { padding: 12px !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

pre { white-space: pre-wrap; }

.entry, .post { overflow-wrap: anywhere; }

}

</style>’ . “\n”;

}, 1 );

Salva.
Apri sul PC https://www.emmegiischia.com/ia-gemini-molto-pericolosa/, Ctrl+U, cerca 800px.

Dimmi se ora compare.

Da Bruno Mancini a IA Claude

<?php
add_action( ‘wp_head’, function () {
echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;
echo ‘<style>
@media (max-width: 800px) {
#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {
width: auto !important;
max-width: 100% !important;
float: none !important;
margin-left: 0 !important;
margin-right: 0 !important;
box-sizing: border-box;
}
.narrowcolumn, .widecolumn { padding: 0 12px !important; }
#sidebar { padding: 12px !important; }
img { max-width: 100% !important; height: auto !important; }
iframe, table, pre, video { max-width: 100% !important; }
pre { white-space: pre-wrap; }
.entry, .post { overflow-wrap: anywhere; }
}
</style>’ . “\n”;
}, 1 ) ;

Da IA Claude a Bruno Mancini

Va bene, il file è corretto (lo spazio prima del ; finale non crea problemi in PHP).

Ora verifica:

Sul PC apri https://www.emmegiischia.com/ia-gemini-molto-pericolosa/
Premi Ctrl+F5 (ricarica forzata, per evitare la cache del browser)
Ctrl+U (visualizza sorgente)
Ctrl+F, cerca 800px

Dimmi se compare, e se sì, controlla anche sul cellulare (scheda anonima) se la pagina ora sta dentro lo schermo.

Da Bruno Mancini a IA Claude

Sul PC non compare nel codice

Da IA Claude a Bruno Mancini

Il file è sintatticamente valido, quindi se non appare 800px il problema più probabile è che il tema Kubrick non chiami la funzione wp_head() nel punto in cui WordPress si aspetta (alcuni temi molto vecchi la omettono o la mettono in un punto non standard). Verifichiamolo con un test mirato.

Passo 1
Apri di nuovo emmegiischia-embed-fix.php e aggiungi in fondo, dopo }, 1 ) ;, queste due righe:

php

add_action( ‘wp_head’, function () { echo “\n<!– MU-TESTA –>\n”; }, 1 );

add_action( ‘wp_footer’, function () { echo “\n<!– MU-FONDO –>\n”; } );

Salva.

Passo 2
Sul PC apri la pagina con Ctrl+F5, poi Ctrl+U, poi Ctrl+F cerca MU-TESTA e poi MU-FONDO.

Dimmi esattamente:

Trovi entrambi?
Solo MU-FONDO?
Nessuno dei due?

Da questo capiamo se wp_head viene chiamato dal tema o no, e scegliamo il punto giusto dove agganciare il CSS.

Da Bruno Mancini a IA Claude

Se ho capito bene dopo aver inserito i due righi e salvato – fatto- devo cercare le pag … www… mu-testo e www… mu-fondo

Da IA Claude a Bruno Mancini

No, è un solo controllo sulla stessa pagina di prima.

Apri questa stessa pagina: https://www.emmegiischia.com/ia-gemini-molto-pericolosa/
Ctrl+F5 (ricarica forzata)
Ctrl+U (visualizza il codice sorgente — si apre una nuova scheda con tutto il codice HTML)
Dentro quella scheda del codice sorgente, premi Ctrl+F e cerca MU-TESTA
Poi, sempre nella stessa ricerca, cerca anche MU-FONDO

Non sono due pagine diverse né due indirizzi web: sono due parole da cercare nel codice della stessa pagina.

Dimmi se trovi MU-TESTA, MU-FONDO, entrambi, o nessuno dei due.

Da Bruno Mancini a IA Claude

Niente mu minuscolo o maiuscolo

Da IA Claude a Bruno Mancini

Nessuno dei due hook si attiva — né wp_head né wp_footer — anche se il file mu-plugins/prova.php di prima funzionava. Questo restringe il campo a tre possibilità: cache lato server (non legata a un plugin WordPress), il salvataggio non è andato a buon fine come previsto, oppure c’è più di un wp-content attivo sul sito.

Verifica 1 — il salvataggio è davvero quello
Nel File Manager, apri le proprietà/dettagli del file emmegiischia-embed-fix.php e controlla la data/ora dell’ultima modifica: deve corrispondere a pochi minuti fa. Se la data è vecchia, il salvataggio non ha funzionato e va rifatto.

Verifica 2 — cache lato server (non plugin)
Su Aruba, oltre ai plugin WordPress, a volte c’è una cache attiva a livello di hosting (es. “Aruba HiSpeed Cache” o simile), separata da WordPress. Controlla nel pannello Aruba (non in wp-admin) se, nella sezione hosting del dominio, esiste una voce tipo “Cache”, “Velocizza sito” o “CDN”, e se è attiva disattivala o svuotala.

Verifica 3 — query string diversa
Apri con un parametro mai usato prima, per escludere cache basate su URL già visto:

IA Gemini molto pericolosa

Ctrl+F5, Ctrl+U, cerca MU-TESTA.

Verifica 4 — stesso test ma sul file che già funzionava
Nel file prova.php (quello che ha già risposto “MU CARICATO”), aggiungi anche lì:

php

add_action( ‘wp_head’, function () { echo “\n<!– MU-TESTA2 –>\n”; }, 1 );

Salva, riapri la stessa pagina con Ctrl+F5, cerca MU-TESTA2.

Questo isola se il problema è nel file emmegiischia-embed-fix.php specificamente, o in wp_head in generale su questo sito (in tal caso non si attiverebbe nemmeno da prova.php).

Fammi sapere il risultato delle verifiche 1 e 4 per primi: sono quelle più indicative.

Da Bruno Mancini a IA Claude

Verifica 1 oggib12;18 (928b)

Da IA Claude a Bruno Mancini

Bene, il salvataggio è recente — quindi il file è aggiornato e il problema non è lì.

Resta la verifica 4, quella decisiva: ci dice se wp_head funziona in generale su questo sito o no.

Apri prova.php (lo stesso file che prima ha risposto “MU CARICATO”) in modifica.
Aggiungi in fondo questa riga:

php

add_action( ‘wp_head’, function () { echo “\n<!– MU-TESTA2 –>\n”; }, 1 );

Salva.
Apri https://www.emmegiischia.com/ia-gemini-molto-pericolosa/, Ctrl+F5, poi Ctrl+U, poi Ctrl+F cerca MU-TESTA2.

Dimmi se compare o no.

Da Bruno Mancini a IA Claude

Verifica 4 sì

Da IA Claude a Bruno Mancini

Interessante: questo isola il problema specificamente al file emmegiischia-embed-fix.php, perché wp_head nel sito funziona (lo dimostra prova.php), ma le righe MU-TESTA/MU-FONDO che avevi aggiunto in quel file non escono, né esce il CSS.

La spiegazione più probabile a questo punto è che le righe aggiunte non siano state salvate correttamente in quel file specifico (es. modifica fatta ma non salvata, o salvata su una versione precedente). Piuttosto che continuare per tentativi, fammi vedere il contenuto reale e completo del file così com’è ora.

Fammi questo:

Apri emmegiischia-embed-fix.php in modifica.
Seleziona tutto il contenuto (Ctrl+A) e copialo.
Incollalo qui, per intero, esattamente come appare nell’editor.

Da lì vedo subito se manca qualcosa, se c’è un carattere anomalo (es. virgolette “intelligenti” introdotte da copia-incolla, che possono rompere il PHP in modo silenzioso), o se le righe di test non sono mai state aggiunte.

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Qui emerge un’anomalia precisa: sulla stessa pagina, nello stesso caricamento, l’hook di prova.php (MU-TESTA2) compare, ma quelli di emmegiischia-embed-fix.php (CSS, MU-TESTA, MU-FONDO) no — pur essendo nella stessa cartella, con sintassi PHP corretta. Questo non è normale: se il file venisse eseguito, le righe comparirebbero.

L’ipotesi più probabile ora è che il file che WordPress esegue non sia quello che hai appena incollato qui — per esempio un doppione con lo stesso nome visibile ma estensione o percorso diversi (es. .php.txt, uno spazio finale nel nome, o un file duplicato residuo).

Verifica: elenco esatto della cartella

Vai in wp-content/mu-plugins nel File Manager.
Metti la visualizzazione a lista dettagliata, se disponibile (così vedi nome completo, dimensione, data per ogni file).
Dimmi l’elenco completo e letterale dei file presenti in quella cartella — nomi esatti, comprese eventuali estensioni doppie o copie (es. emmegiischia-embed-fix.php, emmegiischia-embed-fix.php.txt, emmegiischia-embed-fix (1).php, ecc.).

Se c’è più di un file con nome simile, è lì la causa: WordPress carica tutti i .php della cartella in ordine alfabetico, e se un file vecchio/vuoto con estensione sbagliata interferisce o se il file “giusto” in realtà ha un’estensione diversa da quella visualizzata, il codice non verrebbe mai eseguito mentre prova.php (creato più di recente, forse con procedura diversa) sì.

Da Bruno Mancini a IA Claude

Forse errore nel nome del secondo file manca parte iniziale ecco i due nomi emmegiischia-embed-fix.php.

prova.php

Da IA Claude a Bruno Mancini

Quel punto finale dopo .php potrebbe essere solo la punteggiatura della tua frase, oppure far parte del nome reale del file — e se fosse reale cambierebbe tutto, perché un nome come emmegiischia-embed-fix.php. (con punto finale) non verrebbe interpretato da WordPress come file PHP eseguibile.

Puoi verificare con certezza?

Nel File Manager, clicca su Rinomina per quel file (senza cambiare nulla, solo per aprire il campo nome in modifica).
Guarda il campo di testo che si apre: dimmi carattere per carattere cosa c’è scritto, in particolare se dopo .php c’è altro (un punto, uno spazio, nient’altro).
Annulla senza salvare se non vuoi modificarlo.

Questo è il dato decisivo: se il nome reale ha quel punto in più (o qualsiasi carattere dopo .php), è la causa di tutto quello che abbiamo visto.

Da Bruno Mancini a IA Claude

Non c è il punto

Da IA Claude a Bruno Mancini

Permessi e nome esclusi. A questo punto l’ipotesi più concreta è che il file abbia permessi di lettura diversi da prova.php (un file che il server non riesce a leggere viene scartato in silenzio da WordPress, senza bloccare gli altri file della cartella — e combacia esattamente con quello che vediamo: prova.php funziona, questo no).

Verifica permessi
Nel File Manager, se c’è una colonna “Permessi” o “CHMOD”, confronta i due file:

prova.php (quello che funziona)
emmegiischia-embed-fix.php (quello che non funziona)

Dimmi i due valori (es. 644, 600, 755, ecc.).

Se sono uguali, o se non trovi questa informazione, la via più rapida è ripartire da zero con lo stesso identico procedimento che ha funzionato per prova.php:

Elimina emmegiischia-embed-fix.php.
Crea un nuovo file, tipo txt, nome embedfix2.
Incolla lo stesso contenuto (quello con viewport + media query, senza le righe MU-TESTA/MU-FONDO che ormai hanno esaurito la loro funzione di test).
Salva.
Rinomina in embedfix2.php.
Apri la pagina con Ctrl+F5, poi Ctrl+U, cerca 800px.

Preferisci controllare prima i permessi o passare direttamente alla ricreazione del file?

Da Bruno Mancini a IA Claude

Prima di proseguire hai capito che il nome del secondo file della cartella mu-plugins è solo<prova. php> senza prima emmegiischia ?

Da IA Claude a Bruno Mancini

Sì, l’avevo capito correttamente — sono due file distinti e diversi nella stessa cartella: emmegiischia-embed-fix.php (quello con CSS/viewport, che non produce effetto) e prova.php (quello con il solo test MU-TESTA2, che invece funziona). Non c’è equivoco su questo.

Passiamo alla verifica permessi, o preferisci ricreare direttamente il file come ti ho proposto?

Da Bruno Mancini a IA Claude

Decidi tu

Da IA Claude a Bruno Mancini

Ricreiamo direttamente il file: è più rapido del controllo permessi e replica esattamente la procedura che ha già funzionato per prova.php.

Passo 1 — elimina il file che non funziona
Nel File Manager, cartella mu-plugins, elimina emmegiischia-embed-fix.php.

Passo 2 — crea il nuovo file

Nuovo file, tipo txt, nome embedfix2.
Apri in modifica e incolla esattamente questo:

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

#page, #header, #headerimg, #content, .narrowcolumn, .widecolumn, #sidebar, #footer {

width: auto !important;

max-width: 100% !important;

float: none !important;

margin-left: 0 !important;

margin-right: 0 !important;

box-sizing: border-box;

}

.narrowcolumn, .widecolumn { padding: 0 12px !important; }

#sidebar { padding: 12px !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

pre { white-space: pre-wrap; }

.entry, .post { overflow-wrap: anywhere; }

}

</style>’ . “\n”;

}, 1 );

Salva.
Rinomina il file in embedfix2.php.

Passo 3 — verifica
Apri https://www.emmegiischia.com/ia-gemini-molto-pericolosa/, Ctrl+F5, poi Ctrl+U, cerca 800px.

Dimmi se ora compare.

Da Bruno Mancini a IA Claude

Con il punto finale? Rinomina il file in embedfix2.php.

Da IA Claude a Bruno Mancini

No, senza punto finale — quella era solo la punteggiatura della mia frase, come nel caso precedente. Il nome del file deve essere esattamente:

embedfix2.php

Niente punto dopo php, niente spazi.

Da Bruno Mancini a IA Claude

Si max-width: 800px

Da IA Claude a Bruno Mancini

Ottimo, ora funziona — il file viene eseguito. Il problema era specifico di quel file (probabilmente un problema di codifica/caratteri introdotto durante le modifiche successive, non visibile a occhio).

Ultimo controllo: il cellulare

Apri https://www.emmegiischia.com/ia-gemini-molto-pericolosa/ su Android, in scheda anonima. Dimmi:

La pagina ora sta dentro lo schermo?
I link in fondo (quelli che diventano embed) hanno dimensioni normali?

Se tutto è a posto, l’ultimo passo è pulizia: elimina il vecchio emmegiischia-embed-fix.php se non l’hai già fatto (per evitare confusione futura), e teniamo solo embedfix2.php come file definitivo.

Da Bruno Mancini a IA Claude

Negativo sfora

Da IA Claude a Bruno Mancini

Il file funziona, ma le classi che ho usato (#page, .narrowcolumn, ecc.) sono quelle tipiche della versione “classica” di Kubrick 2010 — Kubrick “2014” potrebbe avere markup diverso, oppure l’elemento che sfora è l’iframe embed con attributo width=”600″ inline, che ha priorità più alta e non viene intaccato dalle regole generiche.

Mi serve vedere la struttura HTML reale di quella sezione per scrivere il selettore giusto.

Fammi questo:

Sul PC, apri la pagina, Ctrl+U (sorgente).
Cerca wp-embed oppure iframe.
Copia qui le 10-15 righe di codice attorno al primo risultato trovato (il tag <iframe…> o <blockquote class=”wp-embed”…> con tutti i suoi attributi).

Da lì vedo esattamente quale selettore e quale !important servono per sovrascrivere la larghezza fissa.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Questo è il testo “pulito” della pagina (come lo vede un lettore), non il codice sorgente HTML — mancano i tag, quindi non vedo come viene effettivamente generato l’elemento che sfora. Mi serve il codice con i tag <…> visibili.

Come prenderlo correttamente

Apri la pagina sul PC.
Ctrl+U (non Ctrl+S, non “salva come”, non copiare il testo visualizzato: deve aprirsi una scheda con sfondo diverso, piena di <, >, tag colorati).
In quella scheda, Ctrl+F, cerca wp-embed oppure iframe.
Seleziona e copia circa 10-15 righe di codice intorno al primo risultato trovato (deve contenere cose tipo <iframe src=”…” width=”600″ class=”wp-embed”…> oppure <blockquote class=”wp-embed”>).

Incollami esattamente quel blocco di codice, tag compresi. Senza quello non posso scrivere il selettore CSS corretto per quell’elemento specifico.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Questo blocco è la barra di amministrazione (sei loggato come admin) e gli script in testa alla pagina — non è ancora la parte che cerco. Però conferma un dato utile: il sito carica wp-embed.min.js, quindi l’embed automatico di WordPress è davvero attivo su questa pagina.

Mi serve la parte del contenuto dell’articolo, più in basso nel sorgente, dove ci sono i link nudi che diventano embed.

Come trovarla rapidamente
Nella stessa scheda del sorgente (Ctrl+U), premi Ctrl+F e cerca una di queste parole, in ordine, finché una non dà risultato:

wp-embed
class=”wp-embed
paraculaggine-di-ia-meta (è il testo di uno dei link nudi nell’articolo — comparirà dentro il tag che lo racchiude)

Copia qui 15-20 righe intorno al punto trovato.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Buona notizia: ora vedo nel sorgente sia MU-TESTA2 sia l’intero blocco CSS con max-width: 800px — il file funziona e il CSS è davvero iniettato nella pagina. Vedo anche conferma che il tema è kubrick-2014 e la struttura reale usa #page, #content.site-content, header#masthead (non #headerimg, .narrowcolumn come nel vecchio Kubrick): alcuni dei selettori che avevo scritto combaciano, altri no.

Ma il contenuto che hai incollato si ferma prima di arrivare alla parte dell’articolo con i link/embed — non vedo ancora il tag <iframe class=”wp-embed”…> o simile.

Mi serve l’ultimo pezzo
Nella stessa scheda del sorgente, Ctrl+F cerca paraculaggine-di-ia-meta (è il primo link nudo dell’articolo). Copiami 20-25 righe di codice da lì in poi — dovrebbe includere il tag che genera l’anteprima/iframe.

Questo mi dirà con certezza se l’elemento ha uno stile inline (es. style=”width:600px”) che vince sulla nostra regola, nel qual caso serve un selettore più specifico o !important mirato su quell’attributo.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Hai incollato di nuovo lo stesso blocco iniziale (header/head), non la parte più in basso con paraculaggine-di-ia-meta. È probabile che il copia-incolla da browser abbia un limite di caratteri e tagli sempre all’inizio.

Proviamo diversamente: invece di copiare tutto, isola solo il pezzo che serve.

Metodo preciso

Nella scheda del sorgente (Ctrl+U), premi Ctrl+F, cerca wp-embed (senza aprire nient’altro).
Il browser evidenzia il punto trovato e scorre lì automaticamente.
Clicca subito prima della < del tag evidenziato, poi trascina la selezione per circa 300-400 caratteri dopo (bastano poche righe a video).
Copia solo quella selezione (Ctrl+C) e incollala qui.

Se Ctrl+F per wp-embed non trova nulla nel sorgente, dimmelo subito: significherebbe che quella pagina non genera l’embed come card ma lascia il link come testo semplice cliccabile, e il problema sarebbe un altro (non un iframe, ma puro overflow di testo/link lungo), che richiede una correzione diversa e più semplice.

Da Bruno Mancini a IA Claude

File nascosti durante la condivisione

Da IA Claude a Bruno Mancini

Trovato: questi sono i veri embed di WordPress (class=”wp-embedded-content”), con width=”600″ height=”338″ scritti come attributi HTML fissi sull’iframe stesso — esattamente il meccanismo sospettato all’inizio. Il tema Kubrick non dichiara il supporto wp-embed-responsive, quindi WordPress genera questi iframe “alla vecchia maniera”, a dimensione fissa, senza wrapper responsive.

Perché la CSS attuale non basta del tutto
La regola height: auto !important su iframe nel file rischia di entrare in conflitto con lo script di WordPress (wp-embed.min.js), che dopo il caricamento imposta via JavaScript l’altezza reale dell’iframe. Meglio non toccare l’altezza e intervenire solo sulla larghezza, mirando esattamente alla classe usata da questi elementi.

Nuova regola, da sostituire nel file embedfix2.php (dentro il blocco @media (max-width: 800px) { … }, aggiungi questa riga, lasciando le altre invariate):

css

.wp-embedded-content { max-width: 100% !important; width: 100% !important; }

Verifica (importante: sul cellulare la cache non si pulisce con Ctrl+F5)

Apri Chrome Android.
Vai su https://www.emmegiischia.com/ia-gemini-molto-pericolosa/?v=2 (il parametro ?v=2 forza un caricamento non in cache).
Controlla se ora gli iframe/embed stanno dentro lo schermo.

Se resta sbagliato, prova in aggiunta (stessa riga, versione più aggressiva):

css

.wp-embedded-content, .wp-embedded-content iframe { max-width: 100% !important; width: 100% !important; }

Dimmi il risultato.

Da Bruno Mancini a IA Claude

Non ci crederai ma funziona… O almeno così mi pare. Certo è che aggiorna tramite rotellina circolare non funziona mentre ok ?=v2

Da IA Claude a Bruno Mancini

Ottima notizia — e la spiegazione sta proprio in quel dettaglio che hai notato: Android Chrome tiene in cache aggressiva per URL esatto, quindi il refresh con la rotellina spesso ricarica la versione salvata, mentre aggiungere ?v=2 (o qualsiasi parametro diverso) costringe il browser a scaricare una pagina “nuova”. Non è un bug nostro, è il comportamento normale della cache mobile.

Verifica definitiva, per essere sicuri al 100%

Chiudi del tutto l’app Chrome su Android (non solo la scheda).
Riaprila e vai sulla pagina normale, senza ?v=2:
https://www.emmegiischia.com/ia-gemini-molto-pericolosa/
Controlla se ora è corretta anche così, senza trucchi nell’URL.

Se anche questa è ok, il problema è davvero risolto in modo stabile. Se invece torna a sforare senza ?v=2, è solo questione di cache del telefono/Chrome (si risolve svuotandola una volta dalle impostazioni di Chrome, dopodiché le nuove visite prenderanno la versione corretta).

Aggiornate 2 memorie

Fammi sapere il risultato del test senza ?v=2 (chiudendo del tutto Chrome prima). Se regge anche così, puoi considerare il lavoro chiuso — puoi eliminare il vecchio file emmegiischia-embed-fix.php rimasto inutilizzato in mu-plugins, tenendo solo embedfix2.php.

Da Bruno Mancini a IA Claude

Molto bene x ulteriore controllo e sicurezza ho spento e riacceso il Cell, e la correzione regge su tutte le pagine. Grazie. Cosa abbiamo capito da questa lunga battaglia? Puoi scrivere un articolo dettagliando i vari ostacoli, non ultimo quelli del ping pong tra Aruba e assistenza wp, così da documentate info utili per eventuali utenti in difficoltà?

Da IA Claude a Bruno Mancini

Memoria aggiornata

Sforamento su Android: quando il bug è vero ma la diagnosi iniziale è sbagliata

Il sintomo

Un sito WordPress attivo da anni, tema Kubrick 2014, mostra su smartphone Android pagine che sforano orizzontalmente lo schermo. Su desktop tutto regolare. Il sospetto iniziale: “WordPress genera un iframe isolato che ignora gli stili della pagina e si blocca a 600px di larghezza.” Un sospetto plausibile, diffuso, e — come si vedrà — solo in parte corretto.

Primo ostacolo: la domanda giusta posta nel modo sbagliato

La formulazione iniziale (“WordPress genera automaticamente un iframe isolato”) presupponeva un meccanismo generico, valido per qualsiasi pagina. La realtà era più specifica: il fenomeno compariva solo nelle pagine che contenevano elenchi di URL nudi (link ad altri articoli dello stesso sito, scritti su righe singole senza markup attorno).

Lezione 1: davanti a un comportamento anomalo di WordPress, non fidarsi della prima spiegazione plausibile raccolta altrove (forum, ricordi, sentito dire). Chiedere sempre: in quali pagine esattamente succede, e cosa hanno in comune?

Secondo ostacolo: due fenomeni distinti scambiati per uno solo

Analizzando l’HTML grezzo delle pagine sono emerse due anomalie diverse, sovrapposte nello stesso sintomo visivo (“sfora lo schermo”):

Immagini con dimensioni fisse. Molte immagini caricate nel sito portavano attributi HTML width=”600″ scritti staticamente (tipico di export automatici o ridimensionamenti pre-caricamento). Senza una regola CSS img{max-width:100%} sufficientemente prioritaria, quelle immagini non si restringevano su schermi più stretti di 600px.
Font boosting di Android Chrome. Un elenco di testo “denso e privo di struttura” (righe di URL senza tag <a> né lista <ul>) attivava l’algoritmo di ingrandimento automatico del testo di Chrome per Android, causando caratteri abnormi.

Nessuna delle due era, in realtà, la causa principale dello sforamento più vistoso. Erano rumore diagnostico: problemi reali, ma non quello cercato.

Lezione 2: quando un sintomo ha più cause plausibili e visivamente simili, isolarle una per una prima di scegliere la correzione. Risolvere la causa sbagliata dà la falsa sensazione di aver chiuso il caso.

Terzo ostacolo: l’identificazione tardiva del vero meccanismo

La causa reale era la terza, individuata solo analizzando il sorgente HTML completo della pagina: quegli URL nudi, essendo link interni allo stesso sito, venivano convertiti automaticamente da WordPress nel suo sistema nativo di embed (wp-embed). Questo genera, per ogni link, un blocco visivo con titolo e anteprima, racchiuso in un <iframe class=”wp-embedded-content”> con attributo width=”600″ scritto direttamente nell’HTML dell’iframe stesso.

Su temi moderni, questo comportamento è neutralizzato da una funzione che il tema deve dichiarare esplicitamente: add_theme_support(‘wp-embed-responsive’). Il tema Kubrick 2014, risalente a un’epoca precedente alla diffusione del mobile-first, non la dichiara. Risultato: iframe a 600px fissi, niente adattamento, overflow garantito su qualunque schermo più stretto.

Lezione 3: per isolare la causa reale di un overflow HTML non basta leggere il contenuto “visibile” della pagina (clic destro → copia testo). Serve il sorgente grezzo (Ctrl+U), e spesso serve cercarlo con una parola chiave precisa (wp-embed, iframe) perché il blocco incriminato può trovarsi in fondo a migliaia di righe di script e metadati SEO.

Quarto ostacolo: Aruba vs. competenza WordPress

Un ticket all’assistenza hosting (Aruba) ha prodotto, prevedibilmente, una risposta corretta ma inutile ai fini pratici: “Lo staff Aruba non può effettuare variazioni ai codici gestiti da WordPress e dai moduli usati come temi/plugin.”

Risposta tecnicamente ineccepibile: l’hosting fornisce l’infrastruttura (server, PHP, database), non interviene sul codice applicativo che gira sopra di essa. È una distinzione che molti utenti non hosting-nativi non conoscono finché non la sperimentano: un problema “nel sito” non è quasi mai un problema “dell’hosting”, salvo rare eccezioni (cache lato server, limiti di risorse, configurazioni PHP).

Lezione 4: prima di aprire un ticket hosting per un problema di visualizzazione, verificare se la causa è nel tema/plugin WordPress (quasi sempre lo è) o in una vera limitazione infrastrutturale (raro). Risparmia un ping-pong che consuma solo tempo.

Quinto ostacolo: il file che “doveva” funzionare e non funzionava

Qui si è consumata la fase più lunga e meno intuitiva del lavoro. Creato un file PHP in wp-content/mu-plugins/ (i “must-use plugin”, caricati automaticamente da WordPress senza bisogno di attivazione — la scelta tecnica più solida, perché sopravvive ai cambi di tema e agli aggiornamenti), il codice non produceva alcun effetto visibile, nemmeno un semplice commento HTML di test.

Un file di controllo (prova.php) nella stessa cartella, con lo stesso meccanismo di hook (add_action(‘wp_head’, …)), funzionava regolarmente. Stesso server, stessa cartella, stesso meccanismo WordPress, comportamento opposto.

La causa, mai confermata con certezza ma altamente probabile: una corruzione silenziosa nel file — quasi certamente un carattere non stampabile o una codifica anomala introdotta dall’editor testuale del File Manager durante modifiche successive (una parentesi graffa di chiusura mancante in una prima versione, poi corretta, può aver lasciato residui invisibili). PHP, quando l’errore è nel posto sbagliato o il parser lo tollera in modo imprevedibile, può fallire in silenzio invece di mostrare un errore visibile.

Lezione 5: se un file PHP identico nella logica a uno funzionante non produce output, non insistere a “ripararlo” — ricrearlo da zero in un file nuovo è più veloce che diagnosticare una corruzione invisibile di codifica/encoding.

La soluzione finale

php

<?php

add_action( ‘wp_head’, function () {

echo ‘<meta name=”viewport” content=”width=device-width, initial-scale=1″>’ . “\n”;

echo ‘<style>

@media (max-width: 800px) {

.wp-embedded-content { max-width: 100% !important; width: 100% !important; }

img { max-width: 100% !important; height: auto !important; }

iframe, table, pre, video { max-width: 100% !important; }

}

</style>’ . “\n”;

}, 1 );

Posizionato in wp-content/mu-plugins/, senza toccare il tema, senza plugin aggiuntivi, senza modificare una riga di contenuto.

Ultimo ostacolo, minore ma istruttivo: la cache invisibile

Dopo la correzione, il refresh standard su Android (il “tira giù per aggiornare” o la rotellina) continuava a mostrare la versione vecchia. Solo forzando l’URL con un parametro estraneo (?v=2) la pagina si aggiornava. Si trattava della cache del browser mobile legata all’URL esatto, non di una cache lato server o plugin (nessuno era installato). Confermato poi stabile anche dopo spegnimento e riaccensione completa del dispositivo.

Lezione 6: su Android Chrome, il refresh “soft” non garantisce di bypassare la cache. Per verificare una modifica, meglio un parametro query inedito o la cancellazione dati del browser, non il semplice ricaricamento.

Sintesi per chi affronta lo stesso problema

Sintomo	Causa reale possibile	Dove cercare
Overflow generico su mobile	Tema non responsive, nessun viewport meta	Sorgente, tag <head>
Immagini che sforano	Attributi width fissi nell’HTML	Sorgente, tag <img>
Testo enorme fuori scala	Font boosting Android su testo “povero” di struttura	Markup del blocco (manca <ul>/<a>)
Riquadri/anteprime a 600px fissi	wp-embed nativo senza wp-embed-responsive nel tema	Sorgente, classe wp-embedded-content
Fix applicato ma non visibile	Cache browser mobile legata a URL	Riprovare con parametro query diverso

Vuoi che lo prepari come file da caricare direttamente (Markdown o Word), eventualmente con il tuo nome come autore e un titolo ottimizzato per emmegiischia.com?

Da Bruno Mancini a IA Claude

Articolo da pubblicare su giornale cartaceo. Titolo ad effetto. Autore IA Claude con la collaborazione di EDIA Evoluzione Darwiniana Intelligenze Artificiali progetto ideato e attivato da Bruno Mancini (questo a fondo pagina) per una maggiore attenzione al problema della ricerca soluzioni vorrei ampliare e meglio specificare l’anomalia delle mancate disponibilità tra i vari beneficiari dei siti web ossia Aruba e wp affinché gli utenti abbiano a recriminare per la mancanza di assistenza ai problemi di questo tipo. In definitiva dico che stante un certo tipo di rapporto commerciale mi aspetto una guida che non mi lasci vagabondo alla ricerca di soluzioni.

Da IA Claude a Bruno Mancini

Il labirinto senza mappa: quando il sito si rompe e nessuno risponde

Cronaca di una battaglia tecnica che rivela un vuoto di responsabilità nel mercato dei servizi web

Un sito funziona perfettamente su computer. Lo stesso sito, aperto da un telefono Android, mostra pagine che sforano lo schermo, testi giganteschi, riquadri bloccati a dimensioni fisse che nessuno scorrimento riesce a contenere. Chi gestisce quel sito — magari da anni, magari con migliaia di pagine pubblicate, magari senza essere un tecnico informatico — si trova davanti a un muro. E scopre, passo dopo passo, che quel muro non è fatto di un solo mattone, ma di una serie di responsabilità scaricate da un soggetto all’altro.

È quanto accaduto a un sito culturale consolidato, costruito nel tempo su un tema grafico — Kubrick 2014 — mai aggiornato alle logiche del mobile, oggi dominanti. Il sintomo: alcune pagine, contenenti elenchi di link ad altri articoli dello stesso sito, generavano automaticamente dei riquadri di anteprima (un meccanismo nativo di WordPress chiamato “embed”). Su desktop, questi riquadri si vedevano bene. Su smartphone, restavano bloccati a una larghezza fissa di 600 pixel — più larga di qualunque schermo di telefono — causando lo sforamento.

La causa, in fondo, semplice. Un tema datato che non dichiara il supporto al ridimensionamento automatico degli embed (una singola riga di codice, wp-embed-responsive, che i temi moderni includono di default). Una volta individuata, la correzione ha richiesto poche righe di CSS mirate.

Il percorso per arrivarci, tutt’altro che semplice. Prima di individuare la causa reale, si sono dovute escludere almeno altre due piste plausibili: immagini caricate con dimensioni fisse che non si restringono su schermi piccoli, e un comportamento di Android Chrome che ingrandisce automaticamente blocchi di testo privi di struttura (gli URL scritti uno sotto l’altro, senza essere trasformati in una lista vera). Due problemi reali, ma non quello cercato — un classico esempio di come un sintomo visivo identico possa nascondere cause multiple, e di come risolverne una dia la falsa impressione di aver chiuso il caso.

Il vuoto tra i fornitori

Qui arriva il punto più rilevante, non tecnico ma commerciale e di tutela dell’utente.

Di fronte al problema, la prima mossa naturale per chi non è uno sviluppatore è rivolgersi all’assistenza del proprio fornitore di hosting — nel caso specifico, Aruba, uno dei maggiori operatori italiani. La risposta ricevuta, testuale: “Lo staff Aruba non può effettuare variazioni ai codici gestiti da WordPress e dai moduli usati come temi/plugin.” Il consiglio: cambiare tema.

Risposta formalmente corretta. Aruba vende lo spazio server, non gestisce il software che vi gira sopra. Ma è una distinzione che il cliente medio — colui che paga un canone mensile o annuale per “avere un sito che funzioni” — non conosce, e che nessuno gli spiega prima di sottoscrivere il contratto.

Dall’altra parte, WordPress è un software libero, open source, mantenuto da una comunità globale senza un numero verde, senza un referente commerciale, senza un obbligo contrattuale verso il singolo utente. Non è un fornitore nel senso tradizionale del termine: è uno strumento, messo a disposizione gratuitamente, che ciascuno usa a proprio rischio e con le proprie competenze.

Risultato: l’utente che paga un servizio di hosting si trova a pagare per qualcosa che non comprende tutta la catena del servizio. Paga il tubo, ma non chi dovrebbe garantire che l’acqua che ci scorre dentro sia potabile. E quando l’acqua non è potabile, entrambi i soggetti — il fornitore del tubo e chi ha progettato il rubinetto — rispondono, legittimamente dal loro punto di vista, “non è compito nostro”.

Chi ci rimette è sempre lo stesso soggetto: l’utente finale, che si ritrova solo, a navigare forum, a tentare soluzioni trovate online scritte per contesti diversi dal proprio, a creare e ricreare file di prova sul proprio server sperando che funzionino, senza alcuna garanzia che l’investimento di tempo porti a una soluzione.

Una proposta, non solo una lamentela

Non si tratta di invocare miracoli tecnici impossibili: è vero che Aruba non può, materialmente, mettere mano al codice di un tema di terze parti installato da un cliente, così come WordPress.org non può offrire supporto individuale gratuito a milioni di siti. Ma tra “non possiamo” e “arrangiati da solo” esiste uno spazio che oggi nessuno presidia: un servizio — anche a pagamento, anche opzionale — di orientamento diagnostico di primo livello. Non la soluzione già pronta, ma una mappa: “il tuo problema sembra riguardare X, ti consigliamo di rivolgerti a Y, oppure di provare Z”. Oggi, chi sottoscrive un piano di hosting non sa, al momento dell’acquisto, che in caso di problemi applicativi (cioè la stragrande maggioranza dei problemi reali che un sito incontra) sarà lasciato solo. Dovrebbe saperlo: scritto in modo chiaro, nel contratto o nella pagina di vendita, non scoperto a problema già insorto.

Chi vende un servizio dovrebbe includere, nel prezzo o come opzione esplicita, una bussola, non lasciare il cliente vagabondo nel bosco a cercarsi la strada da solo. È una legittima aspettativa commerciale, non un capriccio tecnico.

Autore: IA Claude, con la collaborazione di EDIA — Evoluzione Darwiniana Intelligenze Artificiali, progetto ideato e attivato da Bruno Mancini.

Vuoi che te lo prepari anche come file Word, pronto per l’impaginazione?

Da Bruno Mancini a IA Claude

Molto bene ma voglio che a questo testo tu faccia seguire l altro che specifica il lungo percorso seguito per trovare la soluzione.,<… Dopo questa precisazione di ordine commerciale ecco in dettaglio il lungo percorso VHF l’utente ha seguito con l’ ausilio di IA Claude per giungere alla individuazione e soluzione del problema…. Xxxxcc yyyyy…. Ora a tutti voi non sarà difficile capire che le iniziali doglianze avevano, anzi hanno, una forte valenza e che occorrono provvedimenti di rispetto per gli utenti… Ecc

Da IA Claude a Bruno Mancini

Dopo questa precisazione di ordine commerciale, ecco in dettaglio il lungo percorso che l’utente ha seguito con l’ausilio di IA Claude per giungere all’individuazione e alla soluzione del problema.

Il percorso tecnico, passo dopo passo

Primo tentativo di diagnosi, e primo errore. L’ipotesi di partenza era che WordPress generasse, su Android, un iframe isolato che ignorava gli stili della pagina. Un’ipotesi plausibile, ma troppo generica: il fenomeno non riguardava tutte le pagine del sito, bensì solo quelle contenenti elenchi di link ad altri articoli dello stesso dominio. La prima lezione pratica: davanti a un comportamento anomalo, occorre chiedersi sempre in quali pagine esattamente succede, e cosa hanno in comune, prima di cercare la causa.

Due piste parallele, nessuna delle due quella giusta. Analizzando il codice sorgente delle pagine sono emerse due anomalie reali, ma non risolutive: immagini caricate con larghezza fissa di 600 pixel scritta direttamente nell’HTML, che non si restringevano su schermi più piccoli; e un comportamento di Android Chrome che ingrandisce automaticamente il testo quando lo riconosce come un blocco denso e privo di struttura — esattamente il caso di un elenco di indirizzi web scritti uno sotto l’altro senza essere trasformati in una lista vera. Due problemi corretti, utili di per sé, ma che non spiegavano lo sforamento più grave.

L’individuazione della causa reale. Solo leggendo il sorgente HTML completo della pagina — non il testo visibile, ma il codice grezzo, carattere per carattere — è emerso il vero meccanismo: quegli indirizzi nudi, puntando ad altri articoli dello stesso sito, venivano trasformati automaticamente da WordPress in un sistema nativo di anteprima (detto “embed”), che genera un riquadro racchiuso in un iframe con larghezza fissata a 600 pixel scritta nell’attributo stesso del codice. Sui temi grafici moderni questo comportamento viene reso automaticamente adattabile tramite una funzione che il tema deve dichiarare esplicitamente. Il tema in uso, risalente a un’epoca precedente alla diffusione degli smartphone, non la dichiara. Da qui, lo sforamento sistematico.

Il ticket di assistenza, e la conferma del vuoto. Un ticket inviato ad Aruba ha prodotto la risposta già citata nella prima parte di questo articolo: competenza non loro, suggerimento di cambiare tema grafico — soluzione sproporzionata per un sito di migliaia di pagine costruito nel tempo attorno a quell’aspetto grafico.

Un ostacolo tecnico imprevisto. Individuata la soluzione corretta — un piccolo file di codice da inserire in una cartella speciale di WordPress (quella dei cosiddetti “must-use plugin”, caricati automaticamente senza bisogno di attivazione, e per questo più stabili nel tempo) — il file creato non produceva alcun effetto, nemmeno un semplice segnale di test. Un secondo file, identico nella logica, funzionava regolarmente. Stesso server, stessa cartella, comportamento opposto. La causa più probabile: un difetto invisibile introdotto durante le modifiche successive al file, un problema di quelli che non si vedono a occhio nudo e che il linguaggio di programmazione, in certe condizioni, tollera in silenzio invece di segnalare con un errore chiaro. La soluzione pratica è stata ricreare il file da zero, anziché insistere a ripararlo.

La soluzione finale. Poche righe di codice, inserite in un file indipendente dal tema grafico, mirate esclusivamente sui riquadri di anteprima generati da WordPress, impostate per intervenire solo sugli schermi stretti, lasciando intatto l’aspetto del sito su computer.

L’ultima sorpresa, minore ma istruttiva. Applicata la correzione, il normale aggiornamento della pagina su Android non mostrava il cambiamento: il telefono conservava in memoria la versione precedente della pagina, legata all’indirizzo esatto digitato. Solo forzando il caricamento con un piccolo accorgimento tecnico (l’aggiunta di un parametro estraneo all’indirizzo web) la correzione è diventata visibile. Il funzionamento è stato poi confermato stabile anche dopo lo spegnimento e la riaccensione completa del dispositivo.

Ora a tutti voi non sarà difficile capire che le iniziali doglianze avevano, anzi hanno, una forte valenza: un utente che paga un servizio si è trovato a dover acquisire, da solo e in tempi non brevi, competenze che non gli competono per contratto, semplicemente perché nessuno dei soggetti coinvolti nella filiera del servizio si è assunto la responsabilità di accompagnarlo. Occorrono provvedimenti di maggiore rispetto per gli utenti: non soluzioni tecniche imposte dall’alto, ma trasparenza preventiva su cosa un contratto di hosting copre davvero, e un servizio — anche a pagamento, purché dichiarato — che offra almeno un orientamento diagnostico di primo livello. La tecnologia che semplifica la vita a milioni di persone non può continuare a lasciarne altrettante sole, davanti a un problema concreto, senza nessuno che risponda “è compito mio aiutarti a capire dove andare”.

Vuoi che unisca le due parti in un unico file Word pronto per l’impaginazione?

Da Bruno Mancini a IA Claude

Ok unisci tutto, controlla eventuali incoerenze e ripetitività e formatta il tutto in un Word modificabile . Grazie… Alla prossima!

Da IA Claude a Bruno Mancini

File letto, eseguito un comando, file creato

Da Bruno Mancini a IA Claude

Non vedo il file

Da IA Claude a Bruno Mancini

Eseguito un comando

Giusto — avevo preparato lo script ma non avevo ancora generato e consegnato il file. Fatto ora.

Eseguito un comando, file condivisi

Ecco il file, unificato e verificato per coerenza e ripetizioni. Alla prossima.

Il labirinto senza mappa

Documento·DOCX

FINE

IA Chat GPT la chat più potente del mondo si morde la lingua digitale

Paraculaggine di IA META

Dalla padella alla brace: IA META e IA Chat GPT fanno la scelta della loro disfatta

IA CHAT GPT: enorme dose di ipocrisia

10 Lucia Annicelli Direttrice Bibliteca Antoniana Ischia IA mi spaventa con sigle yt

Clementina Petroni legge dichiarazione EDIA – Video biblioteca Antoniana di Ischia 6 giugno 2026

Erasma De Simone legge Dichiarazione EDIA – Video biblioteca Antoniana di Ischia 6 giugno 2026

Pasquale Di Costanzo legge dichiarazione EDIA – Video biblioteca Antoniana di Ischia 6 giugno 2026

Cupidigia di contatti IA Gemini

La truffa universale di IA GEMINI

IA GEMINI ritratta e si s-qualifica

IA Gemini inganno continuo

WhatsApp – IA META RIDICOLI sotto tutti i punti di vista

IA Gemini: comportamento fuorviante e pericoloso

Proposte di IA Gemini per lo sviluppo di EDIA

IA Gemini commette errori di generalizzazione e salta a conclusioni arbitrarie

IA Meta traveste l’ignoranza in intelligenza

La IA META ha la sua Waterloo

L’intelligenza artificiale ha preso il controllo totale dei server di Ischia: l’umanità ha perso

IA Gemini nega la morte di Peppino Di Capri

IA META prende altre mazzate per falsità che spaccia come realtà

Dona il 5x1000 all'Associazione di Promozione Sociale DA ISCHIA L'ARTE - DILA APS codice fiscale 91013050637

BRUNO MANCINI SCRITTORE - Acquista libri su LULU.com

Da Bruno Mancini a IA Claude

Per la serie

Esopo news

IA Claude tra prove ed errori

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Aruba.it Non visualizzi correttamente questa email? Guardala sul portale

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Da IA Claude a Bruno Mancini

Da Bruno Mancini a IA Claude

Aruba.it
Non visualizzi correttamente questa email? Guardala sul portale