[Résolu] DP7 / mise en place module CKEditor

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bien le bonjour,

Je viens à vous pour un souci de mise en place de CKEditor sous DP7.
En effet voici comment je l'ai mis en place :

  • Téléchargement de CKEditor (version 3.6.1.7072)
  • Décompression dans le répertoire /www/sites/all/libraries/ckeditor
  • Après quoi, j'ai activé le module dans le menu prévu à cet effet
  • J'ai affecté CKEditor au format "Full HTML" dans le menu Administration>Configuration>Rédaction de contenu.
  • Pour finir j'ai configuré ce module, en choisissant le français comme langage d'interface et en ajoutant tous les boutons dont je pense avoir besoin pour l'édition de mon contenu.

Seulement voila, que j'édite un webform que déjà créé ou que j'édite un nouveau contenu, et sous le format "Full HTML", l'éditeur n'apparait nullement.

Auriez-vous une idée de ce qui se passe ?
D'avance merci pour vos retours sur cette question.

Version de Drupal : 
Tags : 

Bonjour,

Rien ne s'affiche dans l'onglet réseau sous Firebug. Je n'ai pas non plus de message d'erreur js dans la barre d'état sous IE9.. Je ne pense pas que des fichiers soient manquants.

J'ai tenté la réinstallation mais même chose.
D'autres idées peut-être svp ?

Merci bien :)
En fait j'avais désactiver l'historique sur FF et donc du coup Firebug avait bien du mal à restituer les données..

J'ai du "403 Forbidden" sous l'onglet réseau du Firebug pour ce qui concerne le Wysiwyg, CKeditor et TinyMCE que j'ai tenté d'installer mais également sans qu'il s'affiche.

Alors peut-être un problème avec les autorisations sur les fichiers. L'utilisateur du serveur web doit avoir le droit de lire les fichiers du module et du plugin.

Faire un ls -al sur les répertoires où sont les fichiers proviquant les erreurs 403 et en changer les droits.

Bonjour,

J'ai remarqué que j'avais ces erreurs '403 Forbidden' pour 3 modules, dans 'sites\all\modules', pour \wysiwyg, \ckeditor et \pathauto.

J'ai donc déterminé pour essayer des autorisations chmod 777 pour mon dossier 'sites\all\modules' et tous ces sous-dossiers.
Mais rien n'y fait, j'ai toujours ces mêmes erreurs '403 Forbidden' et pas d'éditeur lorsque je souhaite rédiger un nouveau contenu quel qu'il soit..

Je ne saisis pas d'où cela peut-il provenir.

Arf, même en mettant du chmod 777 sur site/all/libraries en plus de sites/all/modules, toujours rien.. :/

Et toujours cette erreur 403, ce qui est le plus étrange puisque tous les droits sont en place pour les fichiers pointés par ces erreurs. Je désespère.

Je suis 'administrator', et effectivement ce rôle a bien tous les droits pour l'utilisation de l'input 'full html', et pour lequel est définit CKeditor.

J'ai même tenté de créer un nouveau format de text, pour lequel j'ai définit comme éditeur wysiwyg TinyMCE, et lorsque je le sélectionne à l'édition d'un contenu il n'apparait pas..
C'est incompréhensible je ne saisis pas, et pas évident de faire sans.

J'ai eu le même problème avec TinyMCE, j'ai pu analyser grâce à Firebug que le seul problème venait d'une erreur 404 sur fr.js (le fichier de trad français, non existant). J'ai donc mis la langue en Anglais provisoirement, et ça fonctionne. Après effectivement si tu as des erreurs 403 le problème n'est pas le même.

Merci :)

Je viens d'essayer encore autre chose, mais sans résultat.
J'ai désactivé le module Wysiwyg, et j'ai installé le module CKeditor, proposé sur http://drupal.org/project/ckeditor
J'ai ensuite mis les librairies qui vont habituellement dans 'sites\all\libraries\ckeditor' dans 'sites\all\modules\ckeditor\ckeditor' comme il est dit de faire lorsqu'on utilise le module CKeditor au lieu de Wysiwyg.
Seulement toujours rien qui s'affiche lors de l'édition de contenu. Et maintenant les erreurs '403 Forbidden' sont situées sur le répertoire 'sites\all\modules\ckeditor'. Je crois que j'ai vraiment tout essayé, c'est complètement fou cette histoire..

Reçu.

Un doute m'étreint : quand tu changes les autorisations d'un répertoire, tu fais bien un chmod -R 777 le_repertoire ?

Autre question : le .htaccess a-t-il été bidouillé ? Parce qu'en fait il n'y a pas que CKEditor qui provoque des 403.

EDIT : En regardant de plus près, tous les javascripts qui sont dans /sites/all/modules provoquent un 403, ce qui nous ramène quand même à un souci de permission sur les répertoires.

Donc :

  • Vérifier que les possesseurs des répertoires libraries et modules sont bien les mêmes, et sur toute l'arbo. Faire un chown -R user:group * si nécessaire aux endroits appropriés.
  • Re vérifier les permissions sur ces mêmes répertoires : chmod -R 777 * sur /sites/all par exemple, quitte à revenir à des autorisations plus strictes par la suite.

Lorsque je change les autorisations, sachant que j'utilises FileZilla, je fais un clic droit sur le répertoire distant, et dans 'permissions' je mets 777, puis je coche 'récursion dans les sous-dossiers' pour l'appliquer aux enfants de ce répertoire.

Et j'ai édité le .htaccess pour pouvoir faire mon installation de Drupal 7 chez mon hébergeur, OVH.
J'y ai simplement ajouté :

SetEnv PHP_VER 5_TEST
SetEnv REGISTER_GLOBALS 0
RewriteEngine On

Alors ça devrait être bon. Ce serait quand même plus sûr de pouvoir voir les répertoires en console ...

Que donne, avec Filezilla, un clic droit puis 'Droits d'accès au fichier ...' sur, par exemple, /sites/all/modules/pathauto/pathauto.js ?

Je suis quasi certain que le souci vient d'un problème d'autorisations sur les sous-répertoires de /sites/all/modules/ .

Donc, voilà ce que je propose, parce que je n'ai plus d'idées :
- Désactiver pathauto, media, wysiwyg et ckeditor
- les désinstaller proprement sur /admin/modules/uninstall
- effacer les répertoires de ces modules
- faire un clear cache du site.
- uploader pathauto, l'activer, et voir si ça fonctionne (pas de 403 dans Firebug, le module renomme bien les URL).
- essayer de corriger les problèmes d'autorisations s'il y en a.

Ensuite, appliquer la même procédure avec les autres modules plus complexes.

J'ai désinstallé proprement, effacé les répertoires, clear le cache, retenté d'upload un à un, mais dès que j'ai mis wysiwyg ça a recommencé. Je me demande si FileZilla fait bien le job.. Comment puis-je accéder à mes dossiers via une console ?

Bon et bien, j'ai repris mon dossier contenant mon installation fraichement mise en place il y'a 15 jours, ainsi que sa base de données. J'ai refais l'installation du module wysiwyg, ainsi que ckeditor et tout fonctionne parfaitement.

Je ne sais donc pas ce qui a pu se passer.
En tous les cas un grand grand merci à toi Numerizen pour ton soutien, ton aide, et pour tout ce temps que tu m'as accordé.

Merci encore.

J'ai mis des permissions 777 * sur 'sites/all', mais rien n'y fait.
Et je ne comprends pas très bien ce que signifie vérifier que les possesseurs des répertoires 'libraries' et 'modules' sont bien les mêmes, faire un chown -R user:group *..

Ce sont des manips à faire en console, mais tu ne dois pas avoir les droits pour changer ces attributs. Nous devons donc partir du principe que le serveur les gère correctement.

Il me semble avoir vu des threads ici sur des soucis d'autorisations avec OVH. TU as cherché sur le forum ?

Je rencontre ce problème également. De mon point de vue, et je cherche de ce côté en ce qui me concerne, le problème n'est pas lié à des droits Drupal ou à des chmod. L'erreur 403 est générée par Apache et/ou un processus qui bloque l'accès en 403 aux fichiers de type .css et .js qui sont dans les dossiers sites/all/modules.

A suivre...

Je continue de penser qu'il s'agit d'un problème lié à la config d'Apache ou d'un Vhost, en tout cas pas directement lié à Drupal.

1 - Si j'essaie de télécharger un document js, css, png ou autre présent dans http://www.monsitedrupal7.ext/sites/all/unmoduleavecunjs/lefichierjs.js j'obtiens une erreur 403 "standard" d'Apache, et pas du tout le fichier en question.

2 - J'ai activé les fonctions de compression des fichiers css et js dans l'admin de Drupal (section performance) et hop, plus d'erreur ! (en tout cas sur les js et les css)

3 - J'essaie de mettre un fichier php "seul" (avec une instruction phpinfo() par ex) et je le requête directement : erreur 403. Idem avec un png, un fichier html, etc.

Il semble que tout ce qui est demandé par un autre processus que le serveur Apache soit refusé (sous-entendu les instructions includes ou autre doivent fonctionner puisque les modules complémentaires sont fonctionnels).

J'ai lu pas mal de posts sur les forums de drupal.org, mais peu semblent chercher une solution "globale", on a plutôt des tentatives isolées pour faire fonctionner un module ou un autre en particulier...

Je cherche encore...

Tout indique un problème de droits sur les répertoires : le fait d'activer la compression des fichiers css et js fait qu'ils sont servis depuis un autre répertoire (sites/default/files de mémoire).

Le fichier .php ne doit pas être accessible en direct, pour des raisons de sécurité. Il me semble qu'il y a une directive dans le .htaccess à ce propos.

Je vérifierais le propriétaire (group et user) du répertoire concerné.

Par ailleurs, et c'est peut-être là le souci, le chemin devrait être sites/all/modules/unmodule/unfichier.js et non sites/all/unmodule/unfichier.js.

And the winner is...

Voilà, l'admin du serveur est rentré de vacances et il se trouve que certains droits ne sont pas correctement placés sur certains répertoires... Tout est rentré dans l'ordre en ce qui me concerne. On retombe bien sur un problème de configuration du serveur. Moralité : ne jamais prendre d'hébergement ailleurs que chez soi... Toujours des galères dans le cas contraire...

@numerizen : pour le chemin des js dans le repertoire modules, il s'agit d'une coquille de ma part dans le message.

Fin du sujet pour ma part.

salut
j'ai eu un probleme du genre aujourd'hui :
j'avais une erreur 403 en voulant atteindre '/sites/all/libraries/jwplayer/jwplayer.js' sur un "perso" ovh.

n'ayant pas d'acces ssh et seulement ftp, j'ai retourné les permissions du dossier et fichier dans tous les sens avec filezilla et rien à faire alors que les autres librairies javascript au meme endroit sont accessibles.

j'ai remarqué que chez moi (sous linux), j'ai pas les memes droits sur les dossiers sur celui de jwplayer que les autres libs.
j'ai donc changé les droits en local ainsi que le proprietaire en mettant www-data pour tout le monde et j'ai de nouveau uploadé le dossier complet de jwplayer en prenant soin de supprimer le distant avant et tout est rentré dans l'ordre.