Présentation:

Anomali Web est le projet de développement du site internet http://nonmarchand.org

Actuellement, le site est développé sur la base du logiciel libre PmWiki, agrémenté de quelques cookbooks.

Pour participer au développement, contactez pour l'instant Benjamin Grassineau

Espaces non-marchands de Anomali Web:

Connectez-vous ou inscrivez-vous pour pouvoir contacter cet utilisateur.

Zone d'expression :

A faire

• Notification par email (ne marche pas). Paramétrer le Smtp. A voir un jour, le système de mdp perdu.
• L'interface graphique d'édition (boutons absents sans raison).
• Pbme de captcha sur le wiki (bug ?). Pas nécessaire pour le moment.
• Créer un site images (commencé, mais pas terminé sur toile-libre).
• Améliorer les recherches en créant une fonction matchstring plus performante (pas de pbme de retour à la ligne)
• Créer un markup conditionnel pour les pages annonces, agenda et groupes (si auteur=nompage) (gain de place).
• Créer une fonction itérative pour le pagelist par variables (pour l'instant, est basé sur un include)

Carnet de bord

• 03/01/2013
• Il y a un bug sur l'affichage des modifications récentes. Très ennuyeux !! (résolu)
• Grosses améliorations
  • Tout est désormais stocké dans des variables textes (sauf annonces, groupes et agenda).
  • Recherches par variables (à améliorer) abandon de fmt=extract
  • Edition par variables
  • Maj de la date dans les tableaux
  • Sécurisation des formulaires
  • Suppression du suivi des objets (trop lourd)
  • Ajout de l'option page publique privée.
  • Amélioration du compteur
  • Limitation des pages à 30 enregistrements.
  • Orientation de l'ergonomie vers l'enregistrement de listes pour les gros volumes de prêts, dons, etc.
  • Redirection pour les pages sensibles.
  • Migration agenda et annonces sur le portail.
  • les annonces sont publiques (édition)
• 17/10/2012
  • Ajout du plugin htpasswdform pour l'enregistrement sur le site.
  • Styles basculés vers le group header ou vers le fichier config.
• 21/09/2012
  • Intégration des textes persos et des pages de discussion dans les espaces persos.
  • Simplification du système d'enregistrement des utilisateurs avec htpasswd
• 13/08/2012

Modification de l'url (cleanage). + petite modification groupes (parenthèse enlevée).

• 25/07/2012

amélioration du classement des média. construction bdd et maj des formulaires.

• 02/06/2012

Corrections mineures sur les formulaires de groupe (ajout groupes et catégories qui ne marchaient pas). Liens anomali web modifié dans le footer.

• 27/02/2012

J'oubliais la dernière fois. Il est important de faire des tests au niveau de l'édition simultanée de plusieurs formulaires, avec arrêt de formulaire en cours de route. J'avais réfléchi à des problèmes possibles récemment.

• 24/02/2012

Bon, le moins qu'on puisse dire, c'est qu'après un travail acharné, le site a sacrément muri depuis 3 mois. En gros, j'ai considérablement amélioré le stockage des données dans les fichiers medias, activites, etc. J'ai supprimé quelques groupes, le forum, etc, pour mieux organiser le site. J'ai finalisé le principe d'identifiant qui contiennent de l'info, pour les objets sdf. J'ai constitué une base de données type flat, pour les lieux, objets, activités et catégories de medias. Adieu les mots-clés... Restructuration des formulaires tous déplacés vers la page gestioncompte. La plupart des formulaires ont été déplacées vers les pages modele et b. Ajout d'une possibilité de changer la langue. Amélioration du système d'administration.

Gain considérable en terme de place... et beaucoup plus clair.

A faire.

• Actuellement, la principale faiblesse du site, vient que les formulaires stockent des sortes de variables temporaires sur le dd du serveur. C'est lourd en terme d'efficacité. L'avantage, c'est la simplicité du truc, et le fait que ça n'utilise pas les cookies. Une solution. Matérielle. De nouveaux dd permettent un accès plus rapide (seulement 10 à 100 fois plus lent que les ram). Code. La première chose à faire, c'est de limiter les formulaires. En particulier, le choix des catégories pourrait se faire via une redirection. les variables temporaires seraient chargées dans la page gestion compte. Seul souci, que faire lorsqu'un internaute stoppe un formulaire en cours de route... Pas ingérable, mais à étudier.
• Je pense qu'il serait possible d'améliorer le système de connexion. A moins d'automatiser l'inscription sur chaque site. ca ne presse pas. Reste encore à fractionner en sous-domaine. Mais là encore, ça ne presse pas.
• Un truc tout bête à faire également, c'est de modifier le style des listes avec le css sur la colonne de gauche.

• 21/11/2011

Le soir (bonne brise !)

Suite à modification des formulaires de recherche, je m'y remets car j'ai plein d'idées en tête...

L'objectif est de réfléchir au conditionnel. Si le site grossit... Peut-être ne grossira-t-il jamais, mais en tous les cas, il faut y réflechir dès maintenant, au cas où.

Alors, comme dit plus bas, la première chose à faire c'est de créer un fichier htaccess qui contienne trois données : login, mdp, lieu. Chaque triplet est unique.

• Seul le fichier lieu sera accessible par l'utilisateur.
• Il devra se connecter au site administration, qui contiendra les pages de moderation sensibles (et sera super blindé), pour le modifier.
• Il devra être accessible à partir des différents sites (entreposés, probablement, sur des serveurs distincts).
• Il doit être rapidement mis à jour sur les serveurs. Par exemple, le fichier pourrait être copié automatiquement toutes les heures (mettre un message pour l'expliquer, lors de la première inscription).

Le site est ensuite scindé en plusieurs sites. Peut-être est-il intéressant d'avoir un nom de domaine pour faciliter les choses.

Deux groupes automatiquement par domaine, moderation, administration.

Domaine /administration

L'enregistrement, la sélection des lieux, objets, etc.

Domaine /utilisateurs/pmwiki

• Les pages utilisateurs. Elles sont conservées. Pas de gros changement.

Mais elles sont regroupées avec les pages textes perso et utilisateurs.

• Si le site grossit. Partitionnement des utilisateurs par ordre alphabétique, tout simplement.
• Au niveau de la structure des pages. Rien à modifier pour l'instant, si ce n'est les liens vers les nouveaux espaces. Plusieurs solutions sont possibles.

1. Créer automatiquement les espaces. 2. Renvoyer à une page de création, sur le site en question, avec lien. C'est une meilleure solution, car elle prend moins de place. Mais il faudra alors abandonner l'onglet créer un nouvel espace, à moins de faire un include de l'autre site (problématique question sécurité). Ou peut être récupérer seulement une variable ? (technique)

Nb: un classement par lieu pourra facilement être mis en place par dessus.

Estimation: le site peut à mon avis encaisser sans trop de difficultés 30.000 utilisateurs. L'avantage est de pouvoir partitionner si nécessaire par nom. De plus, les pages de discussion et les textes persos sont hors recherche, d'où allègement du serveur.

Le lien vers la page utilisateur. Il faut le créer dans les signatures. Peut-être améliorer le markup si nécessaire.

Domaine /encyclopédies/pmwiki

Pas de changements notables, si ce n'est que les espaces textes perso et discussions sont déplacés.

L'encyclopédie peut être partitionnée par thèmes, pas de souci à ce niveau là.

L'encyclopédie peut encaisser trente mille pages, puis être découpées ensuite en sous-encyclopédies

Domaine /laboratoire/pmwiki

Pas de changements à prévoire. Evolution lente.

Domaine /médiathèques/pmwiki

Le gros du site, en terme de ressources. Finalement le partitionnement par lieu n'est pas logique, car le nom contient assez aisément une référence au lieu. Un tableau associatif basique suffit.

Le partitionnement doit donc se faire par catégorie. Ce qui allègera considérablement les recherches.

L'interaction est faible sur les médiathèques. Seul un souhait est posté. Ce qui facilite une migration. Le souhait comprend juste un lien vers la page utilisateur, et c'est tout. Eventuellement, il serait intéressant de réfléchir à un système de connexion automatique. Est-ce compliqué ? Aucune idée !

Les medias SDF sont stockés dans un groupe à part. Celui-ci est structuré par les mêmes catégories que la bibliothèque. Il peut devenir gros en ressources, aussi sera-t-il peut-être nécessaire de le partitionner. Malheureusement, à ce niveau, je n'ai pas de solution... S'il faut renoncer à faire un post automatique sur le groupe, il faut recourrir à un suivi manuel. Ce qui finalement, n'est peut-être pas plus mal. Ca obligerait à s'investir dans la rédaction d'un petit post sur l'objet. Ensuite, si jamais c'est le cas, il est très facile de partitionner le groupe, et de l'entreposer sur des serveurs distincts.

Domaine activites/.

Pas de difficultés à ce niveau. Partitionnement par type, si nécessaire.

La structure interne des pages devrait peut-être être modifiée. Actuellement, c'est trop lourd.

Domaine objets/

Idem.

Concernant la structure des pages, je pensais à une structure du type vis:disponible (peut contenir le nom de l'emprunteur), visdescription:texte, et c'est tout. Le tout étant stockée dans la page, avec un fox delrange. Comment générer ensuite la page ? Idée, limiter la page à 30 objets dans une catégorie. Ensuite, la génération se fait automatiquement. Mais il faut coder un truc en php pour ne pas inclure inutilement.

Ou plus simple, inclure juste la variable dans un foxdelrange, avec un include. Trente pages ne devraient pas fatiguer le serveur.

La recherche se fait ensuite grâce à une recherche de variable, soit sur le nom, soit sur le contenu de la variable.

Les liens entre pages objets, groupes et activités. Il n'y aura plus les liens entrants, seulement les liens sortant.

La question difficile. Que faire des objets empruntés ? S'il y a séparation du groupe objets, comment gérer ? Plutôt qu'une solution technique complexe, il peut être ingénieux de laisser l'utilisateur remplir lui-même, en faisant apparaître un onglet, indiquer que vous avez emprunté un objet ? Seul soucis, récupérer les variables objets et utilisateurs. Pas de solution pour le moment.

Domaine groupes/

Partitionné en trois sous-groupes : groupes, membres, fiche groupe. Ca devrait suffire.

Domaine zg

A la différence des autres, l'information pertinente est le positionnement géographique, en plus le nom de la zone ne contient pas nécessairement le lieu. D'où partitionnement par lieu. C'est essentiellement une page informative et qui plus est, largement publique, donc, pas de souci particulier pour la scission.

Domaines navigation/

Comprend les pages d'aides, le sommaire des recherches, l'enregistrement dans les formulaires.

Idéalement, il faudrait une variable de session (constante ?) qui permet d'indiquer que c'est une recherche, un formulaire (si oui, quel groupe enregistrer ?). La liste serait la même dans tous les cas. Seul le formulaire serait modifié.

Mais c'est peut-être plus safe de le déplacer dans des pages à part, en bout de course (pas besoin, dans les pages de recherche) noms correspondants : recherche, formulaire. Ca ne multiplie que par deux, les pages de catégorie 3.

Pages objets, lieux, activités, Groupes.

Elles sont toutes supprimées, et transformées en listes de variables, soit sur le site administration, soit sur le site navigation, soit sur les domaines respectifs. Quelle est la meilleure solution ?

Le plus logique est de les entreposer sur les domaines concernés. Elles seront structurées sous la forme d'une liste, comprenant deux niveaux de catégories. Ex: Bricolage/Outil/Scie Bricolage/Accessoire/Vis. Ensuite, en cliquant sur le lien, l'utilisateur récupère l'information et l'insère dans le formulaire. au pire, s'il y a scission, les catégories sont réinjectées dans le nouveau groupe.

Soit 30 pages environ, maximum. (1 page des catégories principales contenant 30 catégories, contenant elles-même 30 sous-catégories/Chaque sous-catégorie contient 30 objets. Soit 30^3 = 2700 objets. C'est suffisant.

Idem pour les activités et les groupes.

Au niveau administration de la ferme

Ce n'est pas à proprement parler une ferme, puisque les wikis sont indépendants.

D'abord, une estimation. Je pense qu'ainsi conçu, le site peut encaisser une charge de 100 000 utilisateurs avec très peu de moyens. J'entends par là qu'une petite équipe de trois quatre personnes peut le maintenir sans difficultés, et qu'il n'occupera pas non plus grave de place, et ne consommera que peu de ressources.

Niveau bande passante, et recherche, le problème devrait être largement résolu par la répartition des sites sur différents serveurs.

Quant à la taille mémoire :

Comptons en moyenne 50 ko par page en estimation haute. En fait, c'est beaucoup. Les pages wiki atteignent rarement ces tailles, et de nombreux utilisateurs ne rempliront pas leurs espaces.

Au delà, c'est irréaliste. Car il n'y aura jamais autant de monde à pratiquer les échanges non marchands.

Pour limiter la place, il faut clairement limiter les diff.

Domaine Utilisateurs : 100 000 x 50 ko x 3 = 15 000 000, soit 15 GB.

Curieusement, c'est potentiellement un des plus lourds. sans compter le problème probable des photos, liens poubelles, etc. Seul deux systèmes de recherche (par lieu) indexé sur le nom, donc, cela devrait aller vite, par catégorie. En espérant que pm tienne le choc...

Domaine Objets. 1 seul groupe. 5 gb.

Idem pour les autres : A, O et G., soit 15 GB.

Domaines SDF.

Le point sensible. Toute la difficulté, c'est que ça pourrait facilement atteindre les 1 OOO OOO d'objets. 1000000 de pages, pmwiki crashe, même en partitionnant bien, ça va être fastidieux. C'est là où il est le plus tentant de recourir à une base de données.

Ca me revient, j'ai pensé à une solution plus simple. Chaque objet (catégorie) a une page sdf, sur laquelle, les utilisateurs inscrivent le nom de code et la description. Ca limite à 3000 pages. Nettement plus gérable... (150 MO)

Par contre, les medias sdf sont plus problématiques. Mais il n'y a guère de solutions. Il faut partitionner par type (audio, vidéo, etc.), puis par catégorie. Relativement simple, car le lien dans une médiathèque pointera automatiquement vers la médiathèque. Quant à la recherche par code. Elle peut se faire via google. En tout, on peut bien compter 10 000 000, soit d'objets SDF, à mon avis, au niveau bande passante, le tout étant à diviser par 30². soit 900, ce qui donne : environ 10 000 par pages par catégories de rang 2. Gérable. Au niveau place, en revanche. On peut compter 500 000 000 Ko, soit, 500 GB. Ca commence à peser !

Encyclopédies. Je dirais au maximum 100 000 pages par thèmes (dans 50 ans !!!), d'où, 15 Go.

Zones gratuité. Je doute qu'on atteigne des niveaux monstrueux. 10 000 zones. Un grand rêve...

Voilà, en gros, le tout devrait peser dans les 600 Go. Enlevons les medias sdf, et ça tourne autour de 100 Go. Ce qui n'est pas grand chose (en terme de bande passante, par contre..., mais la charge doit être distribuée.) Sauf à trouver un système plus gérable pour les medias SDF. Un moyen simple est peut être de coopérer avec le site bookcrossing. A terme. Finalement, il serait tout à fait possible d'utiliser les identifiants et l'espace d'enregistrement du site et de renvoyer le lien vers leur site. Ou alors, pour les livres en bookcrossing, recours à une bdd.

Mais le plus simple est de rester sur la même ligne ! Voilà le système qui serait envisageable. Le code lien pointe vers une page wiki qui contient 30 codes sdf. Quel classement ? Basiquement, par catégories, avec insertion de la variable depuis la page d'enregistrement. Tout à fait faisable, puisque le partitionnement des médiathèques devrait comporter 30 catégories de rang 3. Attention, toutefois, lors du réengistrement à bien spécifier la catégorie du media, pour l'insérer dans la bonne médiathèque. D'où division de la place comme suit : 10 000 000 / 30. soit 3OO OOO . Ouf !! 15 GB.

Donc, on arrive bien à 100 Gb.

Si je multiplie par 1O, il faut rajouter, je dirais un Tera octet. Qui dit mieux !!

Vers midi (acalmie...)C'est une meilleure solution, car elle prend moins de place.

Bon alors, après mures réflexions...

Je pense qu'il n'y aura pas forcément de gros problèmes avec le site. La seule chose à prévoir, peut-être, c'est de réduire au maximum les pagelist pour ne pas encombrer le serveur. Le stockage à plat ne semble pas poser de difficultés.

http://www.languefrancaise.net/PmWikiFr/IndexDocAdmin

Reste que le passage des groupes lieux en variables doit être fait (idem pour les groupes activités et objets...).

avec cette variable, ça permettrait d'alléger les pages de formulaires. http://www.pmwiki.org/wiki/PmWiki/EditVariables#EditRedirectFmt

Tôt le matin (coup de tempête)

Sinon, si ça vient à foirer, il faudrait partitionner le site en zones géographiques.

Le partitionnement peut être fait sur le même serveur, dans un premier temps, puis être dispatché sur plusieurs serveurs.

Il serait assez logique, à ce niveau, que ce soit des membres organisateurs de l'association qui l'hébergent sur un serveur dédié, voire sur un poste individuel, à l'instar d'un jeu en réseau. A développer...

Ce qui doit être commun aux différentes zones.

• Les identifiants utilisateurs.
• Les emprunts en cours (optionnel: si pas d'alternatives).

Le reste peut être géré sur les ensembles géographiques respectifs.

Au niveau de l'adressage. L'information doit être contenue dans le nom du répertoire qui contient l'installation. pmwiki deviendra France...

Il faudrait, à ce niveau, que la base de données contienne les deux informations (login/mdp) et lieu, afin de répercuter l'information dans les signatures.

Seconde étape, il est unitile de garder les pages lieux, objets et activités. Elles peuvent être générées à partir d'un modèle.

Ide

• 20/11/2011 : Quelques réflexions pour la suite.

D'abord, trois choses à faire pour la version 1.0. Un répertoire des variables. Normaliser le nom des variables. De la place à gagner dans les formulaires.

Au niveau des variables. J'en distingue trois catégories principales.

• Variables d'espace. Elles indiquent une information sur la page. Je les nommerais bien de la forme Lieu en conservant la majuscule au début.
• Variables de tableau. Elles informent sur un enregitrement. Deux types.
  • Variables de description. Définie ainsi MC, OR, etc. avec l'identifiant.
  • Variables temporaire. Par exemple, qui a prêté l'objet. (sp ?)
• Variables de formulaire.
  • Variables de visibilité des formulaires (elles commencent par un v)
  • Variables telles que objets, activités, utilisateurs, etc. C'est un peu le désordre. Attention, elles sont généralement connectées aux pagelist.

Je pense aussi qu'il y a un souci d'affichage en cas de crash du site, il affiche un message d'erreur en haut du site, tout moche ! deux failles, semble-t-il. L'édition simultanée, qui est foireuse avec fox. La deconnexion au bout d'un certain temps d'édition.

Sinon. J'ai pas mal réfléchi aujourd'hui, aux problèmes qui pourraient se poser si le site montait en puissance. Ce serait un peu dommage d'arriver à un crash au bout de 20 utilisateurs !!

Or, extrapolons, par un pur jeu d'esprit. Supposons qu'il y ait 10 000 utilisateurs inscrits. Cela fait potentiellement 50000 espaces sur le réseau non-marchand. Ajoutons au moins 5000 lieux. 2000 objets, etc. Comme les pages gardent un historique, ça peut vide devenir ingérable.

La question à vérifier, c'est, est-ce que le page list est plus rapide avec les liens ou avec les variables ?

Alors, réponse. Ca dépend semble-t-il du nombre de liens et de la quantité de texte. Le problème, c'est que le pagelist va chercher la variable dans le texte, et les liens dans un index des liens. Cela dit, globalement, la recherche est plus rapide avec les liens. [problème résolu]

Quoi qu'il en soit. Il y a au moins deux manières d'optimiser la recherche : en scindant par groupes. C'est le plus simple, et le plus cohérent. En limitant la quantité de textes, peut-être, saute-t-il les directives ?

Mon idée est la suivante. Supprimer les pages lieux. Crée une base de données hiérarchiques. Seul souci, dans ce cas, il faut faire une recherche avec la variable. Est-ce une bonne idée ?

A voir. La base est faite sous forme de textes. l'utilisateur la consulte, puis sélectionne input select son lieu dans la liste. Ca modifie la variable sur sa session.

Cela peut être plus simple... pas sûr. Le problème est de trouver un moyen d'ouvrir une session. mais la probabilité pour que les deux variables soient postées en même temps est faible. Admettons, cette page pourrait n'être accessible qu'a l'utilisateur qui a cliqué sur le lien (lastmodifiedby).

Pour ce qui est des objets et activités, ça pourrait être la même chose. Dans ce cas, les variables seraient stockées dans les espaces personnels sous la forme de variable nomobjet:apreter admettons qu'il y ait trois ou quatre variables liées: description, emprunteur actuel, disponibilité (ça suffirait).

Donc, reprenons. Supposons qu'il y ait 200 objets par personne dans un espace. ça fait un truc comme 20000 objets à tester pour une recherche, dès qu'il y a 100 personnes. Probablement long.

Pour les objets sdf. Le schéma pourrait être le même. Stockage sur un autre serveur. Chaque objet comprend plusieurs identifiants avec deux variables: description, suivi. le stockage par objet permettrait de limiter les problèmes de recherche. Seul souci, pas possible de poster le suivi sur un autre serveur. a moins de copier le fichier access, et de mettre une action de connexion simultanée. Ca pourrait marcher.

Partitionnement géographique. compliqué à mettre en oeuvre, notamment en cas de transactions entre personnes qui sont de lieux différents...

Néanmoins, après une longue réflexion, ça me paraît être la meilleure solution.

Les pages Utilisateurs, Lieux, Activités, Objets, peuvent être convertis en variables.

En tout, leur nombre devrait se limiter ainsi :

Objets et activités, pas plus de 2000 chacune. effectuer des regroupements au besoin, et étendre la possibilité de décrire avec précision, ce que l'on fait. Lieux environ 2000 par pays. Ca parait suffisant. De toute façon, ça ne va pas changer grand chose.

Les Utilisateurs peuvent être classés par ordre alphabétique, tout simplement.

Le stockage peut se faire dans un fichier wiki. La particularité est que ces pages doivent être:

• robustes en supportant l'édition simultanée (fox paraît un peu léger pour cela)
• supporter le multisessions
• être accessibles des différents sites.
• être capables de transporter la variable sur le site d'origine.

Une fois la variable récupérée sur le site d'origine, elle est réutilisée dans le site.

Les pages lieux, objets, etc. sont affichées avec une modification de variable.

Reste le découpage... Deux choses sont fixes: l'utilisateur, les espaces (définis par le nom utilisateur). Le partitionnement par lieu paraît compliqué, parce qu'il implique de recréer à chaque fois les espaces sur un autre serveur. Pas impossible mais inutile. Ce qui serait faisable, c'est un partitionnement par sous-espaces d'activité. etant donné que ça, ça ne varie pas. Dans ce cas, le site serait progressivement découpé en boîte de rangement plus fines. médiathèque du voyage, médiathèque généraliste, etc. Reste que les transferts d'infos entre les serveurs seraient alors sûrement assez lourds.

• 19/11/2011 : Le site passe en version 1.0. Scission du site en quatre parties. Débogage des formulaires dans les tableaux. Allégement du format d'enregistrement des données dans les tableaux.

Enfin la vraie version Beta !!!

Comme dit plus haut, ça marche!! A priori, plus que des bugs mineurs. Merci de me les signaler si vous les voyez. J'ai également amélioré grandement les textes de présentation, ainsi que la présentation des pages textes.

Reste désormais à réfléchir sur un éventuel ralentissement du site, au fur et à mesure que les pages grandissent.

• D'abord, alléger les formulaires. Gros travail de simplification à faire sur le group header du réseau don emprunt objets. Réduire le nombre de variables.
• Ensuite, limiter le nombre de pagelist.
• Enfin, partitionner le site.
  • Le réseau de médiathèques peut être mis à part.
  • Partitionnement par lieu. C'est ce qui me paraît le plus simple. Cela demandera probablement l'activation d'une base de données du type sqlite.
• 15/11/2011 : Démarrage du carnet de bord. Suivi des bugs, etc.

Actuellement. Amélioration de l'affichage sur les pages groupes, objets, activités. Le rattachement est désormais centralisé dans une page modele. Il y a quelques jours, j'ai également transformé le bouton modifier dans les tableaux, en include. Une incertitude demeure : est-ce que ça va manger trop ou pas de ressources systèmes.

Projets :

• Si le site rame, comment faire ?
  • Alléger au maximum les pages, tout d'abord, en éclaircissant le code.
  • Séparation progressive en sites distincts (médiathèques, encyclopédies, etc.) En principe, les données sont structurées, ce qui devrait faciliter une migration. Par exemple, scission du site médiathèques en sous-catégories.
  • Intégration d'une base de données, sur le modèle du site permaculture.
  • Peut-être est-il possible de gagner encore sur l'enregistrement des données.
• Amélioration du système d'enregistrement des médiathèques. Utilisateur peut choisir sa catégorie, en plus de celles qui existent..

Archives

• Activités ponctuelles. Solution: inscrire le nom de l'objet ou de l'activité dans la variable description ensuite, recherche par mots clés dans la page objet ou activité. Cela ne concernera que certaines activités : stop, ou certains objets : plantes (graines, plante, etc.) seul problème, un markup doit permettre de supprimer les accents et caractères spéciaux ou alors, le faire au moment de la création de la page objet ou activité (pour les activités seulement celles qui sont du type transport)

Discussions (Éditer):