flux rss de spip-contrib

hello,

avec le passage de spip3, le flux RSS de contrib n'est plus valide
http://www.spip-contrib.net/spip.php?page=backend

il y a cette ligne du lecteur multimedia qui s’ajoute après le XML
<script type="text/javascript" 
src="plugins/Lecteur_multimedia/javascript/soundmanager/soundmanager2.js"></script><script 
type="text/javascript" 
src="plugins/Lecteur_multimedia/javascript/player_enclosure.js"></script>

--

-- 
_________________________________________
http://www.erational.org

Re: [Spip-zone-commit] r57914 - _galaxie_/plugins-spip-net/svp2010/extra2

article PDF

Re: article PDF

> j'arrive bien a créer la table meta qu'il faut et à y stocker les données du
> formulaire : pour commencer on a le choix de l'orientation, portrait ou
> paysage...
> mais maintenant je sais pas trop comment récupérer cette valeur pour la
> prendre en compte dans le fichier pdf/lib_pdf_global.php, dans la fonction
> PDF, $orientation
> est-ce possible ?

euh... $GLOBALS['meta']['le_nem_de_la_meta_a_recuperer']

Re: SlowQueries FullText

> Donc retour d'experience pour corriger le problème :
>
> 1/ Remplacer le LEFT JOIN LEFT JOIN par un LEFT JOIN INNER JOIN pour chaque liaison avec objet
> 2/ ajouter des INDEX séparés id_objet et objet sur chaque table _liens (qui avaient deja toutes un INDEX id_xxx)
>
> Avec ces deux corrections la requete passe de plus de 80s à 0.5s environ.

Super.
Je me doutais un peu qu'on pouvait optimiser la requête mais je
n'avais pas de quoi tester sous la main et je voulais pas dire
n'importe quoi.
Pour les index il faut privilégier celles qui servent souvent dans les
jointure et les filtrages. C'est dur de trouver un compromis parce-que
les index pénalisent les grosses tables au moment des
insertions/modifications tandis que ça peut décupler le temps
d'interrogation des table

Re: requeter en PHP sur une table pouvant ne pas exister

>> Je cherche l'équivalent PHP pour un formulaire (la requête ne
>> renverrait rien si le plugin devant installer les tables n'a pas été
>> activé ou a été supprimé). Des pistes ?
>>
>
> Un test à base de sql_showtable() peut être ?
>
Ah... J'aurais pas pensé à ça ...parce-que un "DESC " sur une table
inexistante me renvoie une erreur 1146
http://programmer3.spip.org/sql_showtable,619
http://programmer3.spip.org/trouver_table,620
Je vais tester cela. Je suppose si la table n'existe pas (et si ça ne
renvoie pas d'erreur), un count() sur le résultat et je serai fixé ?
Cool.

--

-- 
♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪.♪♫•*¨*•.¸¸❤¸¸.•*¨*•♫♪
_______________________________________________
spip-zone <at> rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Re: SlowQueries FullText

Le 01/02/2012 15:27, Gildas Cotomale a écrit :
>> Donc retour d'experience pour corriger le problème :
>>
>> 1/ Remplacer le LEFT JOIN LEFT JOIN par un LEFT JOIN INNER JOIN pour chaque liaison avec objet
>> 2/ ajouter des INDEX séparés id_objet et objet sur chaque table _liens (qui avaient deja toutes un
INDEX id_xxx)
>>
>> Avec ces deux corrections la requete passe de plus de 80s à 0.5s environ.
>
> Super.
> Je me doutais un peu qu'on pouvait optimiser la requête mais je
> n'avais pas de quoi tester sous la main et je voulais pas dire
> n'importe quoi.
> Pour les index il faut privilégier celles qui servent souvent dans les
> jointure et les filtrages. C'est dur de trouver un compromis parce-que
> les index pénalisent les grosses tables au moment des
> insertions/modifications tandis que ça peut décupler le temps
> d'interrogation des table

SPIP lisant beaucoup plus souvent qu'il n'écrit, le choix est tout de même facile à faire, non ?

JLuc

Re: SlowQueries FullText

Le 1 février 2012 16:16, JLuc <jluc <at> no-log.org> a écrit :
> Le 01/02/2012 15:27, Gildas Cotomale a écrit :
>> Pour les index il faut privilégier celles qui servent souvent dans les
>> jointure et les filtrages. C'est dur de trouver un compromis parce-que
>> les index pénalisent les grosses tables au moment des
>> insertions/modifications tandis que ça peut décupler le temps
>> d'interrogation des table
>
>
> SPIP lisant beaucoup plus souvent qu'il n'écrit, le choix est tout de même
> facile à faire, non ?
>

Et du coup, je me pose une question depuis le début de ce fil de
discussion: et pour Spip 2.x, quand on a une table spip_mots_articles
(ou rubriques ou syndic) bien dodue, et plein de jointures dans les
squelettes (du genre on fait plus souvent appel à id_article de la
table spip_mots_articles qu'à id_mot) est-ce qu'il ne vaut pas mieux
aussi opter pour l'index sur les id_article (id_rubrique et id_syndic)
?

--

-- 
Beurt

Re: [Spip-zone-commit] r57922 - _plugins_/mutualisation

Le 01/02/2012 15:05, suske <at> brubel.net a écrit :
> Author: suske <at> brubel.net
> Date: 2012-02-01 15:05:21 +0100 (Wed, 01 Feb 2012)
> New Revision: 57922
>
> Modified:
>     _plugins_/mutualisation/plugin.xml
> Log:
> après quelques tests ça semble passer en spip3beta2
>
>
> Details: http://zone.spip.org/trac/spip-zone/changeset/57922
>
> _______________________________________________
> Spip-zone-commit <at> rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit
>

pourquoi il fonctionné pas en spip 3 ?

parceque je suis en beta 2 en spip 3 et mutualisation depuis un moment

Re: [Spip-zone-commit] r48833 - _plugins_/less-css/trunk

Salut Cerdic.

Je remarque que tu utilises dans le cadre de Zpip-less ce plugin pour la partie PHP je suppose, ce qui me fait
penser que tu utilises LESS CSS dans tes développements :)

Je note cependant que LESS php dans ce plugin semble "très ancien" :
http://leafo.net/lessphp/ => en version 0.3.1 contre 0.2.0 dans le plugin

Est-ce une volonté particulière ? Est-ce que passer à la nouvelle version de less php entrainerait des
problèmes particuliers pour toi ?

Merci de ta réponse et bonne nuit ! :)

Le 16 juin 2011 à 12:58, cedric <at> yterium.com a écrit :

> Author: cedric <at> yterium.com
> Date: 2011-06-16 12:58:08 +0200 (Thu, 16 Jun 2011)
> New Revision: 48833
> 
> Modified:
>   _plugins_/less-css/trunk/lesscss_fonctions.php
>   _plugins_/less-css/trunk/plugin.xml
> Log:
> on preprocess less pour transformer la directive 
> @import_spip "css/truc.less"
> en un @import +find_in_path(css/truc.less)
> ce qui permet d'utiliser le path de SPIP et de surcharger un import
> 
> 
> Details: http://zone.spip.org/trac/spip-zone/changeset/48833
> 
> _______________________________________________
> Spip-zone-commit <at> rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit