
Recherche avancée
Autres articles (85)
-
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 (...) -
MediaSPIP version 0.1 Beta
16 avril 2011, parMediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Pour avoir une installation fonctionnelle, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...) -
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
Sur d’autres sites (17779)
-
Evolution #2006 : Intégration des types de documents xml d’Office 2010
8 mars 2011, par cedric - -
Anomalie #3164 : Problème de sauvegarde en MySQL
11 août 2014, par cedric -Il ne faut pas mélanger dans le même ticket des bugs de la sauvegarde sous SPIP 2.x et sous SPIP 3.x, ce sont des modules totalement différents
-
Anomalie #4353 (Nouveau) : MYSQL 5.7 - Comportement du timestamp vs la variable explicit_defaults_...
17 juin 2019, par Eric LupinacciSuite à une réinstallation de SVP (var_mode) qui supprime les tables et les recrée dans la foulée je me suis rendu compte que le timestamp de la table spip_depots ne se mettait plus à jour automatiquement.
En cherchant avec Matthieu j’ai noté que chez moi la variable explicit_defaults_for_timestamp était à 1 ce qui ne devait jamais être le cas auparavant et donc provoquait ce dysfonctionnement si la déclaration du champ ne précisait pas la mise à jour automatique : DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMPEn général, j’ai toujours vu les déclarations du type ’maj’ => ’timestamp’ sans rien préciser.
Ne serait-il pas utile de forcer à la création d’un timestamp le default et le comportement à l’update de façon à se prémunir de ce problème de configuration MYSQL. En plus, une fois créée sans update auto il faut soit un alter table soit recréer la table ce qui est lourd.