Affichage de la page d'accueil de pluxml.org avec Epiphany

flipflip

Bonjour à tous,

Je test le navigateur Epiphany sur ma fedora et voila comment s'affiche la page d'accueil de pluxml.org



Uploaded with ImageShack.us

HEOLLIAES

Change de navigateur!

PPmarcel

Salut Flip Flip.

J'ai moi même identifié ce problème depuis 3 mois avec Pluxml 5. Il s'agit en fait d'un problème d'affichage lié d'une part à la compression des pages en gzip, et d'une autre part les navigateurs utilisant le moteur de rendu webkit.

On m'a dit que ça marchait bien avec Chrome. Mais personnellement je rencontre ce problème avec Jumanji sous Linux, et midori sous Windows. Je dois utiliser Firefox (moteur gecko) pour aller sur les sites ayant la compression gzip activée.

Stéphane

Chrome et Chromium (que j'utilise) aucun probleme

flipflip

Bonjour,

Etonnant ce problème avec la compression activé...

HEOLLIAES, justement je viens de changer pour passer à Epiphany, marre de firefox qui bouffe 140Mo de ram, marre de son rendu lent.

PPmarcel

J'ai essayé de ne forcer que gzip ou x-gzip dans class.plx.utils.php, mais cela ne change rien au problème.

Stéphane

la compression gzip se désactive à partir de l'admin Parametres > configuration avancées. Au cas ou...

PPmarcel

Tu penses bien que je ne l'ai jamais activé du coup
Non, j'essayais de voir si l'une ou l'autre compression pouvait être incompatible avec webkit.

Il n'y a qu'avec PluXml que j'ai rencontré ce problème.

EDIT: Le problème est indépendant du serveur web. Avec lighttpd on retrouve le même soucis.

super_g2

au fait, il y a un truc que je n'ai jamais compris : le serveur (apache2 par exemple, via le mod adéquate) permet de compresser en gzip automatiquement ou de permettre (si un site est compatible) cette compression?

flipflip

super_g2, oui le serveur envoie les données compressé et c'est au navigateur de les décompresser.

Sur le net j'ai rien trouvé en rapport

super_g2

ce que je voulai dire est :
le serveur compresse par défaut ou c'est au site (via une fonction interne) d'en faire la demande au serveur?

flipflip

C'est un paramétrage soit géré par le serveur, soit c'est le site qui en fait la demande. Souvent les admins des serveurs n'active pas cette fonction pour soulager le processeur et avoir de meilleur temps de réponse. Il vaut mieux l'activer au coups par coups.

kurokame

Bonjour,
Je déterre ce vieux sujet car j'ai été confronté au même problème que flipflip avec une version 5.0.2 et Epiphany (version 2.30.6). Firefox et Chromium, aucun soucis. Je suis sur une une Ubuntu 10.04.
Après quelques tests et investigation aussi coté serveur web, j'ai l'impression qu'il y a un binz avec PHP au niveau du module ./core/lib/class.plx.utils.php près des fonctions httpEncoding et ob_gzipped_page. Je ne suis pas un développeur mais en modifiant la comparaison des conditions elseif de la première fonction, mes pages s'affichent enfin correctement au lieu de caractères bizarres.
Je n'ai pas testé avec la dernière version mais le code n'a pas changé.

Stéphane

kurokame a écrit:

Je ne suis pas un développeur mais en modifiant la comparaison des conditions elseif de la première fonction, mes pages s'affichent enfin correctement au lieu de caractères bizarres.
Je n'ai pas testé avec la dernière version mais le code n'a pas changé.

Peux-tu nous donner les modifications du code que tu as fait stp

kurokame

Bonjour Stéphane,

579         public static function httpEncoding() {
580                 if( headers_sent() ){
581                         $encoding = false;
582                 }elseif( strpos($_SERVER['HTTP_ACCEPT_ENCODING'], 'x-gzip') != false ){
583                         $encoding = 'x-gzip';
584                 }elseif( strpos($_SERVER['HTTP_ACCEPT_ENCODING'],'gzip') != false ){
585                         $encoding = 'gzip';
586                 }else{
587                         $encoding = false;
588                 }
589                 return $encoding;
590         }

Ça supprime la comparaison du typage. C'est du pur bidouillage et ça casse très probablement certains contrôles. Mais c'est avec ça que le problème rencontrée avec Epiphany, est plutôt du coté de la compression Pluxml.

amoweb

Bonsoir Kurokame,

Essaies d'utiliser ce code dans index.php :

# On applique la compression gzip si nécessaire et disponible

if($plxMotor->aConf['gzip']) {

	if(!ob_start("ob_gzhandler")) ob_start();

}

au lieux de :

# On applique la compression gzip si nécessaire et disponible
if($plxMotor->aConf['gzip']) {
	if($encoding=plxUtils::httpEncoding()) {
		header('Content-Encoding: '.$encoding);
		echo("\x1f\x8b\x08\x00\x00\x00\x00\x00");
		$size = strlen($output);
		$output = gzcompress($output, 9);
		$output = substr($output, 0, $size);
	}
}

kurokame

Bonsoir amoweb,

Ce code correspond à la dernière version de Pluxml. Je viens d'installer "à l'écart" celle-ci sans la moindre modification et la page d'accueil s'affiche correctement.
Je crois que ça va me forcer à mettre à jour plus rapidement que prévu.

S'il n'y a pas de problème jusque là (si ma modification ne perturbe pas le fonctionnement de la compression des pages), je vais conserver ce que j'ai fait.
Dans tous les cas, je vous remercie.

bankai

Je test dés que j'ai accès au PC

Stéphane

kurokame a écrit:

Bonsoir amoweb,

Ce code correspond à la dernière version de Pluxml. Je viens d'installer "à l'écart" celle-ci sans la moindre modification et la page d'accueil s'affiche correctement.
Je crois que ça va me forcer à mettre à jour plus rapidement que prévu.

S'il n'y a pas de problème jusque là (si ma modification ne perturbe pas le fonctionnement de la compression des pages), je vais conserver ce que j'ai fait.
Dans tous les cas, je vous remercie.

On aurait du commencer par te demander quelle version de PluXml tu utilisais, car le code évolue de version en version

bankai

Je viens de testé ton code pour l'erreur des codes google qui ne sont pas reconnus à cause de la compression G-Zip, pour le moment tout fonctionne.

Je le test sur mon site ici: http://www.site-de-bankai.fr/

Je continue de voir si tout les codes fonctionne mon cher Amaury, je te remercie de ton travaille

bankai

Donc je reviens avec une grosse erreur ^^
Si je désactive la compression mon site est valide Xhtml 1.0 Strict
Si j'active la compression c'est le drame:( , le site passe en Html 4.01 avec plus d'une centaines d’erreurs.

amoweb

Chez moi aussi la validation ne fonctionne plus. Il semblerai que le validateur ne reçoit ça, juste avant le header de la page :

<br />
<b>Warning</b>: ob_start() [<a href='ref.outcontrol?PHPSESSID=6ef8d36d7590a9ffda74d2028429e2f4'>ref.outcontrol</a>]: output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter' in <b>/homez.184/local/www/index.php</b> on line <b>92</b><br />

EDIT : A priori ça arrive quand une session est lancée avant, le ob_start.

amoweb

Je propose une autre solution (pour PluXml 5.1.3) qui semble fonctionner avec Epiphany et validator.w3.org. Reste à savoir si elle fonctionne avec G+.

Dans plxUtils : remplacer la fonction httpEncoding par

/**
	 * Méthode qui retourne le type de compression disponible
	 *
	 * @return	stout
	 * @author	Stephane F
	 **/
	public static function httpEncoding() {
		if(headers_sent()){
			$encoding = false;
		}elseif(strpos($_SERVER['HTTP_ACCEPT_ENCODING'],'gzip') !== false){
			$encoding = 'gzip';
		}else{
			$encoding = false;
		}
		return $encoding;
	}

Dans index.php : Utiliser :

# On applique la compression gzip si nécessaire et disponible
if($plxMotor->aConf['gzip']) {
	if($encoding=plxUtils::httpEncoding()) {
            header('Content-Encoding: '.$encoding);
            $output = gzencode($output,-1,FORCE_GZIP);
        }
}

Au lieu de :

# On applique la compression gzip si nécessaire et disponible
if($plxMotor->aConf['gzip']) {
    if($encoding=plxUtils::httpEncoding()) {
        header('Content-Encoding: '.$encoding);
        echo("\x1f\x8b\x08\x00\x00\x00\x00\x00");
        $size = strlen($output);
        $output = gzcompress($output, 9);
        $output = substr($output, 0, $size);
    }
}

En espérant que ça fonctionne partout...

Stéphane

Merci de nous confirmer le bon fonctionnement de la compression Gzip activée avec
- le navigateur Epiphany
- le plugin Google+
Ainsi nous pourrons officialiser la solution apportée par Amaury dans la prochaine version de PluXml (5.1.4)

bankai

Je test et je confirme après si bon

bankai

Ha ha pour le moment je suis OK de partout mon ami, cela fonctionne.
Le soucis d'ordre w3c est corrigé.
Le +1 de Google fonctionne aussi.

kurokame

Bonjour Stéphane,

J'utilise pour l'instant la version 5.0.2 de Pluxml. Je prends du temps avant de, et pour faire les mises à jour.
Je suis allé un peu trop vite en besogne hier soir, car la compression gzip sur une installation toute fraîche n'est pas activée. Et en l'activant, je retombe sur le même problème d'affichage.

J'apporte une précision supplémentaire, c'est que la compression est activée aussi coté serveur web - mod_deflate d'Apache, ce qui rend en effet la compression par Pluxml inutile. J'étais persuadé que la compression de Pluxml ne s'activait pas dans ce cas. Ce n'est qu'en étudiant davantage le PHP depuis, que je crois comprendre qu'il se passerait une double compression dont le navigateur Epiphany est bien en peine de gérer par rapport à ses homologues Firefox et Chromium (je fais des tests de compatibilité, de validation w3c et d'autre un peu moins nécessaires, comme utiliser du SVG, depuis peu). Est-ce exact ?

Je vais tester aussi ces changements et je ferai un retour.

Après la modification du code proposée par amoweb, avec Epiphany, la page s'affiche correctement avec l'option gzip de Pluxml activée.
Je viens de l'adapter sur l'ancienne version (5.0.2) pour la fonction ob_gzipped_page et ça s'affiche correctement aussi.

Stéphane

Voilà des bonnes nouvelles. Merci bankai et kurokame pour ces retours.
amoweb a fait un sacré boulot pour trouver la solution.
on va pouvoir adopter la modification alors.

bankai

oui merci Amaury pour cette modification.

kurokame

Merci à l'équipe.