Recherche avancée

Médias (0)

Mot : - Tags -/signalement

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

Autres articles (44)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

  • Other interesting software

    13 avril 2011, par

    We don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
    The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
    We don’t know them, we didn’t try them, but you can take a peek.
    Videopress
    Website : http://videopress.com/
    License : GNU/GPL v2
    Source code : (...)

Sur d’autres sites (6181)

  • Anomalie #3697 : Bug svn10000 SPIP 3

    14 février 2016, par MiKaël Navarro

    Cependant je m’étonne que cette erreur là « remplissent les logs du serveur Web », d’autant que l’erreur n’est pas critique.
    Normalement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false. Par contre, oui ça créait une erreur PHP si le dossier n’existait pas, mais qui ne devrait pas perturber il me semble la suite du processus de mise à jour. Je n’ai pas été vérifier cependant.

    Effectivement le if ($dir = opendir(...)) n’entre pas dans le if si opendir retourne false, mais ce n’est pas le code que j’ai dans l’archive spip-3.1.zip (r22707 aujourd’hui en date du 6 janvier), au lieu de ça j’ai seulement (sans le if) : 

    $dir = opendir($base) ;
while (($f = readdir($dir)) !== false) 
...

    De plus je suis d’accord, ce n’est pas une Erreur mais un simple Warning que l’on retrouve dans /var/log/nginx/error.log :

    2016/02/14 12:36:04 [error] 1141#0 : *197 FastCGI sent in stderr : "PHP message : PHP Warning :  opendir(baddir/) : failed to open dir : No such file or directory in /home/mickey/public_html/test-opendir.php on line 2
PHP message : PHP Warning :  readdir() expects parameter 1 to be resource, boolean given in /home/mickey/public_html/test-opendir.php on line 3" while reading response header from upstream, client : 127.0.0.1, server : localhost, request : "GET / mickey/test-opendir.php HTTP/1.1", upstream : "fastcgi ://unix :/var/run/php5-fpm.sock :", host : "localhost"


    Ensuite le test while (($f = readdir($dir)) !== false) rentre dans une boucle infinie et c’est avec ça que j’ai créé un log de plus de 2Go !

    D’après les commit, je vois que c’était déjà corrigé dans la version SVN, mais un test supplémentaire mange pas de pain ça sera plus robuste et évitera l’écriture d’un Warning dans les logs pour rien :)

    En tout cas merci pour votre réactivité.

  • Evolution #3361 (Nouveau) : Tri par défaut des entrées des menus du bandeau de l’espace privé

    5 décembre 2014, par tcharlss (*´_ゝ｀)

    Sur un site nu, sans aucun plugin, le bandeau de navigation de l’espace privé reste utilisable car il y a peu d’éléments.
    Par contre, dès que les menus commencent à se peupler en installant des plugins, ça devient difficile de s’y retrouver car il n’y a pas de logique de tri apparente.
    Mais surtout, entre 2 sites ayant les mêmes plugins, les entrées des menus peuvent être classées différement. C’est un peu gênant pour jongler entre un site de dev et un site en ligne, cf. image en pièce-jointe.

    À priori et à fortiori, les entrées sont organisées de la sorte :

    • D’abord les entrées des plugins du core, toujours dans le même ordre, fixé.
    • Ensuite les entrées ajoutées par les plugins, et là, c’est la fête. Ils sont rangés selon la date de leur installation, peut-être ?

    Bref, je propose :

    • Soit de tout classer alphabétiquement
    • Soit idem, tout en plaçant en premier les entrées du core (donc 2 groupes, chacun classés alphabétiquement)

    Qu’en pensez-vous ?

    Pour les gens curieux, les fichiers concernés sont ceux-là :

    Comme je suis sympa, je mets ça en priorité « bas »

  • Anomalie #3281 (En cours) : remarques sur le nouveau thème graphique de la 3.1

    13 août 2016, par b b

    Ha mais non pardon, je pensais qu’on avait intégré les propositions alors que non... J’ouvre de nouveau, mais il serait bien de s’occuper de ce ticket un jour... (parce que là ça commence à dater ^^).

    Pour tenter d’avancer, quelques remarques à propos des propositions de tcharlss :

    formulaires latéraux (fiche d’un objet) : couleurs neutres (bordures et fond), boutons plus lisibles.

    Perso je n’avais même pas remarqué le problème car j’utilise toujours le gris dans le privé. Ça a failli être la couleur par défaut pour la 3.1, mais Arnaud nous a "gentiment" fait remarquer que le gris n’est une couleur... Du coup, je ne suis pas certain que ta proposition lui fera plaisir, par contre ça le fera certainement réagir :p

    Pour les boutons plus lisibles, je crois bien qu’on a augmenter le contraste de ce côté, ça semble bon de mon côté à ce jour.

    - fiche d’un objet : pas d’ombre portée, remplacée par une simple bordure.

    Perso avec ou sans je m’en cogne un peu, mais je trouve plus en accord avec le reste du thème de ne pas utiliser d’ombre portée. Je crois bien que c’est la seule présente dans tout le privé, elle fait un peu tâche du coup. +1 donc :)

    - marge entre le contenu éditorial d’un objet et les formulaires de date etc.

    Ce point semble aussi réglé maintenant.

    - bandeaux identité et outils : couleur de fond identique.

    J’ai un gros doute sur ce point, en effet, si on utilise la "non couleur" gris (^^) et qu’on applique le gris clair du premier bandeau au second (#f4f4f4), la séparation visuelle entre la zone haute et la zone de contenu est beaucoup moins perceptible.

    D’autres avis ?

Navigation