
Recherche avancée
Autres articles (66)
-
Le profil des utilisateurs
12 avril 2011, parChaque utilisateur dispose d’une page de profil lui permettant de modifier ses informations personnelle. Dans le menu de haut de page par défaut, un élément de menu est automatiquement créé à l’initialisation de MediaSPIP, visible uniquement si le visiteur est identifié sur le site.
L’utilisateur a accès à la modification de profil depuis sa page auteur, un lien dans la navigation "Modifier votre profil" est (...) -
Configurer la prise en compte des langues
15 novembre 2010, parAccéder à la configuration et ajouter des langues prises en compte
Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...) -
XMP PHP
13 mai 2011, parDixit Wikipedia, XMP signifie :
Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)
Sur d’autres sites (6868)
-
Anomalie #3421 (Nouveau) : Problème de redirection lors de l’installation
10 avril 2015, par Franck DalotBonjour :-)
Spip 3.1 [21983]Lorsque qu’une personne souhaite faire une installation "neuve" de spip 3.1
Après envoi des fichiers via FTP sur le serveur, la personne est normalement redirigée vers .../ecrire/ ?exec=installLe problème est que au lieu de cela, un message apparait sur /ecrire/ de type :
Site en travaux
Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.Si la personne réactualise la page, alors c’est bon.
Le problème est présent sur un mutualisé OVH. (peut importe la version de php)
J’arrive à le reproduire en local, sous easyphp 14.1 sous windows 8.1 et php 5.6.4Le problème est présent depuis ce commit :
https://core.spip.net/projects/spip/repository/revisions/21974Franck
-
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.
-
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é.