Recherche avancée

Médias (1)

Mot : - Tags -/illustrator

Autres articles (111)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

Sur d’autres sites (10393)

  • Anomalie #3205 (Nouveau) : [Plugin-dist Mots] Incompatibilité avec l’API d’édition d’objet ?

    13 avril 2014, par charles razack

    Il semblerait que la création d’un groupe de mots par le biais l’API d’édition d’objet ne fonctionne pas.
    A première vue, on dirait que c’est dû à un souci de nommage de fonctions au niveau du plugin.

    Pour reproduire, dans le traitement d’un formulaire par ex. :

    include_spip('action/editer_objet');<br />$set = array('titre'=>'Mon super titre',, 'tables_liees'=>'articles');<br />$id_groupe = objet_inserer('groupe_mots', '', $set);

    var_dump($id_groupe); renvoie NULL et pour cause : le groupe de mots n’a pas été créé.

    Cause probable :

    Dans le fichier action/editer_groupe_mots.php du plugin, les fonctions sont nommées groupemots_xxx() au lieu de groupe_mots_xxx(),
    ce qui fait que la fonction objet_inserer() de l’API ne les trouve pas.
    Du coup elle tente une insertion "générique" qui pour une raison ou une autre ne fonctionne pas (pb avec sql_insertq ligne 209, je n’ai pas regardé ce qui cloche exactement).

  • Revision 109633 : Ma console réseau de mon navigteur indique : - jquery-ui.js : 508,86ko ...

    22 mars 2018, par placido@… — Log

    Ma console réseau de mon navigteur indique :
    - jquery-ui.js : 508,86ko
    - jsdyn-formulaires_dateur_jquery_dateur_js_14fce12d.js : 517,89 ko
    Le fichier js dynamique est chargé via $.getScript depuis le fichier formulaire/dateur/inc-dateur.html qui inclut déjà lui-même jquery-ui !
    On se retouve donc avec une double dose d’un jquery-ui (déjà pachidermique) à la moindre saisie date appelée. C’est clairement un problème.
    Je m’interroge sur la nécessite de l’insertion des css et js via affichage_final. Sauf cas particulier qui m’échappe, je pense que cette fonction saisies_affichage_final n’a pas (plus) lieu d’être.
    Je propose d’opter pour un chargement des éléments globaux via insert_head et insert_head_css (sans jquery-ui) et pour les cas particuliers, cela doit se gérer au niveau du squelette de la saisie (à l’instar de ce que fait déjà la saisie date qui fait un #INCLURE de inc-dateur.html).
    En attendant des avis, on peut déjà rendre cette fonction surchargeable (désactivable).

  • Revision 109633 : Ma console réseau de mon navigteur indique : - jquery-ui.js : 508,86ko ...

    11 juin 2018, par placido@… — Log

    Ma console réseau de mon navigteur indique :
    - jquery-ui.js : 508,86ko
    - jsdyn-formulaires_dateur_jquery_dateur_js_14fce12d.js : 517,89 ko
    Le fichier js dynamique est chargé via $.getScript depuis le fichier formulaire/dateur/inc-dateur.html qui inclut déjà lui-même jquery-ui !
    On se retouve donc avec une double dose d’un jquery-ui (déjà pachidermique) à la moindre saisie date appelée. C’est clairement un problème.
    Je m’interroge sur la nécessite de l’insertion des css et js via affichage_final. Sauf cas particulier qui m’échappe, je pense que cette fonction saisies_affichage_final n’a pas (plus) lieu d’être.
    Je propose d’opter pour un chargement des éléments globaux via insert_head et insert_head_css (sans jquery-ui) et pour les cas particuliers, cela doit se gérer au niveau du squelette de la saisie (à l’instar de ce que fait déjà la saisie date qui fait un #INCLURE de inc-dateur.html).
    En attendant des avis, on peut déjà rendre cette fonction surchargeable (désactivable).

Navigation