Projet : mutualiser des données entre plusieurs PluXml

Gzyg · septembre 2015

Bonjour,

Pour un projet en cours, je m'oriente sur un site utilisant plusieurs PluXml au même niveau hiérarchique, histoire que chaque PluXml puisse avoir sa propre vie si une des composantes du projet (pour une quelconque raison) tombe en carafe. Cela dit, comme tous ces PluXml formeront ensemble une unité, il pourrait être intéressant de mutualiser certaines données tant internes (fichier css, plugin, ...) qu'externes (infos utilisateurs, uploads, commentaires, etc).

Je n'ai encore rien de précis en cours, c'est au stade de la réflexion, donc vous pouvez prendre votre temps pour répondre.

Merci, à plus,

Gzyg

Rubén · septembre 2015

J'ai du mal à saisir ton projet. Tu veux créer des sites miroirs ?

cpalo · septembre 2015

Bonjour,

Je l'ai fait avec deux pluxml dont un en sous-site.
Sur le forum il y a deux trois sujets sur la mise en commun de certains élements ( data, css,etc..)

http://forum.pluxml.org/viewtopic.php?id=4322

http://forum.pluxml.org/viewtopic.php?id=4397

Cordialement

Gzyg · septembre 2015

Ruben : non, pas de sites miroirs, juste scinder les parties d'un site pour les déplacer ou les rendre autonomes plus facilement.

cpalo : oui, ça je l'ai déjà fait aussi et c'est ma solution de secours, au cas où ce que je souhaite n'est pas réalisable (ou l'est hors de mes compétences).

Je souhaite que chaque PluXml conserve (sans les partager par le réglage adéquat dans le panneau d'administration) chacun leurs dossiers themes, plugins et data (et admin) justement pour pouvoir (au cas où) les rendre indépendants (les changer d'hébergeur ou de propriétaires).

Ce qu'il me fau(drai)t, c'est un "machin" qui irait récupérer les données de chacun des PluXml et qui serait capable de les redistribuer sur demande à n'importe quel autre PluXml.
Ainsi, en cas de désactivation d'un PluXml, il suffit de le débrancher du "machin" pour stopper l'échange de données.
Et de le faire fonctionner ailleurs avec juste ses propres données.

Peut-être que le machin en question serait une BDD ? Mais un truc simple genre sqlite (qui est intégrée à php et qui doit donc être utilisable sur tout hébergement php) ou un json ou autre chose... un "machin", quoi ! ]:D

Désolé pour le manque de précision (et/ou de clarté) mais je commence tout juste à réfléchir à ce projet et rien n'est encore vraiment fixé en terme de fonctionnalités.
"Brainstorm time", ensuite je ferais le tri entre ce que je suis capable [del]de comprendre[/del] de faire et le reste.

à plus,

Gzyg

Gari · septembre 2015

Tu veux plusieurs pluXml parfaitement étanches et cloisonnés, mais qui seraient tout de même capables de "partager" des données.
Autant je pige le côté "cloisonnement", autant j'ai du mal à voir ce que tu veux partager. Un cas d'utilisation, un exemple, seraient les bienvenus

On peut imaginer 3, 7, 23 pluXml bien différents (donc étanches) d'un côté et une sorte de page d'administration supra-pluXml de l'autre, qui permet de visualiser/déplacer/copier des ressources d'un pluXml à l'autre, le tout 100% manuel... C'est ça que tu veux ?

Draky · septembre 2015

Il veut peut-être parler d'un truc genre "WordPressMu" ?
Tu installes un WordPRess spécial sur ton hébergement, et les gens peuvent créer un compte et alors ils ont leur propre blog mais ce sont les mêmes fichiers WordPress pour chacun.
Par contre chaque utilisateur à ses propres fichiers pour les médias, images, etc.

Gzyg · septembre 2015

Draky : Pas tout à fait un WordPressMu. Je ne souhaite mutualiser que les données, justement pas les fichiers. Mais ça concernerait bien plusieurs utilisateurs (niveau éditeur voire admin).

Gari : c'est presque ça si tu enlèves cloisonnement.

À imaginer en pensant (à peu près) au système de franchisation pour les petits commerces mais sans "maison-mère" ou alors avoir un PluXml "factice" au-dessus des autres et sur lequel pointerait les différents dossiers themes, plugins et data des PluXml du dessous ?

Faudrait que je fasse un schéma... :rolleyes:

à plus,

Gzyg

kowalsky · septembre 2015

Gzyg a écrit:

Je souhaite que chaque PluXml conserve (sans les partager par le réglage adéquat dans le panneau d'administration) chacun leurs dossiers themes, plugins et data (et admin) justement pour pouvoir (au cas où) les rendre indépendants (les changer d'hébergeur ou de propriétaires).

La solution la plus simple suivant ce que tu indiques est de déplacer les répertoires thèmes et plugins dans le répertoire data.

Ensuite tu n'as plus qu'à changer l'emplacement de ceux-ci dans "Paramètres -> configuration avancée".

Emplacement des thèmes (dossier) : data/themes/
Emplacement des plugins (dossier) : data/plugins/

Ce qui fait que tu n'as plus qu'à récupérer le répertoire "data" pour mutualiser tout cela.

Tu peux aussi également renommer le répertoire "data" de chacun de tes sites (data01, data02, data03, etc.) ce qui te permettra de tous les sauvegarder au même endroit et de les rendre interchangeable rapidement en modifiant le fichier config.php à la racine du pluxml :

par défaut :
<?php
define('PLX_CONFIG_PATH', 'data/configuration/');
?>

pour site1 :
<?php
define('PLX_CONFIG_PATH', 'data01/configuration/');
?>

pour site2 :
<?php
define('PLX_CONFIG_PATH', 'data02/configuration/');
?>

etc.

Par contre cette méthode ne permet que d'afficher un seul site à la fois (sauf à créer des sous-domaines, mais là il s'agit encore d'une autre configuration)

Il n'est pas évident de saisir ta démarche car tu indiques que tu veux utiliser un seul "pluxml" pour faire tourner plusieurs "pluxml" et c'est là où tu nous perds dans ta demande : "pluxml" est un CMS généralement utilisé pour faire tourner un site unique. Tu veux faire du multi-sites sur un même hébergement ? Du multi-hébergements d'un même site ? Du multi-sites sur plusieurs hébergements ?

Gzyg · septembre 2015

Oui mais non

À priori, il ne devrait rien y avoir à déplacer. Chaque PluXml doit garder ses propres données. C'est ensuite le fameux "machin" qui ferait la collecte et la répartition à la demande. OK, ce n'est pas très clair.

Un schéma avec des exemples est en cours de préparation.

Merci en tout cas d'y avoir passé du temps.

à plus,

Gzyg

newic · septembre 2015

Un genre de réseau pair a pair décentralisé ?

Gzyg · septembre 2015

Non, pas un truc aussi gros.

En fait juste une base de données "simpliste" (mais xml ou sqlite) qui agrègerait (irait chercher) les données issues de chaque PluXml et qui les dispatcherait ensuite sur une forme de portail.
L'idée est surtout de "décentraliser" au maximum de façon à pouvoir, si besoin, "désolidariser" un PluXml sans intervenir sur chacun des autres.

Une sorte de Lego(R) mais avec des PluXml... ]:D

à plus,

Gzyg

newic · septembre 2015

L'idée est intéressante j'expérimente un truc dans le même esprit, sauf qu'il me semble que si tu utilises une base de données qui centralise tes autres services pour tes différentes communautés alors ton architecture n'est plus à la décentralisation et fragile.

Et tu es plutôt dans l'unification que dans la désolidarisation avec un soucis de préservation de l’indépendance des communautés/individus.

Enfin si j'ai bien compris ce que tu voulais faire, c'est très intéressant.

kowalsky · septembre 2015

@gzyg : à part le coup du "décentraliser" que je ne pige toujours pas

, le reste de ta description ressemble fortement au fonctionnement d'un Planet.

Gzyg · septembre 2015

@kowalsky : "planet" plus ou moins car, même s'ils y ont leur place, ce ne sont pas tant les flux rss des différents PluXml qui devront pouvoir être agrégés sur le "portail" mais plutôt leurs "méta données".

"Décentralisation" est employé par défaut est n'est pas forcément le bon concept, je te l'accorde. Schémas (et explications plus détaillées) en cours.

à plus,

Gzyg

cpalo · décembre 2015

Bonjour,

Je continue à avancer dans mon projet de sous-sites ou sous-domaines avec PluxXml ( promis, je ferai une synthèse, mais cela ne méritera pas le titre de tuto, quand j'aurai fini).
Rappel de la structure:
sitePrincipal (Pluxml)
data
articles
configuration
medias
statiques
sousSite (Pluxml)
data
articles
configuration
Après divers essais et réflexions, j'ai fait le choix que le site principal et le sous-site conservaient leur dossier configuration mais partageaient les mêmes dossiers data/medias et medias/statiques.
Lorsque je crée une nouvelle page statique, que ce soit à partir du site principal ou du sous-site, elle est bien enregistrée dans data/statiques.
Et, ce qui me paraît logique ( puisque le dossier configuration n'est pas partagé), c'est que ces nouvelles pages sont enregistrées dans le fichier configuration/statiques.xml correspondant au site principal ou sous-site suivant l'endroit où on l'a créée.
Pour qu'elles apparaissent dans l'autre site ou sous-site , il faut que je modifie manuellement l'autre fichier statiques.xml.
Je pensais ( mais donc à tort) que lorsqu'on était dans le panneau d'administration, dans la rubriques pages statiques, cela nous affichait toutes les pages statiques (fichier.php) présent dans le dossier data/statiques. mais ce n'est pas le cas.
Est-ce qu'il y aurait une solution pour que toutes les pages statiques présentes dans ce dossier apparaissent?
Cordialement

Scith · décembre 2015

J'ai tout lu mais j'ai moi non plus rien compris désolé ... Ce qui rend l'aide difficile.
Quelle est la finalité du projet concrètement au juste ? A quoi correspondent ces sous-sites ? Pourquoi ne pas juste avoir des PluXml complets à différents endroits (le core ne pesant qu'1mo) ?

Pour les pages statiques, elles sont en effet indexées dans un fichier, ce n'est pas une lecture de répertoire

cpalo · décembre 2015

Je ferai attention lorsque je me mettrai à réaliser la synthèse de tout ça pour être très explicite.

L'utilisation de sous-sites ou de sous-domaines, c'est le chef de projet web qui le détermine à partir de l'analyse des besoins et de la situation. Et chaque projet n'est jamais parfait et un autre chef de projet pourra avoir une autre approche.

Préalablement les termes:
on peut avoir accès au sous-site de deux manières suivant que l'on crée ou non un sousDomaine
http://domaineName/dossier-du-sousSite
http://sousDomaineName
et ils peuvent être complètement autonome du site principal (et effectivement aucun problème d'installer un Pluxmxl "entier") ou dépendant d'une partie du site-principal pour utiliser une partie commune ( et que lorsque on y apporte une modification, on ne la fait qu'une fois).
Exemple de l'utilisation d'un framework ( bootstrapp entre autres, mais que je n'utilise pas personnellement). On l'installe à la racine du site principal.; ce ne serait pas le plus judicieux de le réinstaller une seconde fois à la racine du sousDomaine. Donc autant le partager.
Pareil pour le dossier médias, car il peut y avoir des images ou des documents communs.

Alors pourquoi des sousDomaines ? pour une boutique, un espace privé, un forum, etc.; mais ce n'est qu'un des choix possibles et ce n'est pas forcément le meilleur.

Je vais prendre un exemple réel, celui d'un site associatif qui auparavant était sous Joomla avec trois espaces privés sous Agora-Project, et donc plusieurs bases de données ainsi que l'idée d'un forum. Lors de la refonte du site, et donc analyse des besoins et des ressources, Pluxml et muForum (cf sur le forum) sont apparues comme des outils suffisant.
Les trois espaces privés ( élus, formateurs, stagiaires) et le forum devaient conserver le style du site principal, avec quelques "customisation" bien sur: d'ou nécessité d'un lien avec le theme principal et le dossier common ( qui est "mon framework" perso).
De même , lorsque le programme de formation, ou des documents de stages, ou des projets éducatifs sont mis en ligne ou mis à jour sur le site, c'est plus judicieux qu'ils soient partagés ( car ainsi on est certain que le site et les sous-sites ont la même version) plutôt que les mettre en ligne dans un dossier média au sein de chaque sous-site.

Attention je précise:
Tous mes sous-sites sont des Pluxml "entier" avec le core. Mais ils partagent certains dossiers ( cf configuration avancée).

Projet : mutualiser des données entre plusieurs PluXml

Réponses