Recherche avancée

Médias (1)

Mot : - Tags -/belgique

Autres articles (112)

  • Configurer la prise en compte des langues

    15 novembre 2010, par

    Accéder à la configuration et ajouter des langues prises en compte
    Afin de configurer la prise en compte de nouvelles langues, il est nécessaire de se rendre dans la partie "Administrer" du site.
    De là, dans le menu de navigation, vous pouvez accéder à une partie "Gestion des langues" permettant d’activer la prise en compte de nouvelles langues.
    Chaque nouvelle langue ajoutée reste désactivable tant qu’aucun objet n’est créé dans cette langue. Dans ce cas, elle devient grisée dans la configuration et (...)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

Sur d’autres sites (5536)

  • Automation for Downloading, Encoding, Renaming and Uploading [on hold]

    5 février 2019, par Madara Uchiha

    How do I automate - downloading anime episodes from Torrent > Encode the videos with ffmpeg or gui > rename (with encoder tag) > upload to Google drive ?
    Should work 24/7. Need help !

  • Anomalie #3398 (Nouveau) : Date du thread modifiée lorsqu’un message de forum est soumis, sans ten...

    6 mars 2015, par Pascal Verrier

    Bonjour,

    Configuration : un SPIP neuf 3.0.17 avec le plugin Comments 3.3.2 permettant l’affichage en thread (et donc de répondre à un message, ce qui n’est pas possible avec le core seul).
    Concerné : plugin-dist forum.

    Je constate sur SPIP 3.0.17 ce fonctionnement curieux :
    - j’ai configuré dans un premier temps le forum d’un article en modération à postériori
    - j’ai posté un premier message puis y ai fait une réponse : je constate bien le changement de la date du thread qui se recale sur la date du dernier posté (et donc publié)
    - j’ai modifié la configuration pour passer en modération à priori
    - j’ai ajouté dans le même thread un troisième message (qui donc cette fois n’est pas publié, car modéré)
    - dans la base de données je constate que la date_thread s’est de nouveau calée sur le dernier message, alors qu’il n’est pas publié (statut "prop")

    Cela ne me semble pas normal ; sur mon site de production (http://www.harmoweb.cnrs.fr/spip.php?rubrique28) intégrant l’affichage de la liste des threads, du plus récent au plus ancien (en se basant sur date_thread) cela a pour effet de "faire remonter" des messages anciens sur lesquels des messages viennent d’être posté même s’ils ne sont pas publiés (dans notre cas des spams interceptés par nospam, nous n’avons pas de modération à priori, mais le mécanisme posant problème est le même).

    Dans mes recherches je suis également tombé sur cette correction d’anomalie https://core.spip.net/issues/852 où le problème de base était similaire mais si j’ai bien compris ne concernait que les mises à jour de statut de messages publiés à priori ; l’évolution de date_thread est normale dans ce cas, contrairement à la situation où le message n’est pas publié d’office, la date de thread ne tenant donc pas compte du statut du message fraîchement posté : lors de l’enregistrement d’un nouveau message, date_thread ne devrait être changé sur tous les messages du fil que si ce message est publié, et non dans les autres cas.

  • Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

    23 juillet 2015, par Peet du

    Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

    Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
    Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

    Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
    Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

    SUGGESTION
    Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
    Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
    Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

    Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

    SUGGESTION 2
    L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

    SUGGESTION 3
    même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

    • cvtautosave_formulaire_charger
    • cvtautosave_formulaire_traiter

    en _dist ?

Navigation