SPIP-ContribHome > 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.
Any message or comments?
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
- Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
- Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
- version de SPIP, en bas de la partie privée
- version du plugin testé et des éventuels plugins nécessités
- version de PHP (exec=info en partie privée)
- version de MySQL / SQLite / PostgreSQL
- Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
- En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparait.
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Discussions by date of activity
38489 discussions
Bonjour,
Est-ce qu’une version compatible SPIP 4.0 / 4.1 est prévue ?
Merci,
François
bonjour
ravi que vous vous en serviez..
j’attendais de savoir si ça intéressait qqun d’avoir une màj.
je m’y mets tt de suite ..
fwd
Reply to this message
bonjour
Désolé mais j’ai une erreur sur ce même fichier ligne 1421
merci de votre aide
Bonjour,
Ce message d’erreur ne concerne pas les plugins Giseh.
Il signifie que la fonction exec de PHP est désactivée chez l’hébergeur.
Reply to this message
Bonjour et bravo pour tout ce travail,
je cherche à faire un seul formulaire pour les articles d’une rubrique (recrutement) qui reprendrait dans chaque article (offre d’emploi) le titre de l’article dans les envois au webmestre afin de savoir pour quelle offre la réponse a été donnée.
J’ai cherché (certainement mal) dans le forum et je n’ai pas trouvé.
J’imagine une info a ajouter dans l’appel du formulaire :
#FORMULAIRE_FORMIDABLE{emploi,#TITRE}Par avance, merci, Alain
1. Il faut reperer le “nom technique” du champ (listé à droite lorsqu’on édite le formulaire), du type
input_1.2. Ensuite le passer effectivement en paramètres, mais pas avec la syntaxe que tu utilise, mais selon celle donnée plus haute dans l’article.
Si ton formulaire a l’identifiant
reponse_emploica donnerait :#FORMULAIRE_FORMIDABLE{reponse_emploi, #ARRAY{input_1, #TITRE}}Tout dépend si c’est un appel dans les contenus, ou automatisé dans les squelettes de telle branche (ce qui est le plus logique dans ton cas).
Il faut ajouter un champ caché (hidden), et pré-remplir ce champ avec une info du contexte (le ID_ARTICLE ou directement le titre humain), pour ensuite le réutiliser dans ton message final.
Sinon tu peux aussi voir si le plugin Emplois te permet d’encore mieux gérer de manière dédiée ce besoin plutôt que détourner les articles.
Bonjour et merci à Maïeul et RastaPopoulos
J’ai en effet utilisé les deux infos et j’étais un peu à l’ouest.
Bien sur avec le champ caché (j’ai déjà le titre sur la page publique) et le code dans le squelette article-xx.html de la rubrique :
#FORMULAIRE_FORMIDABLE{reponse_emploi, #ARRAY{hidden_1, #TITRE}}J’ai exactement ce que je souhaite, dans les mails, le tableau des réponses et l’accusé de réception, c’est parfait.
Encore merci
Alain
Bonjour,
En lisant votre échange, je pensais pouvoir récupérer le titre de mon article dans un champ caché, (en appelant mon formulaire directement dans cet article) :
Mais je ne récupère que la valeur
#TITRE.Merci pour vos lumières !
Ah, ça fonctionne en utilisant directement dans le squelette :
Ma syntaxe ne doit pas être correcte avec :
SPIP 4.1.5 et Formidable à jour.
Bé oui @Graphie, ça n’existe pas, depuis quand as-tu vu que #TITRE pouvait avoir un quelconque sens dans le contenu texte de n’importe quel contenu ? :p
C’est une balise de boucle, du langage de squelette.
Hé voui, je comprends bien.
Donc pour un formulaire inclus dans le corps d’un article, pas de possibilité de savoir depuis quel article il a été envoyé ?
Bé non, mais puisque tu es déjà dans le texte d’UN article précis unique bah t’as pas du tout besoin de dynamisme non ? Tu peux remettre le titre que tu veux dans le hidden=Mon super titre
(oui en plus dans un modèle c’est toujours “=” hein pour clé=valeur, c’est pareil pour tous les modèles du monde)
Oui, bien sûr : c’est aussi simple de renseigner directement la valeur souhaitée.
Par contre, la syntaxe que tu proposes et que j’utilise aussi sur tous les modèles, renvoie une erreur en PHP8 :
c’est pour ça que j’ai testé avec :
Il n’y a pas le message d’erreur avec PHP 7.4, mais le champ n’est pas valorisé !
Aaah mais oui mais non, ce param c’est pas un param de modèle, c’est dans l’ordre des args du formulaire, donc ça doit être un tableau. La syntaxe est d’ailleurs documentée juste au-dessus :
Formidable, le générateur de formulaires
Cool, merci pour les retours @RastaPopoulos ;-)
Reply to this message
Bonjour,
le plugin Bouquinerie est important pour notre site. Le plugin répond de façon tout à fait intelligente à des besoins d’inventaire et nous avons besoin de l’utiliser de façon exhaustive. Cependant, s’il n’y a pas de mise à jour du plugin pour suivre les évolutions de SPIP — ou un suivi sur cette mise à jour —, nous sommes amenés à penser que le temps que nous mettons à créer notre inventaire et à le mettre à jour en utilisant le plugin est risqué pour l’avenir. Dans le fond, la question est quelle pérennité pour le plugin ? Nous serions ravis d’aider au maintien et à l’évolution si c’est possible. Avec un grand merci pour le travail déjà réalisé !!
Bonjour,
une v2 pour SPIP >= 4 est en cours d’élaboration ici https://git.spip.net/spip-contrib-extensions/bouquinerie/branches -> sur la branche master.
Parmi les nouveautés, la possibilité de classer les auteurs du livre.
Il est possible que cette version marche en production, mais personnellement et faute de temps, je n’ai pas encore franchi le pas.
Si vous voulez aider, vous pouvez essayer cette nouvelle version dans une version de test de votre site et me faire part de vos éventuelles remarques.
à suivre donc…
Rebonjour,
désolé du retard, nous allons procéder à l’installation de la nouvelle version sur un site de test. Merci, et à suivre, effectivement !
Un suivi, quelque temps plus tard.... Voilà, nous avons installé une version SPIP 4.1.5, sur moteur PHP 7.4 et avec la version 2.0 de Bouquinerie en projet.
Malheureusement, la version en projet n’est pas fonctionnelle avec SPIP 4.1.5 et la seule option autorisée dans l’interface de SPIP consiste à « Afficher les plugins incompatibles » et l’action « Supprimer » (voir la capture d’écran ci-jointe).
Le plugin Rôles (nécessaire à Bouquinerie premières versions) est également incompatible en version SPIP 4.1.5. Tous les autres plugins requis sont toutefois compatibles.
Bonjour,
Il est possible de “forcer” la compatibilité en ajoutant :
define('_DEV_VERSION_SPIP_COMPAT', '4.0.99');dans le fichier “config/mes_options.php”
dd
Bonjour,
j’ai pas encore testé sur SPIP 4.1.
Par contre sur 4.0,x, cela devrait être bon.
Reply to this message
Bonjour,
Je calcule à l’aide d’un filtre une période de jours (ici, 49), avec ma balise set et get, j’affiche bien ce nombre.
Mais lorsque je demande à afficher les événements depuis 49 jours avec get, je n’ai pas le même résultat qu’avec le nombre...
<BOUCLE_evts(EVENEMENTS){id_article?}{age_debut<=#GET{dateabsolue}}{par date_debut}><BOUCLE_evts(EVENEMENTS){id_article?}{age_debut<=49}{par date_debut}>Je n’y comprends rien !!
Je suis finalement passé par un autre chemin en utilisant le critère
<!evenement_passe #GET{depart}>ou depart est une date calculée. :-/Reply to this message
Bonjour,
un portage / nettoyage spip 4 est-il prévu ? pour savoir si je tente de degager du temps pour cela ... ou pas
Bonsoir,
J’ai modifié la compatibilité dans le fichier paquet.xml
Le plugin affiche les données iptc sur un spip 4.0.1 ce qui me suffit.
Je n’ai pas les données exif.
Merci
Ah oui, ce serait cool que quelqu’un porte ce plugin pour SPIP 4.
Reply to this message
Pour info ; ce plugin fonctionne bien en SPIP 4.1 juste en changeant les bornes de compatibilité.
Reply to this message
Bonjour,
Sans doute depuis la dernière màj de spip,
La page agenda d’un site n’affiche plus les événements :
https://hydre.casa/spip.php?page=agenda
Pourtant ils sont bien présents et s’affichent ailleurs.
Le site est en SPIP 3.2.16, avec plugins Agenda 4.5.3 et Agenda Fullcalendar Facile 2.5.2
voici le message erreur quand on recalcule la page agenda :
Erreur SQL 1064
You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ’agendafull ’date_fin’) AND ((evenements.id_article NOT IN (SELECT * FROM( SE...’ at line 5
voir saisie écran plus complète ci-jointe
Sur un autre site, avec le même Spip et les deux mêmes plugins Agenda (mais qui est chez un autre hébergeur), il n’y a pas ce problème.
J’ai désactiver/réactiver ces 2 plugins, rien n’a changé.
J’ai lancé “réparation de la base”, ça mettait ok, rien de changé
merci si vous avez d’autres pistes...
Cordialement
Dans ta copie d’écran on voit que la requête SQL générée par SPIP a une syntaxe foireuse :
... WHERE (evenements.statut='publie') AND (evenements.date_debut agendafull 'date_fin')....Avec ?var_mode=inclure tu pourrais essayer de préciser quelle est le squelette concerné et ensuite quelle est le source précis de la boucle qui génère cette requête foireuse (avec ?var_mode=debug et par l’examen du source).
Ça semble dû à des ajustements récents dans la compilation par SPIP des boucles avec des jointures... qui ne vont pas bien dans ce cas là.
En l’absence de réponse ici, tu pourrais en parler sur discuter.spip.net en donnant toutes ces infos et en précisant quelle est la version de SPIP actuellement utilisée par le site (et quelle était la version précédemment utilisée ?)
Reply to this message
Bonjour
Je viens de mettre à jour les logiciels sur un site en exploitation
avec PHP 8.0 - SPIP 4.1.5 - Giseh vers du 18/7/2022 - écran de sécurité 1.4.2
j’ai le message d’erreur suivant :
Sinon je retrouve tous mes articles
merci de votre aide
Bonjour,
Je n’arrive pas à reproduire le problème (qui semble relever de SPIP).
Une piste : dans le fichier de SPIP
\ecrire\inc\filtres_images_lib_mini.php, remplacer à la ligne 433 :
[$destWidth, $destHeight] = _image_ratio($ret['largeur'], $ret['hauteur'], $maxWidth, $maxHeight);par :
[$destWidth, $destHeight] = _image_ratio(intval($ret['largeur']), intval($ret['hauteur']), intval($maxWidth), intval($maxHeight));C’est Ok. Quelle maitrise !
cordialement
Reply to this message
Bonjour,
Voilà le message que j’ai quand j’utilise Mailjet :
je suis en Spip 3.2.15, avec Mailshot 2.2.3
Merci de me dire ce qui manque dans ma config.
Sylvain Le Doaré
Sans doute car le fichier .htaccess est manquant.
J’ai bien un fichier .htaccess à la racine de mon site, il y a une cinquantaine de ligne (commentaires compris), C’est le fichier générer par mon hébergeur.
Que devrait-il contenir comme instruction pour que le webhook fonctione?
Le contenu du fichier htaccess.txt de SPIP (qui entre autre gère les urls propres mais aussi la redirection des urls en .api vers les fonctions internes de SPIP et des plugins)
j’ai placé dans le htacces de mon hébergeur tout le contenu du htaccess de Spip et j’ai toujours les message de Mailjet comme quoi le webhook est down!
Un peu pareil, avec mailjet aussi, et comment j’ai réglé ça :
- “avant”, ça marchait
- j’ai mis à jour mailshot de la
v1.31.4à lav3.0.7à la mi juillet- depuis,
bulkmailer_mailjet_webhook(ma surcharge debulkmailer_mailjet_webhook_dist) n’est plus appelée.- le dernier
mailshot_feedback.logdate aussi de cette mi juillet. C’est donc queaction_api_mailshot_webhookn’est pas appelé.- le paramétrage de mailjet indique l’url de notification suivante :
/mailshot_webhook.api/mailjet/et le test échoue en erreur.- je n’ai pas changé en juillet le htaccess concernant le traitement des .api :
RewriteRule ^(ecrire/)?([\w]+)\.api([/.](.*))?$ spip.php?action=api_$2&arg=$4 [QSA,L]- quand j’interroge la ressource demandée par mon navigateur, la requête échoue en raison d’une erreur
403 (forbiden). Qu’est ce qui peut causer ça ? La fonction SPIP renvoie 403 quand la data reçue est malformée.- Je vois que dans l’url paramétrée sur mailjet pour les webhooks, il y a un www. alors que désormais c’est l’url sans www qui est préférée. Je supprime donc les www du paramétrage.
Le test sur le site mailjet est toujours en échec, mais par contre un log est désormais bien créé dans
mailshot_feedback.log. Ouf, la fonctionaction_api_mailshot_webhookest donc bien appelée.Et je constate que le problème est réglé.
Reply to this message