Recherche avancée

Médias (0)

Mot : - Tags -/formulaire

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

Autres articles (96)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • Amélioration de la version de base

    13 septembre 2013

    Jolie sélection multiple
    Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
    Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

Sur d’autres sites (12120)

  • Revision 68533 : Et meeeeerde je voulais pas commiter ma modif de DATE pour dans le commit ...

    21 décembre 2012, par rastapopoulos@… — Log

    Et meeeeerde je voulais pas commiter ma modif de DATE pour dans le commit précédent [68532] !
    DONC je change pour cette modif un numéro fonctionnel.
    Et donc c’est quoi :
    La saisie "date" sait gérer "horaire=oui" en option.
    Si on ne le met pas, ça fait la même chose qu’avant.
    Si on met cette option, alors ça génère *deux* input, un pour la date, un pour l’heure, et ça enregistre le tout dans la *même* variable, mais en tableau.
    Par exemple si nom=debut, ça va donner debut[date] et debut[heure].
    Ça c’est pour la *sortie*.
    En *entrée* la saisie sait prendre :
    - soit une date au format SPIP j/m/a
    - soit une date SQL, avec heure ou pas
    - soit un tableau avec les deux clés "date" et "heure" au format SQL
    À venir : la vérification "date" qui gère aussi le tableau date/heure si détecté et qui normalise donc avec la bonne heure choisie par le même champ de formulaire.

  • Anomalie #2974 : changement de langue par défaut du site change langue des articles

    25 avril 2013, par Suske -

    Pour faire avancer le schmilblick, résultat de ma quête découverte dans le code de SPIP (merci à l’équipe spéciale pour sa précieuse collaboration) : en résumé, je confirme.

    http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/configurer_langue.php#L56 appelle caculer_langue_rubriques après validation de la sélection (http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/rubriques.php#L365) et là, on a :

     sql_updateq("spip_rubriques", array("lang" => $GLOBALS[’meta’][’langue_site’], "langue_choisie" => ’non’), "id_parent=0 AND langue_choisie != ’oui’") ;
    

    Les rubriques racine avec langue_choisie=’non’ ont "lang" modifié avec la valeur qui vient d’être sélectionnée comme "Langue principale du site".

    C’est utile/nécessaire dans le cas d’un site sans gestion du multilinguisme au niveau des rubriques (si on décide que le site en javanais devient brusquement un site en russe par exemple) mais dans ce cas-ci cela entraîne le basculement d’un secteur linguistique vers une autre langue.

    Cela provient du fait que dans le cas du multilinguisme par secteur (meta "multi_secteurs"=’oui’) la langue principale du site n’est pas indiquée "lang_choisie"=’oui’ car la langue est la langue par défaut. Du coup il me semble qu’on pourrait mettre cette valeur en base sur la ou les rubriques racines au moment de la validation du choix de langues pour les rubriques racines uniquement.

    J’ai testé

    sql_updateq("spip_rubriques", array("langue_choisie" => ’oui’), "id_parent=0 AND langue_choisie != ’oui’") ;
    

    à la ligne http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/configurer_multilinguisme.php#L38

    Par ailleur, dans le cas où l’utilisateur crée ou déplace ensuite une autre rubrique en langue principale du site à la racine, le problème revient. Donc cette seule intervention, si elle est valable, n’est pas suffisante. Comme calculer_langue_rubriques est appelé dans ces cas de figure, j’ai ajouté en début de fonction :

        // si secteurs de langue fixer lang_choisie à oui pour la racine - à non pour les autres
    

    if (lire_meta(’multi_secteurs’)=="oui")
    sql_updateq("spip_rubriques", array("langue_choisie" => ’oui’), "id_parent=0 AND langue_choisie != ’oui’") ;
    sql_updateq("spip_rubriques", array("langue_choisie" => ’non’), "id_parent != 0 AND langue_choisie = ’oui’") ;

    Cela fait le boulot et je n’ai pas vu de conséquence négative jusqu’ici mais cette gestion est suffisemment complexe pour que je me contente de rapporter ça ici pour voir ;-).

  • Révision 20520 : #2999 et http://forum.spip.net/fr_247990.html : liste plus exhaustive et complet...

    13 mai 2013, par cedric -

    Source : commentaires en bas de http://wanderr.com/jay/detect-crawlers-with-php-faster/2009/04/08/
    (version optimisée/factorée, on ne garde que les UA qui ne matchent pas les mots-clés génériques en début de liste)