Puis j'ai testé par curiosité le plugin pour les réseaux sociaux et même constat. Oui je sais, c'est de la faute de Facebook qui a prit du temps à passer son bouton en HTML5.
Je vais voir si j'ai un peu de temps à proposer les modifs à y apporter si ça peut aider.
Ne prends pas mal ce que je dis hein, je sais très bien qu'il y plus préoccupant comme problème et que chacun à sa vie. Le siège le plus confortable est toujours celui de l'utilisateur hein ^^
Enfin bref, tout ça pour dire que j'admire beaucoup le travail qui est fait sur PluXML, je regrette juste de ne pas être capable bien souvent de donner un coup de main.
Y a aucun souci. Le but est d'avancer et de corriger ce qui est faisable quand on peut le faire.
Bon voilà, c'est fait pour le plugin des réseaux sociaux ^^
Par contre pour celui là, j'avoue être allergique au JS donc ><
Par exemple, quand on utilise les boutons du plugin, faudrait ça soit compatible HTML5. Par exemple, pour une iframe avec une vidéo Youtube :
Oui le gros problème c'est que le "style" remplace bon nombre de paramètres qu'on pouvais avant passer à la balise... donc ça complique énormément la validation/modification.
edit : faudrait vraiment augmenter la marge de gauche dans l'éditeur de code intégré
Le premier est qu'il utilise la balise <strike> qui n'est pas valable en XHTML, il faut lui préférer l'utilisation de <del>.
Le second : la taille des images est précisée en css du type style="width:640px;height:480px" hors en responsive c'est la misère à gérer vu que le css est surchargé par celui inséré dans le code html.
L'utilisation des attributs width et height de la balise img permettent eux d'être surchargé via le css. De plus cela accélère le rendu du dom car le navigateur connait la taille de l'image avant d'avoir fini de la charger.
Une idée de comment je pourrai modifier ces deux comportements ?
Pour la taille des images, il suffit de laisser les dimensions vides dans le formulaire et de ne pas redimensionner l'image a posteriori dans le textarea. Une fois l'article enregistré, les attributs width et height ne seront pas présents.
Le fait de mettre ces attributs accélère le rendu de la page, contrairement à ce que tu dis (ou alors j'ai mal compris ta phrase), car le navigateur sait les dimensions à afficher et n'a pas à les "calculer".
Mais c'est vrai que pour un design pour mobile, si ces attributs sont présents, la surcharge css ne sert plus à rien.
Pour ce qui est de la balise strike, il suffit de la remplacer par del partout dans le code. Un chercher/remplacer avec un bon éditeur de code doit faire l'affaire (sublime Text 2 le fait très bien).
Pour les attributs de l'image c'est un "bug" de ckeditor http://dev.ckeditor.com/ticket/5547 et il existe un patch par contre vu que les fichiers sont minifiés ... c'est la misère
Merci pour ces avancées.
Pour la balise u, ce serait plutôt :
config.coreStyles_underline : { element : 'ins' };
[corrigé pour ne pas laisser traîner une erreur, avec "underline" et non "u", et ":" au lieu de "=" pour les deux lignes - Merci à Stéphane, voir son message ci-dessous]
Bonjour
Pour éviter de toucher aux fichiers de ckeditor, voilà la meilleure solution (en attendant la mise à jour du plugin)
Editez le fichier plugins/ckeditor/ckeditor.php
En dessous de la ligne
CKEDITOR.replace('id_'+textareas[i].name, {
Ajoutez:
coreStyles_strike : { element : 'del' },
coreStyles_underline : { element : 'ins' },
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Merci Stéphane pour les corrections et pour cette méthode.
Une petite remarque en passant, au sujet du sens attribué à ces balises :
- pour un texte barré, la balise del (delete) est tout à fait logique
- par contre, la balise ins signifie qu'un texte a été inséré, ce qui ne correspond pas à la mise en valeur d'un texte, qui est souvent l'objectif du souligné
Solution : Conserver ins pour le souligné, de façon à avoir un code XHTML valide, et éviter autant que possible d'utiliser le soulignement !
Il vaut mieux pour l'ergonomie du site réserver le soulignement aux liens. Le soulignement pouvant être considéré comme une emphase, les balises <em> ou <strong> seraient plus adaptées. Tu peux les styler comme tu veux via CSS, mais je te conseille la mise en gras ou la couleur, plutôt que le soulignement.
(trouvé sur webrankinfo) et il a raison.
Après, si le soulignement est absolument nécessaire, on peut aussi utiliser une span avec une classe "underline" ou "souligne".
J'ai eu un petit bug sur un de mes sites avec ckeditor. A priori, il y a une ligne vide qui traine :
<b>Warning</b>: Cannot modify header information - headers already sent by (output started at /home/www/[...]/plugins/ckeditor/ckeditor.php:805) in <b>/home/www/[...]/auth.php</b> on line <b>47</b><br />
J'aurai souhaité que les utilisateurs ayant le statut de rédacteur ne puissent pas modifier la charte graphique.
Par conséquent lors d ela rédaction d'un article, j'aurai souhaité qu'ils n'aient pas accès au bouton; taille et style de la police entre autres, ou encore acces au code au code html ou les boutons d'alignement.
Est-ce possible et comment?
Merci
Bonjour je viens d'installer à l'instant ce plugin mais j'ai un soucis:
en voulant insérer une image en explorant le serveur j'ai ceci
PHP Error Message
Warning: is_dir() [function.is-dir]: open_basedir restriction in effect. File(/usr/local/apache/htdocs/data) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/a5483979/public_html/plugins/ckeditor/kcfinder/core/uploader.php on line 225
Free Web Hosting
PHP Error Message
Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/usr/local/apache/htdocs/data/.htaccess) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/a5483979/public_html/plugins/ckeditor/kcfinder/core/uploader.php on line 254
Free Web Hosting
plus un pop up
Cannot write to upload folder. /usr/local/apache/htdocs/data
Si les droits en écriture sur le dossier /data et /data/images sont bien en 755, à la vue des messages d'erreur ça semble un restriction de ton hébergeur (open_basedir restriction in effect). Quel est ton hébergeur ? As-tu les moyens de tester sur un autre hébergeur (ça semble etre le meme probleme que ici http://forum.pluxml.org/viewtopic.php?id=3811)
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Voici ce que j'ai
Pluxml version 5.1.7 (encodage UTF-8)
Version de php : 5.2.17
Etat des "magic quotes" : 1
✔ ../../data/configuration/ est accessible en écriture
✔ ../../data/articles/ est accessible en écriture
✔ ../../data/commentaires/ est accessible en écriture
✔ ../../data/statiques/ est accessible en écriture
✔ ../../data/images/ est accessible en écriture
✔ ../../data/documents/ est accessible en écriture
✔ Bibliothèque GD installée
✔ Fonction d'envoi de mail disponible
Avant d'installer CKEditor, j'avais installé plxEditor et je n'avais pas de problème de ce genre.
Mon hébergeur est 000webhost.com en version gratuite. Je viens d'installer Pluxml et CKEditor chez free mais ce coup-ci j'ai
The "safe_mode" PHP ini setting is turned on! You cannot run KCFinder in safe mode.
Du coup, je ne suis pas plus avancé!
plxEditor et Ckeditor ne fonctionnent pas de la même façon et n'utilisent pas les mêmes instructions php.
le coup du safe_mode chez free c'est normal c'est une restriction de l'hébergeur. ckeditor c'est mort chez eux, il n'est pas possible de contourner cette restriction.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je viens de regarder les droits des dossier /data et /data/images. Le premier était en 700 et je l'ai mis en 755 et le second est déjà en 755. Malheureusement, pas de changement!
Réponses
lesquels ?
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Puis j'ai testé par curiosité le plugin pour les réseaux sociaux et même constat. Oui je sais, c'est de la faute de Facebook qui a prit du temps à passer son bouton en HTML5.
Je vais voir si j'ai un peu de temps à proposer les modifs à y apporter si ça peut aider.
Ne prends pas mal ce que je dis hein, je sais très bien qu'il y plus préoccupant comme problème et que chacun à sa vie. Le siège le plus confortable est toujours celui de l'utilisateur hein ^^
Enfin bref, tout ça pour dire que j'admire beaucoup le travail qui est fait sur PluXML, je regrette juste de ne pas être capable bien souvent de donner un coup de main.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Par contre pour celui là, j'avoue être allergique au JS donc ><
Par exemple, quand on utilise les boutons du plugin, faudrait ça soit compatible HTML5. Par exemple, pour une iframe avec une vidéo Youtube :
Code actuel :
Code valide :
Autre exemple avec le bouton pour barré du texte :
Code actuel :
Code valide :
Oui le gros problème c'est que le "style" remplace bon nombre de paramètres qu'on pouvais avant passer à la balise... donc ça complique énormément la validation/modification.
edit : faudrait vraiment augmenter la marge de gauche dans l'éditeur de code intégré
Reste plus qu'a changer tout ça dans le plugin ><
Le premier est qu'il utilise la balise <strike> qui n'est pas valable en XHTML, il faut lui préférer l'utilisation de <del>.
Le second : la taille des images est précisée en css du type style="width:640px;height:480px" hors en responsive c'est la misère à gérer vu que le css est surchargé par celui inséré dans le code html.
L'utilisation des attributs width et height de la balise img permettent eux d'être surchargé via le css. De plus cela accélère le rendu du dom car le navigateur connait la taille de l'image avant d'avoir fini de la charger.
Une idée de comment je pourrai modifier ces deux comportements ?
Le fait de mettre ces attributs accélère le rendu de la page, contrairement à ce que tu dis (ou alors j'ai mal compris ta phrase), car le navigateur sait les dimensions à afficher et n'a pas à les "calculer".
Mais c'est vrai que pour un design pour mobile, si ces attributs sont présents, la surcharge css ne sert plus à rien.
Pour ce qui est de la balise strike, il suffit de la remplacer par del partout dans le code. Un chercher/remplacer avec un bon éditeur de code doit faire l'affaire (sublime Text 2 le fait très bien).
Concernant les deux modifs :
Utilisation de del à la place strike
Utilisation de width et height à la place de style=
Je peux m'en charger mais j'aimerai que cela soit intégrer dans les futures versions pour ne pas avoir à le refaire à chaque mise à jour du cms
Pour la balise u, ce serait plutôt : [corrigé pour ne pas laisser traîner une erreur, avec "underline" et non "u", et ":" au lieu de "=" pour les deux lignes - Merci à Stéphane, voir son message ci-dessous]
Pour éviter de toucher aux fichiers de ckeditor, voilà la meilleure solution (en attendant la mise à jour du plugin)
Editez le fichier plugins/ckeditor/ckeditor.php
En dessous de la ligne Ajoutez:
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Merci Stéphane je vais tester ça
Une petite remarque en passant, au sujet du sens attribué à ces balises :
- pour un texte barré, la balise del (delete) est tout à fait logique
- par contre, la balise ins signifie qu'un texte a été inséré, ce qui ne correspond pas à la mise en valeur d'un texte, qui est souvent l'objectif du souligné
Solution : Conserver ins pour le souligné, de façon à avoir un code XHTML valide, et éviter autant que possible d'utiliser le soulignement !
J'ai trouvé une explication très intéressante, à propos du soulignement :
http://forum.webmaster-rank.info/referencement-google/le-poids-de-la-balise-u-t4762.html#p54550
Après, si le soulignement est absolument nécessaire, on peut aussi utiliser une span avec une classe "underline" ou "souligne".
Cette ligne perturbe la redirection de la partie administration. Enlevée, tout rentre dans l'ordre.
background-color: none !important;
Par
background: none !important;
Rien de bien grave
J'aurai souhaité que les utilisateurs ayant le statut de rédacteur ne puissent pas modifier la charte graphique.
Par conséquent lors d ela rédaction d'un article, j'aurai souhaité qu'ils n'aient pas accès au bouton; taille et style de la police entre autres, ou encore acces au code au code html ou les boutons d'alignement.
Est-ce possible et comment?
Merci
Quel éditeur de texte utilises-tu dans PluXml ?
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Mais je vais faire alors faire un essai avec PlxEditor, pour comparer.
Cordialement
je viens de trouver cela sur le forum aujourd'hui:
http://forum.pluxml.org/viewtopic.php?id=3755
Je pense que cela devrait m'apporter ma solution pou réduire les fonctionnalités d emise en page.
Cordialement
BUG Erreur de syntaxe empêchant d'enregistrer des articles
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
en voulant insérer une image en explorant le serveur j'ai ceci
PHP Error Message
Warning: is_dir() [function.is-dir]: open_basedir restriction in effect. File(/usr/local/apache/htdocs/data) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/a5483979/public_html/plugins/ckeditor/kcfinder/core/uploader.php on line 225
Free Web Hosting
PHP Error Message
Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/usr/local/apache/htdocs/data/.htaccess) is not within the allowed path(s): (/home/:/usr/lib/php:/tmp) in /home/a5483979/public_html/plugins/ckeditor/kcfinder/core/uploader.php on line 254
Free Web Hosting
plus un pop up
Cannot write to upload folder. /usr/local/apache/htdocs/data
Qu'est-ce qui ne fonctionne pas bien?
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Pluxml version 5.1.7 (encodage UTF-8)
Version de php : 5.2.17
Etat des "magic quotes" : 1
✔ ../../data/configuration/ est accessible en écriture
✔ ../../data/articles/ est accessible en écriture
✔ ../../data/commentaires/ est accessible en écriture
✔ ../../data/statiques/ est accessible en écriture
✔ ../../data/images/ est accessible en écriture
✔ ../../data/documents/ est accessible en écriture
✔ Bibliothèque GD installée
✔ Fonction d'envoi de mail disponible
Avant d'installer CKEditor, j'avais installé plxEditor et je n'avais pas de problème de ce genre.
Mon hébergeur est 000webhost.com en version gratuite. Je viens d'installer Pluxml et CKEditor chez free mais ce coup-ci j'ai
The "safe_mode" PHP ini setting is turned on! You cannot run KCFinder in safe mode.
Du coup, je ne suis pas plus avancé!
le coup du safe_mode chez free c'est normal c'est une restriction de l'hébergeur. ckeditor c'est mort chez eux, il n'est pas possible de contourner cette restriction.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)