@juanin Stavo per fare un post anche io su questa cosa

Qua in versione intera.

Da quanto ne so è sicuramente fattibile far pagare i contenuti, come è lecito riempirci di pubblicità per monetizzare.
Però il GDRP mi pare vieti di chiedere un consenso per la profilazione come condizione di accesso ai contenuti. O sbaglio?
Che mettano pure il paywall, ma sta cosa in un cookie wall è criminale.

Tra l'altro è un update che hanno messo non più di alcuni giorni fa. Cioè noi stiamo dietro a fatti come quelli del trasferimento dei dati in US, e questi liberamente fan così? MAH!

E sto vedendo una marea di cookie wall con il tasto di rifiuto temporizzato, la x o il "chiudi senza accettare" che viene mostrato dopo oltre 15 secondi.
Altri che al posto del Rifiuta, mettono il "personalizza" e devi cliccare prima su "deseleziona tutti" e poi su "salva la tua scelta". Pazzesco.

Grazie ragazzi!

@juanin con debugview ho visto che in effetti funziona e vedo i dati, ho approfondito il controllo e ho visto che i report ha iniziato a compilarli correttamente con i vari eventi!
@RAW controllato per bene sia api measurement che id, tutto perfetto ora!

La cosa strana è che resta la notifica sulla configurazione che lo stream non riceve dati, ma invece li riceve...

Bug di GA4, o è infastidito dal fatto che non li riceve dal "suo" di script?

Ciao ragazzi, sto testando anche io questa soluzione.

Prima di tutto chiedo: la presenza contemporanea di un GTM server side che inietta altri script, pregiudica il funzionamento del vostro script per GA4?

Lo sto testando (prima della chiusura del body come da indicazioni, su un prestashop, dominio di terzo livello) e lo stream su GA4 non riceve dati.
Lo stesso stream invece se lo uso nella proceduta GTM Server Side con Stape.io, funziona correttamente. Sono già passate le famose 48 ore

Il file ibriditics viene richiesto correttamente con il preflight e viene avviato correttamente, e sembra generare il payload ed i cookies

Cosa potrebbe essere che impedisce la ricezione dei dati?
Va messo sia ID che API Measurement per far funzionare il tutto o basta l'ID? (G-xxxxxx)
E' meglio mettere lo script prima della chiusura dell'head invece?

@infermieri-attivi Esatto, c'era un problema con la 4.2.0 (se si aggiornava da versioni 4.x troppo vecchie) e quindi oggi hanno rilasciato la 4.2.1

Aggiornamento: il problema sta accadendo su un altro merchant di un brand "fratello" di quello con problemi (stessa categoria merceologica)

Anche se l'assistenza di Google nega, comincio a maturare l'idea che il problema possa essere dovuto al fatto che principalmente esiste solo il bonifico bancario anticipato come metodi di pagamento...

Ciao @secap59
dipende come lo "installi", in ogni caso è cosa ovvia e necessaria fare un backup della vecchia installazione, sia i file, sia il database.

Se installi (scompattandolo prima) Joomla nello stesso spazio del tuo vecchio sito farai un bel "cocktail" di files, che eviterei.
Se vuoi lavorare per bene sul nuovo sito, tenendo online il vecchio, ti basta installare Joomla in una sottocartella (tipo https://www.sitodisecap59.it/joomla4/). Quando tutto sarà pronto, lo sposti nella cartella principale con poche regolazioni, avendo preventivamente backuppato il vecchio e svuotato la cartella principale.

Il caro vecchio #Joomla 3 si avvicina al pensionamento.
Dopo ben 10 anni di vita, è uscito a settembre 2012, si è arrivati alla "Security Support Phase".

Che cosa vuol dire?
Che Joomla 3.10.x, dal 16 Agosto 2022, non sarà più seguito dal lato sviluppo per nuove implementazioni, migliramenti delle features, ecc. ma sarà solo supportato per garantirne la sicurezza.

Quindi dopo questa estate Joomla 3 riceverà solo patch di sicurezza fino alla data di #EOL (fine vita) che è stata programmata per il 17 Agosto 2023, a 2 anni dal rilascio di Joomla 3.10.

Questo è un chiaro invito a prepararsi alla "mini-migrazione" a Joomla 4.x, la nuova versione fiammante del #CMS open source.
Ad oggi la migrazione alla versione 4 è facile ed indolore in quasi tutti i casi, ed ormai sono disponibili oltre 4000 estensioni compatibili.

Potete approfondire il tema anche con questo articolo pubblicato su Joomla.org
https://magazine.joomla.org/all-issues/may-2022/joomla-3-10-enters-the-security-support-phase

@juanin ha detto in Dashboard basica con canali e obiettivi da Matomo a Data Studio:

@kal a sto punto installate metabase e puoi pure liberarti di Data Studio.

Su Metabase ho letto che è basato su JAVA e mi è venuto male.
Vale la pena però?

@kal eh magari, non è possibile, è un cliente particolare (HQ esterno, 4/5 agenzie IT e Digital che collaborano).
Si fa prima a non usare shopping, davvero
Sarebbe solo un "test" interno che ci dovremmo sobbarcare, se il sito fosse un nostro prodotto ovviamente ci si potrebbe pensare. Però creare account con questa logica è quello che Google vieta più di tutto, se provassimo a collegarlo all'ADS con tutti i dati e poi ci chiudessero anche l'ADS sarebbe un danno enorme.

Per ora stiamo cercando di dare ai DEV le più corrette indicazioni su aspetti tecnici di quel sito, è in Angular e sembra non sia implementato così bene il SSR, quindi qualche "bot" di Google potrebbe in effetti inciampare!

@fabioantichi l'assistenza ha letteralmente mollato, riporto il tono giusto per capire la "loro" delusione.
Notare che la nostra richiesta era almeno di capire "cosa" blocca la validazione.

Ho provato e scalato il caso a tutti i livelli possibili ma non ho altri strumenti o informazioni aggiuntive.
L'unico strumento a disposizione è il Richiedi una revisione dal Merchant che puoi ancora utilizzare.
Per quanto riguarda la mia procedura interna, per quanto voglia esserti d'aiuto, non posso fare altro.
Cordialmente
xxxxxx

Pazzesco!

Grazie @fabioantichi! Diciamo che buona parte, quella applicabile, che c'è nella tua utilissima guida è rispettata.

Sicuramente farò fare un approfondimento, il fatto è che questo store è identico in altre 6 country e a quanto pare, anche senza ulteriori modifiche che abbiamo fatto fare per adeguarci maggiormente alle policy legali italiane, qualcuna sembra sia collegata al Merchant senza problemi. Misteri!

Ciao @infermieri-attivi,
se gestisci gli appositi redirect 301 (anche con delle semplici regole di rewrite nell'htaccess) l'impatto sarebbe davvero minimo, o perlomeno vedresti solo un calo temporaneo. Google comunque dovrà reindicizzare, ma in SERP le vecchie URL che restano comunque non porterebbero a dei 404.

Anche io preferisco non avere quell'ID nell'URL, però se la tua situazione a livello SEO è valida (ho capito che sito è, ed il traffico mi sa che è elevato), io non andrei a toccare le url.

Se invece è un progetto agli inizi puoi toglierli senza troppi timori, ma sempre predisponendo dei redirect!

Ciao a tutti,
stiamo combattendo per un cliente contro Google che per qualche "mistero" non ci vuole approvare un account Google Merchant a causa della "Rappresentazione ingannevole" di "qualcosa" nel sito.

Abbiamo anche sentito ovviamente l'assistenza e il caso è in gestione, anzi, a quanto ci dice il supporto Google, hanno fatto pure un'escalation interna del caso.
Il consulente del supporto Google davvero non sa dove sbattere la testa.

Il problema è che anche il supporto "umano", navigando il sito collegato al Merchant, non rileva problematiche di nessun tipi, tantomeno di "rappresentazione ingannevole" (le norme qua: https://support.google.com/merchants/answer/6150127?hl=it)

Il sito ha prodotti prettamente B2B, ma la vendita è aperta anche al B2C, i prezzi sono mostrati sia ivati sia solo imponibile. Non ci sono promozioni o Call to action "ingannevoli".
Termini, privacy, faq varie, ecc, sembra tutto in ordine.

Una cosa che internamente temiamo è la tecnologia del sito, di cui non abbiamo il controllo. Si dovrebbe trattare del Lightrange di SAP: un ecommerce con rendering JS, di quelli che si vede l'intero html della pagina solo quando "generata" (quindi con i DevTools di Chrome) e non con il "Visualizza sorgente pagina".

Ci chiedevamo anche, cosa che secondo il consulente Google però non inficia, se possono essere le foto dei prodotti ("mezzi" da magazzino) ma sono comunque degli ottimi rendering o delle belle foto scontornate pure bene.

Es. particolare rendering:

Es. particolare foto scontornata:

L'ultima cosa che temiamo è un claim del tipo "la nostra azienda ha 50 linee di prodotto" e poi nello shop ne vendono solo 10.

Se qualcuno ci è già passato, secondo voi questi fattori anche "tecnici" possono inficiare sulla sospensione? Tipo il bot che si incaglia sul rendering della pagina o fattori simili?

Grazie davvero per ogni spunto!

Caso chiuso?
https://blog.google/outreach-initiatives/public-policy/trans-atlantic-data-privacy-framework-building-long-term/

In fase di prova, vorrei farli più che comprarli.
Ma alla fine, ci vorrei solo speculare
(e scusate ma non ho letto tutto il "flame" precedente).

Ciao @valerianerieneri.
Ma che page builder? Se è SPPB assicurati che sia aggiornato.
Inoltre inserire un Feed da Instragram non è più semplice come una volta, ci sono molte più restrizioni.

Eventualmente prova a seguire questa guida.

Ci sono plugin più semplici, ma è molto probabile che tutta la trafila su FB/IG sia sempre da fare.
È proprio un limite di Instagram.

Si risolverebbe tutto con:

• iscrizione a YT con nome e cognome reali visualizzabili per evitare profili fake o bombing vari (la gente vedi come se la fa sotto se alla critica è abbinato il suo nome).
• pubblicazione in chiaro di chi ha messo "mi piace" e "non mi piace" (tipo facebook).

Sono un po' stanco di tutto questa omertà e hiding mascherati da "privacy". Scomparirebbe rapidamente tutta la feccia e tutti gli haters.

Per me resta un errore togliere i dislike, o se lo fanno deve esserci a monte un fortissimo e durissimo organo di controllo che elimini qualsiasi video che faccia riferimento ad argomenti sensibili in modo sensazionalistico, con un doveroso fact-checking (disinformazione, terrorismo, bullismo, ecc.)
Questo perché ci sta che il pubblico gradisca o meno un contenuto. Da sempre esistono applausi e fischi.

Ma questa è solo utopia.

@infermieri-attivi ha detto in Joomla 3.9.27 e Joomla 4.0 bloccheranno di default FLoC:

Questo potrebbe consentire di fare comparire su un sito pubblicità più pertinente e quindi più entrate.

In questo caso sarebbe comunque il contrario. Un gruppo è sempre meno preciso di un singolo.
Il problema è che di base si vuole che l'utente sia ben coperto dalla privacy, che va sicuramente contro i cookie dei circuiti pubblicitari. Io non ho una chiara posizione in merito, ma il metodo di Google (FLoC resta un esperimento e sembra già morto) continuava a non andare incontro alle sempre più richieste esigenze di privacy.

Yes, già bella attiva!

Nel post di benvenuto a Joomla 4 abbiamo visto quali sono stati i maggiori cambiamenti e le novità che l'utente può trovare e usare.

Ma cosa è davvero cambiato "dentro" Joomla 4? Solo funzionalità ed estetica... o c'è molto di più?

Ebbene i cambiamenti sotto il cofano sono davvero molti e molto dei quali comprensibili solo dagli sviluppatori: ma la cosa interessante è che frutto di questi cambiamenti sono la velocità del CMS e la sua "gestibilità".

Il team di Joomla ha cercato quindi di includere nel progetto le più recenti versioni e tecnologie come ad esempio:

• Bootstrap 5
• jQuery 3
• PHPMailer 6.0
• Vue.js (per il Media Manager)
• SASS

PHP

Tutta la codebase di Joomla derivante dalla versione 3.x è stata pulita e "modernizzata":

• È stato innalzato il requisito minimo di PHP alla 7.2 ed è già supportato PHP 8.
• Tutto il PHP è stato riscritto con codice Namespaced,
• Per aumentare le prestazioni il "Jfactory" è stato sostituito dai "Dependency Injection Containers"
• Joomla (da sempre) è un vero e proprio framework (al contrario di altri famosi CMS) le cui parti compongo quello che era il CMS che utilizzavamo: con Joomla 4.0 il framework è stato completamente fuso all'interno, quindi completamente usato per le funzionalità del core, evitando poco performanti e fastidiose "personalizzazioni" o disallineamenti di codice tra Framework e necessità del CMS. Questo aumenta performance e manutenibilità.
• È stato rimosso tutto il codice deprecato in Joomla 3.x, oltre 1000 classi!
• Ora è richiesta l'estensione PHP GMP se si vuole usare l'innovativa autenticazione WebAuthn Passwordless Login
• È richiesta l'estensione PHP mcrypt, per consentire l'uso della classe Joomla\CMS\Crypt\Cipher\CrytoCipher: a seguito di questo sono stati eliminati tutti i sistemi cifrati più deboli: JCryptCipher3Des, JCryptCipherBlowfish, JCryptCipherMcrypt, JCryptCipherRijndael256, JCryptCipherSimple
• Migliorato drasticamente il sistema di Event Dispatching: ora è possibile leggere, generare e configurare qualsiasi tipo di evento, aumentando drasticamente la facilità di sviluppo di nuove funzioni grazie alla possibilità di far "comunicare" velocemente tra loro tutti i "pezzi" del CMS.
• Migliorata ed espansa la Command Line Interface (CLI), ora si può davvero fare "tutto" da linea di comando
  
  PS: a cosa serve una CLI per un CMS? Usando i comandi CLI, con pochi minuti di "focus" sulla programmazione e pochi secondi di esecuzione, si possono fare script ripetibili e automatizzabili all'infinito per effettuare qualsiasi operazione su centinaia di installazioni, dai backup, agli update, ai test, ecc, ecc.

Database & MySql

Anche in questo caso è stata fatta molta "pulizia".

• E' stato implementato l'uso dei Prepared SQL Statement per migliorare sicurezza e manutenibilità
• È stata abilitata la "Strict Mode" che aiuterà i devs con i futuri aggiornamenti della versione di MySQL, allineandosi ancora di più anche con PostgreSQL per consentire una più facile compatibilità con le query in entrambi i linguaggi.
• Rimosso il supporto al driver ext/MySQL di PHP (che è stato rimosso in PHP 7.0), quindi il CMS cercherà automaticamente di usare l'estensione MySQLi (disponibile da PHP 5.3) o il driver PDO MySQL (disponibile da PHP 5.3).
• Rimosso il supporto al driver ext/pgsql di PHP e cercherà automaticamente di usare il driver PDO di PostgreSQL (disponibile da PHP 5.3 e Joomla 3.9).
• Dopo attenta analisi sulle statistiche di utilizzo in questi anni, è stato rimosso anche il supporto a SQL Server.

Ad oggi quindi i requisiti minimi per il database sono:

• MySQL 5.6
• PostgreSQL 11.0

Javascript

Sempre più impattante per la gestione non solo della UI ma anche di diverse funzioni del core, vediamo che il vecchio framework Mootools è definitivamente scomparso e il core di Joomla non ha più nulla di basato su Jquery.
Tutto il Javascript "necessario" ora è "vanilla" e segue la sintassi ECMAScript 6+ (ES 2015+), seguendo l'ottima coding style guide di Airbnb, con evidenti risultati di leggerezza, velocità di esecuzione, manutenibilità e pulizia del codice.
È comunque disponibile l'uso di Jquery 3.x.

Bootstrap 5

In Joomla ci sono diverse interfacce grafiche, prima fra tutte quella del Backend di Amministrazione.
Per uniformare l'estetica e dare agli sviluppatori un framework che permettesse di sviluppare velocemente le UI, è stato scelto (dopo una fase di Alpha con BS4) il nuovissimo ed appena rilasciato stabile Bootstrap 5.
Perchè? Perché è innovativo, è molto leggero e soprattutto non dipende più da altri framework Javascript come Jquery, anch'esso quindi rispetta il core "pulito" di Joomla4 è ed tutto sviluppato in JS vanilla.
Bootstrap 5 inoltre è predisposto nativamente al supporto di tutte le lingue RtL e LtR, alle icone SVG (al posto delle orribili font icons) e resta super leggero rimuovendo il supporto a IE10/11. Con BS5 si possono usare facilmente quindi anche componenti React e Vue.js.

Miglioramenti al layer MVC

Ora i componenti, i moduli e i plugin di Joomla! saranno usati solo per implementare le proprie funzioni peculiari, mentre tutte le funzionalità base saranno fornite dal sistema. Un "Command bus" potrà essere usato dagli sviluppatori per semplificare il proprio codice. In questo modo Joomla! 4 limita lo sforzo degli sviluppatori consentendo molta più stabilità e "aggiornabilità" al CMS.

[Post in aggiornamento]