Principaux changements en 3.0.5
- Nouvelle correction de #RANG. La balise s’applique uniquement sur la boucle en cours. Il faut utiliser #_nom:RANG pour prendre le rang d’une boucle parente.
- Corrections CSS pour l’affichage RTL de l’espace privé
- Paginer les rubriques par 500 dans le privé (en l’absence de pagination, des sites avec beaucoup de rubriques étaient ennuyés)
- La validation clavier (via la touche entrée) des formulaires de traduction et de date n’était pas prise en compte par webkit (il ne faut pas de submit en display:none pour lui)
- Correction des urls des articles RSS du suivi de publication dans l’espace privé
- Les traductions d’objets doivent pouvoir être configurées sans le menu de langue mais avec les liens de traductions
- Rétablissement du fonctionnement de [(#FORMULAIRE_INSCRIPTION|oui) ... ]
- Rétablissement de la suppression régulière des articles mis à la poubelle
- Tri fonctionnel sur les listes de la recherche dans le privé
- La notification d’envoi d’email prend en charge aussi le format HTML
- Envoi du véritable entête des requêtes HEAD par le serveur
- Classe CSS ’lat’ sur la colonne gauche de l’espace privé aussi pour les pages en PHP
- Ajout d’un squelette de listes de documents pour qu’ils apparaîssent dans la recherche de l’espace privé
- Correction du squelette backend, dans lequel l’élément <description>
du <channel>
atom est obligatoire
- Correction sur l’accès aux documents protégés
- Le critère {id_groupe}
est disponible pour les boucles SITES
- Les onglets du porte plume passent sous le menu déroulant de l’entête de l’espace privé
- La prévisualisation du porte plume doit pouvoir être effective ailleurs que sur les formulaires d’édition d’objets éditoriaux, et ailleurs que sur un champ ’texte’
- La vieille fonction afficher_documents_colonne() est maintenue pour compatibilité. Elle est considérée maintenant comme dépréciée.
- Le grenier reçoit les scripts de transformation UTF8 de la base de données
- Le grenier reçoit les vieux scripts de liste de mots
- Correction d’un problème sur les mises à jour de plugins : elles pouvaient attraper un plugin de même version que la mise à jour à faire, mais pas forcément de même préfixe !
Principaux changements en 2.1.19
- Correction de #PARAMETRE_FORUM
- Diverses corrections sur les sauvegardes partielles
- 42 types de documents supplémentaires
- correction d’un bug sur le raccourci de tableau
P.S : la 2.1.18 n’aura vécu que le temps que vivent les roses mais elle contenait un bug génant. Pour plus de clarté, nous avons préféré l’incrémenter d’un numéro
Comment mettre à jour ?
N’hésitez pas à utiliser les différents moyens mis à disposition par la communauté pour obtenir de l’aide lors de cette mise à jour :
- Liste spip-user : http://listes.rezo.net/mailman/listinfo/spip
- Forum : http://forum.spip.net
- IRC : http://irc.spip.net
Nous rappelons à toutes et tous que le meilleur moyen pour signaler des failles, ou des suspicions de failles est d’envoyer un email à « spip-team@rezo.net ».
1. par spip_loader.php : si vous avez déjà installé spip_loader, rendez-vous à l’adresse http://VOTRE_SITE/spip_loader.php pour installer la dernière version de SPIP.
Attention cependant : lisez bien les instructions ici : http://www.spip.net/fr_download#spip_loader pour ne pas être surpris par un passage non voulu de SPIP2 à SPIP3.
2. par copie des fichiers : SPIP 3.0.5 est disponible à l’adresse http://files.spip.org/spip/stable/spip-3.0.zip
3. par SVN : si vous êtes dans la branche 3 faites simplement un « svn up » svn ://trac.rezo.net/spip/branches/spip-3.0
La version 3.0.5 est aussi disponible sous la branche : svn ://trac.rezo.net/spip/branches/spip-3-stable et sous le tag svn ://trac.rezo.net/spip/tags/spip-3.0.5
La version 2.1.19 est téléchargeable ici : http://files.spip.org/spip/archives/ (attention à télécharger la bonne version : 2.1.19. Non, je vous assure, il n’est pas totalement inutile de le préciser...)
Comment être tenu au courant de ces annonces ?
Le plus simplement du monde en s’inscrivant sur la mailing liste http://listes.rezo.net/mailman/listinfo/spip-ann .
Bien sûr les réseaux sociaux ne sont pas en reste :
- Twitter : http://twitter.com/spip
- Facebook : http://www.facebook.com/spip.net
- Seenthis : http://seenthis.net/people/spip
Discussions par date d’activité
11 discussions
Bonjour ! Excellente organisation de spip 3, bravo ! Il me semble aussi qu’en étant passée de « forms&tables » à « formidable », de vieilles tables n’aient pas été supprimées. Par ailleurs mon hébergeur me signale qu’un script tourne en boucle, et j’ai des fichiers log de 500 à plus de 2000 lignes. Est-ce grave ?
Bonjour
Je rencontre depuis quelques jours de gros problèmes de lenteur (vraiment très lent). J’observe aussi des logs qui grossissent plus que de raison.
dans mysql.log, j’ai aussi le même genre de messages :
May 02 08:26:55 90.9.252.126 (pid 1801) :Pub:ERREUR : Table ’xxx.spip_syndic_liens’ doesn’t exist - SHOW CREATE TABLE
spip_syndic_liens
May 02 08:27:36 90.9.252.126 (pid 1784) :Pub:ERREUR : Table ’xxx.spip_articles_liens’ doesn’t exist - SHOW CREATE TABLE
spip_articles_liens
May 02 08:27:37 90.9.252.126 (pid 1784) :Pub:ERREUR : Table ’xxx.spip_rubriques_liens’ doesn’t exist - SHOW CREATE TABLE
spip_rubriques_liens
May 02 08:27:37 90.9.252.126 (pid 1784) :Pub:ERREUR : Table ’xxx.spip_breves_liens’ doesn’t exist - SHOW CREATE TABLE
spip_breves_liens
May 02 08:27:37 90.9.252.126 (pid 1784) :Pub:ERREUR : Table ’xx.spip_forum_liens’ doesn’t exist - SHOW CREATE TABLE
spip_forum_liens
Qqun sait d’où cela vient ?
Répondre à ce message
php 5.2 : OK, pas php 5.4
= une information ( et une question )
Bonjour
j’envisage de peut-être changer d’hébergeur, 1&1 semblant trainer les pieds pour échanger 2 des contrats de sites dont je m’occupe. [1] [2] [3]
Mes sites sous SPIP 3.0.5 (sauf le problème des sauvegardes de la base MySQL non résolu ) fonctionne bien sous php 5.2
Mais ayant découvert que php 5.4 était également disponible chez 1&1, je l’ai donc sélectionner
Le résultat a été catastrophique, l’écran d’accueil du site est étant envahi du message suivant en nombreux exemplaire, et l’espace privé inaccessible
Tout est rentré dans l’ordre en rétablissant php 5.2
Mais cela me fait hésiter à changer d’hébergeur ( web4all ne propose, semble-t-il, que php 5.4 )
( j’ai presqu’un an pour réaliser ce transfert, donc pour me décider )
PS Partie du code incriminée par le message :
Bonjour, même chose mais inversée, j’été sous 5.2 je passe en 5.4 c’est moins pire mais toujàurs autant de mesages d’erreur affiché et onc l’impossibilité de mettre les plugins à jour ect.
Dans les deux cas (5.2 et 5.4) j’ai un problème de time zone.
Répondre à ce message
Bonjour ça fait un moment que je n’ai pas suisvi l’actualité de Spip et je ne comprends pas pourquoi il y a désormais deux branches, une 2.xx et une 3.xx.
Quelqu’un peut-il m’expliquer ou s’il y a un artcicle qui explique ça quelque part.
Merci d’avance.
Salut,
C’était déjà le cas avant la sortie de la 3.0, on avait trois branches : 1.9, 2.0 et 2.1
Lors de la sortie de la 3.0 on a annoncé la fin du support de la branche 1.9, et du coup les branches encore supportées sont : 2.0, 2.1 et 3.0.
++
Répondre à ce message
Bonjour,
Je procède actuellement à une migration de :
vers :
Tout se passe bien sauf que le bug mentionné dans l’article :
SPIP 3.0.4 : importante mise à jour - pas de vacances pour SPIP - SPIP 2.1.17 et 2.0.22
à savoir :
est toujours effectif.
Le site comporte maintenant 1565 articles sans auteur !
Donc il faut coriger le bug dans la version SPIP 3.0.5
Cordialement
FDG
Bonjour,
Dans la migration de :
vers :
j’observe que lors de la rédaction d’un article (cf les 3 illustrations sur l’image ci-jointe) :
Dans la colonne de gauche le menu de téléchargement « ajouter une image ou un document » n’apparait pas en mode édition d’un article. Il faut faire « CTRL + rafraichir la page » sur Chrome et Firefox pour le faire apparaître. Sinon c’est le menu de téléchargement des logos de l’article qui apparait en mode édition de l’article.
... à corriger
Cordialement
FDG
Complément d’information/précision
Ce problème de non apparition du menu de téléchargement « ajouter une image ou un document » :
Cordialement
FDG
... mais ce problème se pose à nouveau dès qu’on modifie ce nouvel article !
de plus les modèles d’affichage des images :
<docXXXX|center>
et<imgXXXX|center>
(avec left, center ou right) n’affichent plus d’images dans les espaces privé et publique, il faut utiliser<embXXXX|center>
pour que l’image s’affiche ...... je n’envisage pas de corriger les 1565 articles du site en question ni les articles des 70 autres sites concernés ...
Cordialement
FDG
Répondre à ce message
Bonjour,
J’ai constaté un problème sur les derniers sites que j’ai fait en version 3.0.5 de Spip : lorsque je teste sur le site http://web-sniffer.net une requête HEAD à l’adresse d’un de mes sites, le retour de la requête est une erreur 404.
Quelqu’un a-t-il une idée ?
Merci pour votre aide
Répondre à ce message
Bonjour,
Moi j’ai un problème un peu étrange avec un site que j’ai fait sous la version 3.0.5 de SPIP.
Lorsque j’écris un article et que j’appliques des mises en formes, elle ne s’affiches pas sur le site publique alors que je peux les avoir au niveau de l’édition.
J’ai essayé de voir si c’est mon fichier CSS qui est à incriminer et c’est pas le cas ; ça commence à me stresser surtout que le site est déjà en ligne comme tout fonctionnait bien en local ; si quelqu’un peut me dire que faire, ce me serait d’une grande utilité.
Merci
Répondre à ce message
Bonjour, moi j’ai un bug sous spip 3.0.5 dans édition, sur la barre ou l’icône plan apparait, un survol de cette icône provoque un affichage de 11 ou 12 images non trouvées à la verticale.
Il cherche des images dans le dossier ecrire / images, par exemple : /ecrire/images/header.png mais visiblement ce dossier n’existe pas chez moi.
Normal ? merci !
Répondre à ce message
Bonjour à tous
Après passage de 2.1.19 à 3.0.5, c’est la cata. Montée en charge fulgurante du site, erreurs MySQL, trop de connexions à la base.
Le remplacement des squelettes par ceux de la dist ne règlent pas le problème.
Nous avons une base de 60 000 articles, en ISO 8859
Avez-vous déjà eu ce problème ?
Notre config :
SPIP 3.0.5 @ www.spip.net + spip(3.0.5), compagnon(1.4.0), dump(1.6.7), images(1.1.1), forum(1.8.16), jqueryui(1.8.21), mediabox(0.8.2), medias(2.7.34), mots(2.4.8), msie_compat(1.2.0), organiseur(0.8.6), petitions(1.4.3), porte_plume(1.12.2), revisions(1.7.0), safehtml(1.4.0), sites(1.7.6), squelettes_par_rubrique(1.1.0), stats(0.4.9), svp(0.80.5), tw(0.8.14), urls(1.4.13), vertebres(1.2.1), html5(0.2.1), itwx_2_3_7_classic(2.3.7), nospam(1.0.3), autorite(0.9.12), rssarticle(1.1.0), spip_bonux(3.0.3), facteur(2.2.6), spip_proprio(1.70.0), accesrestreint(3.6.2), player(2.1.2), clevermail(3.0.5), couteau_suisse(1.8.101), tipafriend(1.6.2), iterateurs(0.6.1), queue(0.6.6), breves(1.3.3), compresseur(1.6.7)
Tous les plugins compatibles SPIP3
MySQL
5.0.51a
PHP Version 5.2.6-1+lenny13
Bonjour,
rien de tel de recensé. Il semble que le problème soit lié à un requetage SQL excessif. Normalement ceci est évité par le fonctionnement du cache. Il faudrait analyser en détail les requêtes SQL pour en trouver la source, mais une piste à regarder avant tout est de s’assurer que la protection des documents n’a pas été activée dans le plugin Accès Restreint consécutivement à la migration. C’est une fonctionnalité qui génère beaucoup de requêtes SQL car chaque hit sur une image ou document de SPIP passe alors par PHP et un calcul d’autorisation SQL, sans cache.
Merci pour l’info, nous allons tester.
Bonjour à tous,
La protection des documents est bien désactivée, mais la montée en charge survient malgré tout.
Nous avons testé en revenant en arrière avec un SPIP 2 vierge et la sauvegarde de la base SPIP2.1.19, le problème survient dès que la base est connectée.
Nous avons donc remis en ligne une base allégée SPIP3 contenant moins de 2000 articles avec SPIP 3.0.5.
Tout a bien fonctionné pendant 3 heures, puis la montée en charge est revenue.
À noter que selon PHPMyAdmin le trafic sortant moyen de MySQL était de 300 Mio/heure.
SPIP a-t-il des limites à ne pas dépasser en nombre d’articles ?
Je comprends donc que tu constate le même problème de montée en charge avec SPIP 2.1, contrairement au message initial ?
Pas de limite d’article dans SPIP, ce site fonctionne parfaitement avec plus de 6000 articles en base.
Il faut analyser si ton problème de charge SQL se produit parce que tu as plein de hits (robots ?) sur des pages qui ne sont pas en cache, si ce sont tes pages en cache qui produisent des requetes SQL de façon erronée (auquel cas le squelette ou un plugin maison serait en cause) etc.
Pas de problème générique du côté de SPIP, mais sûrement un problème de performance lié à ton site en particulier qui nécessite une analyse précise en place. Difficile de t’aider plus avec des conseils généraux.
Re-bonjour
Nous avons noté une hausse exponentielle du nombre de requête de spip.php ?action=cron.
Environ 100 000 requetes par mois habituellement, près de 300 000 en septembre et plus de 400 000 pour les 2 premières semaines d’octobre.
Evolution de nos version : spip 2.1.17 le 2 août, 2.1.19 le 17 septembre et 3.0.5 le 12 octobre.
Cette hausse est-elle liée à la version de SPIP ?
Même problème pour moi, la surcharge de mon hébergeur avec des centaines de requêtes ?action=cron s’est produite avec la vers spip 3.0.4 et 3.0.5
En fouillant sur le net, on peut voir que ce problème existe depuis l’année dernière : spip-dev : spip3, page=cron et serveur à genoux
Perso, j’aimerais bien savoir comment désactiver complètement l’exécution du cron dans l’espace public, ainsi je pourrais au moins avoir un site fonctionnel sans surcharge de l’hébergeur...
Je viens de trouver quelque chose : les problèmes avec « /spip.php ?action=cron » se produit lorsqu’on entre dans l’espace privé. Ça ne survient pas avec l’espace public.
Perso, j’ai 3 sites SPIP différents, et tous vivent la même situation...
Bon, pour avoir testé en local, je constate que le problème apparaît dès que j’installe le plug-in Couteau-suisse.
Voila donc pourquoi ce problème ne se manifeste sur aucun site de la communauté. Il faut voir cela avec l’auteur du plugin, donc.
Répondre à ce message
Je suis passé de la version 2.1.8 à la 2.1.19 et depuis je ne peux plus me connecter à mon espace privé !!!!
Quelle pourrait en être la raison ?
Merci pour votre aide.
http://www.farcroixrousse.free.fr/
Salut,
Peut-être as-tu le même problème que moi avec la version 3.0.5.
Est-ce que tu as une page blanche après t’être identifié ? Ou un message d’erreur du type « Fatal error : Allowed memory size… » ?
Essaye de te connecter directement sur une page article genre
ecrire/?exec=article&id_article=3
pour moi ça fonctionne.Sinon tente les solutions présentées ici : http://contrib.spip.net/Mise-a-jour-de-securite-SPIP-3-0-2-2-1-15-et-2-0-20#forum458741
Abel
Répondre à ce message
Sur une version SPIP 2.1.19, il m’est impossible d’ajouter des documents par FTP.
Je place les docs dans tmp/upload ... mais je je vois pas la liste déroulante dans le backoffice.
Voir pièce jointe.
++
Je me réponds à moi-même ...
Les droits CHMOD sur le fichier était 640.
J’ai modifié en 666 et du coup, je le vois dans le backoffice.
Désolé pour le dérangement.
++
Répondre à ce message
Bonjour,
j’avais posté ça ailleurs mais il me semble ça pourrait plus avoir ça place ici.
Sur un site en SPIP 3.0.5 j’ai un message « Fatal error : Allowed memory size… » sur la page d’accueil de la partie privée (ou une page blanche cela dépend). Apparemment les autres pages de la partie privée ne sont pas affectées.
J’ai tenté d’ajuster le paramètre memory_limit, comme conseillé ici, mais :
- Si je mets
ini_set("memory_limit","32M");
dans « mes options » cela ne change rien.et
- Si je mets
php_value memory_limit 32M
dans htaccess j’ai une « Internal Server Error ».Je suis chez OVH avec PHP 5.4 activé.
Merci de votre aide.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |