Gestion des langues et des sessions en PHP / MySQL

[WebRankInfo]

Thibaud Elzière, webmaster du site sosie-star.com (entre autres), a accepté de publier un article sur WebRankInfo intitulé : "La gestion des sessions et des langues en PHP/MySQL pour optimiser le référencement"

Cet article présente une méthode générale et des astuces pour permettre de limiter l'utilisation des sessions et le passage de paramètre en URL (query string) afin d'optimiser le référencement grâce à la gestion dynamique des liens, la réécriture d'URL (URL rewriting). L'auteur applique cette méthode à la gestion dynamique d'un site multilingue.

Edit : cet article n'est plus disponible, désolé

 

[Lord Farquaad]

Ca à l'air intéressant, je viens de commencer la lecture (sans compter terminer tout de suite) et...

La section 2.3: une véritable horreur !!! Mon dieu, c'est probablement la pire chose que j'ai vue au niveau des requêtes mysql !
Habituellement, tout site cherche à minimiser le nombre de requêtes, et ici on croirait que c'est exactement l'inverse ! SI une page contient 1000 liens vers d'autres pages (bon allez c'est beaucoup, mais on pourrait imaginer au moins 30-40, non ?) cela veut dire 1000 requêtes mysql... pour générer une seule page ! Avec ça, vous mettez ko tout site web fortement fréquenté, c'est clair !

Ma solution vite faite:

class urls {
var $pages;
function urls {
$pages = array();
$sql = 'SELECT id, name FROM table_page';
$result = @mysql_query($sql);
while( $ligne = @mysql_fetch_assoc($result) ) {
$this->pages[$ligne['id']] = $ligne['name'];
}
}

function page($id_page) {
if( isset($pages[$id_page]) )
   return $pages[$id_page] . '.php';
else return 'nexisteplus.html';
}
}
$urls = new urls();

et ensuite il ne restera plus qu'à faire $urls->page(23) qui retournera page23.php pour rester fidèle à l'exemple...

Edit: j'ajouterai que pour ce qui est dit dans la section 2.4, avec ce système une nouvelle session est créée pour chaque page vue hors connexion (mauvaise idée il me semble, surtout si on gère les session avec mysql :?), qu'il y a une toute pitite faute dans le code proposé:

return $link . '?' .SID;

et que le tableau n'est pas complet:
Accepte les cookies + loggé : page23.php?
Accepte les cookies + non-loggé : page23.php + nouvelle session à chaque page vue
N'accepte pas les cookies + non-logé idem
N'accepte pas les cookies + loggé : page23.php?PHPSESSID=...

A noter qu'il existe une fonction pour changer le PHPSESSID en autre chose (puisque google n'aime pas :lol

Edit 2: même commentaire pour la 3.1 que pour la 2.3... je pense que le plus simple serait de gérer ces trois fonctions dans une seule classe, ce qui permettrait en plus d'avoir la variable language comme une variable d'instance (ou même statique) au lieu d'une variable globale (plus logique dans notre cas...)
A ce moment là, on pourrait envisager de construire les objets urls (ou un autre nom) en leur passant comme paramètre le numéro de la lanque.
On peut envisager ainsi de faire des pages en deux langues simultanées etc. (ça peut parfois être utile...)
Une autre chose intéressante serait peut-être aussi de passer au constructeur la liste des urls,mots et phrases dont on aura besoin afin de diminuer la taille des variables d'instances stockant ces dernières.

Edit 3: j'ajouterai tout de même: gaffe à la modification directe des requêtes sql via l'url: n'importe qui peut spécifier n'improte quel numéro de langue, et s'il ne correspond à rien :arrow: erreur sql, colonne n'existant pas !

D'autre part je trouve que l'auteur s'embrouille fort avec ses l et L réécrits en language= tous les deux, c'est de la paresse ou du manque de connaissance php ? :? Parce que bon, il y a tout de même moyen de remplacer assez aisément l'ancien numéro par le nouveau, par exemple avec str_replace :roll:

Edit 4: bon avec mon str_replace les choses sont plus simples, mais on aurait très bien pu inventer un deuxième paramètre à page pour passer une autre langue que l'actuelle, et ainsi générer le lien en page23-l1.php...

Autre chose: c'est testé tout ça ? :? parce que dans la fonction current_page(),

$query="SELECT id FROM table_page WHERE name=$name";
$result=mysql_query($query);

cette requête génère une erreur à tous les coups vu qu'il n'y a pas de guillements autour de $name...

Plus loin: connaissant le nom de la page, je ne vois pas trop l'intérêt d'aller rechercher son id dans la bdd et puis son nom, alors qu'il suffirait de:

base_page=basename($_SERVER["PHP_SELF"]) ; // $base_page contient le nom du fichier
$tab_str=explode(".",$base_page); // On récupère la partie sans l'extension
$link1 = $tab_str[0] . '-l1.' . $tab_str[1];
$link2 = ...

et à la limite une fonction pour faire ça si on le fait tout le temps...

Bon ok, je vois l'intérêt de la fonction add_parameter(), mais elle est pas très cool je trouve... on pourrait imaginer par exemple de lui passer un tableau... D'autre part toutes les adresses obtenues par cette fonction sont beaucoup plus difficiles à modifier par la suite, il y a mieux à mon avis...

Pour ce qui est du .htaccess, il est pas cool non plus: pour chaque page utilisant son type de paramètre, il faut le modifier ! Je trouve qu'il est bien mieux de sécuriser les paramètres dans les fichiers php (pour s'assurer qu'il n'y a pas de failles, par exemple tester si c'est bien des entiers etc.), et d'écrire un .htaccess capable de gérer le tout automatiquement... c'est ce que j'ai proposé dans mon tout premier post sur ce forum, auquel un seul membre a répondu, alors que ça me paraissait être un truc de feu :cry:

 

[WebRankInfo]

au moins on a maintenant plein d'idées d'améliorations !
désolé pour les 2 petites erreurs de frappe que je vais corriger... pour le reste, sois indulgent My Lord ;-)

 

[wap]

A propos de la gestion multilingue, il existe un langage de template très intéressant : Templeet.

Ce langage (_très_ simple à maîtriser si vous connaissez PHP) permet de faire beaucoup de choses très simplement. Une des killer features est un système de gestion de cache aux performances excellentes.

Et comme en plus c'est un Logiciel Libre... pourquoi se priver ?

Templeet : http://templeet.org

 

[Lord Farquaad]

au moins on a maintenant plein d'idées d'améliorations !
désolé pour les 2 petites erreurs de frappe que je vais corriger... pour le reste, sois indulgent My Lord ;-)

Je me suis dit que plus je faisais de remarques, plus ce serait constructif :roll:
En fait là j'ai fort l'impression que l'auteur a programmé son site en partie, l'a lancé, puis a voulu l'améliorer petit à petit, et c'est ainsi qu'il a des fonctions qui sont peu optimisées puisque justement, le problème face auquel il s'est retrouvé ne venait plus des urls avec des noms de pages pouvant varier, mais des fonctions appelées un peu partout dans ses pages, et donc devant être obligatoirement conservées...

Ceci me laisse aussi l'impression que l'auteur a des connaissances basiques de php (mais suffisantes pour ce qu'il veut faire tout de même 8))... par exemple au lieu d'écrire une deuxième fonction qui appèle la première, il aurait pu changer sa déclaration en

function page($id-page, $params = ''){
...
// ajout des paramètres
...
return ...
}

(à noter que ça laisse le problème des requêtes similaires et nombreuses...)

Pour templeet: on dirait que les programmeurs ne sont pas rendus compte que leur truc était pratiquement un cms :? :lol:

 

[wap]

Pour templeet: on dirait que les programmeurs ne sont pas rendus compte que leur truc était pratiquement un cms :? :lol:

Sûrement parce que Templeet n'a rien à voir avec un CMS Ce serait comme dire que PHP ou Python sont des CMS.

Templeet est un langage. A l'aide de ce langage, il est possible de créer un CMS, mais aussi toutes sortes d'autres sites (un wiki par exemple).

Et pour info, Da Linux French Page (linuxfr.org) est fait avec Templeet, ce qui constitue tout de même une référence en matière de performances (notamment au niveau de la gestion du cache).

 

[Lord Farquaad]

Bah euh tout de même, quand on voit certaines carractéristiques:

• Gestion complète d'identification (au choix: fichier, MySQL, PostgreSQL ou ODBC)
• Interface d'administration des utilisateurs
• Système de packages, installation et mise à jour
• Mise à jour de Templeet par l'interface d'administration

+la possibilité de venir greffer tout ce qu'on veut là dessus, je ne sais pas trop ce qui n'en fait pas un cms... je vois tout de même des différences avec les cms décrits comme tels, mais bon, je ne vois pas en quoi ceci n'est pas un système de gestion de contenu...

Et pour ce qui est d'un langage: il me semble que c'est pratiquement une réécriture du langage php ça... ils ont programmé tout un tas de fonction php, et pour simplifier leur utilisation dans les pages, ils ont programmé une détection des "~"... juste pour économiser des "<?php ?>" ? :?

Enfin, ça devait être chouette à programmer, et puis si des sites comme linuxfr.org l'utilisent...

 

[wap]

ils ont programmé tout un tas de fonction php, et pour simplifier leur utilisation dans les pages, ils ont programmé une détection des "~"... juste pour économiser des "<?php ?>" ? :?

Alala... qu'est ce qu'ils sont flemmards ces programmeurs quand même !

 

[Lord Farquaad]

Euh... en fait je m'attendais à ce que tu répondes à cette question et que tu me donnes un peu plus ton avis à propos de la comparaison avec un cms...

Au fait je ne sais pas si ta réponse est une petite moquerie de ce que j'ai dit, mais je n'ai dit nul part que ça a dû être facile à programmer... en fait pour ce qui est de la partie détection des "~", je pense que ça a dû être amusant :lol: mais pas trop difficile... j'ai pas regardé leur source mais je pense qu'à leur place, j'aurais fait une rechere des tildes, en lisant le fichier d'une manière quelconque, puis lecture de tout ce qui se trouve jusqu'à la parenthèse ouvrante (auquel on applique trim), puis lecture des parenthèses: comptage ouvrantes + fermantes jusqu'à atteindre 0...

Je viens de regarder le fichier d'installation: intéressant, je me demande si c'est mieux un seul fichier avec des base64_decode ou bien alors plein de fichiers... l'avantage ici c'est que si on perd un fichier, c'est tout ou rien :lol: mais le désavantage c'est qu'on est oblgé de tout installer si on veut éditer le moindre fichier, et si on veut refaire une disitribution, on est obligé de modifier le fichier d'installation...
Au fait je suppose que si on sélectionne des packages supplémentaires pour le téléchargement, on n'obtient quand même quun seul fichier d'installation ? Intéressant ça

 

[wap]

Euh... en fait je m'attendais à ce que tu répondes à cette question et que tu me donnes un peu plus ton avis à propos de la comparaison avec un cms...

Ah. Selon moi, Templeet n'a rien à voir avec un CMS même si Templeet permet de coder un CMS assez simplement.

Toujours selon moi, ce qu'on appelle un CMS c'est quelque chose comme SPIP, OpenCMS ou PHP Nuke. C'est un ensemble de code tout fait qui permet de faire quelque chose de bien précis : gérer du contenu (Content Management System). Impossible de coder autre chose. Et ça suppose que le contenu soit formaté selon la norme du CMS (le résultat c'est que tous les sites PHP Nuke se ressemblent quand même pas mal...)

Avec Templeet, l'approche est complètement différente. L'installation crée bien-sûr un set de pages par défaut, mais développer un site avec Templeet ça veut dire remplacer ces pages par défaut par quelque chose de personnalisé. Pour reprendre linuxfr en exemple (désolé pour la promo, mais ceci dit c'est vraiment une excellente source d'information), et bien le système de news avec modération et notation ensuite par les visiteurs (pour pouvoir ensuite ne voir que les messages bien notés par exemple, et éviter les trolls) est vraiment bien foutu. Un autre projet "phare" sous Templeet, s'appelle Wikleet : un wiki.

Voila deux exemples d'application web qu'il n'est pas possible de faire avec SPIP ou PHP-Nuke, avec un CMS...

Et faire un CMS avec Templeet est tout à fait faisable.

C'est vrai qu'au début, Templeet est assez déroutant Mais c'est bel et bien un langage.

Pour des infos sur l'aspect charge serveur, un benchmark Templeet,Zope, SPIP, Drupal, PHP-Nuke : http://nexus.ouvaton.org/Benchmark_OpenBrick/

Au fait je ne sais pas si ta réponse est une petite moquerie de ce que j'ai dit, mais je n'ai dit nul part que ça a dû être facile à programmer... en fait pour ce qui est de la partie détection des "~", je pense que ça a dû être amusant :lol: mais pas trop difficile... j'ai pas regardé leur source mais je pense qu'à leur place, j'aurais fait une rechere des tildes, en lisant le fichier d'une manière quelconque, puis lecture de tout ce qui se trouve jusqu'à la parenthèse ouvrante (auquel on applique trim), puis lecture des parenthèses: comptage ouvrantes + fermantes jusqu'à atteindre 0...

La partie "détection des ~" en elle-même a du être anecdotique à coder... Mais il y a pas mal d'autre choses derrière Templeet Mais ce n'est pas le lieu pour en parler plus en détail...

Je viens de regarder le fichier d'installation: intéressant, je me demande si c'est mieux un seul fichier avec des base64_decode ou bien alors plein de fichiers... l'avantage ici c'est que si on perd un fichier, c'est tout ou rien :lol: mais le désavantage c'est qu'on est oblgé de tout installer si on veut éditer le moindre fichier, et si on veut refaire une disitribution, on est obligé de modifier le fichier d'installation...
Au fait je suppose que si on sélectionne des packages supplémentaires pour le téléchargement, on n'obtient quand même quun seul fichier d'installation ? Intéressant ça

Ici, si tu perds le fichier d'installation, tu retournes sous templeet.org et tu le récupères (pour info, la dernière version avec tous les packages ne pèse que 1,17Mo).

L'installation dure 20 secondes. Elle va créer 2 répertoires principaux : /templeet et /template. Dans /templeet se trouve le "moteur", donc pas besoin d'y toucher (mais on peut faire des choses si on veut...) Et tout se que tu vas coder se trouve dans le répertoire /template.

Donc chez toi tu gardes la copie locale de /template. Si il y a un problème, tu réinstalles en quelques minutes.

Depuis quelques versions, on peut mettre à jour sa version de Templeet directement via l'interface d'admin. Et la mise à jour ne touche pas à /template. Donc pas de danger de ce côté là non plus.

Voila. J'espère avoir répondu à peu près à tes questions.

 

[Lord Farquaad]

Je vais répondre à ton message dans l'ordre, mais sans faire trop de citations ;-)

Toujours selon moi, ce qu'on appelle un CMS c'est quelque chose comme SPIP, OpenCMS ou PHP Nuke. C'est un ensemble de code tout fait qui permet de faire quelque chose de bien précis : gérer du contenu (Content Management System). Impossible de coder autre chose. Et ça suppose que le contenu soit formaté selon la norme du CMS (le résultat c'est que tous les sites PHP Nuke se ressemblent quand même pas mal...)

Là je ne suis pas tout à fait d'accord. Bon c'est vrai, je n'ai jamais utilisé de cms pour faire un site web, mais quand même... C'est vrai qu'un cms est un ensemble de code tout fait, mais rien n'empêche de l'étendre et d'en faire ce que tu veux. Par exmple il serait tout à fait envisageable de programmer un module qui gère un wiki ou un système de niews semblable à celui que tu explique, c'est juste que cela n'est pas courant (je n'ai aucune idée de si ça existe puisque je ne m'y connais pas assez...)
Et là, on aurait à notre disposition un systèm de templates aussi, mais évidemment dont le fonctionnement serait bien différent. En effet, généralement les cms et autre scripts php préfèrent séparer totalement la partie html de la partie dynamique (clarté du code...), alors que pour templeet c'est exactement l'inverse (certes il y a un tas de fichiers tout en php je suppose, mais les templates contientent du html et un mélange de ce "langage").
Cette différence se verrait clairement au niveau de la création du site, mais au niveau du contenu en sortie, cela pourrait être parfaitement identique ! Il n'est en effet absolument pas exclu de désactiver le "formatage à la norme du cms", qui n'est qu'une entete html liée à une feuille de style... Il suffit de ne pas inclure l'entête !
De plus étant donné que le "langage" de templeet est entièrement basé sur du php, tout ce qu'on peut faire avec templeet peut être fait avec n'importe quel autre fichier php (cms ou non), puisqu'en tout logique on pourrait reprogrammer templeet :roll: Bien entendu chaque script est orienté vers telle ou telle chose, et la mise en oeuvre de certaines choses est plus faciles sur base d'un cms, d'un forum... ou même de rien du tout. Je crois qu'aucun script n'a pour but de limiter les possibilités du webmaster :roll:

Euh... en fait pour tout ce qui est install etc. ça ne m'intéresse pas tellement :roll:

 

[wap]

Euh... en fait pour tout ce qui est install etc. ça ne m'intéresse pas tellement :roll:

Ah. J'avais cru, en lisant :

Je viens de regarder le fichier d'installation: intéressant

 

[Lord Farquaad]

C'est intéressant au niveau du fonctionnement, mais je n'ai pas suffisemment envie de tester templeet que pour prendre le temps de l'installer :roll:

 

[troops]

Pour le multilangue j'me suis moins cassé l'cul que ça

j'ai mis un dossier comme ça :

http://www.example.com/en/
http://www.example.com/fr/

et dans la base je recupere le texte contenu dans la table lang_xx et pof toc pof c regler l'histoire

 

[Wernight]

Je pense que parler des système de template on s'écarte un peu. Tout de même pour faire clair, un template comme Templeet ou Smarty ça permet de séparer la présentation de la logique. Ca permet qu'un monsieur X graphiste fasse la présentation et qu'un monsieur Y fasse le code PHP par exemple.
C'est pour ça qu'on évite les <?= ... ?> pour mettre quelque chose de plus simple et qui n'est pas de la programmation.

Dans le cadre des langues, le cache fourni par ces outils est souvent une bonne solution en cas de forte demande. Sur mon site l'accès à une page en cas de faible demande y est augmenté très légèrement, mais en cas de forte demande je n'ai même pas une seule requête SQL. C'est donc un gros conseil (utilisé pour phpBB3 aussi).