Sous-sites chemin relatif pour les styles et scripts
Bonjour
Je viens de faire la maj 5.3 et pas de problème, et j'en profite donc pour modifier la structure de mon site.
En simplifiant j'ai:
mon site
---core
---css
commun.css
---data
---img
---js
---plugins
---themes
---defaut
---css
style.css
---img
---js
Les trois dossiers que j'ai rajoutés à la racine (css, img et js) sesont pour y mettre les fichiers communs à l'ensemble des sous-sites ,et donc aussi au thème défaut.
Dans la maquette j'ai la ligne
<!-- Feuille de styles génériques : commun à l'ensemble du site et des sous-sites -->
<link href="../css/commun.css" rel="stylesheet" />
Et ça fonctionne
Lorsque je transpose dans le site avec pluxml
<link rel="stylesheet" href="<?php $plxShow->template(); ?>../css/commun.css" media="screen"/>
Là ça ne fonctionne plus
Je voudrai garder un chemin relatif pour ne pas avoir à modifier lorsque je passerai du local sur le web, ou lorsque je ferai un autre site.
Problème ré-écriture d'url?
Merci d'avance
Cordialement
Je viens de faire la maj 5.3 et pas de problème, et j'en profite donc pour modifier la structure de mon site.
En simplifiant j'ai:
mon site
---core
---css
commun.css
---data
---img
---js
---plugins
---themes
---defaut
---css
style.css
---img
---js
Les trois dossiers que j'ai rajoutés à la racine (css, img et js) sesont pour y mettre les fichiers communs à l'ensemble des sous-sites ,et donc aussi au thème défaut.
Dans la maquette j'ai la ligne
<!-- Feuille de styles génériques : commun à l'ensemble du site et des sous-sites -->
<link href="../css/commun.css" rel="stylesheet" />
Et ça fonctionne
Lorsque je transpose dans le site avec pluxml
<link rel="stylesheet" href="<?php $plxShow->template(); ?>../css/commun.css" media="screen"/>
Là ça ne fonctionne plus
Je voudrai garder un chemin relatif pour ne pas avoir à modifier lorsque je passerai du local sur le web, ou lorsque je ferai un autre site.
Problème ré-écriture d'url?
Merci d'avance
Cordialement
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
$plxShow->template() récupère le nom de ton thème, il suffit juste de mettre dans cette syntaxe: Donc ré-écriture d'url ou pas tu n'auras pas a te soucier de modifier ton thème.
A+
mon site/ themes/defaut/css/style.css
et d'ailleurs c'est ce qu'il y a initialement dans le header du thème par defaut
et aucun problème.
Mais c'est pour accéder au:
mon site/css/commun.css
Lorsque j'ai simplement mon site sans installer pluxml, on y accéde par:
Comment est le reste de ta structure ? Où sont placés (et comment) tes "sous-sites"?
monsite
---core
---css
---data
---img
---js
---sous-site1
---sous-site2
---themes
Oui dans sous-site il y a l'index de la racine de pluxml.
Mais mon problème c'est aussi pour le site principal pour faire pointer le
<link rel="stylesheet" href="<?php $plxShow->template(); ?>../css/commun.css" media="screen"/>
qui ne fonctionne pas
Cordialement
Ce qu'il faut faire.
Tu installes un pluxml que l'on appellera Pprincipal. Tu places deux pluxml (entiers j’insiste) que l'on appellera Pun et Pdeux, à la racine de Pprincipal.
Tu te connectes à Pun, tu vas dans les paramètres avancés et tu mets comme emplacement du thème , comme emplacement des plugins , comme emplacement des images et comme emplacement des documents .
Puis tu fais de même avec Pdeux.
Ainsi, tout sera partagé entre tes différents sites (sauf les articles, les commentaires, les pages statiques et les configurations, mais rien ne t'empêches de les partager aussi) et tu n'auras que les dossiers du Pprincipal à gérer.
Pour accéder à Pun tu feras http://www.Pprincipal.org/Pun/ et pour Pdeux : http://www.Pprincipal.org/Pdeux/
Sinon, pour répondre à ta question pour accéder à css/commun.css, tu fait mais je te conseille plutôt de faire comme j'ai expliqué ci-dessus.
Merci.
Là je crois que maintenant plus d'excuses pour retravailler sur mes sous-sites.
Je ferai sans doute un mélange des deux suivant les situations.
Par contre pour acceder à css/commun.css, ce que tu m'as donné ne fonctionne pas.
Pour que cela fonctionne, il faut écrire:
Bon dimanche
Finalement j'ai fait un mixed de mon idée et de celle de Jerry par rapport au partage de dossiers communs.
Et ce qui m'a permis d'aboutir c'est la solution de Stephane par rapport à utiliser un menu complétement personnalisé et non celui automatique
ici
Pour l'instant j'ai fait l'essai avec un site principal et un sous-site (pluxml).
Tout fonctionne sauf le déplacement du dossier data/configuration vers ../data/configuration/boutique alors que pour tous les autres cela fonctionne sans problème.
"n'est pas accessible en écriture ou n'existe pas"
Je suis en local
Ce n'est pas tres grave. Mais pour la petite touche finale j'aurai bien aimé le faire ( sauf si c'est impossible).
Ma stucture du site
common regroupe les css, les images des thèmes, et les scripts communs au site et à tous les sous-sites
le theme du site et le thème du sous-site uniquement les fichiers spécifiques
ce que je n'ai pas encore tester c'est la navigation entre deux sous-sites ou avec un sous-site qui n'utilise pas pluxml
Par contre, je n'ai pas compris le déplacement de la configuration. Elle doit aller dans le sous-site boutique c'est ça ? Et elle est valable pour quel site ?
actuellement j'ai pour le site principal:
et pour le sous-site:
et j'aurai voulu avoir comme pour d'autres dossiers:
../data/sous-site/configuration
et c'est là que j'ai le message d'erreur en question
Je viens de faire un copier coller.;
mais j'ai le meme message d'erreur.
J'arrive presqu'au bout du projet ( si il y a une fin dans un projet web....), après avoir changé plusieurs fois .
La structure du site:
site-principal
common
core
data
configuration
configuration-subsite
etc ...
plugin
subsite
core
themes
theme-principal
theme-subsite
Dans le panneau d'administration du sous-site:
../themes/
../plugins
../data
et ça fonctionne.
Dans le header.php du subsite:
Mais dans le navigateur, en affichant le code source:
Alors que je pensais qu'on aurait du avoir:
Cordialement
<?php $plxShow->template(); ?>
quand on y fait référence dans le header.php, en plus d'y inclure toutes les autres lignes spécifiques au thème juste en-dessous (avec leur hook bien en place).
C'est surtout inhabituel de forcer le domaine absolu (127.0.0.1) dans un adressage. Si le serveur est bien monté, autant local que partagé, tu devrais n'avoir à commencer qu'après le "cahue-net/" et le site sera 100% transportable et recopiable autant de fois que désiré sans le moindre changement. Tu pourras même en profiter pour passer à la dernière version de Pluxml.
Si ton serveur local est un genre de WAMP (ou uWamp, mon préféré), c'est encore plus facile à gérer et à tester avant le grand déménagement.
Bonne chance
J'utilise Xampp.
Je n'ai pas forcé l'adressage du domaine absolu. J'ai conservé le code par défaut de pluxml. Mais là , petite erreur, j'ai appelé le site en tapant 127.0.0.1 dans le navigateur et en allant ouvrir le site via le parcours des dossiers.
Sinon j'ai créé des "domaines locaux" , ( dans cet exemple: local-cahue.net) et lorsque je tape l'adresse dans le navigateur j'obtiens local-cahue.net/ ou local-cahue.net/subsite/..
Et effectivement je n'ai aucun problème pour les copies ou transfert ftp, ou les mises à jour de Pluxml en local.
Pour la structure du site, j'ai changé plusieurs fois.
Le dossier data est partagé car les pages statiques et les médias sont partagés, et cela permet d'avoir un seul dossier à sauvegarder et non pas plusieurs (un principal et un par sous-site). Le dossier plugins est également partagé mais les dossiers de configuration sont différents (site principal et sous-sites) permettant de les activer ou paramétrer différemment.
Le dossier common: le mettre à la racine ou dans le dossier thèmes? J'ai souvent hésité et changé. Finalement je suis revenu à mon idée première en le remettant à la racine, comme souvent pour un framework (cf bootstrap).
La question que je me pose, et que je voulais comprendre, voire corriger, c'est dans l'affichage du chemin du fichier appelé par <?php $plxShow->template(); ?> ou par <?php $plxShow->urlRewrite(); ?> ce /../ après subsite. Mais c'est peut être normal et ça n'empêche peut être pas le "bon" fonctionnement. Dans mon cas le lien avec les feuilles de style en question fonctionnent, mais à vérifier pour les autres liens.
Cordialement
Le principe du hook est simple, en écrivant <?php $plxShow->template(); ?> avant le nom du CSS, ça voudra dire que Pluxml doit regarder sa configuration , voir quel thème est sélectionné, et se placer au niveau de ce thème pour continuer. On peut alors y préciser si on pointe vers un sous-répertoire ou l'autre (CSS, JS, etc). Si ce hook n'est pas là, le chemin commence au premier niveau racine de Pluxml, le rewrite c'est une toute autre chose et je ne vois aucun exemple où ça serait utile ici. Pluxml utilise beaucoup de rewrites dans ses fonctions, c'est normal, mais nos pages sont installées dans un répertoire ou un autre, sans manipuler leur nomenclature. On peut même choisir la réécriture des url dans la configuration. Il nous faudrait un exemple d'un problème à régler pour voir si c'est la seule solution, je n'en vois pas.
Retour sur les 127.0.0.1, il faut réussir à faire tout fonctionner en les enlevant, avant de penser à déménager. Jette un coup d'oeil à une fraîche installation de la dernière version, tu n'y verra pas de "http://...", tout est adressé dynamiquement. C'est la garantie que le déménagement ne va pas tout foutre en l'air.
La structure locale et les sous répertoires n'y changeront rien, l'installation se fait à partir d'une racine présente dans la configuration, tout pat de là. Règle générale, les sous-répertoires installés à la racine sont adressés directement, les autres sont dans le répertoire du thème parce qu'ils s'y rapportent, surtout les CSS cosmétiques. Parfois on peut partager les grand classiques comme les jquery de ce monde, mais l'économie n'en vaut probablement pas la peine.
Oui cpalo, uWamp, j'ai trouvé par accident en fouillant pour une solution portative de petite taille. Sa grande vertu est qu'il ne nécessite aucune installation, on copie les fichiers, on trouve le exe et ça démarre. On éteint tout, rien ne reste en mémoire ou en conflit avec autre chose qui voudrait occuper le port 80. C'est même plus pratique, je trouve, que les Portableapps qui sont déjà un peu plus accaparants.
domaine.fr/sous-site/dossier-interieur/page.php
domaine.fr/sous-site/../dossier-exterieur/page.php
et à la place de <?php $plxShow->urlRewrite(); ?> je pensais alors utiliser <?php $plxShow->racine(); ?>
Le problème technique est très facile à régler mais ça ne répond tout de même pas à mon interogation, un peu le "modèle d'affaire" de ce que l'on tente d'accomplir ici.
Parce qu'on s'entend, installer Pluxml 3 fois et lui faire pointer ses fichiers de configuration tous au même endroit, ça devient l'idée qui règlera tous ces cauchemars. Notre CMS chéri est tellement petit, léger et sans contraintes, on ne parle tout de même pas d'installations multiples de Wordpress ici, on peut mettre une douzaine de Pluxml sur une clé USB.
Alors, le seul hook à utiliser c'est le $plxShow->template() pour les choses propres à un thème , pour tout le reste, aucun hook et le répertoire installé en racine, c'est tout.
Et si l'idée de l'installation multiple (complète) de PLuxml est retenue, alors là les références directes (http://...) ou racine() pourront venir centraliser les CSS, JS "à l'extérieur" de toutes les installations de Pluxml.
On peut accéder à un sous-domaine de deux manières différentes:
http://domaineName.net/dossier-subsite
ou
http://sousdomaineName.net
le dossier-subsite correspond à un pluxml installé où la configuration a été modifiée avec en particulier : ../themes/
ce dossier themes est à la racine du pluxml principal
le code du header du soussite:
Dans le premier cas les liens fonctionnent bien, mais pas dans le second. Ce qui n'est pas étonnant puisqu'il considère alors que la racine est celle du sous-domaine .
Est-ce qu'il y aurait une solution ( excepté de ne pas créer de sous-domaine, et d'appeler le sousite par la première méthode?) pour que les deux méthodes d'appel fonctionnent?
@Pierre Je ne suis pas dans cette option. Ce sont les plugins, les medias et certaines pages statiques ( par exemple les mentions légales) qui sont partagés et c'est aussi permettre des configurations différentes.
Des exemples:
- un site avec une boutique comme sous-site
- un site associatif avec trois espaces privés (élus, formateurs, stagiaires) et un forum (muforum)
- un site de développement où les sous-sites sont des thèmes en développement et qui partagent donc des data-exemples
Cordialement
Actuellement le sous-site est un pluxml installé dans le site principal pluxml
- site-principal
--- data
--- themes
--- sous-site
Tu me proposes donc de l'installer au même niveau que le principal ?
- site principal
- sous-site
Ou même:
- répertoire principal
--- data
--- themes
--- site principal
--- sous-site
Mon idée est d'oublier en premier lieu les histoires de niveaux et de sous-machins par rapport aux machins principaux. L'hypothèse de base est d'installer tous les sites de façon indépendante et autonome. Où elles sont l'une par rapport à l'autre n'a aucune importance, je suggère de toutes les mettre au même niveau, ça simplifiera les choses plus tard.
Ensuite, l'une des installation sera "déclarée" comme la source des données, de la configuration partielle ou totale, les CSS, JS, images génériques, etc. Bref, on installe les morceaux à partager dans celle-ci.
Dans chacune des autres installations, on fait une première opération d'aller à la page d'admin, section de configuration avancée, pour faire pointer vers les répertoires partagés (c'est l'heure des ../../).
Je confesse n'avoir jamais partagé des répertoires de cette façon, les experts de Pluxml vont nous confirmer si la théorie peut affronter la pratique. Mes essais se sont limités à partager des fichiers de CSS, de JS et d'images génériques (pas reliées par le plugin Vignette) entre quelques sites "autonomes". Cette méthode est très facile, tout se fait dans le fichier header.php et le tour est joué. Les répertoires en question pourraient même se trouver sur un autre serveur à l'autre bout du monde, on utiliserait alors le http pour y pointer.
C'est ma théorie, elle a le mérite de se tester rapidement, même avec deux installations toutes neuves si on ne veut rien bousiller.
Je vais tester cela et je reviendrai faire un retour d'expérience.
Je confirme donc , et ce dans les deux cas de figure site et sous-site au même niveau ou imbriqués.
Dans le panneau d'administration, aucun problèmes les ../ ou ./../ sont bien pris en compte et on visualise bien le dossier themes ainsi visé.
Lorsqu'on passe à la visualisation du site:
Si on accède au site ou au sous-site par leur nom de domaine, là il y a problème. Ce n'est pas pris en compte mais pas forcément étonnant ( cf PLX_ROOT)
Par contre si on y accéde par le chemin du serveur ( en local 127.0.0.1/site-principal/sous-site), là ça fonctionne.