Toolbar, dopo aggiornamento a ipb4 non si vede più.

Salve gente, come va? :)
Come da oggetto, ho aggiornato il mio sito a invision4, e mi é scomparsa la toolbar.
Toolbar presente però se creo una semplice pagina html di test, quindi correttamente attivata.
Chiedo a coi per capire da cosa potrebbe dipendere... Il body c'è, la struttura è valida, tutto sembra corretto affinché la toolbar funzioni, invece - semplicemente - non funziona.
Pensavo ad eventuale compressione delle pagine, ma sul pannello di ipb, al momento, non trovo niente al riguardo.

Idee e/o consigli sono ben accetti ;)

Se effettuo la richiesta HTTP omettendo l'header Accept-Encoding la toolbar viene inettata correttamente, quindi credo proprio che IPB stia comprimendo da sé le pagine. Cercando ho trovato solo una vecchia discussione del 2010, controlla un po'.

Grazie Karl... Io, da mobile, non avevo modo di fare tale test!
Ora cerco di capire se si riesce a disabilitare la compressione... AV, da parte sua, non ha qualche modo di forzare la cosa?
-
Via htaccess, magari... Se si riuscisse a disabilitare la compressione sarebbe ok!

Il problema è la compressione lato applicativo e devi proprio cercarlo nelle impostazioni.

Non riesco proprio a trovare niente, purtroppo :/
Chiedo al supporto ipclients, vediamo che dicono ;)

Niente... Ho spiegato che AV ospita taaaanti siti con tanti diversi cms (wordpress, phpbb, joomla, drupal ecc) e che anche da me, con wordpress, smf, ipb3 é sembre stato tutto ok - ed è ancora ok con html statico, ad esempio. Ma loro dicono che non c'è nulla di strano parte ipb4, e che la compressione è lato server, e dunque il problema è nel server, non nell'applicativo.
Insomma, secondo loro é tutto ok :/
Io ho cercato un po' all'interno dello script, ma non riesco a venirne a capo (ipb4 é appena nato - magari a breve noteranno la cosa e verrà risolta, non so).

Ho fatto qualche prova e effettivamente il problema si manifesta solo quando la risposta è compressa. Per me rimane una compressione lato applicativo abilitata.

Ok, trovata la parte di codice incriminata, e toolbar apparsa!
Segnalata la cosa al supporto ipb (era sul file output.php) ;)
-

Codice:

---

/* If the browser supports gzip, gzip the content - we do this ourselves so that we can send Content-Length even with mod_gzip */
                if ( isset( $_SERVER['HTTP_ACCEPT_ENCODING'] ) and \strpos( $_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip' ) !== false )
                {
                        if ( function_exists( 'gzencode' ) and (bool) ini_get('zlib.output_compression') === false )
                        {
                                $output = gzencode( $output ); // mod_gzip will encode pages, but we want to encode ourselves so that Content-Length is correct
                                $this->sendHeader("Content-Encoding: gzip"); // Tells the server we've alredy encoded so it doesn't need to
                        }
                }

---

commentato l'intero blocco :)
-
nel codice, comunque, se leggo bene, pare che si tratti di una incomprensione col server :P

-

Dopo lunghe ed estenuanti discussioni impossibili con il supporto ipb, vi comunico solo che - pur avendo risolto il problema con quel fix, e considerando che la cosa si verifica solo con ipb4 (né con altri script/cms, né con ipb3) - loro continuano a dire che quel codice interroga il server chiedendo se supporta gzip, e se il server dice sì allora passa l'header in gzip. Dunque, per farla breve, se poi ci sono problemi il problema è del server, non dell'applicativo (quindi mi consigliavano di cambiare server, io li ho mandati educatamente a cagher dicendo loro che forse dovrei cambiare applicativo). Io, sinceramente, sarà che non sono un asso con l'inglese, ma proprio non riesco a convincerli. Sono de coccio. Nun ce la fo a convincerli a piazzare una riga di codice dentro all'init per abilitare/disabilitare il gzip (stile joomla, ad esempio), in caso di necessità (tipo questo)... Scusatemi - mi arrendo.

@Saitfainder: Scusami, ma ripensavo a questa discussione e mi chiedevo se, magari, in effetti, non avessero un po' ragione quelli di ipb (non sulla storia del cambio server, non ci penso affatto :D) su questa cosa della compressione gzip.

Cioè, anche quel pezzo di codice, se non erro, chiede al server se "supporta gzip", e se il server risponde sì ecco che... Beh, la toolbar non va :P
Dunque, ecco, non sarebbe meglio cambiare la risposta lato server (almeno in caso di toolbar abilitata) o sistemare la toolbar affinché supporti la compressione (se tecnicamente possibile)?! :)

Chiedo soltanto eh... Giusto per provare a capire se esiste il problema (suppongo non solo con ipb) e se si può risolvere direttamente lato server :)

Eh, no, non chiede e basta: passa anche tutto l'output dentro gzencode, comprimendo manualmente il tutto.
Codice (brutto) di prova:

Codice PHP:

---

<?php
$output = "<!DOCTYPE html><html><head></head><body>OUTPUT!";
if ( isset( $_SERVER['HTTP_ACCEPT_ENCODING'] ) and strpos( $_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip' ) !== false )
{
if ( function_exists( 'gzencode' ) and (bool) ini_get('zlib.output_compression') === false && !isset($_GET['nogzip']))
{
$output = gzencode( $output.".GZ!</body></html>" ); // mod_gzip will encode pages, but we want to encode ourselves so that Content-Length is correct
header("Content-Encoding: gzip"); // Tells the server we've alredy encoded so it doesn't need to
}else{$output.="</body></html>";}
}

echo $output;

---

Prova a vedere come cambia passando il parametro GET nogzip.

A quanto leggo dai commenti nel codice sembra che ci sia (o ci sia stato) qualche bug relativo all'header Content-Length lato Apache, ma non ho approfondito la questione.

Ok, ma prima di comprimere chiede se supporta gzip... Altrimenti non agisce, dico bene? Dunque, ecco, perché il server (AV) risponde "Ok", se quell'ok poi causa problemi? Ecco... Non sarebbe meglio, dato che tanto non è supportato (pena scomparsa della toolbar), rispondere qualcosa tipo "no, non si può"!!? :mrgreen:

Ti riferisci al valore di $_SERVER['HTTP_ACCEPT_ENCODING']? Quello riporta il valore dell'header HTTP Accept-Encoding generato dal browser. Non è quindi il server che dice ok, ma piuttosto è il browser che indica di supportare la compressione delle pagine.

Sì, mi riferivo a quella variabile, e credevo dipendesse dal server (così avevo capito anche dalla discussione con invision, i quali per farla breve, insistevano col dirmi che il codice chiede al server se può, e se può allora comprime - se comprime e poi causa casini a se stesso allora dovrebbe rispondere semplicemente che non può) :|
-
Niente allora... Come non detto! Io la mia soluzione ce l'ho, e va bene così. :P