Home > Site navigation and search > Mise à jour du plugin « Boutons d’administration supplémentaires (...)
Mise à jour du plugin « Boutons d’administration supplémentaires »
Thursday 25 January 2007
Le plugin « Boutons d’administration supplémentaires » a été mis à jour. Dans cette nouvelle version, le bouton « Recalculer cette page » est remplacé par une icône pour gagner de la place et certains boutons liant à des fonctions normalement réservées aux administrateurs sont désactivés pour les rédacteurs.
Discussions par date d’activité
37514 discussions
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
alors on obtient ce message :
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’
- 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:
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
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 :
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
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 :
Possible ? Pas possible ?
La dernière version de mailsubscriber permet de choisir les listes lors de la configuration du champ :)
Super, je teste ça à mon retour de vacances :)
+1 , c’est super ! Merci beaucoup Maieul.
Reply to this message
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
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
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 :
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 :
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)
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-rubriqueEt 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
Reply to this message
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
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