[SPIP Zone] [Spip-zone-commit] r83959 - _core_/branches/spip-3.0/plugins/forum/prive/modeles

Hop,

Le 31/07/2014 04:07, prigent.yohann@gmail.com a écrit :

Author: prigent.yohann@gmail.com
Date: 2014-07-31 04:07:14 +0200 (Thu, 31 Jul 2014)
New Revision: 83959

Modified:
    _core_/branches/spip-3.0/plugins/forum/prive/modeles/forum.html
Log:
Tester si les plugins sont actifs

Details: Connexion · GitLab

J'ai un doute sur ce commit, deux questions :

1) est-ce bien nécessaire, un truc comme (BREVES?) et (SIETS?) ne suffirait-il pas ?

2) le commit ne devrait-il pas plutôt être dans la trunk avant d'être posé dans la branche stable qui est utilisée par pas mal de monde ?

++
b_b

Re hop,

Le 31/07/2014 11:07, Bruno Bergot a écrit :

Details: Connexion · GitLab

J'ai un doute sur ce commit, deux questions :

1) est-ce bien nécessaire, un truc comme (BREVES?) et (SIETS?) ne
suffirait-il pas ?

En fait il faut les deux, cf 24- Ne boucler sur la table sql d’un plugin que si ce plugin est installé et activé sur cette page :

http://contrib.spip.net/Astuces-longues-pour-SPIP

2) le commit ne devrait-il pas plutôt être dans la trunk avant d'être
posé dans la branche stable qui est utilisée par pas mal de monde ?

Je crois bien que oui :stuck_out_tongue:

++
b_b

Le 31/07/2014 11:17, Bruno Bergot a écrit :

En fait il faut les deux, cf 24- Ne boucler sur la table sql d’un plugin
que si ce plugin est installé et activé sur cette page :

Astuces longues pour SPIP

Euh ben non, je ne vois pas à quoi sert le {si}…

Avec le ?, si la table n'existe pas, la boucle n'est pas exécuté. Pourquoi faudrait-il un {si} en plus ?

--
RastaPopoulos

D'accord, du coup je vais rajouter la condition sur la table.

Concernant la branche de déploiement, j'ai pas trop fais gaffe mais chez moi j'ai l'erreur du compilo tous les jours vu que je n'ai pas les brèves. Je pense qu'il y a urgence à le mettre sur la branche en cours. Et à vérifier dans les autres fichiers/plugins si on a pas le même soucis.

--
Yohann Prigent

On 31 Jul 2014, at 11:17, Bruno Bergot <brunobergot@gmail.com> wrote:

Re hop,

Le 31/07/2014 11:07, Bruno Bergot a écrit :

Details: Connexion · GitLab

J'ai un doute sur ce commit, deux questions :

1) est-ce bien nécessaire, un truc comme (BREVES?) et (SIETS?) ne
suffirait-il pas ?

En fait il faut les deux, cf 24- Ne boucler sur la table sql d’un plugin que si ce plugin est installé et activé sur cette page :

Astuces longues pour SPIP

2) le commit ne devrait-il pas plutôt être dans la trunk avant d'être
posé dans la branche stable qui est utilisée par pas mal de monde ?

Je crois bien que oui :stuck_out_tongue:

++
b_b

Hop,

Le 31/07/2014 13:05, Yohann Prigent a écrit :

D'accord, du coup je vais rajouter la condition sur la table.

Concernant la branche de déploiement, j'ai pas trop fais gaffe mais chez moi j'ai l'erreur du compilo tous les jours vu que je n'ai pas les brèves. Je pense qu'il y a urgence à le mettre sur la branche en cours. Et à vérifier dans les autres fichiers/plugins si on a pas le même soucis.

Pour info, le ? sur la table suffit, pas besoin de tester la présence du plugin avec {si} (j'ai testé la modif en local).

++
b_b

Hmmm ok, mais du coup on affichera quand même les forums en attente des brèves même si le plugin est désactivé (mais pas désinstallé) ? Vaut mieux pas laisser ce test sur le plugin ? Certes ça ne générera pas d'erreur de compilo de l'enlever, mais ça affichera encore des brèves si la table existe encore.

--
Yohann Prigent

On 31 Jul 2014, at 13:07, Bruno Bergot <brunobergot@gmail.com> wrote:

Hop,

Le 31/07/2014 13:05, Yohann Prigent a écrit :

D'accord, du coup je vais rajouter la condition sur la table.

Concernant la branche de déploiement, j'ai pas trop fais gaffe mais chez moi j'ai l'erreur du compilo tous les jours vu que je n'ai pas les brèves. Je pense qu'il y a urgence à le mettre sur la branche en cours. Et à vérifier dans les autres fichiers/plugins si on a pas le même soucis.

Pour info, le ? sur la table suffit, pas besoin de tester la présence du plugin avec {si} (j'ai testé la modif en local).

++
b_b

Hop,

Le 31/07/2014 13:48, Yohann Prigent a écrit :

Hmmm ok, mais du coup on affichera quand même les forums en attente des brèves même si le plugin est désactivé (mais pas désinstallé) ? Vaut mieux pas laisser ce test sur le plugin ?

Non je ne pense pas.

Certes ça ne générera pas d'erreur de compilo de l'enlever, mais ça affichera encore des brèves si la table existe encore.

On est dans un cas d'usage "avancé" puisque il s'agit de désactiver un plugin-dist fourni par le core, dans ce cas je pense que c'est au webmestre de supprimer les données de la base s'il ne souhaite pas les afficher. De plus, qu'est-ce qui empêche le webmestre de désinstaller le plugin en question à partir du moment où il peut le désactiver ?

Il serait bien que tu envoie le patch correctif rapidement avant la prochaine release stable :slight_smile:

++
b_b

D’accord, j’aurai plutôt pensé que la logique voulait qu’on teste le plugin vu que c’est accessible facilement vu que c’est en cache dans tmp/ plutôt que la table.

C’est commit.


Yohann Prigent

On 5 Aug 2014 at 13:00:17, Bruno Bergot (brunobergot@gmail.com) wrote:

Hop,

Le 31/07/2014 13:48, Yohann Prigent a écrit :

Hmmm ok, mais du coup on affichera quand même les forums en attente des brèves même si le plugin est désactivé (mais pas désinstallé) ? Vaut mieux pas laisser ce test sur le plugin ?

Non je ne pense pas.

Certes ça ne générera pas d’erreur de compilo de l’enlever, mais ça
affichera encore des brèves si la table existe encore.

On est dans un cas d’usage « avancé » puisque il s’agit de désactiver un
plugin-dist fourni par le core, dans ce cas je pense que c’est au
webmestre de supprimer les données de la base s’il ne souhaite pas les
afficher. De plus, qu’est-ce qui empêche le webmestre de désinstaller le
plugin en question à partir du moment où il peut le désactiver ?

Il serait bien que tu envoie le patch correctif rapidement avant la
prochaine release stable :slight_smile:

++
b_b