SPIP-Contrib

SPIP’s friends

Home > Editeurs WYSIWYG avant SPIP 1.9 > Plugin FCKeditor pour SPIP 1.9

Plugin FCKeditor pour SPIP 1.9

Friday 26 May 2006

Un essai d’intégration d’un éditeur Wysiwig par le système de plugins de SPIP 1.9 (reprise de ma contribution pour SPIP 1.8).


View online : Plugin FCKeditor pour SPIP 1.9

37514 discussions

  • 7

    Bonjour,

    J’obtiens cette erreur fatale a la mise a jour du plugin:

    Fatal error: Can’t use function return value in write context in formidable_mailsubscribers/v1.1.3/formidable_mailsubscribers_pipelines.php on line 43

    Merci

    • OK,
      php 5.4 n’accepte pas une fonction en argument de empty.
      Pb resolu en passant en 5.5 .

    • Bonjour,

      Il faudrait voir la version de SPIP mais un php 7.2 serait bien si SPIP 3.2 cf https://www.spip.net/fr_article4351.html

    • oui c’est ce que j’allais dire. Cela étant je vais corriger vu que spip supporte officiellement ces versions de php

    • Merci Pierre pour la reference.
      La 3.2 devrait donc en principe marcher en php 5.4.
      J’aurai surement a passer aux versions 7 a moyenne echeance.
      Mais, j’ai encore des incompatiblites avec d’autres systemes.
      Enfin, php 5.5 a deja suffi a resoudre le pb du empty.

    • OK Maïeul
      Merci pour le suivi.

    • Voilà la 1.1.4 devrait faire l’affaire. Cela étant je n’ai pas pu tester, vu que php 5.4 pas possible de l’installer facilement sur les dernières version d’ubuntu.

      En plus j’ai l’impression que le code en question ne sert pas à grand chose car le _request est vide systématiquement, A voir.

    • Ok,

      J’ai pu installer en php 5.4 ta nouvelle version (sur Spip 3.2).
      (pas d’erreur comme pour la 1.1.3)

      Actions réalisées
      La mise à jour du plugin « Formidable : abonnements à des listes de diffusion » (de la version : 1.1.3 à 1.1.4) s’est correctement déroulée

      Merci

    Reply to this message

  • Bonjour ,

    Deux anomalies constatées pour le multilinguisme (tests faits avec la version 2.16 du plugin):

    -  la première

    A l’inscription , si le nom du site est une valeur de type multi

            <multi>[fr]nom_du_site[en]site_name</multi>

    alors on obtient ce message :

            You have asked for a subscription to the list "your_list" of [fr]nom_du_site[en]site_name with email address ...

    Les balises multi du nom du site ne sont pas traitées.
    Les tags multis autour du nom de site ne sont pas visibles, mais sont toujours là.
    (Mais le multi du nom de liste est bien rendu .)

    script concerné:


    action/subscribe_mailsubscriber.php

    function action_subscribe_mailsubscriber_dist

    Le multi de la liste est interprèté par un appel a typo().
    mais pas celui du nom de site

    Pour résoudre mon problème


    J’ai donc rajouté aussi typo pour ’nom_site_spip’

            'nom_site_spip' => typo($GLOBALS['meta']['nom_site']),

    -  seconde anomalie:

    Les messages d’inscriptions et de suppression d’une seule liste sont bien dans
    la langue associée à l’email
    Mais pas le message après suppression de TOUTES les listes : il est dans la langue locale

    script concerné:


    action/unsubscribe_mailsubscriber.php

    Pour la suppression d’une seule liste , l’action est unsubscribe_mailsubscriber
    alors un changer_langue dans la langue associée à l’email est fait par la fonction mailsubscribers_verifier_args_action
    le message obtenu est dans la bonne langue.

    Le cas de suppression de TOUTES les listes fait appel à action/confirm_mailsubscriber.php
    qui appelle aussi l’action unsubscribe_mailsubscriber

    Mais dans ce cas particulier il n’y a pas appel de mailsubscribers_verifier_args_action.
    Donc il n’y a pas de changer_langue et la langue du message (et du mail) est fausse.

    Pour résoudre mon problème:


    Pour le cas ou le email en argument n’est pas null (cas ou pas d’appel de mailsubscribers_verifier_args_action.)
    je reprends la langue depuis la variable $infos[’lang’] qui contient déjà la langue associée à l’email
    et fait le changer_langue avec:

            if($emailEnArg && $infos['lang']) {
                    include_spip("inc/lang");
                    changer_langue($infos['lang']);
            }
            

    Reply to this message

  • Bonjour

    J’ai modifié l’insertion en ajoutant
    |inserer_attribut{data-author,#CREDITS}

    Mais cela n’affiche pas l’information dans la box.

    Comment remédier à cela svp ?

    Reply to this message

  • 2

    Bonjour à tous,

    Je voudrais que mes tableaux avec la class “spip” ne soient pas modifiés et que seuls ceux avec la classe “spip tablesorter” bénéficient de Tablesorter.

    La documentation se contredit :

    • dans cette page, il est indiqué “ajoutez la class « tablesorter » à la balise ”
    • dans la description du plugin installé : “Ce plugin permet de trier les tableaux portant la class CSS “spip” en cliquant simplement sur l’entête d’une colonne”.

    Est-il possible de le faire fonctionner ainsi sans toucher au code du plugin qui sautera à chaque mise à jour ?

    Merci !

    • propose une pull request :) cela étant, je ne sais pas ce qui est le mieux, car cela risque de casser certains sites. Peut être une option ?

    • Merci pour ta réponse rapide. En fait ce qui m’embêtait c’était surtout l’image de tri et le padding important, notamment pour avoir un aspect (un peu) responsive du tableau. Sur un smartphone, mes entêtes ne comportaient q’une lettre du titre et l’image à côté.

      J’ai donc surchargé le CSS et les “conséquences visibles” de Tablesorter ne sont plus là en masquant l’image et en diminuant les padding.

      text-align: center;
      vertical-align: middle;
      background-image: none ;
      padding: 1px 1px 1px 1px;

      Bonne après-midi,

    Reply to this message

  • 3

    Bonjour,
    j’envisage d’utiliser ce plugin sur un site qui comporte plusieurs listes. Est-il possible de restreindre l’inscription qu’à une ou deux listes avec quelque chose comme :

    <formulaire|formidable|id_liste=x,y>

    Possible ? Pas possible ?

    Reply to this message

  • 6

    Bonjour Maieul,
    Je rencontre des soucis avec la toute dernière version.
    Ca fait 24h que je me casse la tête sur un nouveau bug sur les sites de mes clients, pour enfin réaliser que cela provient de la dernière mise à jour...
    J’ai regardé les modifs et commentaire sur Git.
    Le problème est le suivant :
    J’utilise des champs extras sur des événements, j’utilise la fonction “afficher_si” sur nombre de ces CA, et même en cascade...
    Désormais quand je modifie un événement, des données (des CAs) sont supprimées de la BDD, alors qu’ils sont liés à des champs bien affiché... C’est très impactant comme soucis...

    Je déduis donc que le nouveau comportement d’afficher_si qui “reset” les datas des champs non affichés, semble également vider des champs affichés ...
    Je vais ajouter des afficher_si_avec_post" => True à gogo pour voir si ca aide mais malgré tout, je pense qu’il y a une coquille qqpart.
    Merci de ton assistance.
    JuL

    • hum. C’est vraiment très très étonnant ton affaire.

      Pourrais tu m’exporter tes champs extras ?

      en attendant je vais supprimer le tags, par précaution. Mais j’avais testé chez moi.

    • Je peux pas les exporter aux formats YAML car je les déclare en php dans mon plugin. Il sont très nombreux et il y a plein de php autour donc tu pourras pas faire un test facilement.

    • envoi moi ton php alors :)

    • en tout cas je viens de retester, et je ne reproduis pas...

    • Suite et fin de l’épisode

      pour info, on a debuger un cas de bug sur les afficher_si, qui peut
      expliquer le bug que tu as eu en janvier.

      Cela se produisait si un champ A était conditionné par la valeur d’un
      champ B qui se trouvait dans un autre fieldset.

      la dernière version de saisies 3.47.3 corrige cela.

    • Il se confirme que le bug était bien lié à cela.

    Reply to this message

  • 6

    Bonjour,
    Depuis quelques versions de champs extra, je dois enregistrer plusieurs fois les modifs pour qu’elles soient effectives. Pour info, je rencontre toujours le problème malgré les maj, je suis actuellement en :
    -  Saisies pour formulaires 3.48.2
    -  API de vérification 1.12.0
    -  Saisies pour formulaires 3.48.2
    Est ce un problème connu ?
    Merci à vous

    • Bonjour,

      cela ne me dit rien. Mais la phrase est peu claire. S’agit-il de modifs
      1. De la valeur de champ extra en particulier ?
      2. Des champs extra eux même (via l’interface graphique).

      Utilisez vous des afficher_si ?

    • Je précise, cela arrive à la création et à la modification de champs extras via l’interface champ extra. Typiquement sur les labels. Ce qui est étrange c’est la différence de valeur entre l’écran de recap des champs extras et le formulaire d’édition des champs extras. Souvent bon dans le forum mais non mis à jour dans l’écran de récapitulatif général (page principal du plug-in interface champ extra)

    • Pas d’utilisation conditionnelle via afficver_si

    • Hum, je ne reproduis pas via l’interface. Et il n’y a pas eu de modif de l’interface ces derniers temsps. En revanche pas mal de modif côté saisie sur l’affichage en onglet, mais je ne vois pas ce qui pourrait jouer.

      Une possibilité cependant, mais cela remonte à il y a au moins 2 ans, ce sont les modifs que j’ai faite sur les sessions et saisies. Peut être du coup vider tout tmp/sessions (en s’assurant que personne ne soit connectés à ce moment là) pour avoir une base saine.

      Si le problème se reproduit, il faudrait alors essayer d’investiguer plus. Et pour cela, nous décrire pas à pas à quel moment cela arrive.

    • Effectivement le problème n’est pas récent et je le rencontre sur différents sites, j’ai longtemps garder une version inférieur pour l’éviter.

      J’ai essayé en vidant les sessions, le problème apparait toujours de façon aléatoire.

      En re-testant, un autre phénomène se produit, après l’ajout d’un champ (testé avec case unique), quand je demande son édition pour renseigner ses infos, le champ disparait complétement (directement au clic sur picto édition). Se genre de phénoménes a lieu également avec le plugin formidable, lors de l’ajout de champ.
      Je suis chez OVH en PHP 7.2, FPM, si cela peut aider.

    • Hum. je viens de retester aussi formidable, et je ne rencontre pas le problème que vous décrivez.

      Est-ce que vous auriez par hasard des plugins supplémentaire qui pourraient interferer avec le JS? Serait-il possible de me monter un site de test/dev pour que je puisse voir ce qu’il en est, et voir si j’arrive à debuger en live, puisque je n’arrive pas à reproduire le bug chez moi.

    Reply to this message

  • Bonjour,
    impossible d’installer correctement le plugin en version v1.10.19 sur un SPIP 3.2.9 tout frais (hébergement ovh php 7.3) : j’obtiens ceci quand je clique pour paramétrer
    Parse error: syntax error, unexpected ’<’, expecting end of file in /home/xxxxxxxx/xxx/plugins/auto/couteau_suisse/v1.10.19/inc/cs_outils.php(446) : eval()’d code on line 1

    je suis allée sur la ligne 446 sans rien trouver de semblable, en ligne 449 on trouve en effet un ’<’ mais qui existe depuis les versions antérieures
    je cale ... après plusieurs réinstallations

    Reply to this message

  • 14

    Yop,
    pour info, qu’est ce qui explique le nécessite PHP 7.0.8 ?

    • Plop,

      C’est la lib Intl de Commerce guys qui nécessite ça.

    • Ben justement, je me suis douté, j’ai regardé, et dans le composer.json ça dit :

      "require": {
          "php": ">=5.5.0"
      }
    • Ah tu fais bien de signaler, faut qu’on mette à jour.
      Maintenant c’est bien php 7.0.8 min : https://github.com/commerceguys/intl/blob/master/composer.json#L7

    • Ah flûte, ça m’arrange pas, c’est pour un vieux serveur avec PHP 5.6 ^^

      Bon, sinon, comment afficher par défaut le symbole € à la place de “EUR” ?

    • Il y a deux manières :
      -  soit tu ne touches à rien et tu utilises les balises avec * puis tu appelles le filtre de formatage toi-même dessus avec les options que tu veux
      https://git.spip.net/spip-contrib-extensions/prix/src/branch/master/prix_fonctions.php#L139
      -  soit tu surcharges le filtre sans le _dist et tu mets autre chose que tu veux par défaut

      Il ne me semble pas qu’on soit parti pour rendre ça configurable pour pouvoir changer le défaut, car la seule manière vraiment accessible c’est avec les devises en code alpha. Les symboles ne sont pas forcément lu correctement partout, et encore moins quand ça dépend des devises. Donc l’afficher autrement, comme par ex avec le symbole, ne devrait pas pouvoir être mis par défaut, mais plutôt utilisé au cas par cas à la main (avec étoile et le filtre), par ex dans des endroits précis où on veut un affichage “marketing” court et joli à présenter (concrètement avec un truc du genre : <span class="offscreen">#PRIX</span><span aria-hidden="true">[(#PRIX*|prix_formater{avec symbole})]</span>).

    • Ah… autre idée si tu veux vraiment par défaut malgré accessibilité et sans devoir surcharger (c’est jamais top) : t’insérer dans “declarer_tables_interfaces” après Prix, et passer par dessus la définition des filtres des deux balises en changeant $interface['table_des_traitements']['PRIX'][]= 'prix_formater(%s)'; par le tien, avec normalement possible la même fonction mais avec l’argument options en plus avec ce que tu désires.

    • Ok merci.
      Ce sera pour un site purement à public français, et en €, une surcharge ira très bien (même pas peur ^^).

    • Test quand même la table des traitements, c’est plus court (2 lignes de code) et ça éviterait la surcharge ! :)

    • Hello,

      Je viens de mettre a jour (merci au passage) et j’ai testé la surcharge de
      $interface['table_des_traitements']['PRIX'][]= 'prix_formater(%s)';

      depuis _options ... mais rien a faire :/ prix est bien necessité ... je vois pas ce que j’ai loupé ..

      j’ai testé ça :

      $GLOBALS['table_des_traitements']['PRIX'][] = 'fragment_prix_formater(%s)';
       
      function fragment_prix_formater($prix, $options = array()){
      	$fonction_formater = charger_fonction('prix_formater', 'filtres/');
       
      	return $fonction_formater($prix, array('currency_display'=>'symbol'));
      }

      et en fait du coup dans la doc/comment c’est écrit que prix_formater currency_display est en symbol par defaut mais dans le code je crois pas... je suis obliger de le forcer partout.

    • Alors
      1) Je sais pas ce que c’est que cette globale, les traitements c’est dans le pipeline “declarer_tables_interfaces” et c’est bien de ça dont j’ai parlé plus haut et c’est ça que tu dois utiliser pour être propre.
      2) Au pire tu peux aussi surcharger sans le “dist” et à l’intérieur appeler la fonction mère avec le dist (en l’appelant en dur du coup, pas avec un charger dynamique)

    • les traitements c’est dans le pipeline « declarer_tables_interfaces »

      qui instancie $GLOBALS[’table_des_traitements’] :)

    • Bah pourquoi ça marcherait pas ? C’est une pratique traditionnelle de modifier $GLOBALS['table_des_traitements']['CHAMP'][] sans passer par le pipeline Cf https://programmer.spip.net/Traitements-automatiques-des ... et assez précisément documenté ici : https://www.teddypayet.com/Supprimer-le-numero-du-titre-de-la-rubrique
      Et sinon clin d’œuil perso en mode souvenir souvenir : http://archives.rezo.net/archives/spip-zone.mbox/B5H7BS3ILDWCFD4A5GINR6GDOLWSV5KC/

    • Et bien c’est ce que je me demandais @Jluc, pourquoi ça marcherais pas ;-)

      bon j’ai dupliqué la fonction filtre dist au final .... merci de vos réponses.

    • cadeau

      /**
       * prix accessibilité
       * surcharge pour retourner le symbole de la devise dans un span
       * <span class="montant" data-montant-nombre="18" data-montant-devise="EUR">18,00&nbsp;<span class="montant__devise">€</span></span>
      **/
      function filtre_montant_formater($montant, $options = array()) {
      	$options['currency_display'] = 'symbol';
      	return filtre_montant_formater_dist($montant, $options);
      }

    Reply to this message

  • 3

    Salut,

    est-ce qu’il y a une solution pour n’avoir qu’une (ou certaines) liste dans les choix du formulaire (via leur identifiant par ex) ?

    Actuellement, on ne peut filtrer les listes que selon les statuts (ouvertes/fermées/à la poubelle) or j’ai plusieurs listes ouvertes mais je ne veux proposer l’abonnement qu’à une seule via le formulaire.

    • Hello,

      Oui l’option existe dans le HTML de la saisie mais elle n’est pas exposée dans le YAML.

      C’est la saisie du plugin mailsubscribers pour le coup.
      À tester pour voir si l’option fonctionne toujours correctement et go la PR ! (ou un commit direct, c’est une modif mineure).

    • a noter que j’ai apporté il y a peu à à formidable mailsubcriber la possibilité également de gerer le cas où l’on a une saisie selection/radio

      identifiantdelinfolettre|Je souhaite m'abonner à la liste "intel"
      nope|Je ne souhaite pas m'abonner

      Cas d’usage : un formulaire d’inscription à une activité, où l’on propose à la fin de s’abonner à l’infolettre. On veut être sur que la personne a bien lu qu’elle a la possibilité de le faire. Donc on met un select obligatoire. La personne est obligée de répondre, mais choisi librement de s’abonner ou pas.

    • La version 2.16.0 du mailsubscriber a corrigé le .yaml (avec des jolies cases à cocher plutot que de demande de saisir une virgule...)

    Reply to this message

Any message or comments?

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document