
Recherche avancée
Médias (1)
-
MediaSPIP Simple : futur thème graphique par défaut ?
26 septembre 2013, par
Mis à jour : Octobre 2013
Langue : français
Type : Video
Autres articles (96)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 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 (...) -
Multilang : améliorer l’interface pour les blocs multilingues
18 février 2011, parMultilang 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. -
HTML5 audio and video support
13 avril 2011, parMediaSPIP 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 (...)
Sur d’autres sites (12421)
-
Anomalie #3476 : Prévisualiser un article post daté
25 juillet 2015, par cedric -Non, sur un article post-daté non publié, on a bien un lien "Prévisualiser".
Il n’y a que si tu passes un article publié en post-daté en changeant la date dans le futur : le formulaire de date en central s’execute en ajax, le reste de la page n’est pas rechargé, et du coup le bloc info de gauche reste avec un lien "voir en ligne" au lieu de "prévisualiser". Ce n’est pas idéal mais beaucoup moins gênant que ce que tu décris.
-
Anomalie #3055 (En cours) : Autorisation sur les listes d’objets
5 mai 2015, par Eric LupinacciEn fait, c’est à mon avis un problème plus général, de rigueur dans l’appel des autorisations en entrée des pages mais aussi de stratégie de définition des autorisations qui sont malheureusement assez rarement arborescentes.
Si on prend les pages objet comme article, rubrique et auteur par exemple, elle commencent toutes par une autorisation :
(#AUTORISERvoir,article,#ID_ARTICLE ou (#AUTORISERvoir,rubrique,#ID_RUBRIQUE ou (#AUTORISERvoir,auteur,#ID_AUTEUR
Cependant d’ailleurs seul l’autorisation article_voir est définie, les autres renvoyant sur l’autorisation par défaut. Mais au moins une autorisation est appelée systématiquement quelque soit le moyen avec lequel on arrive sur cette page.
A partir de là si il existe un bouton qui envoie sur cette page il faut le conditionner par cette autorisation (code HTML) et si c’est un menu créé automatiquement alors là il faut créer une autorisation de menu qui appelle l’autorisation de voir et pas le contraire à mon avis.Donc si on étend ça aux pages articles, auteurs et rubriques je suis d’accord qu’il faudrait une autorisation voir_xxxx (ce qui n’est pas le cas actuellement) qui serait appelée en entrée de la page comme l’exemple ci-dessous pour la page articles :
(#AUTORISERvoir,_articles
et il faudrait alors coder l’autorisation du menu Articles de cette façon :function autoriser_articles_menu_dist($faire, $type, $id, $qui, $opt) return autoriser(’voir’, ’_articles’) ;
En effet, la décision d’afficher ou pas le menu est indépendante du fait de voir ou pas la page articles mais doit s’appuyer dessus si on décide de ne pas présenter un lien qui mène vers une page interdite.
Et il faudrait systématiser cela pour tous les plugins objet du core à mon avis.En second lieu il faudrait faire une passe sur le code des autorisations actuelles pour imbriquer un peu plus les autorisations de façon arborescente ce qui leur donnerait plus de lisibilité car parfois elles sont identiques sans qu’on s’en rende compte car le code est dupliqué.
-
Anomalie #3429 : Incohérence du 2è paramètre du critère `{pagination}`
4 mai 2015, par Eric LupinacciOui, je confirme le problème remonté par Marcimat.
Je pense que la proposition de mettre une virgule est pertinente pagination 10, nom
Le code pour tenir compte de cette modification en gardant la compatibilité avec l’ancienne est le suivant :// Calcul du nommage de la pagination si il existe. // La nouvelle syntaxe pagination 20, nom est prise en compte et privilégiée mais on reste // compatible avec l’ancienne car certains cas fonctionnent correctement if (!isset($crit->param[0][1])) $type = !isset($crit->param[1][0]) ? "’$idb’" : calculer_liste(array($crit->param[1][0]), array(), $boucles, $boucle->id_parent) ; else $type = calculer_liste(array($crit->param[0][1]), array(), $boucles, $boucle->id_parent) ;
en lieu et place de :
$type = !isset($crit->param[0][1]) ? "’$idb’" : calculer_liste(array($crit->param[0][1]), array(), $boucles, $boucle->id_parent) ;
Si on est d’accord avec la proposition de Marcimat je peux commiter.