- Je monte la version de saisie (en gardant la même branche pour réduire le risque de casse) pour être certain que si un jour, un commit qui concerne l'un des plug et saisie, que la version de saisies soit une version sûr !
- + broutilles (exemple, mise en adéquation de borne mini de plug dans les "necessite" avec la version de spip pour quoi le plug est fait)

Après l’importation du fichier odt, le statut de l’article est « en cours de rédaction » et non pas « proposé à l’évaluation ».

Et corrections d’erreurs PHP lorsque le document contient des images dont la taille n’est pas indiquée (peut être du à la conversion doc > odt et la version de libreoffice utilisée pour le faire).

Sur le serveur, /tmp n’est pas toujours accessible pour l’application libreoffice, et notre tmp/odt2spip y fonctionne.
On permet donc simplement de définir _LIBREOFFICE_HOME pour les tests locaux éventuels `define('_LIBREOFFICE_HOME', '/tmp');`

Par précaution, aussi, on nettoie régulièrement le répertoire tmp/odt2spip.

Principe :
* Sur le serveur de conversion (A) : installer un SPIP, libreoffice et activer odt2spip. Créer des clés d’Api nécessaires en configuration.
* Sur un autre site SPIP (B), activer odt2spip, renseigner en configuration l’URL du site spip de conversion, et la clé d’API.

Lorsque le site B charge le formulaire document2spip, il regarde s’il peut convertir les documents,
- soit lui-même (s’il a accès à l’application libreoffice)
- soit via un serveur, si la configuration est renseignée.
- s’il peut, il permet de charger des documents odt, doc(x), html, pdf. Sinon… uniquement odt.

Si un document F non .odt est envoyé à l’API : 
- on le récupère temporairement sur B,
- on le poste à l’api A
- on le stocke sur A temporairement
- on le convertit F' sur A ; on supprime F de A
- on envoie F' à B ; on supprime F'
- on récupère sur B le fichier F', on le stocke temporairement.
- on applique les traitements habituels de odt2spip avec ce fichier.

La seule embrouille possible peut provenir d’un timeout ou d’un gros fichier.
Les traitements se faisant successivement (ce n’est pas le serveur A qui fait un hit sur un callback de B lorsqu’il a fini son traitement ; B attend simplement patiemment),
et le fichier reçu de A n’est pas streamé mais stocké dans une variable. 
C'est surtout ce dernier point qui me semble à améliorer : ie, rediriger le résultat de A directement dans le fichier F' de B en stream.

Pour le reste, ça fonctionne en local. Restera à tester sur un serveur et peaufiner.

- vérifier si 'libreoffice' (la commande) est présente sur le serveur (ou définie par la constante `_LIBREOFFICE_PATH`)
- si oui : on pourra convertir des documents doc, docx sur ce site directement.
- si oui : propose de servir de serveur de conversion en générant des clés d’API acceptées.
- si non : propose d’indiquer une URL et une clé d’API d’un serveur de conversion.

Si la commande 'libreoffice' est dispo, le formulaire 'document2spip' permet de saisir des fichiers
.doc, .docx, .html... qui seront convertis par l’application en .odt.
Note: on ne prend pas en compte encore de serveur distant de conversion à ce point.

Pour l’instant cela fonctionne, en local, sous macOS en déclarant la constante :
`define('_LIBREOFFICE_PATH', '/Applications/LibreOffice.app/Contents/MacOS/soffice');`

L’application a besoin d’écrire dans un répertoire en s’exécutant.
J’ai tenté en vain (en local) de pouvoir utiliser notre répertoire temporaire tmp/libreoffice/{id_auteur}/,
mais les droits ne semblaient pas suffisants. Utiliser `/tmp` fonctionne par contre.

Il faudra voir ce que ça donne sur un serveur.

qui peut prendre en entrée plusieurs types de documents éventuellement
(ie: si un serveur de conversion est indiqué en configuration (mais il faut le faire))

L’idée (à faire) est de pouvoir passer, à terme, des .docx, de les traduire en .odt, 
et de les importer ensuite avec odt2spip comme avant.

- Passage dans des fonctions dédiées de différentes phases qui étaient réalisées dans l’action odt2spip_importe.
- Cette action n’est plus utilisée, mais là pour compatibilité (je n’ai pas testé, mais ça doit être à peu près bon)
- Le formulaire odt2spip devient CVT. Il utilise Saisies. Si Bigup est là, ça le charge au passage (à voir si on garde).

Quand il y a changement de borne de compatibilité, il faut faire un up de minimum z+1, sans quoi les sites utilisant déjà le plug ne peuvent savoir le changement.

ajout de l'option de configuration pour le choix par défaut de l'attachement du fichier odt (cf http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers#comment474935)

proposer la modification des articles existant via l'intégration d'un fichier odt (cf Suske dans http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers#forum474504)

autoriser les auteurs à utiliser odt2spip (cf http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers#forum469746)

eliminer les balises des images qui ne sont pas jpg/gif/png du texte de l'article (cf http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers#forum466920 mais avec une soluce plus simple)

gerer les SPIP 3 encore en ISO-truc (cf http://contrib.spip.net/odt2spip-creation-d-articles-a-partir-de-fichiers#forum466929)
merci Equipement

restauration du copyright: il semblerait que ca ne soit pas le responsable du plantage de plugins.spip.net...