Sur 6 prefixes différents de tables.
Mais une seule base.
Cela sera faisable.

Mais les perfs: pas certain que tous les problèmes soient réglés pour autant.

8-)

Dans 5 installations, on modifiera le ./include/constant.php

Et pour les tables ci-dessous on modifiera le préfixe pour pointer sur le préfixe de l'installation maître.

define('USERS_TABLE', $conf['users_table']);
define('USER_INFOS_TABLE', $prefixeTable.'user_infos');
define('USER_FEED_TABLE', $prefixeTable.'user_feed');
define('USER_MAIL_NOTIFICATION_TABLE', $prefixeTable.'user_mail_notification');

Je pense que cela devrait marcher, je n'ai rien testé.

8-)

Comme les variables  phpwebgallery2.' n'existent pas: Cela ne m'archera pas.

Ce n'est pas comme ça qu'il faudra l'écrire:

Pour tous les sites
define('CATEGORIES_TABLE', $prefixeTable.'categories');

//etc...

// sauf les lignes pour pointer vers le N° 1 avec un nom en DUR !!!!

define('USERS_TABLE', 'phpwebgallery1_users');
define('USER_INFOS_TABLE', 'phpwebgallery1_user_infos');
define('USER_FEED_TABLE', 'phpwebgallery1_user_feed');
define('USER_MAIL_NOTIFICATION_TABLE', 'phpwebgallery1_user_mail_notification');

patnoe a écrit:

//En laissant la ligne suivante seule en dur et les autres en variables, même fonctionnement à vérifier

define('USERS_TABLE', 'phpwebgallery1_users');


//Les groupes seront identiques dans les 6 sites j'ai mis en dur

define('USER_GROUP_TABLE', 'phpwebgallery1_user_group');

Que _users ? Non... Il change la personnalisation... Alors c'est la même partout => _user_infos
Après _user_feed et _user_mail_notification cela se discute.

Quant à _user_group si tu le fait comme ça, alors également faire _groups...

8-)

Attention,
- a ce jour (1.7), les seules tables qui sont safe a partager est USERS et USER_INFOS ...
- partager USER_FEED_TABLE n'a pas de sens (de toute maniere il y aura 6 flux differents avec 6 url differents)
- partager USER_MAIL_NOTIFICATION pose probleme - 6 bases veut dire 6 mails differents et cette table contient une seule fois last_send
- le partage de USER_GROUP_TABLE et GROUPS_TABLE pose probleme a l'effacement d'un group. Il faut aller sur les 5 autres tables et effacer les lignes correspondantes au groupe de la table GROUP_ACCESS_TABLE. En plus ajouter/virer un membre au/du groupe demande de invalider le cache de permissions pour les autres 5 installations.

Dernière modification par rvelices (2007-09-14 23:45:07)

Dans mon idée de partage, je ne pensais pas faire de la sorte.
Je voulais le faire sans modification du source de PWG.

Je m'explique:
  o il faut une base de données unique appelé BDD
  o avoir une première galerie PWG sur BDD avec pwg_ comme prefixe de table (à choisir lors de l'installation), on l'appelle galerie principale
  o avoir x galeries PWG sur BDD avec pwg_00x_ comme prefixe de table (à choisir lors de l'installation), on les appelle galerie1, galerie2, ....
  o la galerie principale supporte les utilisateurs et ne propose que des liens vers les galeries galerie1, galerie2, .... (cf la demo)
  o pour chacunes des galeries x, on modifie le config_local.inc.php pour aoujter:
    $conf['users_table'] = 'pwg_'.'users';
  o on a donc x+1 sites qui utilise la même base utilisateurs mais qui sont indépendantes
 
Et tout ca, c'est fait sans bidouille de constantes, etc...

Par contre, pourquoi pas dans la 1.8 donner la possibilité de partager d'autres tables (info, etc...).
Mais uniquement en paramètrant les tables et sans paramètrer les champs comme pour la table #_user.


Ps: Pour les pbs de synchro, penses à diviser ton répertoire galerie en plusieurs site (répertoire)

J'ai fait les BDD suivantes

la galleries-1 avec préfixe phpwebgallery1
la galleries-2 avec préfixe phpwebgallery2
etc...

dans la galleries-2

mis constant.php sans modif

avec localfiles editor j'ai rajouté 
$conf['users_table'] = 'phpwebgallery1_users'

aucune recopie des users

Ou est l'erreur

Actuellement je fonctionne à nouveau avec le constant.php modifié


Pour Rub, VDigital et Rvelices même login et passe

site idem sauf archives devient archives-1