Je vais essayer de décrire l’archi de PWG telle que je la vois. C’est pas dit que j’ai raison!

Les tables:

• #caddie: panier pour l’admin
• #categories: toutes les infos sur les categories (nb d’images, site, upload, visible,...)
• #comments: les commentaires des images
• #config: toutes les options sont là... sauf celles qui sont dans install/config_<default|local>.inc.php
• #favorites: couple user/image, n fois
• #group_access: couple groupe/categorie, n fois
• #groups: couple id/nom
• #history: l’historique du trafic, par catégorie et par page
• #image_category: couple image/categorie, n fois. Dans les n, il y a forcément la catégorie de stockage (unique), mais il peut y avoir d’autres catégories physiques ou virtuelles pour une image précise.
• #image_tag:liens tag/image en 1 pour 1.
• #images: toutes les infos sur les images, notamment le path, les dimensions, la taille sont mises en base
• #rate: utilisateur/image/vote. La clé est util./image
• #sessions: utilisateur/sessionsid/date d’expiration
• #sites: couple id/url
• #tags: liste des tags. Il y a un champ url_name pour la version “lisible en ascii” du tag.
• #upgrade:table interne pour la gestion des mises à jour, notamment pour la base.
• #user_access: couple utilisateur/categorie
• #user_cache: utilisateur/maj/liste des categories interdites. Pourquoi ces infos ne sont pas dans la table #users, vu que la clé est la même? Pour la purge, puisqu’il est possible de réinitialiser fréquemment ces valeurs (MAJ infos images et catgéories).
• #user_feed: utilisateur/feed/date
• #user_group: couple utilisateur/groupe
• #user_infos: contient la config de personnaliser: taille maxi des images, template, ...
• #user_mail_notification: pour envoyer des avis par mail. Contient une clé de vérification et la date de la dernière notification.
• #users: id/nom/mot de passe/mail
• #waiting: images en attente: nom du fichier/user/etc.

Voilà pour les présentations!
Maintenant, le code

Il est basé sur PHPLib. Le fichier s’appelle template.php.
Les variables sont affectées dans les .php, qui ensuite appellent les .tpl. Ces variables sont gérées comme des constantes.

• L_xxx : texte localisé
• F_xxx : texte dans un formulaire, notamment certains paramètres des champs
• T_xxx : lié au template
• U_xxx : URLs

Cette nomenclature, présente à l’origine dans les templates, n’est en fait pas très suivie.

Pour les variables localisées (constante L_xxx ), il existe en fait plusieurs méthodes d’alimentation:

• {lang:xxx} : utilisé pour avoir la version traduite de xxx.
• l10n(”xxx”): remplace {lang:xxx}. Il existe un preg_replace dans le template pour transformer les lang existants en l10n à la volée.

yoga représente ici le nom du template. clear et dark sont les noms de themes basés sur le template yoga.

• template-common\default-layout.css : styles dépendant de certains paramètres: largeur du menu (et donc du contenu), dimensions de l’espace autour des miniatures. Il se surcharge à l’aide du fichier local-layout.css placé dans le même dossier.
• tools\local-layout.css : donc le fichier exemple de surcharge de template-common\default-layout.css.
• template\yoga\default-colors.css : couleurs basiques comme les erreurs, etc.
• template\yoga\default-layout.css : les composants mini
• template\yoga\content.css : styles liés au contenu, quelle que soit la page.
• template\yoga\fix-ie5-ie6.css : des corrections spécifiques pour IE 5 et 6
• template\yoga\fix-ie7.css : des corrections spécifiques pour IE 7
• template\yoga\fix-khtml.css: des corrections spécifiques pour Konqueror et Safari
• template\yoga\image.css : styles liés à la page picture.php
• template\yoga\menubar.css : styles liés au menu latéral
• template\yoga\popuphelp.css : styles du popup d’aide
• template\yoga\print.css : pour imprimer la page en cours.
• template\yoga\theme\clear\theme.css : contient les styles de couleurs pour le template en cours
• template\yoga\theme\dark\theme.css : idem , mais ceci est un autre thème.

Voici les appels des fichiers CSS:

xxx.php (initié dans template/yoga/header.tpl)
    |_template\yoga\layout.css
    |     |_template\yoga\menubar.css
    |     |_template\yoga\content.css
    |     |_template\yoga\image.css
    |     |_template\yoga\popuphelp.css
    |     |_template\yoga\default-layout.css
    |     |_template\yoga\local-layout.css
    |     \_../../template-common/layout.css
    |         |_template-common\default-layout.css
    |         \_template-common\local-layout.css
    |_template\yoga\fix-khtml.css (conditionnel au navigateur)
    |_template\yoga\fix-ie5-ie6.css (conditionnel au navigateur)
    |_template\yoga\fix-ie7.css (conditionnel au navigateur)
    |_template\yoga\print.css (conditionnel au média)
    |_template\yoga\default-colors.css
    \_template\yoga\theme\clear\theme.css

WARNING: Ceci représente l’ordre naturel ce n’est pas la logique des css. Si tel était le cas, le thème pourrait tout modifier, y compris les largeurs par défaut. Ce n’est pas exactement le cas.

/* Category thumbnails on main page */
#content UL.thumbnailCategories LI {
  width: 49.9%;		/* 49.9% for 2 per line, 33.3% for 3 per line*/
}

Ce paramètre de css est dans template-common\default-layout.css, il peut être surchargé dans template-common\local-layout.css (c’est normal, c’est le principe des fichiers locaux). Pour mettre 3 minitures on codera:

/* Category thumbnails on main page */
#content UL.thumbnailCategories LI {
  width: 30%;		/* 49.9% for 2 per line, 33.3% for 3 per line*/
}

A la grande surprise générale:
Si on le fait dans template-common\local-layout.css : cela sera pris en compte.
Si on veut le faire dans template\yoga\theme\clear\theme.css : cela sera ignoré.

Sur ce dernier point il n’y a pas de problème, car c’est ce que nous voulons.
Cependant d’autres directives de template-common\local-layout.css peuvent être surchargées malgré tout par le thème, sans la moindre difficulté.
template-common\local-layout.css peut contourner les règles du thème avec l’utilisation de !important (à utiliser avec la plus grande modération). En résumé, les css perturbent la logique de toute personne ayant un soupçon de bonne logique.

Dans toutes les pages, le fichier include/common.inc.php est chargé, ce qui donne l’arborescence de chargement suivante:

• include/common.inc.php
  • include/config_default.inc.php
  • include/config_local.inc.php s’il existe
  • include/constants.php
  • include/functions.inc.php
  • include/template.php

Je ne la mentionnerai plus dans le détail des pages.
Par ailleurs, dans la description des fichiers, on a au format liste, les include, au format normal, les tests et les actions.

Si le chargement de la configuration via include/common.inc.php est ok,

• include/user.inc.php
• language/<lang_code>/common.lang.php
• language/<lang_code>/admin.lang.php Si Admin
• template/<template_dirs>/themeconf.inc.php : Chargement du theme et de son instanciation
• include/section_init.inc.php : initialise les $page, notamment $page[items] et le choix du modele de miniatures, $page[’thumbnails_include’]. Il s’agit de include/category_default.inc.php ou include/category_subcats.inc.php selon qu’on veut afficher les sous-categories ou pas en miniatures (intérêt principal pour le calendrier)

Il génère la barre de navigation si nécessaire.
Si le paramètre caddie existe et $page[items] aussi, il remplit le caddie avec les éléments.

• include/page_header.php

Il génère le contenu du menu (notamment les urls des 3 derniers blocs).

• include/page_tail.php

(gérés en dehors du common.inc.php )

• act, pour action, dont voici la liste:
  • logout
• image_order : comment elles sont triées
• start: image de départ

Le fichier de recherche de commentaires. Il comporte un formulaire pour filtrer les commentaires qui sont ensuite affichés en-dessous lors du rechargement de la page. : On a ça:

if (!defined('IN_ADMIN'))
{
  define('PHPWG_ROOT_PATH','./');
  include_once(PHPWG_ROOT_PATH.'include/common.inc.php');
}

Je ne comprends pas pourquoi on place ce if. J’ai bien vu que la condition était reprise pour l’affichage du template compilé, mais je ne vois pas la différence. Je pense qu’avant, la page comments pour l’admin et la page comments du user étaient la même. Une simplification du code est possible? : les deux blocs annoncés comme comments management ne servent à rien: ça va avec la remarque précédente.

Ce fichier génère le flux RSS dont le lien est sur la page notification.php

Le script vérifie que l’utilisateur a envoyé le bon identifiant de feed, et calcule ses droits (catégories visibles).

• include/feedcreator.class.php: Classe qui va générer le fichier XML à partir des données calculées par les requêtes (La version originale).

Le flux XML est envoyé directement dans le flux du navigateur.

Fichier qui ne gère que l’authentification: formulaire avec 3 champs, et la gestion du mot de passe.

Cette page collecte les infos de connexion à la base de données. Elle la crée si besoin. Elle l’initialise avec la config par défaut de la base, plus les informations relatives aux comptes webmaster et guest.

Abonnement RSS aux infos de PWG : MAJ images, categories, commentaires.

Ce fichier permet à un utilisateur de faire générer un nouveau mot de passe, notamment en cas d’oubli: formulaire à 3 champs, avec gestion de l’envoi du mail.

• include/section_init.inc.php : comme category.php (les 2 seuls); sans doute parce qu’il a besoin du $page[’items’] pour calculer les “ranks”.

Il prépare les liens vers les images début et fin

Il incrémente les hits

Gestion du clic sur “représentant de catégorie” (droits admin)

Gestion du clic sur le caddie

Gros test pour l’évaluation (”rating”), notamment en détection de faux anonymes, etc.

Il extrait la liste des catégories contenant cette image

Préparation des infos concernant les images en cours, précédente et suivante

Le champ representative_ext est relié à /pwg_representative/. C’est pour les fichiers média non-images.

Dans la miniature spécifique se trouvent quelques explications sur l’usage qui en est fait (ce qui devrait être standard).

: ligne 365 : ajouter commentaire pour dire qu’on fait l’url de remontée (catégorie parente⇒ pas gérable par referrer?)

Création des liens pour la remontée (chemin dans le titre), le diaporama et la modif des infos

Gestion du clic sur l’ajout aux favoris

Gestion de l’ajout de commentaires

• admin/include/functions.php : pour disposer du mass_inserts ? N’est-ce pas un trou de sécurité de faire un include de fonctions admin? Ne vaut-il pas mieux redéclarer la fonction dans include/fonctions.inc.php ou include/common.inc.php

Affichage de la page avec gestion des urls dynamiques (slideshow)

redimensionnement de l’image

extraction des metadonnees (EXIF, IPTC)

Gestion de l’ajout/suppression de favoris

Affichage des informations (meta + #images)

Gestion de l’évaluation

Affichage des commentaires

Cette page sert à générer les popups d’aide avec le template voulu. Le contenu est stocké dans help/

Page qui gère la personnalisation du profil utilisateur.

Toutes les infos de bases sont dans $user.

Si la page est en validation, il contrôle les champs. Si tout se passe bien,

• admin/include/functions.php

Ensuite, il met à jour la table users qui va bien (pas forcément la sienne), puis #user_infos.

Génération d’une page en prenant des images aléatoirement dans les catégories autorisées. Le nombre de photos correspond à top_number.

Permet de s’inscrire sur PWG. Attention, aucun droit par défaut.

Le fichier convertit tous les champs de recherche en tableaux et chaines de recherche, puis stocke la “règle de recherche” dans la base (table #search), en stockant l’id de la recherche pour l’inclure dans sa propre url. Sur validation search.php reboucle sur lui-même pour stocker les informations dans la base, puis redirige vers category.php avec les bonnes options (?cat=search&search=21)

Affiche au format popupHelp les différentes clauses de la recherche passée en paramètre. Ce fichier est atteignable uniquement dans la page des résultats de recherche.

Gére les mises à jour de la base lors d’une montée de version majeure (1.x à 1.y, x<y). Les montées de version majeures sont ensuite gérées par un script cumulatif dans le dossier install.

Ces pages contiennent les requêtes SQL nécessaires à la migration de la version a.b.c dans sa version immédiatement supérieure jusqu’à la dernière version. La première page de mise à jour est appelée par upgrade.php.

Gére les mises à jour de la base lors d’une montée de version mineure: changement de BSF,1.5.x à 1.5.y avec x<y. Les montées de version mineures sont ensuite gérées par les scripts du dossier install/db.

Sert à importer des images et à les mettre en attente de validation. Le script par défaut initialise le forulaire de chargement. Sur validation, il reboucle sur lui-même et la présence d’un id de catégorie dans l’url le fait procéder à l’upload en vérifiant le respect des paramètres.

Bon, ben voilà quoi. C’est nous!

Permet de gérer les inscriptions/désincriptions des utilisateurs à la notification par mails.

Cette page est appelée avec une section (&section=xxxx). Ces sections représentent toutes les pages avec le double select.

La gestion des double select est faite avant l’affichage des pages par défaut (logique...)

Petite curiosité ligne 146:

$page['section'] = isset($_GET['section']) ? $_GET['section'] : 'upload';

Pourquoi le mode par défaut est l’upload???

Correspond à Administration>Catégories>Gérer

Correspond à l’édition des informations d’une catégorie

Correspond à Administration>Catégories>Déplacer

Correspond à Administration>Catégories>Ajout, Commentaires, Verrouiller, Publique / Privée.

Ces pages sont centralisées car basées sur une gestion de double select.

Correspond à la modification des permissions d’une catégorie

Correspond à Administration>Images>Commentaires Page de validation des commentaires

Correspond à Administration>Configuration>Général

Correspond à Administration>Images>Panier & Administration>Catégories>Gérer,Gérer les éléments

Cela permet le traitement par lot des images.

Elle inclut par défaut admin/element_set_global.php. En mode unitaire, elle inclut admin/element_set_unit.php

Gestion réellement par lot du panier ou de la catégorie.

Format de la page pour la gestion en mode global, i.e. qui affecte toutes les images (auteur, tags, catégories).

Gestion individuelle des éléments d’un lot.

Format pour la gestion en mode unitaire, i.e. les infomrations liées aux photos.

Correspond à Administration>Identification>Groupes

Assure la gestion simplifiée des groupes: création, suppression, consultation des permissions

Correspond à Administration>Identification>Groupes,consultation des permissions d’un groupe (colonne Actions du tableau).

Correspond à Administration>Général>Instructions

Correspond à Administration>Links>Administration

C’est la page d’accueil de l’administration.

Correspond à Administration>Général>Maintenance

Cette page contient notamment les actions de purge (historique,sessions, cache, feeds) et de réparation de la base.

Correspond à Administration>Général>Notification

Correspond au lien d’édition lorsqu’on visualise un image (via picture.php)

Correspond à Administration>Images>Notation

Affiche l’ensemble des notations pour les photos notées.

Correspond à Administration>Général>Gestionnaire des sites

C’est la page d’accueil. Elle permet de traiter toutes les actions sur un site, sauf la synchronisation.

Contient la classe du même nom, utilisée par site_update.

Contient la classe du même nom, utilisée par site_update.

Correspond à Administration>Général>Synchroniser

Par défaut elle présente le site local. Elle est utilisée aussi avec des paramètres pour synchroniser des sites distants.

Correspond à Administration>Général>Historique

Affiche l’historique (!) des consultations.

Correspond à Administration>Images>Tags

Création et renommage des tags.

Correspond à Administration>Images>Miniatures

Assure la génération des miniatures à la volée. Pratique pour des oublis.

Correspond à Administration>Identification>Utilisateurs

Assure la gestion des utilisateurs: recherche, création, suppression, consultation des permissions, association à des groupes

Correspond à Administration>Identification>Utilisateurs,consultation des permissions d’un utilisateur (colonne Actions du tableau)

Correspond à Administration>Images>Validation

Pour la validation des images uploadées.