La nouvelle semaine a commencé par traquer et supprimer l’erreur de PHPDocx. La semaine dernière, on avait des ereurs bizarres dans le fichier error.log sous la version 2.5. Du coup, lundi on a décidé de mettre à jour la version et on est passé à la PHPDocx 3.7.Pour l’info, PHPDocx est payant. Dans toutes les mises à jours, il faut bien faire gaffe à ne rien oublier. Ce que j’ai fait est de modifier la valeur de la variable $phpdocxClasses. Mais je rencontrais un problème quand je testais un fichier pour voir ce qui me donne. Voila la page sur laquelle je faisais du test. Quand je coche tout, il y a vait aucun problème mais quand je filtre les sélections, ca provoquait l’erreur. J’ai testé plusieurs trucs pour comprendre d’ou il vient l’erreur. Apres avoir passé une demie journée avec cette ereur je me suis rendu compte que j’ai supprimé une variable et fait un ENTER sans exprès dans la source php dans laquelle je faisais du test. Pour régler le problème, j’avais besoin de la meme source datée 1 semaine avant. Grace au seveur de stocakge NAS 5200, j’a recupéré le meme fichier et j’ai corigé la betise.Ca a l’air tout bon sous la version 3.7
Mardi j’ai contacté Damien au sujet de la mission Newsletter pour qu’il fasse ses essais la-dessus. Il a bien aimé l’idée et il a facilement ajouté de nouveaux articles.Ensuite, j’ai parlé avec Irina et Olivier pour montrer ce que j’ai fait et ouvrir un compte pour chacun. Mon tuteur m’avait demandé de faire des test pour chaque source qui utilise PHPDocx pour rassurer la bonne fonctionnement. Cela apris un jour à peu pres parce que parfois j’arrive pas à faire des test facilement.D’abord il faut chercher les sources utilisant PHPDocx puis trouver le bon endroit sur intranet et à la fin tester.
J’ai créé un petit plugin/extension pour que le lien qu’on utilise dans l’article fasse référance au fichier correspondant. C’esta-à-dire que ca fonctionnait pas le protocole file://.
Voila le lien dont j’ai profité: https://gist.github.com/rosshanney/3437658. Une fois qu’on a activé le plugin, c’était tout bon.
Le problème d’affichage nous a attiré cette fois-ci. Mon tuteur a un ipad et il voyait pas le thème sous ipad. Pourquoi ca lui arrive je sais pas mais je voyais bien le theme dans mon smartphone. Par contre, l’affichage était pas bon. Avec un peu de recherche, il fallait se servir de la fonction get_browser() ou la variable $_SERVER[‘HTTP_USER_AGENT’]. J’ai recherché ca dans le répertoire WordPress et j’ai trouvé cette ligne:
$is_ios = wp_is_mobile() && preg_match( '/iPad|iPod|iPhone/', $_SERVER['HTTP_USER_AGENT'] );
Il fallait forcer wp_is_mobile() à false. Pour cela, j’ai cherché cette fonction
function wp_is_mobile() {
static $is_mobile;
if ( isset($is_mobile) )
return $is_mobile;
if ( empty($_SERVER['HTTP_USER_AGENT']) ) {
$is_mobile = false;
} elseif ( strpos($_SERVER['HTTP_USER_AGENT'],'Mobile')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Android')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Silk/')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Kindle')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'BlackBerry')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Opera Mini')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Ipad')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'iPad')!== false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Iphone')!==false
|| strpos($_SERVER['HTTP_USER_AGENT'],'Opera Mobi')!==false){
$is_mobile = true;
} else {
$is_mobile = false;
}
}
Comme vous le remarquez, il fallait ajouter au dessus de elseif ce genre de code:
if (strpos .... iPad, then false
return $is_mobile;
La modification a bien fait l’effet car quand on faisait un print ou echo pour le mobile, on le voyais sur smartphone.
Pour l’info, pour visualiser l’ecrans sous Ipad depuis votre navigateur, vous pouvez utiliser le plugin de firefox UserAgentSwicher: https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/
On va passer à une autre chose la semaine prochaine mais on réessaiera plus tard éventuellement.
Nejat ARINIK 
