Recherche avancée

Médias (1)

Mot : - Tags -/ogg

Autres articles (62)

  • Contribute to translation

    13 avril 2011

    You can help us to improve the language used in the software interface to make MediaSPIP more accessible and user-friendly. You can also translate the interface into any language that allows it to spread to new linguistic communities.
    To do this, we use the translation interface of SPIP where the all the language modules of MediaSPIP are available. Just subscribe to the mailing list and request further informantion on translation.
    MediaSPIP is currently available in French and English (...)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

Sur d’autres sites (5624)

  • Anomalie #3713 (Nouveau) : Plantage de la page sur un copier/coller

    21 février 2016, par realet RealET

    Bonjour,

    Testé en 3.0 et 3.1.

    Le cas s’est produit sur un site utilisant beaucoup les multi.
    Le canevas pour les différentes langues est déjà là dans les articles avec xxxx à l’endroit où il faudra insérer le texte quand il sera traduit.
    Les traductions sont faites hors de SPIP, et copiées/collées.
    Et le plantage reproductible se fait en :

    • créant un article avec le premier texte en PJ dans le corps du texte
    • enregistrer
    • modifier
    • coller à la place des xxxxx de la fin le contenu du 2e texte (c’est la longueur de ce qui est collé qui compte)
    • plantage de la page (pas du navigateur, juste de la page)

    Ce qui est rigolo, c’est que si je copie le texte original dans un éditeur de texte, que je colle dedans ce qui fait planter, et que je colle le résultat dans le texte de SPIP (en ayant tout supprimé avant), ça ne plante pas.

    J’ai vérifié dans un formulaire non SPIP, les mêmes textes ne plantent pas au copié/collé.

    Intuitivement, je dirais que c’est du côté du navigateur, un JS sur le formulaire SPIP (celui qui enregistre le contenu pour le retrouver en cas de plantage ?)

    En pièce jointe, les textes de test.

    PS : moi, j’ai testé avec Opera 35 sous Windows. La personne qui a eu le problème était sur MacOSX, je ne sais pas son navigateur

  • Révision 21918 : Bugfix : un unset sur une valeur de session ne doit pas generer un cache de sessi...

    23 février 2015, par cedric -

    Cas typique :
    - le plugin panier verifie a chaque hit si le visiteur a un panier en session et sinon par precaution appelle session_set(’id_panier’) pour unset une evenuelle valeur
    - session_set peuple la valeur a null et appelle ajouter_session()
    - ajouter_session voit que le visiteur n’a pas de cookie session et genere un hash de session
    - il inspecte le tableau de session voit qu’il n’y a rien a enregistrer et rend la main ni vu ni connu (croyait-il).
    Mais comme on a renseigne $_COOKIE[spip_session] celui-ci est pris en compte dans la fonction spip_session() et genere un cache sessionné. Le plus drole c’est qu’on ne pose le cookie. Donc on recommence au hit suivant avec un nouvel identifiant de session, ce qui est une catastrophe en performance si le site utilise des balises #SESSION. Chaque hit sur le site génére un nouveau cache (donc calcul, donc ecriture sur le disque, donc gonflement du cache etc.)

    Pour mémoire quand on joue avec les sessions dans les plugins et les squelettes il faut toujours verifier que au final un curl anonyme sur le site est servi sans aucun "Calcul" ni "Ecriture du cache" dans spip.log.

  • Révision 21920 : Report de r21918 et r21919 : Bugfix : un unset sur une valeur de session ne doit ...

    23 février 2015, par cedric -

    Cas typique :
    - le plugin panier verifie a chaque hit si le visiteur a un panier en session et sinon par precaution appelle session_set(’id_panier’) pour unset une evenuelle valeur
    - session_set peuple la valeur a null et appelle ajouter_session()
    - ajouter_session voit que le visiteur n’a pas de cookie session et genere un hash de session
    - il inspecte le tableau de session voit qu’il n’y a rien a enregistrer et rend la main ni vu ni connu (croyait-il).
    Mais comme on a renseigne $_COOKIE[spip_session] celui-ci est pris en compte dans la fonction spip_session() et genere un cache sessionné. Le plus drole c’est qu’on ne pose le cookie. Donc on recommence au hit suivant avec un nouvel identifiant de session, ce qui est une catastrophe en performance si le site utilise des balises #SESSION. Chaque hit sur le site génére un nouveau cache (donc calcul, donc ecriture sur le disque, donc gonflement du cache etc.)

    Pour mémoire quand on joue avec les sessions dans les plugins et les squelettes il faut toujours verifier que au final un curl anonyme sur le site est servi sans aucun "Calcul" ni "Ecriture du cache" dans spip.log.

Navigation