On enlève son support dans SPIP, ce qui nettoie pas mal le code.
On pourrait aller plus loin peut être en ne conservant plus le fichier 'sqlite3'. À voir.
Notons au passage, si tant est que des personnes aient encore des bases de données Sqlite 2, ce qui est assez peu probable,
la documentation pour migrer indique : https://www.sqlite.org/version3.html
```
To convert an SQLite 2.8 database into an SQLite 3.0 database, have ready the command-line shells for both version 2.8 and 3.0. Then enter a command like the following:
sqlite OLD.DB .dump | sqlite3 NEW.DB
```
- des menus favoris sont définis déjà dans une fonction (surchargeable) definir_menus_favoris() et ordonnés.
- les préférences auteurs peuvent modifier ces favoris et les ordonner selon leur choix (un JS aide en cliquant les labels)
- il est possible dans le formulaire de préférence de revenir aux valeurs de menus favoris par défaut
Le bouton apparait si la personne qui edite a le droit de modifier le mot de passe.
Un nouveau mot de passe aleatoire est defini et on envoi un mail sur la base de modeles/mail_nouveaux_identifiants.html qui peut etre personalise
Dans le header, on met l'id_auteur de l'auteur connecte au survol de son nom (dans le title) pour permettre de le retrouver. L'url reste exec=infos_perso car elle n'est de toute facon pas visible dans tous les navigateurs. On a garde cette URL car on ne sait pas definir exec=auteur&id_auteur=xx dans la definition de l'onglet dans le paquet.xml
On passe par un appel à objet_modifier_champs avec une nouvelle action 'completer_traduction' qui permet à d'éventuels plugins d’ajouter des champs
à compléter au moment d’une création de traduction, ou de faire d’autres actions à ce même moment, en utilisant les pipelines pre_edition ou post_edition.
Ici on ajoute simplement un formulaire permettant de cocher des entrées "favorites " sur les menus principaux.
Ce formulaire est pour l'instant ajouté sous le formulaire de préférences actuel.
Note: j'avais tenté de l'intégrer directement dans le formulaire de préférence, mais ce n'était pas pratique
à l'usage à cause de l'auto-submit sur ce formulaire.
Du coup, pour ne pas casser de trop la compatibilité, on mappe l'ancienne utilisation $.cookie() sur le nouveau Cookies.get() / Cookie.set() en ajoutant un log de dépréciation.
Ici c'est la version "développement" qui loge en console les utilisations dépréciées.
Pratique pour lister les .bind, .unbind et consœurs qui ont disparu en jQuery 3.1.
La fonction aide_lang_dir() est transférée dans inc/lang.php car elle n'est plus uniquement utilisée pour l'aide mais aussi pour les br.
Le serveur d'aide est aussi transféré dans le plugin.
La conséquence temporaire de cette manip est que l'aide n'est plus disponible lors de l'installation. Il faudra voir comment réintroduire ces compléments d'information plus tard mais ce serait mieux que l'installation soit totalement autoporteuse.
- la page plan du core est simplifiée et ne liste que les rubriques, tout simplement.
- sa décoration est allégée au passage.
- les inclusions `prive/squelettes/inclure/plan-{objet}.html` ne sont plus appelées par le Core (hormis pour les rubriques)
Le plugin plan, lui, surchargera tout cela.
À noter que les anciennes inclusions `prive/squelettes/inclure/plan-{objet}.html` changent d'écriture avec le plugin plan ;
si des plugins ajoutant des objets éditoriaux (hors de ceux fournis avec SPIP — articles, sites, brèves —) possédaient un tel fichier,
il devra être actualisé.
Le sélecteur utilisait une version perso de jQuery UI pour sortable qui clashait avec celle du plugin dist éponyme. Du coup, cela cassait les éventuelles saises de date en présence d'un sélecteur dans la page (avec polyhierarchie par exemple).
On mime le comportement du dateur pour brancher le sortable du sélecteur sur la version de jQuery UI proposée par le plugin dist.
Au passage, cela répare la compatibilité du plugin polyhierarchie avec SPIP 3.1
avec des rôles.
On intègre l'API présente actuellement dans le plugin Rôles, en modifiant
un peu les fonctions d'édition de liens.
Celles-ci permettent maintenant d'éditer des liens ayant donc des rôles.
Ces différents rôles et le nom de la colonne SQL qui les reçoit,
s'ils sont utilisés, doivent être déclarés avec la déclaration
de l'objet éditorial correspondant.
Un exemple est donné avec le plugin «Roles auteurs» qui définit
quelques rôles. Les champs décrivant les rôles : `roles_colonne`, `roles_titres` et `roles_objets`
doivent être déclarés (via le pipeline declarer_tables_objets_sql).
```
"roles_colonne" => "role",
"roles_titres" => array(
'redacteur' => 'info_statut_redacteur',
'traducteur' => 'roles_auteurs:traducteur',
'correcteur' => 'roles_auteurs:correcteur',
'relecteur' => 'roles_auteurs:relecteur',
),
"roles_objets" => array(
'articles' => array(
'choix' => array('redacteur', 'traducteur', 'correcteur', 'relecteur'),
'defaut' => 'redacteur'
)
#'*' => array()
)
```
Une fois déclaré, on peut appeler les fonctions d'édition de lien
en transmettant des valeurs de rôles, tel que :
```
objet_associer(
array('auteur' => 3),
array('article' => 11),
array('role' => 'correcteur')
);
// utilisera le rôle par défaut
objet_associer(
array('auteur' => 3),
array('article' => 11)
);
```
Si aucun rôle n'est indiqué, le rôle par défaut est appliqué.
Dans le cas d'une dissociation également, si aucun rôle n'est indiqué,
seuls les liaisons avec le rôle par défaut seront supprimés ; pour
supprimer tous les rôles, il faut à ce moment là indiquer '*' :
```
objet_dissocier(
array('auteur' => 3),
array('article' => 11),
array('role' => 'correcteur')
);
// utilisera le rôle par défaut
objet_dissocier(
array('auteur' => 3),
array('article' => 11)
);
// enlèvera tous les rôles
objet_dissocier(
array('auteur' => 3),
array('article' => 11),
array('role' => '*')
);
```
Le formulaire d'édition de liens n'utilisera pas les mêmes squelettes
de liaison lorsqu'une colonne de rôle est déclarée.
Ainsi dans cet exemple, au lieu de `prive/objets/liste/auteurs_lies.html`
et `auteurs_associer.html`, cela utiliserait `prive/objets/liste/auteurs_roles_lies.html`
et `auteurs_roles_associer.html`. Il faut donc créer ces squelettes.
Ces squelettes peuvent poster les valeurs au formulaire pour insérer
de nouveaux liens, de la forme `qualifier_lien[auteur-3-article-11][role]`
en postant `redacteur` par exemple.
Il est possible au passage de poster en plus d'autres valeurs, qui seront
intégrées dans l'enregistrement du lien.
Ainsi, poster en même temps `qualifier_lien[auteur-3-article-11][valeur]` = `50`
enregistrera la valeur 50 dans la colonne `valeur` de la table de lien (qui doit
exister !).
D'autres informations sont présentes dans http://contrib.spip.net/Des-roles-sur-des-liens,
http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles_auteurs ou encore
http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles
+ refactoring : l'action iconifier disparait totalement, le code qu'on en utilisait est integre a formulaires/editer_logo.php en supprimant le code mort
nicod_
spip
