Recherche avancée

Médias (1)

Mot : - Tags -/university

Autres articles (86)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • List of compatible distributions

    26 avril 2011, par

    The table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
    If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)

Sur d’autres sites (7921)

  • Anomalie #3823 : Pagination et connect

    10 février 2017

    La notion INCLURE{connect=x} avec &connect=y dans l’URL

    La documentation dans SPIP.net fait bien mention d’un connect dans l’URL. Dans transmise en tant qu’argument d’inclure.
    La seule documentation que je trouve qui propose cela est http://programmer.spip.net/Inclure-suivant-une-connexion (je sais pas qui a écrit ce truc).
    Ce qui se passe lorsqu’il y a cette écriture est, comme je le signalais, que le connect dans l’URL reste prioritaire sur celui de l’argument transmis à #INCLURE ou <inclure></inclure>.

    Déjà ce point pourrait être amélioré (mais ça touche du code pas si anodin)

    Le problème avec {pagination}

    Solution en suffixant les liens de pagination avec le connect.

    Dans tous les cas cette solution ne peut pas marcher, je ne vois pas l’intérêt de s’éterniser là dessus.

    Je le redis mais si :

    • la page du site utilise le connect ’’ par défaut (pas de connect=x dans l’URL)
    • il a un squelette normal, et dedans des boucles normales, et dedans à un endroit les inclusions avec connect et avec pagination que tu montres.
    • cliquer avec le comportement qui ajouterait &#38;connect=xx dans l’url de pagination, va mettre &#38;connect=xx dans l’URL du site
    • le site va alors s’afficher (tout le squelette) avec le connect=xx (même ta pagination cela dit ^^)

    Ce comportement là est contre-intuitif, faux et surtout non désiré.

    Autre solution ? ajax en cause.

    Le problème vient de l’ajax. Sans Ajax, le comportement de la pagination est correct.
    Du coup, je pense que le principal souci de ce côté vient que le rechargement ’ajax’ ne tient pas compte du connect utilisé par le bloc rechargé.
    Donc ça se passe quelque part

    Remplacer

    $page[’texte’] = encoder_contexte_ajax(array_merge($contexte, array(’fond’ => $f)), ’’, $page[’texte’],
                    $options[’ajax’]) ;
    

    par (ajout du connect au contexte)

    $page[’texte’] = encoder_contexte_ajax(
        array_merge($contexte, array(’fond’ => $f, ’connect’ => $connect)),
        ’’, 
        $page[’texte’],
        $options[’ajax’]
    ) ;
    

    semble faire fonctionner l’ajax correctement.

    Je me demande s’il peut y avoir des effets de bord.

    Et sinon, merci @realet pour ton commentaire, mais tu es autant dev que nous. Et on est bien gentils de passer du temps sur des trucs dont on n’a pas besoin…

  • Anomalie #3245 (Nouveau) : Formulaire editer_liens affiché inutilement dans certains cas

    24 juillet 2014, par tcharlss (*´_ゝ`)

    Reproduire le comportement

    Pour observer le problème, je propose d’utiliser les mots-clés, qui se servent du formulaire « editer_liens ». Donc :

    • 1) Avoir au préalable des articles avec des mots-clés, et d’autres sans.
    • 2) Désactiver l’ajout de mots-clés aux articles pour tous les groupes de mots-clé.

    Résultat :

    • Les articles possédant des mots-clés comportent toujours le formulaire. Là, ça me semble normal.
    • Les articles ne possédant pas de mot-clé affichent eux aussi le formulaire. Là, ça me paraît erroné : il devrait être caché. Il n’a aucune utilité, et on a "désactivé" l’utilisation des mots-clés pour les articles, ça veut dire qu’on en veut pas.

    Continuons.

    • 3) Retirer tous les mots-clés liés aux articles.

    Résultat :

    • Maintenant, le formulaire n’est plus affiché, car plus aucun article ne possède de mot clé : on retrouve le comportement normal.

    Problème

    Le problème vient d’un test effectué dans charger : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L94

    Le raisonnement actuel est le suivant : quand le formulaire n’est pas éditable, il est caché s’il n’existe aucun lien pour le type d’objet.
    Ou pour reprendre l’exemple des mots, plus parlant : le formulaire est caché s’il n’existe aucun mot lié à un article (n’importe quel article).
    Or je pense qu’il devrait être caché s’il n’existe aucun mot lié à l’article en cours.

    Donc, en remplaçant :

    objet_trouver_liens(array($objet_lien=>’*’),array(($objet_lien==$objet_source ?$objet :$objet_source)=>’*’))


    par :

    objet_trouver_liens(array($objet_lien=>’*’),array(($objet_lien==$objet_source ?$objet :$objet_source)=>$id_objet))

    On retrouve le comportement qui me semble "normal".

  • Anomalie #4623 : Styles des fieldset dans l’espace privé

    18 avril 2021

    Bon stop (ou pas) !

    Il semble que les blocs fieldset ne peuvent pas parfaitement se styler seuls. Manifestement c’est assez récent que les navigateurs acceptent un display:flex; dessus par exemple.

    J’ai fait quelques tests en partant du formulaire de préférences des menus (tiens d’ailleurs ce formulaire a des div.editer sans div.editer-groupe parent (à corriger !)
    Il contient un fieldset + .editer-groupe.deux_colonnes (columns : 2)

    Ce que j’ai testé (sous macOS avec FF, Safari, Chrome & Opéra) : la formule suivante (enlever le .editer-groupe interne et le monter sur le fieldset)

    1. <span class="CodeRay"><span class="tag">fieldset</span><span class="class">.editer-groupe</span>
    2.     <span class="tag">legend</span>
    3.     <span class="tag">div</span><span class="class">.editer</span>
    4.     <span class="tag">div</span><span class="class">.editer</span>
    5.     ...
    6. </span>

    Télécharger

    1) Si on applique un columns: 2 sur ce fieldset,
    - Firefox & Safari : conservent le legend, passent le reste en 2 colonnes
    - Chrome & Opéra : ignorent et conservent donc un affichage 1 colonne.

    2) Si on applique un display: flex; flex-wrap: wrap sur ce fieldset
    - Tous : le legend est conservé comme tel
    - le reste passe effectivement en flex (permettant donc de mettre plusieurs .editer sur la même ligne)

    Déjà je suis étonné que Flex semble fonctionner, contrairement à ce que dit https://caniuse.com/mdn-html_elements_fieldset pour tous les Gecko. Et Edge aussi est indiqué en non fonctionnel.

    Donc du coup… je me dis que le .editer-groupe dans le fieldset à encore du sens stylistique.
    Ce qui pour le coup ne nous arrange pas forcément, mais ça évite aussi de casser un truc de plus dans cette structure html en le laissant.

    Donc du coup, on en reviendrait peut être à "fieldset.editer-section" ou "fieldset.editer-fieldset" ou "fieldset.fieldset" ou "fieldset" (sans rien)…
    J’utilise .editer-section ensuite (mais peut importe)

    A) fieldset.editer-section > div.editer-groupe

    (le plus proche de l’actuel je pense)

    1. <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
    2.       <span class="tag">div</span><span class="class">.editer</span>
    3.       ...
    4.   <span class="tag">fieldset</span><span class="class">.editer-section</span>
    5.     <span class="tag">legend</span>
    6.     <span class="tag">div</span><span class="class">.editer-groupe</span>
    7.         <span class="tag">div</span><span class="class">.editer</span>
    8.         ...
    9. </span>

    Télécharger

    B) fieldset.editer-groupe > div.editer-section

    L’autre possibilité si ça facilite vraiment le css, c’est d’inverser les classes (avec l’ennui principal de du coup devoir reprendre l’existant)

    1. <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
    2.       <span class="tag">div</span><span class="class">.editer</span>
    3.       ...
    4.   <span class="tag">fieldset</span><span class="class">.editer-groupe</span>
    5.     <span class="tag">legend</span>
    6.     <span class="tag">div</span><span class="class">.editer-fieldset</span>
    7.         <span class="tag">div</span><span class="class">.editer</span>
    8.         ...
    9. </span>

    Télécharger

    B) fieldset.editer-groupe.editer-section > div.editer-groupe

    Ou du doubler d’une autre classe

    1. <span class="CodeRay">  <span class="tag">div</span><span class="class">.editer-groupe</span>
    2.       <span class="tag">div</span><span class="class">.editer</span>
    3.       ...
    4.   <span class="tag">fieldset</span><span class="class">.editer-groupe</span><span class="class">.editer-section</span>
    5.     <span class="tag">legend</span>
    6.     <span class="tag">div</span><span class="class">.editer-groupe</span>
    7.         <span class="tag">div</span><span class="class">.editer</span>
    8.         ...
    9. </span>

    Télécharger

    Mais dans ce cas là je trouve cela redondant (fieldset.editer-section me parait suffisant, si on doit effectivement mettre un classe css dessus)
    Le plus ennuyant est peut être de devoir annuler des styles CSS du .editer-groupe dans .editer-section > .editer-groupe ;