Vous n'êtes pas identifié(e).
13 février 2024 Sortie de Dotclear 2.29
Bonjour,
Sur notre plateforme en dotclear 2.27.3, j'ai un souci avec l'utilisation du plugin CKeditor :
- un utilisateur avec des droits à minima "gérer tous les billets et commentaires" : cela fonctionne, la barre de boutons de ckeditor s'affiche bien.
- un utilisateur avec des droits seulement "gérer ses propres billets et commentaires" : cela ne fonctionne plus. L'appel js (...)/admin/index.php?process=Plugin&p=dcCKEditor&config=1&context=post&v=2.27.3 renvoie une 404.
J'ai ce bug sur notre plateforme multiblog en production ainsi que sur mon serveur local.
Si je regarde https://git.dotclear.org/dev/dotclear/s … src/My.php , les droits pour l'utiliser semblent cohérents avec les problèmes que je rencontre.
Est-ce que cette fonctionnalité n'est réservée que pour les utilisateurs admin de blog ou gestionnaire de tous les billets ?
Ou est-ce bien un bug de Dotclear ?
J'ai corrigé mon fichier plugins/dcCKEditor/src/My.php en ajoutant la permission dcCore::app()->auth::PERMISSION_USAGE et j'ai le résultat attendu.
Pensez-vous que ce soit risqué ?
Merci de vos retours.
Johan
C'est exactement ça ! (mon path se retrouve alors premier)
Merci beaucoup Franck.
Bonjour,
Comment faire dans un plugin pour « surcharger » des templates des default-templates ? (currywurst ou mustek)
Est-ce possible ?
Ici je souhaite dans que mon plugin modifie/surcharge les 2 fichiers suivants :
_entry-feedback.html de inc/public/default-templates/currywurst
le post.html de inc/public/default-templates/mustek
J'ai bien réussit à ajouter dans mon plugin :
$core->addBehavior('publicBeforeDocument',array('MyPublicClass','addTplPath'));
class MyfooterPublic
{
public static function addTplPath($core)
{
$tplset = $core->themes->moduleInfo($core->blog->settings->system->theme,'tplset');
if (!empty($tplset) && is_dir(dirname(__FILE__).'/default-templates/'.$tplset)) {
$core->tpl->setPath($core->tpl->getPath(), dirname(__FILE__).'/default-templates/'.$tplset);
} else {
$core->tpl->setPath($core->tpl->getPath(), dirname(__FILE__).'/default-templates/'.DC_DEFAULT_TPLSET);
}
}
}Le path est bien présent dans $core->tpl->getPath().
Mais pour le reste je sèche. C'est possible de faire prendre en compte des « surcharges » de ces fichiers ?
Merci de votre aide.
Bonjour,
Sur nos hébergements web, deux sites ont été également victimes de cette faille sérieuse de phpmyvisites. Des restaurations complètes ont été nécessaires (des milliers de fichiers php modifiés).
Il est important de vérifier les dates des fichiers (de tout le site, pas seulement du dossier de phpmyvisites).
Un lien : http://www.phpmyvisites.us/#infohack pour savoir si votre site est potentiellement atteint.
Johan
En attendant qu'un plugin soit développé...
Une idée : Utiliser un widget texte dans lequel mets le code html voulu.
Johan
Bonjour,
En joignant chaque fichier mp3 au billet (un mp3 par billet), je viens de tester, cela fonctionne aussi dans itunes.
En mettant bien le fichier au niveau des « Pièces jointes ».
Les documents sont bien joints dans le flux rss (ou atom) qui est du coup un flux de podcast.
Johan
Moe a écrit :Je ne me permettrai pas de juger un plugin qui n'est pas de moi. :)
Bien entendu, ça se comprend tout à fait !
Ce que je voulais dire, c'est plutôt avoir un regard purement informatif sur le plugin, sur son état actuel (utilisable en "live" ou alors juste pour les codeurs à des fins de tests), afin de savoir si il est raisonnable de l'utiliser sur un site public.
Mathieu ;-)
Bonjour,
Merci Moe de m'avoir alerter...
Mathieu, je peux t'envoyer le plugin. Contacte-moi directement et je te le renvoie.
Je l'utilise de mon coté pour faire de la « supervisation ». Pas pour afficher les fils publiquement.
Il manque aussi le filtre des billets qui seraient protégés (avec mot de passe ou PrivateMode).
Le flux des billets fonctionne mais les textes wiki ne sont pas mis en forme (pas grand chose à priori).
Il n'est pas terminé... c'est peut-être l'occasion d'avancer !
Johan
Mais comme il s'agit d'une activation blog par blog, c'est peut être pas une si bonne idée que cela, je vais peut être mettre des droits plus souples dans la prochaine version.
Merci !
En attendant, je me régale avec ce plugin \o/
Super le plugin ! Merci beaucoup !
Je l'ai activé sur notre plateforme.
J'ai toutefois du faire deux modifications dans :
- _admin.php (
et :
- admin/ps_plugin.php (j'ai viré la condition « superadmin »)
ligne 30 :
$core->auth->check('media,media_admin,admin',$core->blog->id)à la place de
$core->auth->isSuperAdmin()Ceci pour permettre aux propriétaires de blogs d'activer eux-même Pictures Show (pour _admin.php) et pour qu'ensuite il n'y ai pas de bug pour eux sur la page d'activation (admin/ps_plugin.php).
J'espère ne pas avoir créer d'effet de bord. Et ça m'embête un peu de modifier de plugin...
Pourquoi l'activation est-elle réservée aux superadmin ?
Bon, j'ai revu complètement mon plugin homePageMode ( premier du nom ), et viens de mettre en ligne homePageMode2.
Bonjour,
Je viens de tester ta nouvelle version (0.5) qui me semble bien plus simple à utiliser !
Pour les besoins de notre plateforme de blog (multiblog, thèmes partagés) nos utilisateurs réclament de pouvoir afficher un éditorial simplement et cette nouvelle version devrait les combler. Cela fonctionne en multiblog.
Merci !
Le seul bémol : en page d'accueil s'affiche bien l'édito (et un lien vers les billets) mais pas les premiers billets.
Je me suis demandé du coup si un template homePageMode.html est une bonne idée ou si l'utilisation des behaviours ne serait pas plus adaptée pour pousser l'édito avant la liste de billets ?... Cela permettrai aussi de garantir une meilleure compatibilité avec les différents thèmes. Mais apparemment il n'y a pas de behaviors pour cela !
Johan
Effectivement ça marche au poil chez toi! :)
Je demandais des retours car par exemple, sur la plateforme de blogs de l'académie de versailles, le chargement est assez long. En même temps, je crois qu'il en a VRAIMENT beaucoup.
Ceci dit, j'ai normalement optimisé le code depuis et je ne sais pas si Johan a changé la version depuis...
Oui, c'est fait depuis hier en fin d'après midi.
ça va carrément plus vite comme je te l'ai dis par mail.
A suivre dans quelque temps avec j'espère plein de blogs ayant activé MultiBlogSearch :-)
Johan
Bravo et merci !
Je viens de tester sur notre plateforme : nickel :-)
Je regarderai tes modifs quand j'aurai plus de temps...
Tu va faire des heureux : dans certaines de nos petites écoles, ils attendaient cette fonctionnalité avec impatience (car leur charte impose un accès protégé en particulier par rapport aux parents quand il y a des photos de leurs bambins).
Johan
Quelques autres questions concernant Dotclear :
- L'utilisation d'un plugin doit-elle obligatoirement passer par un blog ? Par exemple, pour accéder au plugin Subscription, il faut renseigner l'url http://un_blog.domaine.tld/index.php/subscription
Vu tes questions (et mes réponses), je pense que dans ton cas tu n'es pas forcé de passer par un blog.
Pour la suite de tes questions, je ne suis pas assez calé...
Regarde du coté de la doc et du code plugins existants. Du moment que tu arrive à instancier des objets, ça doit être possible.
Johan
Côté script, j'ai bien compris la procédure à suivre. J'en ai développé un petit qui réalise les étapes suivantes :
1. Insertion d'une ligne dans la table dc_blog avec les renseignements nécessaires : Id du blog, uid (md5+uniqid), dates de création et modification, URL, Nom et description, activation à oui.
Peut-être mettre ces infos dans une table distinctes et quand le token est validé, récupéré les données et les mettre dans la base de dotclear.
Je pense que c'est plus propre. Comme tu le dis plus bas.
J'y avait pensé aussi mais un peu tard...
Concernant ta page d'activation, s'agit-il d'un blog sur lequel tu fais un lien vers index.php/subscription ou bien as-tu redéveloppé une page faisant usage du plugin ?
C'est le blog par défaut. avec des liens.
Voir ma signature.
Sinon dernière question : pourrais-tu m'indiquer quels choix t'ont poussé à choisir Dotclear plutôt qu'une autre solution telle que Wordpress MU qui gère nativement les fermes de blog ?
Quand j'avais regardé wordpress, qui pour chaque blog créés ajoute des tables distinctes dans la base, ça m'a paru plus complexe à gérer à long terme.
Et surtout, Dotclear et sa communauté m'avait l'air bien sympa :-)
Le développement était en beta mais ça carburait dur (il y a un tout petit plus d'un an).
Je suis très content de ce choix :-)
Johan
En fait, j'avais utilisé la v0.1...
Johan
Le principe final doit être une page d'activation, joignable via l'url principale (ex: blogs.universite.fr), sur laquelle un membre de l'université (Etudiant, Personnel, Enseignant) n'aura qu'a saisir une fois son login pour activer son blog personnel (impliquant une communication avec un annuaire LDAP)
Et son mot de passe j'imagine ?
Pour créer le blog de façon automatisée il faut qu'un script fasse au moins deux choses :
- ajouter les infos (blog, utilisateur,...) dans la base de données.
- créer le bon répertoire du blog contenant le bon fichier index.php
C'est ceci que fait mon script.
Ou plutôt le script du plugin Subscription que j'ai adapté à nos besoin (chemins à adapter + quelques adaptations + bug avec captcha).
http://marcvachette.info/?plugin-subscr … version-02
De mon coté je n'utilise pas ldap.
Je filtre simplement les emails du formulaire de création.
Si c'est bon, le blog est créé et un mail envoyé à l'utilisateur (contenant en particulier son mot de passe).
ça marche bien sauf pour les personnes qui ne savent pas lire leurs mails (nous en avons beaucoup !) et dans ce cas le blog restera désespérément vide si les gens ne me contacte pas...
Peut-être peux-tu aussi filtrer avec les emails ? (qui sont dans ldap et correspondent à un login que tu récupères)
Tu demandes dans ton formulaire les infos :
- email,
- vrai nom du blog,
- nom court du blog pour le dossier
- option : blog perso ou de groupe ?
- ...
Ce que je n'ai pas fait de mon coté : avoir une architecture propre comme celle proposée dans les tutos depuis. Je n'ai pas non plus de sous-domaine (que je ne sais pas géré automatiquement).
De ton coté, j'imagine encore qu'il faudrait modifier les classes d'identification de dotclear pour se connecter via l'annuaire ldap.
Je suis le fil si tu as d'autres questions !
Johan
Une bonne nouvelle.
Je ne voyais pas de bug avec le query_string :/ enfin bon, tant mieux.
t'as peut-être un cache à zéro avec ton navigateur ?
Mais ça m'intéresse tout de même Johan si tu poursuis tes tests avec le fichier .htaccess.
Quelle règle tu mets dans le htaccess ?
Johan
Pour le cache, je vois qu'on peut appeler serveDocument avec le troisième paramètre à 'false' :
http://dev.dotclear.org/2.0/browser/tru … rs.php#L37
C'est peut être une piste.
Bien vu !
Avec :
self::serveDocument('private.html','text/html',false);la page private ne reste plus en cache.
ça fait un souci de moins :-).
En tout cas en query_string, il n'y a maintenant plus de bugs (j'ai testé avec ie7, firefox et chrome). Ok aussi pour la déconnexion.
Reste les différentes sessions lancées avec le mode path_info, sans htaccess... J'ai vu jusqu'à 4 sessions de lancées (en commençant par consulter un billets, puis un mois des archives, puis les archives, puis /index.php/ puis /). une session par niveau de chemin descendant...
Je devrais peut-être mettre un htaccess...
kerjoa a écrit :L'arrachage de cheveux continue...
Ça ne corrige pas les problèmes...
Pour les problèmes, on a bien:
1) le souci en path_info sans .htaccess qui donne deux sessions PHP démarrées sur le blog
2) euh ?
1) : oui . voir parfois 3 sessions
2) j'ai aussi l'impression qu'il y a un problème avec les caches de navigateurs
Et peut-être avec le cache dotclear car le comportement est vraiment parfois très étrange : difficile parfois de reproduire les mêmes bugs.
L'arrachage de cheveux continue...
Ça ne corrige pas les problèmes...
j'ai l'impression qu'il n'y a plus le bug.
En fait il reste un problème avec les caches des navigateurs.
Si je permet le php dans mon blog et je met ceci dans private.html pour que le navigateur ne garde pas en cache :
<?
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date dans le passé
?>Dans ce cas il n'y a plus de bug.
Il faudrait donc pouvoir ajouter un header php dans private.html via le plugin. Je pense qu'il y a ce qu'il faut pour dans dotclear. Je regarde de mon coté.
Johan
Bug reproduit.
Configuration :
Blog en path info sans .htacess.
Url renseigné dans les paramètres du blog : http://www.monsite.tld/index.php/Reproduction de l'anomalie:
Aller sur la page http://www.monsite.tld/index.php/ , se connecter, naviguer sans aller à la racine du site.
L'accès à http://www.monsite.tld/index.php fonctionne.
http://www.monsite.tld/index.php/ ou http://www.monsite.tld/ servent la page private.htmlVoici le code : http://lab.dotclear.org/browser/plugins … public.php
Une idée ?
Je viens de m'arracher les cheveux sur ce truc :-)
En remplaçant dans _public.php ligne 34 :
$session_private = session_id();
if (empty($session_private))Par :
//$session_private = session_id();
if (empty($session_private) && $core->blog->settings->url_scan == "query_string" )j'ai l'impression qu'il n'y a plus le bug.
Mais ne me demandez pas pourquoi...
Johan
Bonsoir,
oui, j'utilise bien la 0.4RC10.
J'ai constaté aussi qu'il pouvait y avoir deux variables de session...
Je regarderai plus en détail demain.
Johan
> h2d2 : tu m'a envoyé un message par mail, mais comment te répondre si ton adresse « moi@yahoo.fr » n'est pas valide... ? embêtant car j'ai passé un peu de temps à te répondre :-(
il me redemande le mot de passe pour ces pages :
http://blog.crdp-versailles.fr/testblog/index.php/ ou http://blog.crdp-versailles.fr/testblog/
mais pas pour http://blog.crdp-versailles.fr/testblog/index.php
mince, c'était blog2 pas testblog :
il me redemande le mot de passe pour ces pages :
http://blog.crdp-versailles.fr/blog2/index.php/ ou http://blog.crdp-versailles.fr/blog2/
mais pas pour http://blog.crdp-versailles.fr/blog2/index.php
Et ce comportement dépend de la page sur laquelle je me suis loggué.
Autre chose :
je navigue, puis me déloggue.
Si je demande la page : http://blog.crdp-versailles.fr/blog2/ elle s'affiche.
si je vais sur une autre page, on me demande bien le mot de passe.
Johan
Vous n'êtes pas identifié(e).