Cahier des charges de la migration Drupal6

Cahier des charges général

• logiciel libre
• production de code HTML
  • accessible
  • valide W3C
  • ne nécessitant pas javascript dans la partie publique
• rôles de contributeurs donnant accès à des fonctionnalités différentes. À minima:
  • contributeur
  • administrateur/webmaster
  • superadmin
• système de contrôle de versions des objets éditoriaux, revert possible
• aspect graphique identique à l'existant ou proche (un rafraîchissement du style peut être proposé, notamment pour améliorer le mobile)

Cahier des charges de migration

Les URLs doivent être toutes conservées et mener au contenu migré. Pour cela, le CMS doit soit associer le contenu aux mêmes URLs, soit, si ce n'est pas possible, mettre en place une redirection via htaccess ou équivalent.

Les fichiers uploadés doivent être accessibles sous les mêmes conditions d'autorisation.

Fonctionnalités éditoriales attendues

Page d'accueil

Citation du moment: affichage d'un article de type citation pris au hasard

Flux RSS: configurables à partir de l'interface d'administration ou du template (LinuxFR, AdL, Lolix, ...)

Bandeaux de campagnes: idéalement configurables à partir de l'interface

Dernière vidéo: dernier article de type video, avec métadonnées affichées (chapo) + vignette

Nuage de tags: chaque article doit pouvoir être taggué

Revue de presse, actualités, communiqués: derniers articles de type presse, actualités, communiqués

Édition des articles

Édition par saisie via formulaire web de code HTML et/ou markup, éventuellement en mode wysiwyg si production de code propre et récupération de l'existant.

Workflow éditorial: un auteur saisit un contenu, le maque comme en cours de rédaction ou proposé, puis le contenu est validé et publié. Éventuellement, possibilité de programmer la publication d'un contenu.

Révisions, possibilité de retour en arrière.

Upload de plusieurs fichiers par article, insertion dans le corps de l'article, éventuelle vignette.

Il est possible d'associer un ou plusieurs chemins d'URLs spécifiques à un article.

Types de contenus éditoriaux

Champs customs types par types.

Articles réservés aux membres

Catégorisation des articles, possibilité de personnaliser la page listant les articles.

Multiliguisme

Le site doit pouvoir fournir une version Française, mais aussi Anglaise avec une navigation et des contenus différents.

Vues

Il doit être possible de mettre en places des vues permettant par exemple (et en conservant les URL actuelles):

• de produire des listes de pages par taxonomie (présentations d'Apriliens, FAQ, histoire de l'April, revuer de presse, vidéos, citations, etc.)
• la bibliographie, classée par type
• un calendrier des évènements (sous différents formats: HTML, RSS/Atom, ICAL)

Recherche

Le CMS doit fournir un outil de recherche, éventuellement permettant des pratiquer des recherches complexes sur les metadonnées des articles.

Webmastering

Idéalement, on doit pouvoir mettre le site web en blackout ou maintenance sauf pour les webmasters.

Le CMS doit pouvoir fournir des pages 404 personnalisées, éventuellement adaptatives (outil de recherche, proposition de contenu).

Le CMS peut proposer des outils de SEO, en adéquation avec les valeurs de l'association.

Intégration au SI

Formulaire de contact

Un formulaire de contact permet de sélectionner un type de demande, de saisir un texte et d'envoyer un courriel à un ensemble de destinataires pré-configuré.

Intégration des statistiques de la base des membres

Il est possible d'afficher dans certaines pages des indices sur les nombres de membres, idéalement par l'interpolation d'une variable extraite à partir de la base des membres.

Intégration à /my

La page personnelle du membre est intégrable comme partie du site, en reprenant la charte graphique générale et en s'authentifiant comme membre.

Une page permet de se renvoyer le mot de passe

Formulaire d'adhésion

Le formulaire d'adhésion est intégré au CMS, tout comme /my/

Trombinoscope, équipe, page des personnes morales =

Ces pages sont intégrées au CMS tout comme /my/.

Authentification gDTC/SSO

Il est possible d'utiliser gDTC comme base d'authentification des membres et ainsi d'implémenter le SSO. Idéalement, les membres du CA et permanents ont des droits étendus ajoutés.

La création de nouveaux comptes par les utilisateurs est fermée.

Alexandrie

Les articles récupérés par le bot Alexandrie sont récupérables par le CMS sous la forme d'un type d'article particulier, avec des champs spécifiques.

Fonctionnalités administratives attendues

Fonctionne en Debian stable (stretch au 13/03/2018)

Sauvegarde du corpus dans une base MySQL

Support full HTTPS

Supervision possible des nouvelles versions disponibles, des alertes de sécurité.

Facilité d'application des patches de sécurité.

Supervision du fonctionnement nominal, envoi d'alertes par le CMS en cas de besoin, journal d'évènements.