Recherche avancée

Médias (91)

Autres articles (49)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

Sur d’autres sites (6529)

  • Evolution #3638 (Nouveau) : Utiliser la rechercher Fulltext par défaut pour le critère {recherche}

    7 janvier 2016, par Gilles VINCENT

    Suite à la discussion entammée sur spip-dev, je suggère d’utiliser la recherche Fulltext par défaut, au lieu des REGEXP actuelles
    http://thread.gmane.org/gmane.comp.web.spip.devel/66780

    Par défaut, recherche génère des requêtes des type REGEXP, ce qui n’est utile que si des utilisateurs font des recherches avec des expressions régulières, ce qui n’est pas le cas. Depuis le commit r21697 les tables ont installées par défaut au format MyISAM (demande #2727). SPIP gagnerait donc à utiliser les recherches en Fulltext.

    Analyse détaillée du problème faite par Remi () :

    Le problème c’est que ce type de requête est généré dès lors qu’il y a un
    espace dans la recherche et les requêtes REGEXP n’utilisent pas les index.

    Donc ça ne concerne pas que les utilisateurs qui recherchent des
    expressions régulières.

    Pour une recherche aussi bête que "chercher un mot" ça recherche
    REGEXP sur chaque colonne de la table
    spip_articles. Evidemment ça renvoie tous les articles contenant "un".

    Un exemple particulièrement inefficace : 51s pour faire une recherche sur 2
    mots sans avoir la certitude que les 2 mots ne s’y trouvent.

    1. Query_time : 51.073814 Lock_time : 0.018906 Rows_sent : 16363 Rows_examined : 36816

    SELECT t.id_article, t.surtitre, t.titre, t.soustitre, t.chapo, t.texte,
    t.ps, t.nom_site, t.url_site, t.descriptif FROM `xxxxxx`.spip_articles AS t
    WHERE t.surtitre REGEXP ’Etats unis|Etats|unis’ OR t.titre REGEXP ’Etats
    unis|Etats|unis’ OR t.soustitre REGEXP ’Etats unis|Etats|unis’ OR t.chapo
    REGEXP ’Etats unis|Etats|unis’ OR t.texte REGEXP ’Etats unis|Etats|unis’
    OR t.ps REGEXP ’Etats unis|Etats|unis’ OR t.nom_site REGEXP ’Etats
    unis|Etats|unis’ OR t.url_site REGEXP ’Etats unis|Etats|unis’ OR
    t.descriptif REGEXP ’Etats unis|Etats|unis’ ;

    Ici, ça me renvoie les articles qui contiennent "punissons",
    "réunis".

    A ce niveau, un bête like me met "que" 5s :

    SELECT * from (select *, concat( t.surtitre, t.titre, t.soustitre,
    t.chapo, t.texte, t.ps, t.nom_site, t.url_site, t.descriptif) search from
    spip_articles t) s WHERE s.search like ’%unis%’ or s.search like
    ’%Etats%’ ;

    Mais honnêtement 5s, ce n’est pas non plus acceptable.

    Mais s’il vous faut mettre un truc par défaut autre que du fulltext,
    utilisez LIKE sur la chaine à rechercher. Ca ira plus vite et ça vous
    renverra des résultats plus cohérents.

    Remi

  • Anomalie #3647 : #INTRODUCTION

    11 janvier 2016, par Ivan Lewkowitz

    Hello Franck, désolé, voici plus de détails :

    Il s’agit d’un Spip 3.0.21 mis à jour en 3.1 via Spip_loader.
    J’ai suivi les indications de maj. Les plugins sont compatibles (couteau suisse).
    Base de données : MySQL (exportée du site online via l’admin de Spip et réimportée en local, toujours via l’admin Spip, même version évidemment). Le fichier se termine en .sqlite (et non .dump ou autre).
    Le codage de la base est tout en utf-8, idem pour le site lui-même.

    Online, le site est en Spip 3.1 et Php 5.2 (module Apache) alors que dans Mamp, c’est Php 5.6.10 qui tourne (ou Php 7 au choix). Quand on passe d’une version à l’autre de Php en local, la première balise #INTRODUCTION est ignorée (le DIV accueillant l’intro est vide au lieu d’afficher un paragraphe).
    Ça c’est pour l’intro dans une boucle ARTICLES.


    [(#INTRODUCTION800|liens_ouvrants|propre)]

    Mais bizarrement, j’appelle aussi l’intro en survol sur des titres d’articles plus loin, et ça fonctionne sans problème :

    Donc… mystère. Donc pour résumer ma première balise intro ne saute qu’en local et avec Php 7 (donc rien de dramatique). J’ai pas essayé d’activer Php 7 chez mon hébergeur ; c’est proposé en beta encore.
    A ta dispo.

  • Révision 22875 : Déplantage de la balise #RANG quand on a déclaré autre chose qu’un simple champ p...

    4 mars 2016, par rastapopoulos@spip.org

    On garde exactement le même fonctionnement qu’avant avec un "AS titre_rang" rajouté. Mais on fait deux tests au lieu d’un seul :
    - d’abord on cherche le titre en se disant que "lang" est défini AVANT
    - et si on ne trouve pas, là on prend depuis le début
    Mais dans les deux cas, vu que c’est séparé en deux, et qu’on cherche "lang" explicitement et pas une virgule toute seule : on peut donc prendre tout caractère pour le titre, y compris les virgules qu’il y aurait dans des fonctions.

    Cela gère donc bien tous les cas, enfin de toute façon plus de cas qu’avant.

Navigation