Compatibilité: l'argument {{{connect}}} a dû être rajouté à la fonction surchargeable '''styliser'''. Celle-ci avait déjà un argument supplémentaire optionnel, jamais utilisé, savoir la possibilité d'avoir un autre suffixe que '''.html''' pour les squelettes. L'argument optionnel {{{connect}}}, de plus grande utilité, vient s'intercaler avant lui. Rien de changé pour SPIP ni pour les extensions qui n'utilisaient pas ça (y en a-t-il qui le font ?).
Oui : Connexion · GitLab
Ce "fork" permet d'avoir des squelettes avec les extensions : 'css', 'js', 'svg', 'xml', 'htc', 'html', 'spip'
En pratique, je n'ai pour l'instant utilisé que css et js
Dans ta surcharge, tu ignores carrément cet argument, alors que l'incompatibilité viendrait au contraire d'une surcharge en amont, appelant cette fonction avec cet argument dont tu refuses meme qu'il soit fourni.
Compatibilité: l'argument {{{connect}}} a dû être rajouté à la fonction surchargeable '''styliser'''. Celle-ci avait déjà un argument supplémentaire optionnel, jamais utilisé, savoir la possibilité d'avoir un autre suffixe que '''.html''' pour les squelettes. L'argument optionnel {{{connect}}}, de plus grande utilité, vient s'intercaler avant lui. Rien de changé pour SPIP ni pour les extensions qui n'utilisaient pas ça (y en a-t-il qui le font ?).
Je continu ce fil, pour signaler que je n'arrive pas à voir cette fonctionnalité décrite :
Sans mutualisation sur /spip/ j'ai un titre :
SPIPAdmin petitions et le reste vide.
Avec mutualisation sur /spip/marcimat/ j'ai :
Erreur(s) dans le squelette
1 Aucun squelette 'petitions' n'est disponible... :mutualisation
2 Erreur de compilation
Evidemment, je suis loggué en webmaster sur les deux sites en questions... Il y a un truc qui m'échappe ?
Compatibilité: l'argument {{{connect}}} a dû être rajouté à la fonction surchargeable '''styliser'''. Celle-ci avait déjà un argument supplémentaire optionnel, jamais utilisé, savoir la possibilité d'avoir un autre suffixe que '''.html''' pour les squelettes. L'argument optionnel {{{connect}}}, de plus grande utilité, vient s'intercaler avant lui. Rien de changé pour SPIP ni pour les extensions qui n'utilisaient pas ça (y en a-t-il qui le font ?).
Je continu ce fil, pour signaler que je n'arrive pas à voir cette fonctionnalité décrite :
Sans mutualisation sur /spip/ j'ai un titre :
SPIPAdmin petitions et le reste vide.
Si tu as ce libellé, c'est qu'il a repéré la table. On dirait qu'il n'y a tout simplement pas de pétitions dans cette base.
Avec mutualisation sur /spip/marcimat/ j'ai :
Erreur(s) dans le squelette
1 Aucun squelette 'petitions' n'est disponible... :mutualisation
2 Erreur de compilation
Evidemment, je suis loggué en webmaster sur les deux sites en questions... Il y a un truc qui m'échappe ?
la connexion wemaster sur le 2e site n'est pas nécessaire, en revanche il faut que son fichier de connexion figure dans le répertoire config/ du site appelant, sous le nom que tu donnes à la variable d'URL "connect":
./?page=petitions&connect=autre ===> il existe config/autre.php contenant spip_connect_db(....'autre'...)
* Committo,Ergo:sum tapuscrivait, le 23/10/2007 19:00:
* esj@rezo.net tapuscrivait, le 23/10/2007 18:22:
Compatibilité: l'argument {{{connect}}} a dû être rajouté à la fonction surchargeable '''styliser'''. Celle-ci avait déjà un argument supplémentaire optionnel, jamais utilisé, savoir la possibilité d'avoir un autre suffixe que '''.html''' pour les squelettes. L'argument optionnel {{{connect}}}, de plus grande utilité, vient s'intercaler avant lui. Rien de changé pour SPIP ni pour les extensions qui n'utilisaient pas ça (y en a-t-il qui le font ?).
Dans ta surcharge, tu ignores carrément cet argument, alors que l'incompatibilité viendrait au contraire d'une surcharge en amont, appelant cette fonction avec cet argument dont tu refuses meme qu'il soit fourni.
Effectivement, de mémoire, pour toi cet argument est la grammaire SPIP à utiliser et il est identique à l'extension du squelette.
Alors que pour d'autre(s), il faudrait séparer grammaire à utiliser et extension, car l'extension donne l'éditeur ouvert au double clic dans les interfaces graphiques et assez souvent, la colloration syntaxique, voire les suggestions de code (intellisense).
ça fait 2 ans qu'on se traîne avec ce troll
Ce qui me semble certains, c'est qu'on a un élément (l'extension) qui est utilisé pour 2 usages différents l'un interne à SPIP (la grammaire) et l'autre externe à SPIP (la modification du code source d'un squelette).
Je continu ce fil, pour signaler que je n'arrive pas à voir cette fonctionnalité décrite :
Sans mutualisation sur /spip/ j'ai un titre :
SPIPAdmin petitions et le reste vide.
Si tu as ce libellé, c'est qu'il a repéré la table. On dirait qu'il n'y a tout simplement pas de pétitions dans cette base.
Ah, oui, ça c'est vrai, y'en a pas.
J'avais mal compris, je croyais que ça allait lister tout de même les noms des champs de la table genre 'id_petition','titre'... même s'il n'y a pas d'entrée dedans.
Avec mutualisation sur /spip/marcimat/ j'ai :
Erreur(s) dans le squelette
1 Aucun squelette 'petitions' n'est disponible... :mutualisation
2 Erreur de compilation
Evidemment, je suis loggué en webmaster sur les deux sites en questions... Il y a un truc qui m'échappe ?
la connexion wemaster sur le 2e site n'est pas nécessaire, en revanche il faut que son fichier de connexion figure dans le répertoire config/ du site appelant, sous le nom que tu donnes à la variable d'URL "connect":
./?page=petitions&connect=autre ===> il existe config/autre.php contenant spip_connect_db(....'autre'...)
Pardon, ce que je voulais dire, c'est que c'est un deuxième site automone, avec son propre connect.php (sites/marcimat/config/connect.php), sa propre base et donc sa propre table 'petitions'.
En fait, je m'attendais au même résultat au moins, à savoir avoir le titre et page blanche. Pourquoi alors ça met une erreur ici donc ?
J'avais mal compris, je croyais que ça allait lister tout de même les
noms des champs de la table genre 'id_petition','titre'... même s'il n'y
a pas d'entrée dedans.
j'ai rajouté un texte disant que la table est vide. C'est vrai qu'on pourrait faire mieux, mais je ne voudrais pas non plus trop charger ce qui n'est qu'une espèce de démo.
la connexion wemaster sur le 2e site n'est pas nécessaire, en
revanche il faut que son fichier de connexion figure dans le
répertoire config/ du site appelant, sous le nom que tu donnes à la
variable d'URL "connect":
./?page=petitions&connect=autre ===> il existe config/autre.php
contenant spip_connect_db(....'autre'...)
Pardon, ce que je voulais dire, c'est que c'est un deuxième site
automone, avec son propre connect.php
(sites/marcimat/config/connect.php), sa propre base et donc sa propre
table 'petitions'.
* Committo,Ergo:sum tapuscrivait, le 23/10/2007 19:00:
* esj@rezo.net tapuscrivait, le 23/10/2007 18:22:
Compatibilité: l'argument {{{connect}}} a dû être rajouté à la fonction surchargeable '''styliser'''. Celle-ci avait déjà un argument supplémentaire optionnel, jamais utilisé, savoir la possibilité d'avoir un autre suffixe que '''.html''' pour les squelettes. L'argument optionnel {{{connect}}}, de plus grande utilité, vient s'intercaler avant lui. Rien de changé pour SPIP ni pour les extensions qui n'utilisaient pas ça (y en a-t-il qui le font ?).
Dans ta surcharge, tu ignores carrément cet argument,
Oups, je l'avais pas vu passer le commit avec l'argument donnant la grammaire (pardon, l'extension) (pardon, les 2 mélangées).
alors que l'incompatibilité viendrait au contraire d'une surcharge en amont, appelant cette fonction avec cet argument dont tu refuses meme qu'il soit fourni.
C'était pas un refus, juste un commit que j'avais pas suivi (oups quoi).
Donc, le code proposé distingue maintenant l'extention de la grammaire.
Je m'en fiche qu'ils communiquent ou non entre eux, je veux juste tester la fonctionnalité sur leur base de donnée à eux qui n'est pas la même que le premier cité.
Mais si je vais sur http://zazen/spip/mon_site/?page=articles ou ?page=spip_articles bien... que des erreurs 404 alors que ce site a aussi des articles et des rubriques...
Mais comment veux-tu que le premier connaisse l'existe du second si tu ne lui dis pas ?
Meuh...
Je la refais, car on doit pas se comprendre.
J'ai un site spip dans http://zazen/spip/ qui a des articles et des rubriques (évidemment)
Si je fais sur les pages ?page=articles
Le log dit:
l'erreur de squelette indéfini n'est pas provoquée si le nom du squelette correspond à une table SQL connue dans la base interrogée.
si tu prends le nom d'un squelette existant, SPIP n'a pas de raison de provoquer cette erreur donc ne va mettre en route cette nouveauté qui n'aurait pas d'intérêt puisqu'il y a un squelette beaucoup mieux que celui minimal fourni à la volée.
C'est bien pour ça que je donnais plutot l'exemple de la table petitions. Mais tu peux prendre aussi ?page=meta par exemple.
Ah, ?page=meta, ça m'affiche des choses sur http://zazen/spip/ .
Enfin !
Mais : après le tableau de 10 entrées, il y a <h2 style="text-align: center;">vide</h2>
Par ailleurs, je n'ai pas de squelette ?page=articleS : il n'y a pas de articleS.html ni dans dist ni ailleurs...
Il y a un truc qui est bizarre non ?
En fait, il trouve bien la table ici, mais elle a une contrainte dure à respecter ! :
3 WHERE (articles.date = '2007-10-24 00:21:14')
4 AND (articles.date_redac = '2007-10-24 00:21:14')
