Silverpeas » Silverpeas Components » GED

Bonjour Emmanuel,

Est-ce qu'on peut faire un point sur les versions installées sur le serveur de prod ?
Vous etes passé en 5.13.3 ou pas ? si oui, depuis la 5.11.4 ?

D'autre part, vous n'aviez pas vu ce problème lors de la validation sur le serveur de test de la 5.13.3 ?
Est-ce que ce problème est présent sur tous les wysiwyg de dossiers ?

Analyse de la GED I10009H et du dossier PDM de l'anomalie remontée.

Identifiants techniques :

• GED I10009H = kmelia9547
• Dossier PDM de la GED = 86325

---

Etat des lieux sur le système de fichiers et dans la table sb_attachment_attachment de la version 5.11.x¶

Au niveau de la base de données :

• enregistrement de Node_86325wysiwyg_fr.txt d'une taille de 4673 le 2013/06/07
• enregistrement de Node_86325wysiwyg_en.txt d'une taille de 2451 le 2013/06/07
• enregistrement de Node_86325wysiwyg_fr.txt d'une taille de 420 le 2013/11/14

A la date du 14 novembre 2013, le contenu français à été mis à jour et est passé d'une taille de 2451 octets à 420 octets (contient certainement les drapeaux dont vous faites mention). Cependant, le contenu anglais, lui, reste non modifié et a une taille de 2451 octets.

Au niveau du système de fichier :

Dans le répertoire /tmp/kmelia9547_20131228/Attachment/wysiwyg, que vous nous avez mis à disposition sur votre serveur, il existe bien les deux fichiers en relation avec les informations de la base de données :

• 2451 7 juin 2013 Node_86325wysiwyg_en.txt
• 420 14 nov. 17:29 Node_86325wysiwyg_fr.txt

Les contenus sont différents, mais les deux sont écrits en français (je ne sais pas pourquoi le fichier "anglais" contient du texte en français ...).

Dans cette situation là, les contenus français et anglais (même si les deux au final sont en français) devaient bien être exposés aux utilisateurs, c'est à dire les drapeaux lorsque les contenus français étaient sélectionnés (via les pictos FR / EN), et les drapeaux plus le texte en français lorsque les contenus anglais étaient sélectionnés.

---

Etat des lieux sur le système de fichiers de la version 5.13.2¶

A partir de cette version, les contenus wysiwyg ne sont plus gérés via la table sb_attachment_attachment.
Ils sont intégralement gérés par la JCR de Silverpeas.

La JCR propose une gestion nodale.
Rapidement, la structure des informations pour les wysiwyg est la suivante : pour chaque contenu wysiwyg associé à une ressource (la ressource étant le dossier dans notre cas) existe un noeud "principal" dans la JCR et à partir de ce noeud sont accédées les versions française ou anglaise (ou autre d'ailleurs).

Lors de la migration des wysiwyg, il aurait dû être créé un seul noeud pour le dossier en question. A partir de ce noeud serait alors accédé le contenu en français ou anglais selon le choix de l'utilisateur.

Suite à la migration, deux noeuds "principaux" ont été créés pour le dossier en question et pour chacun les contenus wysiwyg sont identifiés en français (donc celui anglais est à ce moment là perçu techniquement en français). Les identifiants de ces deux noeuds principaux, dans la JCR, sont les suivants :

• Node_86325wysiwyg_fr.txt : simpledoc_284653
• Node_86325wysiwyg_en.txt : simpledoc_284654

Les contenus physiques sont quant à eux toujours stockés sur le système de fichiers, mais la structure pour y accéder est différente de la version 5.11.x :

• /tmp/kmelia9547_20140208/simpledoc_284653/0_0/fr/Node_86325wysiwyg_fr.txt
• /tmp/kmelia9547_20140208/simpledoc_284654/0_0/fr/Node_86325wysiwyg_en.txt

Les contenus des deux fichiers sont identiques par rapport à la version 5.11.x, mais le contenu anglais (perçu comme du français) n'est plus exposé et Silverpeas expose le contenu français d'un des deux noeuds principaux qui existent. Il semble que cela soit ici celui souhaité qui est affiché pour la langue française.

A ce niveau, nous sommes effectivement d'accord qu'il y a bien deux soucis :

1. il n'y aurait dû exister qu'un seul noeud "principal" (le serveur Silverpeas s'attend à n'en trouver qu'un seul)
2. le contenu anglais, quel qu'il soit, devrait être perçu comme tel (et donc pas en français)

En fait ces deux problèmes sont de même nature que ceux remontés par le REDMINE https://tracker.silverpeas.org/issues/5197 (problème sur les pages web qui présentaient des versions obsolètes). Même s'il est vrai que cette anomalie ne faisait pas référence à des contenus multi-langues.
La solution mise en place pour la résoudre (la 5197) a été de créer pour le passage de Silverpeas en 5.12.7 ou 5.13.3 un traitement d'ajustement des contenus wysiwyg "mal restitués" dans l'application.
Ce traitement a abouti notamment :

• à l'existence d'un seul noeud "principal" pour chaque contenu wysiwyg
• à l'identification des contenus anglais de nouveau fonctionnelle

C'est ce que nous allons constater dans le prochain point.

---

Etat des lieux sur le système de fichiers de la version actuelle, la 5.13.3¶

Il n'existe pour le dossier PDM plus qu'un seul noeud "princpal" pour les contenus wysiwyg : simpledoc_284653 (l'autre a été supprimé).
Ce dernier contient un contenu en français et un autre anglais (d'un point de vue technique) :

• [...]/data/workspaces/kmelia9547/simpledoc_284653/0_0/fr/Node_86325wysiwyg_fr.txt
• [...]/data/workspaces/kmelia9547/simpledoc_284653/0_0/en/Node_86325wysiwyg_en.txt

Ces contenus sont quasiment identiques à ceux des versions précédentes de Silverpeas, mis à part les URL qui permettent d'afficher un drapeau français et anglais qui différent.

J'ai également remarqué que dans chacun des répertoires listés ci-dessus, il existe un fichier qui se nomme de la même manière que le wysiwyg mais suffixé de ".bak" (par exemple, Node_86325wysiwyg_fr.txt.bak, comme pour indiquer une sorte de sauvegarde). Je ne sais pas d'où viennent ces fichiers suffixés de cette manière, mais en analysant leur contenu je peux formuler une hypothèse.

Je pense qu'une opération massive de renommage des liens, permettant d'afficher les petits drapeaux français et anglais, a été effectuée dans les fichiers wysiwyg. Chaque fichier pour lequel le renommage a été effectif a occasionné la création d'une sauvegarde du contenu précédent du fichier. Le nom du fichier de la sauvegarde est constitué du nom du fichier sauvegardé et de l'extension .bak.

---

Quelles solutions à votre problème ?¶

Nous pouvons constater que l'opération mise en place pour la 5.12.7 et 5.13.3 a bien fonctionné dans le sens où il existe bien dans la JCR un seul noeud "principal" et où les contenus anglais sont bien perçus comme tel.

Sauf que dans votre cas, comme vous le signalez dans cette demande, ces contenus anglais de nouveau restitués vous posent parfois problème.

Nous ne pouvons malheureusement pas, de notre côté, réaliser et intégrer un traitement massif pour une prochaine version corrective de Silverpeas car il n'existe pas de règle technique permettant de savoir si le contenu anglais aurait dû être rétabli ou non. Dans le doute, nous avons préféré faire apparaître de nouveau le contenu anglais.

En revanche, si l'hypothèse que j'ai formulée dans le point précédent est bonne, vous avez peut-être la possiblité d'établir des règles techniques et fonctionnelles qui vous permettraient de modifier massivement le contenu de tous les wysiwyg qui ne sont pas corrects.

Par exemple, il pourrait être imaginé de forcer le contenu de tous les fichiers qui respectent l'ensemble des règles suivantes :

• le nom de son répertoire parent doit être strictement "en" (pour ne cibler que les contenu anglais)
• sa date de dernière modification doit être au 14 février
• son nom doit commencer par "Node_" (permet de ne cibler que les wysiwyg associés à des dossiers)
• un fichier comportant le même nom, mais en plus suffixé de ".bak", doit exister dans le même répertoire
• il doit contenir toutes les phrases clés suivantes :
  • weblib/images/fr.gif
  • weblib/images/uk.gif
  • <p>Le pilote des documents contenu dans ce thème est le Responsable Etudes. <br/>Les

Le contenu forcé serait celui qui semble être le contenu type :

<div class="drapeau">
  <a href=""><strong><img alt="" src="/weblib/images/fr.gif"/></strong></a>
  <a href=""><strong><img alt="" src="/weblib/images/uk.gif"/></strong></a>
</div>

Il ne faudrait par contre pas réaliser de nouvelle sauvegarde en ".bak" pour ne pas supprimer la sauvegarde du fichier d'origine.

---

Pour finir, je ne peux pas garantir que dans la durée ces fichiers ".bak" n'engendrent pas de souci de gestion des contenus wysiwyg dans Silverpeas.

Nous avons installé la version 5.13.4, il y quelques semaines maintenant.
La procédure pour corriger le problème de façon unitaire semble dans la théorie correcte, mais comme je l'ai précisé dans ma mise à jour précédente :

Il n'est pas possible de supprimer totalement le descriptif WYSIWYG des dossiers dans une seule langue

Donc, nous n'avons pour l'instant AUCUN MOYEN de corriger les descriptifs WYSIWYG des dossiers.

De plus, nous ne pouvons définitivement pas parcourir TOUS les descriptifs WYSIWYG de tout le portail pour vérifier si le problème est présent.

Avez vous une solution pour faire une recherche, afin de trouver les endroits à corriger ?

Oui, en version 5.13.4, il n'existe pas de moyen de supprimer un contenu WYSIWYG dans une langue (notamment sur les dossiers).
C'est pourquoi nous avons mis en place le nouveau comportement, celui décrit dans la note n°13 de cette demande REDMINE, pour donner cette possibilité depuis l'application.

Afin d'être cohérent avec la création ou la mise à jour d'un contenu WYSIWYG vide (0 octets), nous avons également fait en sorte que les contenus WYSIWYG vides ne soient plus pris en compte dans l'affichage des contenus WYSIWYG.

Enfin, pour essayer de répondre à votre problématique principale, nous pouvons essayer de mettre en place un script de reprise des données de la JCR qui supprimerait les contenus WYSIWYG vides, ou les contenus WYSIWYG identiques entre les différentes langues, liés à une même ressource.
Les règles seraient simples. Pour chaque ressource (un dossier, une publication, etc.) serait recherché le contenu WYSIWYG dans ses différentes langues, et s'il en existe au moins un dans une langue, l'une des règles ci-dessous serait appliquée :

• si le contenu WYSIWYG pour une langue est vide (strictement 0 octet), alors il est supprimé
• si le contenu WYSIWYG est identique entre chacune des langues, alors un seul est gardé et les autres sont supprimés

Est-ce que ce script de reprise vous conviendrait-il ?

Le script de purge indiqué à la note 16 est en cours d'intégration.
A celui-ci a été ajouté un traitement de renommage des fichiers WYSIWYG sur le système de fichier. En effet, le suffixe des noms de ces fichiers peuvent parfois ne pas être en accord avec la réelle langue du contenu.
Par exemple, kmelia26/simpledoc_38/0_0/en/2607wysiwyg_fr.txt sera renommé en kmelia26/simpledoc_38/0_0/en/2607wysiwyg_en.txt car le fichier se trouve dans le répertoire des contenus anglais (information juste) et que son extension indique un contenu français (extension fausse).

Le chemin d'accès d'un contenu WYSIWYG est constitué des éléments suivants : [identifiant de l'instance de l'application]/[identifiant du noeud JCR principal associé à une ressource dans Silverpeas (un dossier par exemple)]/[version du contenu (toujours 0_0 pour les WYSIWYG)]/[signe de la langue du contenu]/[nom du fichier wysiwyg].
Le nom d'un fichier WYSIWYG est constitué des éléments suivants : [identifiant de la ressource dans Silverpeas (une publication par exemple)]wysiwyg_[langue du contenu].txt. A noter que :

• la partie _[langue du contenu] est parfois non présente, cela indique en principe un contenu français
• le préfixe du nom du fichier WYSIWYG :
  • pour une publication, l'identifiant en base d'une publication est utilisée. Par exemple, si l'identifiant en base d'une publication est 1234, alors pour un contenu WYSIWYG français, le nom du fichier est 1234wysiwyg_fr.txt (ou 1234wysiwyg.txt dans le cas de contenus anciens en français)
  • pour un dossier, la concaténation de Node_ avec l'identifiant en base du dossier est utilisée. Par exemple, si l'identifiant en base d'un dossier est 4321, alors pour un contenu WYSIWYG anglais, le nom du fichier est Node_4321wysiwyg_en.txt

Avec l'ensemble de ces indications, il est possible de retrouver à quelle ressource dans Silverpeas un contenu WYSIWYG est rattaché à partir de son chemin d'accès.

Concernant l'identification des contenus WYSIWYG faux ou obsolètes, comme vu dans l'ensemble des notes précédentes, nous n'avons pas de règle fonctionnelle nous permettant de les identifier dans le cadre d'un script de reprise intégré au produit Silverpeas.