Citation :

Ah ceci va aller à l'encontre de mes tests, il va falloir que je reteste tout ceci...

Citation :

Humm curieux tout ceci...
En fait, à ma connaissance, pour utiliser un éditeur tiers sous xoops, il faut :
1- Un éditeur validé pour l'API de xoops - C'est le cas de TinyMCE grâce au travail de luciorota et jayjay - à déposer dans "/class/xoopseditor"
2- Soit l'on choisit de mettre cet éditeur par défaut pour xoops, pour cela il faut changer la variable "$htmlEditor" (comme expliqué plus bas dans cette discussion).
2bis - Soit on choisit module par module (s'ils sont compatibles aux choix des éditeurs) d'accorder l'utilisation de l'éditeur.
3- Dans le cas du 2-, seuls les modules utilisant un formulaire avec des parties "textarea" positionnée "textareahtml" pourront bénéficier de l'utilisation de l'éditeur. Ce qui veut dire qu'il faut parfois modifier certains modules s'il on veut utiliser un éditeur wysiwyg.

Ce que j'ai proposé, c'est 1+2+3.
A priori, d'après tes remarques, tu aurais un mélange entre le 2, 2bis et 3 (mis à part le fait que "TinyEditor" est plus compliqué dans l'idée étant donné qu'il vient en plus avec un module pour le configurer).
Je te laisse donc jeter un oeil à tout cela, mais encore une fois, merci pour tes tests et tes remarques, cela m'est d'un grand secours.
@+

Yes ! Super sympa jeanpaul !

Citation :

Bon je vais faire une déduction assez rapide, mais bon si ca fonctionne pour toi avec 1and1, qu'est-ce qui cloche chez ovh ?

Je vais attendre plus de retour avant d'ouvrir un sujet à propos de "xoops hébergé chez OVH" mais il est vrai que j'ai pas mal de "petite" choses comme cela qui ne fonctionnent pas ?!

En tout cas merci encore d'avoir testé

Up up
Personne n'a testé cette version de TinyMCE ?

Sympa ce petit tuto ! Content de voir que mes observations ont reservies .
Bravo flaggada !

Citation :

Chat chest cool
Marchi

Salut tout le monde,

Ce sujet tombe pile poil !
Ca fait un moment que j'utilise pour mes productions "TinyEditor" qui, pour préciser les choses, est un module de "ralf57" qui utilise la version 2 (je crois) de TinyMCE. Ce module est excellentissime, il intègre parfaitement TinyMCE dans xoops. La gestion des droits d'accès à l'éditeur et le paramétrage des barres sont formidablement bien pensés !
Ceci dit, cette version de TinyMCE est obsolète de nos jours avec l'arrivée de navigateur comme FireFox 3, Opera 9.x ou encore Google Chrome (et c'est pas fini si on pense à IE8...). Des fonctionnalités de cette version de l'éditeur sont soient difficilement utilisables sous ces navigateurs, soit l'éditeur n'est même pas utilisable (sous Opera, Google Chrome, ou encore Safari).
Je me suis donc penché sur son remplacement. Et après avoir fait le tour, je pense qu'il n'y a pas vraiment mieux que TinyMCE avec Xoops (enfin c'est mon avis). Pour cela, j'ai jeté un oeil au travail de
Lucio Rota pour xoopseditor (pour xoops 2.3.1, je crois que c'est le lien proposé par phmo). Pour autant, depuis, TinyMCE a encore été mis à jour et de plus, le français n'est pas au rendez-vous.
J'ai donc mis la main à la patte pour 1, partir sur la dernière version de TinyMCE (la 3.2.0.2) et 2, traduire les "plugins" xoops de TinyMCE de luciorota et ralf57.
Je vous propose donc ce résultat qui devrait fonctionner pour xoops 2.0.1x et 3.x.
Mais tout n'est pas rose
Et oui je rencontre un problème de taille, si pour moi tout fonctionne à merveille en local, l'éditeur ne fonctionne pas sur mes productions chez OVH
Alors, disons que je suis un peu géné, mais je vous propose tout de même le machin et du coup, ba si vous pouvez tester du coup au vues de vos retours (si cela vous intéresse bien sûr...) je serai fixé sur les soupçons que je nourris à propos de l'hébergement.

Rappelons que l'archive que le propose est à déposer dans "/class/xoopseditor" et que si vous souhaitez utiliser définitivement cet éditeur pour l'ensemble du site, il vous faudra aller modifier "class/xoopsform/formdhtmltextarea.php" et modifier la variable

pour



tinymce3.2.0.2-xoops-fr.zip

@vous lire

@Sukhoi : Ok dac, malheureusement, je ne pense pas faire figure d'expert xoops. J'ai fait d'autres tests ces derniers jours, et je ne trouve toujours pas d'où cela peut venir. Tu peux suivre mes tests ICI.

@FabienSt : Ba, euh oui, je suis d'accord avec toi, mais cela dépend du site "xoopsé". Dans le cas de celui-ci, il s'agit du site d'un club de handball, et il me paraissait sympa de proposer des avatars sous forme de "maillots". Chacun peut choisir son numéro .

J'ai fait quelques tests ces derniers jours.
Je suis passé en PHP4, rien n'y fait, le changement d'avatar fonctionne toujours en local même en PHP4.
Du coup je suis passé en PHP5 sur OVH et idem, le changement d'avatar ne fonctionne toujours pas

D'autre part, mes pistes se brouillent, j'ai pu faire un test de changement à partir d'un autre site positionné également sur un serveur OVH ayant le même "core" xoops (on va dire package xoops/modules), et bien, cela fonctionne :-o .

J'en perd mon latin ou plutôt mon esprit de technicien en informatique...

Je reste sur le "qui vive", si vous avez des pistes...

@+

Salut, du coup, le problème est résolu ? Car moi aussi je galère avec ce problème et j'ai du mal à comprendre d'où cela peut bien venir... Si t'as un tuyau je suis preneur

Salut,

J'ai avancé un peu sur la question, après des tests sur plusieurs environnements en local, je pense pouvoir dire que cela ne vient pas de MySQL, car le changement d'avatar fonctionne bien en local avec une version MySQL 5.0.45 > 5.0.44 de OVH.
Pour le moment, je n'ai pas encore testé sous une version PHP 4.x en local comme celle de OVH.
Par contre, le problème ne vient pas non plus de "register_globals" et "session.use_trans_sid" que j'ai finalement désactivés, reste "allow_url_fopen", mais je ne pense pas que cela vienne de cette variable...

Si vous avez d'autres idées, je suis preneur, pour le moment, je m'oriente donc vers un problème PHP4 ?! ...on verra si mon test écarte également cette partie...