
Recherche avancée
Médias (2)
-
Granite de l’Aber Ildut
9 septembre 2011, par
Mis à jour : Septembre 2011
Langue : français
Type : Texte
-
Géodiversité
9 septembre 2011, par ,
Mis à jour : Août 2018
Langue : français
Type : Texte
Autres articles (106)
-
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 (...) -
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Pas question de marché, de cloud etc...
10 avril 2011Le vocabulaire utilisé sur ce site essaie d’éviter toute référence à la mode qui fleurit allègrement
sur le web 2.0 et dans les entreprises qui en vivent.
Vous êtes donc invité à bannir l’utilisation des termes "Brand", "Cloud", "Marché" etc...
Notre motivation est avant tout de créer un outil simple, accessible à pour tout le monde, favorisant
le partage de créations sur Internet et permettant aux auteurs de garder une autonomie optimale.
Aucun "contrat Gold ou Premium" n’est donc prévu, aucun (...)
Sur d’autres sites (12864)
-
Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde standard des q’un prefixe ....
31 octobre 2014, par YannX spipSalut,
Le 31/10/2014 12:00, Ybbet Spip a écrit :
Le 31 octobre 2014 11:19, YannX SPIP <yannx.spip@hotmail.fr
yannx.spip@hotmail.fr>> a écrit :Le 30/10/2014 17:57, redmine@spip.org redmine@spip.org> a
écrit :La demande #3196 a été mise à jour par cedric -.
- Statut changé de /Nouveau/ à /Fermé/
- Resolution mis à /invalid/
Bon, faute de description et suite a r21750 / r21752 je ne
constate aucun probleme de backup sur une base avec un prefixe
different de ’spip’
Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde
standard des q’un prefixe ....
<http://core.spip.org/issues/3196#change-10189>- Auteur : YannX spip
- Statut : Fermé
- Priorité : Normal
- Assigné à :
- Catégorie :
- Version cible : 3.0
- Resolution : invalid
- Navigateur :
Deux avertissements :
- prévenir que la sauvegarde peut etre incomplète
- préciser le prefixe utilisé "qq.part" dans l’interface
(pour qu’un gestionnaire pas trop expérimenté ne galère pas trop !)Merci
YannX
Vous recevez ce mail car vous êtes impliqués sur ce projet.
Pour changer les préférences d’envoi de mail, allez sur
http://core.spip.org/my/accountLe problème est simple, bien que quelque peu aléatoire...
depuis que la sauvegarde est passée sous sqlite,
je crois n’avoir pas souvent réussi
(sur une douzaine au moins de sites SPIP 3.x chez OVH) une
sauvegarde complète d’une base SPIP.Encore en milieu de semaine sur SPN : la restauration a zappé
totalement
la tables ARTICLES .. et la table RUBRIQUESLa seule solution a été de ré-intégrer "a la mano" par Adminer
(merci Suske)
de petits bouts du dump SQL queprudentj’avais AUSSI fait avec
Save_autoPeut-etre que ce souci serait aussi dû à l’implémentation SQlite
chez OVH ?
(j’avais constaté que l’instalaltion automatique SQlite SPIP
créait un MySQL non-accessible ! )
mais il me faudrait demander à Bernard de vérifier sur son serveur
kimSufi
si c’est également le cas....Je n’ose imaginer un utilisateur moins aguerri...
Et ça ne serait pas dans ton cas un soucis de timeout ? Ou de mémoire ?
Sauf si je n’ai pas vu un rechargement de page,
j’apercois bien l’ecran final de SPIP qui m’affiche parfois (0/...) sur
certaines tables :
donc si c’etait un timeout, ce serait plutot de la base.... mais pas dès
les premières tables ??Non, je vais commencer à croire à un conflit d’implémentation
MySQL-SQlite chez OVH
(si ce n’est un bug dû au préfixe, ou au principe de SQlite...) mais je
ne sais déterminer d’ici !Si cette hypothèse se verifiait (appel a tous les utilisateurs de bases
SPIP_préfixées chez OVH ??),
cela serait très gênant pour de nouveaux utilisateurs,
car tout le monde ne peut pas etre hébergé chez Nursit ! ;-) -
Anomalie #4776 (Fermé) : Plug invisible depuis svp
7 mai 2021, par Franck DHello :)
Firefox 88.0.1
SPIP 4.0.0-alpha GIT [master : 42d36eda]Laragon avec :
php 8.0.3
Apache 2.4.46
MySQL 8.0.23
phpMyAdmin 5.1.0Juste pour dire qu’il y a pleins de warning au moment de l’installation et que le plug n’ai pas visible dans "svp" une fois l’installation fini (voir copie d’écran) alors qu’il est bien présent dans le dossier plugins-dist
A savoir que j’ai un fichier mes_options avec dedans :
- <span class="CodeRay"><span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_NO_CACHE</span><span class="delimiter">'</span></span>, -<span class="integer">1</span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_INTERDIRE_COMPACTE_HEAD_ECRIRE</span><span class="delimiter">'</span></span>, <span class="predefined-constant">true</span>);
- <span class="predefined">error_reporting</span>(<span class="exception">E_ALL</span>^<span class="exception">E_NOTICE</span>);
- ini_set (<span class="string"><span class="delimiter">"</span><span class="content">display_errors</span><span class="delimiter">"</span></span>, <span class="string"><span class="delimiter">"</span><span class="content">On</span><span class="delimiter">"</span></span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">SPIP_ERREUR_REPORT</span><span class="delimiter">'</span></span>,<span class="exception">E_ALL</span>);
- <span class="predefined">$GLOBALS</span>[<span class="string"><span class="delimiter">'</span><span class="content">taille_des_logs</span><span class="delimiter">'</span></span>] = <span class="integer">500</span>;
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_MAX_LOG</span><span class="delimiter">'</span></span>, <span class="integer">500000</span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_LOG_FILELINE</span><span class="delimiter">'</span></span>,<span class="predefined-constant">true</span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_LOG_FILTRE_GRAVITE</span><span class="delimiter">'</span></span>,<span class="integer">8</span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_DEBUG_SLOW_QUERIES</span><span class="delimiter">'</span></span>, <span class="predefined-constant">true</span>);
- <span class="predefined">define</span>(<span class="string"><span class="delimiter">'</span><span class="content">_BOUCLE_PROFILER</span><span class="delimiter">'</span></span>, <span class="integer">5000</span>);
- </span>
A voir s’il y a un lien avec : https://core.spip.net/issues/4775
-
Révision 23364 : Restructuration complète du critère `{par xxx}` pour y voir plus clair et apporte...
31 janvier 2017, par marcimat@rezo.net- les expressions telles que `par num titre` ou `par multi titre` sont extensibles. `par expr champ` cherchera une fonction
`calculer_critere_par_expression_expr` pour gérer cette expression- une fonction `calculer_critere_par_champ()` est utilisée pour retrouver la table de tri d’un champ demandé.
Cette fonction est d’ailleurs aussi utilisée par les fonctions `num` ou `multi`.
Cela harmonise un peu les diverses utilisations entre ces 3 cas principaux `par xpar num xpar multi x`.x peut être :
- un champ de la table (titre),
- un champ dont la table de jointure est nommé (documents.titre),
- un champ dont l’alias de table est nommé (L1.titre) (à éviter, surtout là pour compat)
- un champ d’exception de jointure (titre_mot)
- un champ d’une autre table dont la jointure est explicite (ARTICLES documents)par taille
- un champ d’une autre table dont la jointure est possible (DOCUMENTS)par rang_lienLe changement est que si la jointure existe déjà pour un champ, le champ sera correctement préfixé de l’alias de table correspondant,
et dans certains cas une nouvelle jointure ne sera pas créé inutilement.Entre autres :
- `(DOCUMENTS)id_article ?id_rubrique ?vu=nonpar rang_lien`, le ORDER BY de rang_lien est bien préfixé de l’alias d’une table de jointure.
Il ne peut plus y avoir d’ambiguité sur le champ, rapporté par Mysql si la table de jointure est présente 2 fois. Cependant le ticket #3894 reste entier.