Recherche avancée

Médias (1)

Mot : - Tags -/pirate bay

Autres articles (59)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

Sur d’autres sites (11458)

  • Evolution #4080 : Raccourci puce : se débarasser de l’image

    24 janvier 2018, par tcharlss (*´_ゝ`)

    Dans le ticket #1817, un des arguments pour générer une vraie liste à la place de puces, c’est que les utilisateurs se trompent de raccourci (ils voudraient une vraie liste mais mettraient de simple tirets au lieu de -*).
    Je nuancerais, d’après ce que j’ai vu, je suis presque sûr que des fois c’est volontaire, pour des raisons esthétiques à priori.

    À mon avis ça pourrait générer effectivement une vraie liste, mais avec une classe supplémentaire :

      . Et ces listes pourraient être stylées avec le chevron à la place du truc par défaut au moyen de list-style-type
      Ça ferait donc 3 types de listes en tout : normales, numérotées, et "décorées" (avec un chevron ou autre selon le thème).

      Bon, après ça crée une petite incohérence dans la syntaxe. Si toutes les vraies listes commencent par un tiret suivi d’un caractère (étoile ou dièse), idéalement dans ce cas ça devrait être un tiret suivi d’un chevron ou autre : ->

  • Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

    14 février 2018, par Pierre-Aurélien Georges

    Bonjour,

    voici le contexte : le serveur web de mon hébergeur est mal configuré (et je n’ai malheureusement pas réussi à leur faire corriger le problème). Le site web [1] est accessible aussi bien en HTTP qu’en HTTPS, mais en allant sur /ecrire/ ?exec=info je vois que le serveur ne renseigne ni la variable $_SERVER[’HTTPS’] ni la variable $_SERVER["SCRIPT_URI"], et à vrai dire lorsque je compare sur ce serveur un phpinfo() en HTTP et un phpinfo() en HTTPS je vois qu’il y n’a strictement AUCUNE différence entre les deux, et qu’il est donc totalement impossible de savoir (côté serveur) si la requête a été faite en HTTP ou en HTTPS.

    Dans ce contexte bien précis, le code de la fonction url_de_base() situé dans /ecrire/inc/utils.php pose problème, car il se base sur le contenu de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"] pour choisir entre HTTP et HTTPS et il ne tient absolument pas compte du contenu du champ META, ce qui dans mon cas est bien dommage car j’y ai mis l’url en https:...

    La conséquence de tout ceci est qu’en HTTPS cela entraîne des problèmes d’affichage d’images et de CSS qui ne sont pas bien appliqués, cf. [2]. Sur ce forum, vous verrez que je ne suis pas le seul à avoir affaire à un serveur mal configuré de la sorte, et que nous sommes plusieurs à avoir ce même problème. La solution de bricolage donnée par un des participants du forum est de rajouter dans /config/mes_options.php les deux lignes suivantes :

    $_SERVER[’HTTPS’] = "on" ;
    $_SERVER[’SERVER_PORT’]=’443’ ;
    


    Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage et c’était pas évident de trouver cette astuce !

    Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ? En effet, lorsque META commence par "https://" ça veut dire que le serveur gère le HTTPS, et donc s’il ne renseigne pas les variables HTTPS et SCRIPT_URI et bien dans le doute mieux vaut générer des url de base en "https://" plutôt qu’en "http://" car si cette url de base se retrouve mentionnée au sein d’un fichier html ou css, et que le fichier en question est demandé en HTTP, ce n’est pas grave s’il contient des ressources en HTTPS, alors que le contraire pose problème (ne pas mettre de ressources en HTTP au sein d’une page en HTTPS !)

  • Anomalie #4097 (En cours) : bug HTTPS dans la fonction url_de_base() sur certains serveurs mal con...

    15 février 2018, par b b

    le serveur web de mon hébergeur est mal configuré

    Ca fonctionne, certes, et c’est donc ce que j’ai fait pour mon site, mais c’est vraiment du bricolage

    Tout est dit, serveur mal configuré, bricole pour contourner le bug de l’hébergeur en question :p Mais au moins, ça fonctionne.

    Pour faire plus propre et plus simple, serait-il possible à l’avenir de modifier le code de url_de_base() pour qu’en l’absence de ces deux variables $_SERVER[’HTTPS’] et $_SERVER["SCRIPT_URI"], la fonction aille regarder dans META si c’est du http ou du https qui y est renseigné (au lieu de mettre forcément du http) ?

    L’idée semble bonne à premier vue tellement ça parait simple, mais j’ai peur que cela ait des effets de bord sur certaines configurations, notamment derrière un proxy. Attendons les avis des autres membres de l’équipe avant de l’intégrer ou non.