Recherche avancée

Médias (91)

Autres articles (103)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

  • ANNEXE : Les plugins utilisés spécifiquement pour la ferme

    5 mars 2010, par

    Le site central/maître de la ferme a besoin d’utiliser plusieurs plugins supplémentaires vis à vis des canaux pour son bon fonctionnement. le plugin Gestion de la mutualisation ; le plugin inscription3 pour gérer les inscriptions et les demandes de création d’instance de mutualisation dès l’inscription des utilisateurs ; le plugin verifier qui fournit une API de vérification des champs (utilisé par inscription3) ; le plugin champs extras v2 nécessité par inscription3 (...)

Sur d’autres sites (9416)

  • Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde standard des q’un prefixe ....

    31 octobre 2014, par Ybbet SPIP

    Le 31 octobre 2014 11:19, YannX SPIP <> a écrit :

    Le 30/10/2014 17:57, 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/account

    Le 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 RUBRIQUES

    La seule solution a été de ré-intégrer "a la mano" par Adminer (merci
    Suske)
    de petits bouts du dump SQL que prudent j’avais AUSSI fait avec Save_auto

    Peut-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 ?

    —
    YannXhttp://www.spippourlesnuls.fr

    _______________________________________
    liste : http://listes.rezo.net/mailman/listinfo/spip-dev
    doc : http://www.spip.net/
    dev : http://trac.rezo.net/trac/spip/
    irc ://irc.freenode.net/spip

  • Anomalie #3196 : Bug (bien connu des anciens) de sauvegarde standard des q’un prefixe ....

    31 octobre 2014, par YannX spip

    Salut,

    Le 31/10/2014 12:00, Ybbet Spip a écrit :

    Le 31 octobre 2014 11:19, YannX SPIP <
    yannx.spip@hotmail.fr>> a écrit :

    Le 30/10/2014 17:57, 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/account

    Le 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 RUBRIQUES

    La seule solution a été de ré-intégrer "a la mano" par Adminer
    (merci Suske)
    de petits bouts du dump SQL que prudent j’avais AUSSI fait avec
    Save_auto

    Peut-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 ! ;-)

    —
    YannX
    http://www.spippourlesnuls.fr

  • Anomalie #3364 (Nouveau) : Nous allons vérifier votre identité …

    9 décembre 2014, par touti touti

    Actuellement la page pour demander un changement de mot de passe fait moyennement rire, entre ce "nous" hypothétique et la vérification d’identité, on n’est pas au quai d’orsay !!

    ***
    Nouveau mot de passe
    Pour changer votre mot de passe, nous devons d’abord vérifier votre identité. Pour cela indiquez-nous l’adresse email associée à votre compte.
    Votre adresse email ---champ input pour indiquer l’email--- OK
    *****
    La chaine de langue est dans ecrire/lang/spip_fr.php
    ’pass_procedure_changer’ => ’Pour changer votre mot de passe, nous devons d’abord vérifier votre identité. Pour cela indiquez-nous l’adresse email associée à votre compte.’,

    Je propose de la remplacer par
    ’Pour modifier votre mot de passe, merci d’indiquer l’adresse email associée à votre compte.’

Navigation