Recherche avancée

Médias (0)

Mot : - Tags -/xml-rpc

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (28)

  • Les images

    15 mai 2013

  • Pas question de marché, de cloud etc...

    10 avril 2011

    Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
    sur le web 2.0 et dans les entreprises qui en vivent.
    Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
    Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
    le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
    Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...)

  • ANNEXE : Les extensions, plugins SPIP des canaux

    11 février 2010, par

    Un plugin est un ajout fonctionnel au noyau principal de SPIP. MediaSPIP consiste en un choix délibéré de plugins existant ou pas auparavant dans la communauté SPIP, qui ont pour certains nécessité soit leur création de A à Z, soit des ajouts de fonctionnalités.
    Les extensions que MediaSPIP nécessite pour fonctionner
    Depuis la version 2.1.0, SPIP permet d’ajouter des plugins dans le répertoire extensions/.
    Les "extensions" ne sont ni plus ni moins que des plugins dont la particularité est qu’ils se (...)

Sur d’autres sites (3904)

  • Anomalie #3978 : Reload ajax et contexte au retour d’un URL_ACTION_AUTEUR

    29 septembre 2018, par cedric -

    Pas de bug ici, juste une erreur de conception dans les 2 squelettes :)

    Dans le cas 1 les arguments reloada=1 et reloadb=1 sont passés en argument du href et viennent dans l’URL après un reload ajax d’un bloc
    Du coup quand on passe un {args:{reloadb:''}} et {args:{reloada:''}} dans le refresh ajax ça annule bien l’argument de l’URL et évite la boucle infinie

    Dans le cas 2 les reloada et reloadb ne sont pas en arguments de l’URL mais en argument de l’URL de retour passée à l’action
    Du coup les arguments {args:{reloadb:''}} et {args:{reloada:''}} ne viennent rien faire car ils s’appliquent sur l’URL de l’action, pas sur l’URL de retour.

    Consequence sans doute pas vue : au second coup le refresh de A se fait via l’URL action, c’est a dire en faisant une action indésirable au lieu de simplement rafraichir

    Solution : indiquer dans le refresh ajax qu’il faut utiliser l’URL de départ et pas l’URL action :

    Bloc A (#REM
    


    
    Reload A => Declenchera ensuite le Reload de B
    

    

    [(#ENVreloada|oui)
    

    &lt;script type=&quot;text/javascript&quot;&gt;<br />
    
    ajaxReload('blocb', {args:{reloadb:''},href:'#SELF'});<br />
    
&lt;/script&gt;
    

    ]
    

    Bloc B (#REM
    


    
    Reload B => Declenchera ensuite le Reload de A
    

    

    [(#ENVreloadb|oui)
    

    &lt;script type=&quot;text/javascript&quot;&gt;<br />
    
    ajaxReload('bloca', {args:{reloadb:''},href:'#SELF'});<br />
    
&lt;/script&gt;
    

    ]

    A noter qu’ici j’ai aussi ajouté une class nohistory sur les liens pour ne pas modifier l’URL de la page web et éviter qu’elle ne devienne celle de l’action

  • Revision 62476 : On améliore nos pipelines On ajoute une static pour éviter de ...

    13 juin 2012, par kent1@… — Log

    On améliore nos pipelines
    On ajoute une static pour éviter de repasser dans le goulot plusieurs fois.
    On utilise document_modifier au lieu d’une requete sql
    On ajoute quelques explications

  • Revision 62814 : Une chaine de langue manquante Moins de logs De simples quotas au ...

    21 juin 2012, par kent1@… — Log

    Une chaine de langue manquante
    Moins de logs
    De simples quotas au lieu de doubles, il parait que c’est plus rapide

Navigation