NPDS : Gestion de contenu et de communauté

Précédemment, nous avons vu comment construire une moulinette de "dépannage"

Il s'agissait d'utiliser "à chaud" un outil permettant de réparer rapidement un petit dégât ou de faire une petite correction. Un commentaire nous a indiqué que cette méthode n'était pas la seule et que l'on pouvait aussi faire ce travail directement dans phpmyadmin.

Chaque méthode a ses avantages et, pour ma part, j'aime bien tester à blanc avant d'exécuter ce genre de script et je sauvegarde plutôt deux fois qu'une afin de revenir très rapidement en arrière si besoin est. C'est quand c'est chaud que ce genre d'intervention est le plus risqué. Et puis nous nous sommes volontairement placés dans un contexte d'hébergement gratuit.
D'ailleurs, nous ne tarderons pas à évoquer la sécurité :
- Sécurité des données: par exemple ne pas corrompre un champ avec une valeur impropre;
- Sécurité du site: en n'ouvrant pas une faille de sécurité.

De plus, il peut être intéressant de lancer des moulinettes non pas de dépannage mais de maintenance périodique (purge, correction, etc...)

Dans cette troisième étape, nous allons faire en sorte que notre moulinette soit un peu plus universelle. Le but est d'utiliser le même script pour modifier n'importe quelle valeur de n'importe quel champ de n'importe quelle table de la base de données. En plus, nous introduirons un paramètre qui permettra de faire un test "à blanc" (donc sans modification réelle).

Notre exemple précédent comportait une petite insuffisance :

Il faut savoir que NPDS utilise une couche d'abstraction SQL qui fonctionne depuis assez longtemps et qui permet à REv13 de supporter les appels natifs MySql et mysqli

Abstraction ... Abstraction, qu’est-ce que ... une ... d'abstraction ?

Explication donnée par François Lasselin (Blog NALIS, Mars 2006):
« Lorsque l'on développe une application Web, les requêtes SQL sont réalisées grâce à des appels natifs (c'est à dire spécifiques à une Base de données).

Par exemple, pour demander à php de se connecter à MySQL on utilisera "mysql_connect()" et "mysql_query()" pour exécuter une requête. Ces appels natifs sont présents dès que l'application accède à une donnée et sont donc disséminés dans l'applications (dans le code source). Dès lors, une telle application est forcément destinée à un SGBD en particulier car modifier chaque appel natif dans le code source est une lourde tache.

C'est pourquoi les choses ont évolué : Aujourd'hui, il est courant d'utiliser une couche d'abstraction pour accéder à un Système de Gestion de Base de Données (SGBD). »

 Lorsque l'on maintient un site internet, il arrive forcément un jour où l'on doit modifier 'en rafale', le contenu d'une donnée située dans une table de la base de données Mysql.

La plupart des professionnels de l'informatique en général et des NTIC's, en particulier, savent ce qu'est une moulinette'.

Si c'est votre cas et, qu'en plus, vous êtes un virtuose de php, alors je vous propose de retourner à votre passe-temps préféré car ce qui suit ne vous apprendra rien.

Sinon, voici la suite:

Je ne comprenais pas pourquoi, quelle que soit la valeur indiquée dans les préférences de NPDS, le nombre de news affichées dans la page principale, pour un utilisateur enregistré, se limitait toujours à 10.

Je voulais que les 25 derniers articles soient affichés.

Une petite consultation de la bible de NPDS (CONFIGURATION: Les préférences) m'a permis de trouver la raison...

J'ai appris que la donnée concernée par cette limite était storynum, donnée de la table Users. Lors de la création d'un utlisateur, la donnée storynum est initialisée à 10 et cette valeur prime sur la valeur 5 (indiquée dans les préférences), qui s'adresse aux visiteurs non inscrits.

Il ne me restait plus qu'a corriger la valeur de storynum pour chaque utilisateur.

Ceci dit, comment faire lorsque plus de deux cents utilisateurs sont déjà enregistrés...

Première solution: modifier à la main, le contenu de la donnée en question.

C'est juste long comme un jour sans pastis! (même avec modération...).

Plutôt 'cossard' par nature, j'en ai choisi une autre, moins chronophage...

J'ai opté pour l'écriture d'une moulinette en PHP, qui remplacerait automatiquement le contenu de storynum de chaque élément de la table Users par la valeur 25, pour ce site.

Comme ça a bien marché (en une seconde tout au plus), je propose la méthode à tous ceux qui voudraient bien et qui n'osent pas.

La moulinette en question se découpe en quatre éléments:

A-Déclaration des identifiants de connexion à la base mysql:

B-Connexion:

C-Requête de modification:

D-Traitement du résultat:

Le but :

Faire en sorte qu'un champ dans une fiche membre soit invisible aux autres membres mais qu'il reste visible pour son propre profil et aussi aux administrateurs.

Pour cela il faut modifier le fichier module/sforme/extend-user/aff_formulaire.php

Si l'on prend comme exemple la section SHORT-USER et comme exemple le champ "Your Interest" le code donne :

if (isset($user)) $l_cookie=cookiedecode($user);

if ($admin or ($l_cookie[1]==$uname)) {
    $m->add_field('user_intrest', translate("Your Interest"),"$user_intrest",'text',false,150,"","");
}

Cela demande quelques connaissance en PHP mais c'est simple et très efficace.

Fonctionne avec REvolution 11 et REv13 ... et cela doit marcher avec de très nombreuses versions de NPDS

Validation par le navigateur

Afin de vérifier que la validité du format de certaines entrées ou que les champs obligatoires ont bien été remplis avant d'envoyer les données au serveur, HTML5 introduit de nouveaux mécanismes puissants :

Les nouveaux attributs comme required ou pattern, utilisés conjointement avec les pseudoclasses CSS facilitent grandement ces vérifications et l'affichage des informations utiles à l'utilisateur. D'autres techniques plus avancées permettent d'utiliser !! pour définir des règles personnalisées de validation et les messages associés, ou de déterminer si un élément est invalide et pourquoi.

L'attribut required

Si l'attribut required est présent, alors le champ en question doit contenir une valeur lorsque le formulaire est soumis. Voici un exemple de champ input concernant une adresse e-mail obligatoire et permettant de vérifier que l'adresse est bien renseignée et valide selon les critères définis ici :

<input id="email_addr" type="email" name="email_addr" />

L'attribut pattern

L'attribut pattern permet de définir une expression régulière qui sera utilisée pour déterminer si la saisie est conforme au format attendu. L'exemple suivant correspond à un champ texte requis et représentant un code particulier. Dans l'exemple, nous souhaitons que ce code soit composé de trois lettres majuscules suivies de quatre chiffres. Les attributs required et pattern permettent de s'assurer que le champ sera rempli au format souhaité lors de la soumission. Enfin, lors du survol du champ, l'utilisateur verra apparaître un message correspondant à l'attribut title lui indiquant le format attendu.

<input id="part" title="<span style=" type="text" name="SN" />SN - 3 majuscules + 4 chiffres."/>

À partir de l'exemple précédent, on peut ajouter une bordure rouge à l'input tant que le champ ne contient pas de saisie valide. Pour cela, nous ajoutons le code CSS suivant pour créer la bordure rouge si le champ est invalide :

:invalid { border: 2px solid #ff0000; }

L'attribut formnovalidate

L'attribut formnovalidate s'applique aux input et button de type submit. S'il est présent, alors la validation par le navigateur sera désactivée. Dans l'exemple suivant, la validation du formulaire est effectuée en cliquant sur "Submit" mais ne l'est pas en cliquant sur "Save".

<input id="part" title="SN - 3 majuscules + 4 chiffres" type="text" name="SN" />
<input type="submit" value="Save" />
<input type="submit" value="Submit" />