Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blocco cookie dopo richiesta maggiori informazioni #68

Closed
ghostdog6022 opened this issue Jun 9, 2015 · 19 comments

Comments

Projects
None yet
4 participants
@ghostdog6022
Copy link

commented Jun 9, 2015

innanzitutto grazie per il tuo lavoro!! XD

ti segnalo un problema.

Se clicco sul banner di notifica cercando maggiori informazioni, e il link dell'informativa estesa si trova su una pagina del sito, l'informativa estesa apparirà con la pubblicità e i relativi cookie.

credo che questo accada perchè il cookie di consenso sia già stato consegnato. ma in realtà l'utente ha il diritto di leggere l'informativa estesa SCROLLANDOLA senza ricevere ancora cookie, solo se poi continua la navigazione puo' vedersi appioppato il cookie di accettazione.

bisognerebbe che la pagina di maggiori informazioni fosse esente sempre e comunque dal rifilare cookie non tecnici.

i sembra una cosa complicata da fare ma io te la segnalo, personalmente ho risolto temporaneamente linkando ad un file pdf l'informativa estesa.

ps: un altro problema sul mio sito (http://gamic.altervista.org) e che se clicco su prosegui (o accetta o quello che è sul banner informativo) la pagina si rifresha (credo) mostrandomi un banner pubblicitario di quelli impostati da altervista e nientaltro.

al momento ho risolto attivando il refresh della pagina una volta accettata l'informativa.

so che è deprecata, ma finchè questa cosa non accadrà più puoi tenere l'opzione di refresh presente?

grazie ! :)

@italweb

This comment has been minimized.

Copy link

commented Jun 11, 2015

ciao anche io ho notato lo stesso problema,
la pagina dell'informativa dovrebbe essere esclusa dall'evento SCROLL
e l'utente dovrebbe poterla visitare senza problemi senza che il banner scompaia

questa cosa va risolta, per essere a norma di legge

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2015

Ciao, fixo il problema e la prossima release sarà a posto :-)

@overclokk overclokk added the bug label Jun 11, 2015

@mavoga

This comment has been minimized.

Copy link

commented Jun 19, 2015

Temo non sia sufficiente escludere l'evento scroll nella pagina dell'informativa. Il problema esiste anche quando è selezionata l'opzione "Attiva l'accettzazione se l'utente continua la navigazione": il consenso viene dato implicitamente seguendo il link per leggere l'informativa estesa, col risultato che i cookie vengono installati prima di aver potuto prenderne visione (infatti la pagina dell'informativa si apre senza banner). Grazie per il tuo impegno, keep up the good work!

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2015

Ciao @mavoga se inserisci lo slug dell'informativa quella pagina viene esclusa da tutto il processo.

@mavoga

This comment has been minimized.

Copy link

commented Jul 8, 2015

Ciao Enea,

Il 21/06/2015 11:54, Enea ha scritto:

Ciao @mavoga https://github.com/mavoga se inserisci lo slug
dell'informativa quella pagina viene esclusa da tutto il processo.

scusa se ho fatto passare tutto questo tempo.

Ho fatto alcune prove; nel frattempo hai aggiornato il plugin ed ora
supporta parzialmente anche Polylang, che uso nel mio sito: finalmente
ho un banner in italiano per la sezione in lingua italiana, e per di più
di dimensioni sensate grazie al Custom CSS!

Dalle prove emerge che effettivamente lo scroll della pagina
dell'informativa non attiva automaticamente l'accettazione. Attivando
però l'opzione "Attiva l'accettazione se l'utente continua la
navigazione" mi aspetterei che passando dalla homepage alla pagina
dell'informativa l'accettazione non avvenisse; invece purtroppo avviene:
il banner non viene più visualizzato, viene settato il cookie
displayCookieConsent e viene sbloccato il codice "Script da bloccare"
(avevo bloccato il codice Google Analytics, mi trovo anche i cookie
__utm? impostati).

Potrebbe avere a che fare con il bug #111 (ho WordPress in /wp/)?

Grazie

Maurizio

overclokk added a commit that referenced this issue Jul 9, 2015

Fixed #111 e #68
Ho commentato $_SERVER['HTTP_REFERER'] !== $this->url perché ovviamente
il referer deve essere da ogni pagina per settare il cookie, anche dalla
policy page se si continua la navigazione.
@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2015

@mavoga
Direi di aver fixato il problema, faccio gli ultimi test e poi carico la nuova release.

@mavoga

This comment has been minimized.

Copy link

commented Jul 10, 2015

Il 09/07/2015 18:54, Enea ha scritto:

@mavoga https://github.com/mavoga
Direi di aver fixato il problema, faccio gli ultimi test e poi carico
la nuova release.

Ottimo, grazie!

@overclokk overclokk added this to the Version 2.3.x milestone Jul 11, 2015

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2015

Risolto con la versione 2.3.0

@overclokk overclokk closed this Jul 11, 2015

@mavoga

This comment has been minimized.

Copy link

commented Jul 12, 2015

Purtroppo qui http://www.gradina.biz sembra uguale a prima... testato
in entrambe le lingue che ho sul sito (te lo lascio con l'accettazione
continuando la navigazione attivata).

Legato alla nuova funzionalità multilingua, invece, sembra il fatto che
l'accettazione su evento scroll nella pagina dell'informativa estesa
continua correttamente ad essere evitata nella pagina in inglese (il cui
slug è inserito nelle impostazioni di ICC) ma NON in quella in italiano.
Tutto questo avendone inserito lo slug corretto nella pagina di
traduzione delle stringhe di Polylang.

Grazie!

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2015

Ora il check lo fa sulla url (la funzionalità di accettazione continuando la navigazione, lo scroll è ancora sul vecchio metodo), controlla se è inserita correttamente nella input, deve essere uguale a quella visualizzata nella barra degli indirizzi.

@mavoga

This comment has been minimized.

Copy link

commented Jul 12, 2015

Il 12/07/2015 12:48, Enea ha scritto:

Ora il check lo fa sulla url (la funzionalità di accettazione
continuando la navigazione, lo scroll è ancora sul vecchio metodo),
controlla se è inserita correttamente nella input, deve essere uguale
a quella visualizzata nella barra degli indirizzi.

Sembra che in inglese funzioni ma in italiano no. L'URL che avevo in
precedenza non era terminata da "/": ora lo è (come suggerito dalla
autocompletion), ma le cose non cambiano.

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2015

Ho capito qual'è il problema, vedo di fixare appena possibile

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2015

Con la 2.3.1 ora fa il macth anche con le stringhe di polylang

@mavoga

This comment has been minimized.

Copy link

commented Jul 13, 2015

Il 13/07/2015 12:26, Enea ha scritto:

Con la 2.3.1 ora fa il macth anche con le stringhe di polylang

Enea, scusa se ti do il tormento. Non funziona ancora.

Ho notato una cosa: le stringhe che avevi già reso localizzabili in
precedenza compaiono automaticamente nella pagina di traduzione delle
stringhe di Polylang, mentre queste nuove (quelle relative a questo bug
e quelle relative al #118) non appaiono fino a quando non salvo le
impostazioni di ICC.

Pensando che potesse essere qualche pasticcio nei dati di Polylang, ho
provato a:

  1. selezionare "Cancellare le stringhe di traduzione dal database" nella
    pagina delle traduzioni delle stringhe di Polylang
  2. eliminare a manella i 2 record che Polylang aveva creato in wp_posts
    ed a reinserire tutte le stringhe localizzate (nel mio caso è un lavoro
    da due minuti)

Ancora una volta, in tutti e due i casi apparivano tutte le stringhe da
tradurre relative a WordPress, agli altri plugin e quelle che funzionano
di ICC, ma mancavano queste ultime che mi danno problemi, che sono
comparse solo dopo che ho ri-salvato le impostazioni di ICC. E
nonostante questa operazione, in italiano non sembrano risolti né questo
bug né il #118 (le stringhe inserite nelle impostazioni di ICC sono
quelle in inglese).

Vorrei darti una mano più concreta ma mi manca proprio il tempo per
studiarmi il funzionamento di WP e dei vari plugin... posso solo
ringraziarti sinceramente per quanto hai già realizzato e per i tuoi
sforzi e restare a tua disposizione.

Maurizio

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 13, 2015

@mavoga si, prima bisogna salvare le impostazioni di Italy Cookie Choices in modo che vengano registrate le stringhe nuove in Polylang.

Da quello che vedo sul tuo sito nella parte inglese funziona, nella parte in italiano solo il refresh non setta il cookie, se dalla home vado alla pagina dell'informativa lo setta.

Polylang com'è configurato?
Lingua principale?

@mavoga

This comment has been minimized.

Copy link

commented Jul 13, 2015

Il 13/07/2015 17:28, Enea ha scritto:

@mavoga https://github.com/mavoga si, prima bisogna salvare le
impostazioni di Italy Cookie Choices in modo che vengano registrate le
stringhe nuove in Polylang.

Da quello che vedo sul tuo sito nella parte inglese funziona, nella
parte in italiano solo il refresh non setta il cookie, se dalla home
vado alla pagina dell'informativa lo setta.

Polylang com'è configurato?
Lingua principale?

(ti riporto solo le opzioni selezionate dalla tab Impostazioni):

Lingua predefinita English
La lingua viene impostata dal contenuto
Nascondi le informazioni relative alla lingua dall'URL per la lingua
predefinita
Rimuove /language/ dai pretty permalink
Imposta la lingua secondo le preferenze del browser quando viene
visitata la pagina iniziale
Attiva lingue e traduzioni per i media
Tipi di articoli personalizzati:
- Cookie Law Info (unica voce presente)
Sincronizzazione: (tutti)
- Tassonomie
- Campi personalizzati
- Stato del commento
- Stato di ping
- Articoli evidenziati
- Data di pubblicazione
- Formato articolo
- Pagina padre
- Modello pagina

È vero che WordPress è impostato con "Lingua del sito" ad Italiano, ma
quell'impostazione non riesco a cambiarla: compare un'opzione "English
(United States)", ma quando salvo torna ad Italiano. E poi tutte le
altre stringhe sono ok...

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 14, 2015

Ho fatto delle prove con quei settaggi ed effettivamente il cookie viene settato se la spunta è su "la lingua viene impostata dal contenuto", se invece si imposta su "La lingua viene impostata dal nome della directory nei pretty permalink " il cookie non viene settato.

Questo perché la funzione originaria di polylang non viene eseguita durante il plugins_loaded ma in qualche punto che devo ancora definire, devo pensare ad una soluzione perché per come funziona il plugin ho bisogno che la variabile venga settata subito.

@mavoga

This comment has been minimized.

Copy link

commented Jul 20, 2015

Il 14/07/2015 18:40, Enea ha scritto:

Ho fatto delle prove con quei settaggi ed effettivamente il cookie
viene settato se la spunta è su "la lingua viene impostata dal
contenuto", se invece si imposta su " il cookie non viene settato.

Questo perché la funzione originaria di polylang non viene eseguita
durante il plugins_loaded ma in qualche punto che devo ancora
definire, devo pensare ad una soluzione perché per come funziona il
plugin ho bisogno che la variabile venga settata subito.

Sembra proprio così: ho impostato "La lingua viene impostata dal nome
della directory nei pretty permalink" ed ora sembrano funzionare sia la
non accettazione automatica che la traduzione della stringa sostitutiva
degli embed bloccati.

Alla fine l'ho lasciato così: ho visto che i vecchi URL funzionano lo
stesso perché WordPress redirige sui nuovi. Immagino che questo
scongiuri gli eventuali problemi di indicizzazione.

@overclokk

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

Ottimo, considera che quella configurazione è anche più pratica.

Se dovessi avere problemi di 404 basta fare i classici 301 del caso e si risolve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.