Piwigo.org

P@t · 2010-04-11 23:53:30

nicolas a écrit:

Je suis à la révision 5760 et le problème est toujours là.
J'ai tenté de refaire une installation et voilà, patatras :

Code:

Fatal error: Cannot redeclare theme_activate() (previously declared in /var/www/piwigo/themes/sobre/admin/maintain.inc.php:3) in /var/www/piwigo/themes/montblancxl/admin/maintain.inc.php on line 22 Call Stack: 0.0013 483232 1. {main}() /var/www/piwigo/install.php:0 0.1654 3484368 2. activate_all_themes() /var/www/piwigo/install.php:383 0.1701 3693920 3. themes->perform_action() /var/www/piwigo/admin/include/functions_install.inc.php:138

Ce n'est pas le meme problème que celui de arn_bwkrd (qui je le confirme, est réglé sur le trunk, et le sera pour la RC2)

Mais tu fais bien de me signaler ca, je n'avais pas pensé à l'activation automatique de tous les thèmes lors de l'install... il va falloir trouver une solution pour le fichier maintain.inc.php.
Pour moi, la solution passe par une redirection obligatoire après chaque activation...

vincent3569 · 2010-04-12 09:54:40

arn_bwkrd a écrit:
Donc:
-une erreur de texte dans la box1 ''l\'administrateur'' ligne8
-le message de félicitation en anglais première ligne

je confirme les 2 problèmes, constatés
ici [Forum, post 139261 by vincent3569 in topic 17424] mes retours sur la version 2.1RC1 (problème 14) et ici [Forum, post 139268 by vincent3569 in topic 17424] mes retours sur la version 2.1RC1 (problème 17)

nicolas · 2010-04-12 11:11:30

P@t a écrit:
nicolas a écrit:
Je suis à la révision 5760 et le problème est toujours là.
J'ai tenté de refaire une installation et voilà, patatras :
Code:
Fatal error: Cannot redeclare theme_activate() (previously declared in /var/www/piwigo/themes/sobre/admin/maintain.inc.php:3) in /var/www/piwigo/themes/montblancxl/admin/maintain.inc.php on line 22 Call Stack: 0.0013 483232 1. {main}() /var/www/piwigo/install.php:0 0.1654 3484368 2. activate_all_themes() /var/www/piwigo/install.php:383 0.1701 3693920 3. themes->perform_action() /var/www/piwigo/admin/include/functions_install.inc.php:138
Ce n'est pas le meme problème que celui de arn_bwkrd (qui je le confirme, est réglé sur le trunk, et le sera pour la RC2)

Mais tu fais bien de me signaler ca, je n'avais pas pensé à l'activation automatique de tous les thèmes lors de l'install... il va falloir trouver une solution pour le fichier maintain.inc.php.
Pour moi, la solution passe par une redirection obligatoire après chaque activation...

Moi je serais plutôt partisan d'un espace de nom pour les thèmes (comme pour les plugins d'ailleurs). Les deux fonctions dans maintain.inc.php serait en fait des méthodes d'une classe statique genre theme_Nom_du_theme.
Pour les appeler au lieu de faire :

Code:

include "path/2/maintain.inc.php";
theme_activate();

je ferais :

Code:

include "path/2/maintain.inc.php";
theme_Nom_du_theme::theme_activate();  // exemple theme_montblancxl::theme_activate();

Dans ce cas, plus de problème de méthode existant déjà.

Pour le fichier maintain.inc.php, il ressemblerait à ça : (exemple montblancxl toujours)

Code:

class theme_montblancxl
{
  public static function theme_activate($id, $version, &$errors) {
 }

 public static theme_deactivate() {
 }

On doit pouvoir faire un peu plus générique et peut-être faire de l'héritage. Pas besoin de redéclarer complètement la méthode theme_activate(). Elle pourrait se dériver de la classe parente.

Vois-tu où je veux en venir ? Veux-tu que je te fasse un début de mise en place un peu plus précis ? (en t'envoyant le diff)
}

rub · 2010-04-12 12:16:21

nicolas a écrit:
Moi je serais plutôt partisan d'un espace de nom pour les thèmes (comme pour les plugins d'ailleurs). Les deux fonctions dans maintain.inc.php serait en fait des méthodes d'une classe statique genre theme_Nom_du_theme.

+1

P@t · 2010-04-12 12:43:02

Oulala, la grosse artillerie!

Pourquoi ne pas faire plutot:

Code:

montblancxl_activate($id, $version, &$errors) {  }

Et dans la classe theme:

Code:

call_user_func($theme_id.'_activate',
  $theme_id,
  $this->fs_themes[$theme_id]['version'],
  $errors
);

Du coup, on peut virer $id de la fonction, ca fait un peu doublon...

Note: C'est ce qui se fait dans drupal (pour les modules)

rub · 2010-04-12 13:37:25

P@t a écrit:
Oulala, la grosse artillerie!

Ha bon!

P@t a écrit:
Pourquoi ne pas faire plutot:
Code:
montblancxl_activate($id, $version, &$errors) {  }
Et dans la classe theme:
Code:
call_user_func($theme_id.'_activate',
  $theme_id,
  $this->fs_themes[$theme_id]['version'],
  $errors
);

Pour moi c'est kif kif bourricot...
Entre une procédure et une méthode statique d'une classe, c'est la même chose...

Code:

call_user_func(array($theme_id, 'theme_activate'),
  $theme_id,
  $this->fs_themes[$theme_id]['version'],
  $errors
);

Code:

call_user_func($theme_id.'::theme_activate',
  $theme_id,
  $this->fs_themes[$theme_id]['version'],
  $errors
);

C'est pareil non?

Mais je préfère en objet car ça ouvre plus de possibilité.

Maintenant attention aux thémes et aux plugins ouvant avoir le même nom.
Un préfixe sur le $theme_id serait sans doute nécessaire? Pour bien séparer la fonction ou la classe?

P@t a écrit:
Du coup, on peut virer $id de la fonction, ca fait un peu doublon...

En objet aussi.
Mais la, je garderais l'argument, ca permet de ne pas recalculer ou d'avoir un dur le id.

rub · 2010-04-12 13:40:31

rub a écrit:
Mais je préfère en objet car ça ouvre plus de possibilité.

De plus, il n'avait pas été dit que nous ferions de plus en plus d'objet?

P@t · 2010-04-12 13:56:20

rub a écrit:
C'est pareil non?

Mais je préfère en objet car ça ouvre plus de possibilité.

Oui, c'est pareil... mais c'est quand meme plus simple de ne pas utiliser de classes...

1) Je ne vois pas quelles possibilité on va avoir pour le fichier maintain.inc.php (c'est un fichier qui est quand meme en principe rarement appelé!)
A part les fonctions activate et deactivate (éventuellement upgrade)...

2) Les développeurs de thèmes ne sont pas forcément des pros en php... restons simple.
Je ne pense pas que ce soit une bonne chose de mettre des classes la ou il n'y en a pas besoin.

rub a écrit:
Maintenant attention aux thémes et aux plugins ouvant avoir le même nom.
Un préfixe sur le $theme_id serait sans doute nécessaire? Pour bien séparer la fonction ou la classe?

Ca ne sert à rien, les maintain.inc.php des thèmes et des plugins ne seront jamais inclus dans la meme page...

rub a écrit:
P@t a écrit:
Du coup, on peut virer $id de la fonction, ca fait un peu doublon...
En objet aussi.
Mais la, je garderais l'argument, ca permet de ne pas recalculer ou d'avoir un dur le id.

L'id sera forcément en dur, puisque qu'il sera dans le nom de la fonction (pour une classe, c'est pareil)
Mais on peut le garder en argument, ca ne mange pas de pain...

rub · 2010-04-12 14:08:47

P@t a écrit:
1) Je ne vois pas quelles possibilité on va avoir pour le fichier maintain.inc.php (c'est un fichier qui est quand meme en principe rarement appelé!)
A part les fonctions activate et deactivate (éventuellement upgrade)...

Rarement appelé mais qui doit se planter quand même.
Avec de l'héritage, ca permettra de partager des méthodes utilisées fréquemment dans ce contexte.

P@t a écrit:
2) Les développeurs de thèmes ne sont pas forcément des pros en php... restons simple.

Rajouter un

Code:

class theme_montblancxl
{
...
}

C'est pas vraiment plus difficile.

En fournissant un modèle qui va bien, il n'y aura pas de soucis.

P@t a écrit:
Je ne pense pas que ce soit une bonne chose de mettre des classes la ou il n'y en a pas besoin.

C'est pas une réponse typique de ceux qui veulent pas utiliser les classes?

P@t a écrit:
rub a écrit:
Maintenant attention aux thémes et aux plugins ouvant avoir le même nom.
Un préfixe sur le $theme_id serait sans doute nécessaire? Pour bien séparer la fonction ou la classe?
Ca ne sert à rien, les maintain.inc.php des thèmes et des plugins ne seront jamais inclus dans la meme page...

Effectivement.

P@t a écrit:
rub a écrit:
P@t a écrit:
Du coup, on peut virer $id de la fonction, ca fait un peu doublon...
En objet aussi.
Mais la, je garderais l'argument, ca permet de ne pas recalculer ou d'avoir un dur le id.
L'id sera forcément en dur, puisque qu'il sera dans le nom de la fonction (pour une classe, c'est pareil)
Mais on peut le garder en argument, ca ne mange pas de pain...

Disons qu'il sera doublement en dur... Il sera en dur mais peu exploitable... ;-)

nicolas · 2010-04-12 14:47:32

Le gros avantage c'est l'héritage. Le niveau de complexité pour les développeurs de thèmes est du même ordre de grandeur. Faire cette mécanique pour les thèmes peut ensuite être généraliser aux plugins. Les thèmes sont une bonne zone d'expérimentation.

Il ne faut bien évidemment pas coder cela pour la 2.1 mais le garder pour la 2.2. Ce ne sont que des réflexctons, mais je pense sincèrement que cela va dans le bon sens.

rub · 2010-04-12 15:43:18

nicolas a écrit:
Il ne faut bien évidemment pas coder cela pour la 2.1 mais le garder pour la 2.2. Ce ne sont que des réflexctons, mais je pense sincèrement que cela va dans le bon sens.

Ha bon !
La gestion des thèmes, c'est tout nouveau alors pourquoi ne pas le faire en 2.1.
En 2.2 pour les plugins, si l'expérimentation sur les thèmes est concluante.

nicolas · 2010-04-12 16:47:03

rub a écrit:
nicolas a écrit:
Il ne faut bien évidemment pas coder cela pour la 2.1 mais le garder pour la 2.2. Ce ne sont que des réflexctons, mais je pense sincèrement que cela va dans le bon sens.
Ha bon !
La gestion des thèmes, c'est tout nouveau alors pourquoi ne pas le faire en 2.1.
En 2.2 pour les plugins, si l'expérimentation sur les thèmes est concluante.

On est en période de Release Candidate je te rappelle.

P@t · 2010-04-12 17:49:22

Et moi je vous rapelle que le seul soucis qu'on a, c'est lors de l'installation.
Ça serait pas plus simple de laisser tel quel, et d'activer uniquement les thèmes de base à l'installation?

rub · 2010-04-12 18:30:04

nicolas a écrit:
On est en période de Release Candidate je te rappelle.

Je sais bien mais as-tu vu tout ce qu'il y a été fait entre la RC1 et la RC2?
On repart dans les même travers d'avant, c'est à dire faire les dev à fond pendant la RC...
Donc, pour moi, la RC1 n'est pas vraiment intéressante d'un point de vue gestion de bugs...
Elle est intéressante par rapport aux nouveautés c'est certain.
Si la branche 2.1 n'a pas été tirée, c'est qu'il y a bien une raison...
D'ou ma réflexion de le faire maintenant...
En RC2, on ne pourra plus...

Après, ca se peut aussi que je trompe sur le process de RC...

nicolas · 2010-04-12 20:47:03

rub a écrit:
nicolas a écrit:
On est en période de Release Candidate je te rappelle.
Je sais bien mais as-tu vu tout ce qu'il y a été fait entre la RC1 et la RC2?
On repart dans les même travers d'avant, c'est à dire faire les dev à fond pendant la RC...
Donc, pour moi, la RC1 n'est pas vraiment intéressante d'un point de vue gestion de bugs...
Elle est intéressante par rapport aux nouveautés c'est certain.
Si la branche 2.1 n'a pas été tirée, c'est qu'il y a bien une raison...
D'ou ma réflexion de le faire maintenant...
En RC2, on ne pourra plus...

Après, ca se peut aussi que je trompe sur le process de RC...

Pour ma part, et je l'ai signalé à Pierrick qui en a convenu (même si sa position s'est asouplie par rapport à il y a quelques années; peut-être le début de la sagesse!!!), la phase de Release Candidate ne doit apporter aucune nouvelle fonctionnalité. On ne fait que stabiliser du code, corriger des bugs. Là clairement ce n'est plus de la stabilisation mais des évolutions. Le fait qu'on soit en RC1 ou RC2 ou RCn ne change rien au processus.

Après il faut peut-être revoir cela et créer une nouvelle branche juste avant la première RC. Sinon on fait durer la phase de RC pendant des semaines. SI on tire la branche dès le départ et qu'on est dès le départ en correction de bugs, corrections des premiers problèmes rencontrés et stabilsation du code, le processus est plus court. Personnellement je n'aime pas trop cette phase, autant la rendre la plus courte possible. Cela va faire près de 15 jours qu'on a fait la RC1 et la RC2 n'est pas encore sortie.

p.s: Ce n'est peut-être pas la bonne discussion pour en parler mais c'est toi qui a commencé, enfin peut-être pas finalement mais tant pis.

Piwigo.org

Annonce

#16 2010-04-11 23:53:30

Re: [2.1RC1] premieres impressions

nicolas a écrit:

Code:

#17 2010-04-12 09:54:40

Re: [2.1RC1] premieres impressions

arn_bwkrd a écrit:

#18 2010-04-12 11:11:30

Re: [2.1RC1] premieres impressions

P@t a écrit:

nicolas a écrit:

Code:

Code:

Code:

Code:

#19 2010-04-12 12:16:21

Re: [2.1RC1] premieres impressions

nicolas a écrit:

#20 2010-04-12 12:43:02

Re: [2.1RC1] premieres impressions

Code:

Code:

#21 2010-04-12 13:37:25

Re: [2.1RC1] premieres impressions

P@t a écrit:

P@t a écrit:

Code:

Code:

Code:

Code:

P@t a écrit:

#22 2010-04-12 13:40:31

Re: [2.1RC1] premieres impressions

rub a écrit:

#23 2010-04-12 13:56:20

Re: [2.1RC1] premieres impressions

rub a écrit:

rub a écrit:

rub a écrit:

P@t a écrit:

#24 2010-04-12 14:08:47

Re: [2.1RC1] premieres impressions

P@t a écrit:

P@t a écrit:

Code:

P@t a écrit:

P@t a écrit:

rub a écrit:

P@t a écrit:

rub a écrit:

P@t a écrit:

#25 2010-04-12 14:47:32

Re: [2.1RC1] premieres impressions

#26 2010-04-12 15:43:18

Re: [2.1RC1] premieres impressions

nicolas a écrit:

#27 2010-04-12 16:47:03

Re: [2.1RC1] premieres impressions

rub a écrit:

nicolas a écrit:

#28 2010-04-12 17:49:22

Re: [2.1RC1] premieres impressions

#29 2010-04-12 18:30:04

Re: [2.1RC1] premieres impressions

nicolas a écrit:

#30 2010-04-12 20:47:03

Re: [2.1RC1] premieres impressions

rub a écrit:

nicolas a écrit:

Pied de page des forums