Bonsoir,
Je viens à peu près de finir d'écrire un plugin de facturation (que je
m'empresse de vous partager une fois les derniers problèmes résolus),
qui fonctionne très bien en local avec Garradin lancé sur le serveur
intégré de PHP.
Mais une fois envoyé sur l'instance de Garradin d'une asso sur un
serveur Apache : c'est la dégringolade.
Pas de problème pour l'installation du plugin, mais lorsque je tente
d'accéder aux pages du plugin, type /admin/plugin/facturation/, je me
retrouve avec une Internal Server Error.
Les logs d'Apache m'informent de ceci :
[Sat Nov 02 01:40:20.461776 2019] [core:error] [pid 2621] [client 89.234.176.119:47594]
AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration
error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use
'LogLevel debug' to get a backtrace.
[Sat Nov 02 01:40:20.461809 2019] [core:debug] [pid 2621] core.c(3829): [client
89.234.176.119:47594] AH00121: r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php.php.php
[Sat Nov 02 01:40:20.461836 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php.php
[Sat Nov 02 01:40:20.461865 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php
[Sat Nov 02 01:40:20.461893 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php
[Sat Nov 02 01:40:20.461921 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php
[Sat Nov 02 01:40:20.461949 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php
[Sat Nov 02 01:40:20.461977 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php
[Sat Nov 02 01:40:20.462009 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php
[Sat Nov 02 01:40:20.462037 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php
[Sat Nov 02 01:40:20.462064 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri = /admin/plugin/facturation/.php
[Sat Nov 02 01:40:20.462092 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri = /admin/plugin/facturation/
...ce qui me laisse effectivement penser que quelque chose ne va pas.
Lorsque je vais sur la page config.php du plugin, en revanche j'ai une erreur 403. Et
la raison à celle-ci est simplement que dans le fichier .htaccess à la racine de
Garradin, on trouve ceci :
RedirectMatch 403 /config\.(.*)\.php
Or, il est bien prévu que les plugins puisse avoir une page config.php
https://fossil.kd2.org/garradin/wiki?name=Plugins
(lorsque j'enlève cette règle, l'erreur 403 disparaît évidemment et laisse
apparaître la même Internal Error Server)
(et c'est un peu second problème pour lequel je devrais peut-être simplement ouvrir
un ticket sur fossil)
Donc je me pose la question, avant de commencer à analyser toutes les règles de
redirections de Garradi :
Existe-t-il des expériences « sérieuses » d'utilisation de Garradin avec des
plugins ?
Comme j'ai l'impression que les plugins ne sont pas quelque chose de très
développé pour le moment sur Garradin, je me demande si le développement de Garradin
vis à vis des plugins n'a pas encore vraiment eu l'occasion de passer par une
phase de test/debug et que je serais un peu la première personne confrontée à cela ?
Peut-être je me trompe, et le problème viendrait seulement de la configuration de mon
serveur..?
Quelqu'un·e aurait des pistes pour résoudre ça ? Pour l'instant je m'en
vais fouiller dans tous les .htaccess que je trouve
Mea culpa :)
J'avais quelques lignes en plus dans la config de vhost donnée sur le
wiki, et celles-ci étaient bien à propos de redirection/rewrite (je ne
sais plus ce qu'elles faisaient là).
(guère intéressant du coup, mais sait-on jamais :)
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule (.*) $1.php [L]
Néanmoins, en les supprimant, je résouds bien cette erreur absurde, mais
je récupère tout de même une erreur 404 en essayant d'aller sur les
pages du plugin (et elle me renvoie vers la 404 du reste du site, donc
peut-être elle est attrapée par une autre règle avant d'arriver à
Garradin ?)
En fait, Garradin n'est pas dans un vhost dédié à lui (qui serait sous
forme garradin.example.org) mais dans un "dossier" d'un site (donc sous
la forme example.org/admin).
J'écris ici car je patauge un peu et je ne sais pas si c'est une erreur
qui provient de Garradin ou non (le reste de l'installation Garradin
fonctionne sans soucis, alors je me questionne).
adresse riseup:
> Bonsoir,
>
> Je viens à peu près de finir d'écrire un plugin de facturation (que je
> m'empresse de vous partager une fois les derniers problèmes résolus),
> qui fonctionne très bien en local avec Garradin lancé sur le serveur
> intégré de PHP.
>
> Mais une fois envoyé sur l'instance de Garradin d'une asso sur un
> serveur Apache : c'est la dégringolade.
>
> Pas de problème pour l'installation du plugin, mais lorsque je tente
> d'accéder aux pages du plugin, type /admin/plugin/facturation/, je me
> retrouve avec une Internal Server Error.
>
> Les logs d'Apache m'informent de ceci :
>
> [Sat Nov 02 01:40:20.461776 2019] [core:error] [pid 2621] [client
89.234.176.119:47594] AH00124: Request exceeded the limit of 10 internal redirects due to
probable configuration error. Use 'LimitInternalRecursion' to increase the limit
if necessary. Use 'LogLevel debug' to get a backtrace.
> [Sat Nov 02 01:40:20.461809 2019] [core:debug] [pid 2621] core.c(3829): [client
89.234.176.119:47594] AH00121: r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php.php.php
> [Sat Nov 02 01:40:20.461836 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php.php
> [Sat Nov 02 01:40:20.461865 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php.php
> [Sat Nov 02 01:40:20.461893 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php.php
> [Sat Nov 02 01:40:20.461921 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php.php
> [Sat Nov 02 01:40:20.461949 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php.php
> [Sat Nov 02 01:40:20.461977 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php.php
> [Sat Nov 02 01:40:20.462009 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php.php
> [Sat Nov 02 01:40:20.462037 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php.php
> [Sat Nov 02 01:40:20.462064 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri =
/admin/plugin/facturation/.php
> [Sat Nov 02 01:40:20.462092 2019] [core:debug] [pid 2621] core.c(3836): [client
89.234.176.119:47594] AH00122: redirected from r->uri = /admin/plugin/facturation/
>
> ...ce qui me laisse effectivement penser que quelque chose ne va pas.
>
> Lorsque je vais sur la page config.php du plugin, en revanche j'ai une erreur
403. Et la raison à celle-ci est simplement que dans le fichier .htaccess à la racine de
Garradin, on trouve ceci :
> RedirectMatch 403 /config\.(.*)\.php
>
> Or, il est bien prévu que les plugins puisse avoir une page config.php
> https://fossil.kd2.org/garradin/wiki?name=Plugins
> (lorsque j'enlève cette règle, l'erreur 403 disparaît évidemment et
laisse apparaître la même Internal Error Server)
> (et c'est un peu second problème pour lequel je devrais peut-être
simplement ouvrir un ticket sur fossil)
>
> Donc je me pose la question, avant de commencer à analyser toutes les règles de
redirections de Garradi :
> Existe-t-il des expériences « sérieuses » d'utilisation de Garradin avec
des plugins ?
> Comme j'ai l'impression que les plugins ne sont pas quelque chose de
très développé pour le moment sur Garradin, je me demande si le développement de
Garradin vis à vis des plugins n'a pas encore vraiment eu l'occasion de passer
par une phase de test/debug et que je serais un peu la première personne confrontée à
cela ?
> Peut-être je me trompe, et le problème viendrait seulement de la configuration
de mon serveur..?
> Quelqu'un·e aurait des pistes pour résoudre ça ? Pour l'instant je
m'en vais fouiller dans tous les .htaccess que je trouve
>
Bon, excusez moi du spam, mais peut-être est-ce que ça en intéresse
certain·es :)
Je me suis penché du coup sur la différence quand Garradin est servi
avec le serveur PHP depuis la commande "make dev-server", et la
différence est l'usage du script routeur www/_route.php.
On y trouve cette règle concernant les plugins :
elseif (preg_match('!/admin/plugin/(.+?)/(.*)!', $uri, $match))
{
$_GET['_p'] = $match[1];
$_GET['_u'] = $match[2];
require __DIR__ . '/admin/plugin.php';
}
qui semble ne pas avoir d'équivalence dans la configuration Apache
fournie sur le wiki.
De là, j'ai pu extraire et tester une URI type
"admin/plugin.php?_p=facturation&_u=clients.php" qui pour le coup
fonctionne bien :)
Il me reste plus qu'à me creuser la tête pour réussir à écrire la règle
équivalente pour Apache... mais là aussi je patauge (j'ai toujours
galéré avec ça), si jamais quelqu'un·e ici est expert·e des RewriteCond
et RewriteRule... je prends !
adresse riseup:
> Mea culpa :)
>
> J'avais quelques lignes en plus dans la config de vhost donnée sur le
> wiki, et celles-ci étaient bien à propos de redirection/rewrite (je ne
> sais plus ce qu'elles faisaient là).
>
> (guère intéressant du coup, mais sait-on jamais :)
> RewriteCond %{REQUEST_FILENAME} !-d
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME}.php -f
> RewriteRule (.*) $1.php [L]
>
> Néanmoins, en les supprimant, je résouds bien cette erreur absurde, mais
> je récupère tout de même une erreur 404 en essayant d'aller sur les
> pages du plugin (et elle me renvoie vers la 404 du reste du site, donc
> peut-être elle est attrapée par une autre règle avant d'arriver à
> Garradin ?)
>
> En fait, Garradin n'est pas dans un vhost dédié à lui (qui serait sous
> forme garradin.example.org) mais dans un "dossier" d'un site (donc
sous
> la forme example.org/admin).
>
> J'écris ici car je patauge un peu et je ne sais pas si c'est une
erreur
> qui provient de Garradin ou non (le reste de l'installation Garradin
> fonctionne sans soucis, alors je me questionne).
Je m'excuse VRAIMENT pour le spam, mais cette fois c'est fini !
Juste pour dire :
Je pensais pas y arriver, et encore moins aussi rapidement, mais j'ai
réussi à écrire la règle qu'il fallait :
|RewriteEngine On RewriteCond %{REQUEST_URI} "/admin/plugin/(.+?)/(.*)"
RewriteRule (.*) /admin/plugin.php?_p=%1&_u=%2 [QSA,L] |
Je l'ai ajouté sur le Wiki, voilà, plus besoin de chercher, merci quand
même et déso pour ce patatra :)
Je vous récris bientôt pour vous partager mon petit plugin de facturation
Bonnes journées
adresse riseup:
> Bon, excusez moi du spam, mais peut-être est-ce que ça en intéresse
> certain·es :)
>
> Je me suis penché du coup sur la différence quand Garradin est servi
> avec le serveur PHP depuis la commande "make dev-server", et la
> différence est l'usage du script routeur www/_route.php.
>
> On y trouve cette règle concernant les plugins :
> elseif (preg_match('!/admin/plugin/(.+?)/(.*)!', $uri, $match))
> {
> $_GET['_p'] = $match[1];
> $_GET['_u'] = $match[2];
> require __DIR__ . '/admin/plugin.php';
> }
>
> qui semble ne pas avoir d'équivalence dans la configuration Apache
> fournie sur le wiki.
>
> De là, j'ai pu extraire et tester une URI type
> "admin/plugin.php?_p=facturation&_u=clients.php" qui pour le
coup
> fonctionne bien :)
>
> Il me reste plus qu'à me creuser la tête pour réussir à écrire la
> règle équivalente pour Apache... mais là aussi je patauge (j'ai
> toujours galéré avec ça), si jamais quelqu'un·e ici est expert·e des
> RewriteCond et RewriteRule... je prends !
>
j'adore du spam comme tu le fais :-D
Le 02/11/2019 à 04:04, adresse riseup a écrit :
> Je m'excuse VRAIMENT pour le spam, mais cette fois c'est fini !
>
> Juste pour dire :
> Je pensais pas y arriver, et encore moins aussi rapidement, mais j'ai
> réussi à écrire la règle qu'il fallait :
> |RewriteEngine On RewriteCond %{REQUEST_URI}
> "/admin/plugin/(.+?)/(.*)" RewriteRule (.*)
> /admin/plugin.php?_p=%1&_u=%2 [QSA,L] |
> Je l'ai ajouté sur le Wiki, voilà, plus besoin de chercher, merci
> quand même et déso pour ce patatra :)
> Je vous récris bientôt pour vous partager mon petit plugin de facturation
>
> Bonnes journées
>
>
> adresse riseup:
>> Bon, excusez moi du spam, mais peut-être est-ce que ça en intéresse
>> certain·es :)
>>
>> Je me suis penché du coup sur la différence quand Garradin est servi
>> avec le serveur PHP depuis la commande "make dev-server", et la
>> différence est l'usage du script routeur www/_route.php.
>>
>> On y trouve cette règle concernant les plugins :
>>
elseif (preg_match('!/admin/plugin/(.+?)/(.*)!', $uri, $match))
>> {
>> $_GET['_p'] = $match[1];
>> $_GET['_u'] = $match[2];
>> require__DIR__.'/admin/plugin.php';
>> }
>>
>> qui semble ne pas avoir d'équivalence dans la configuration Apache
>> fournie sur le wiki.
>>
>> De là, j'ai pu extraire et tester une URI type
>> "admin/plugin.php?_p=facturation&_u=clients.php" qui pour le
coup
>> fonctionne bien :)
>>
>> Il me reste plus qu'à me creuser la tête pour réussir à écrire la
>> règle équivalente pour Apache... mais là aussi je patauge (j'ai
>> toujours galéré avec ça), si jamais quelqu'un·e ici est expert·e des
>> RewriteCond et RewriteRule... je prends !
>>
>
Pour info ce tuto n'était pas à jour.
Tu peux virer ta RewriteRule. A la place le VHost doit ressembler à ça :
<VirttualHost *:80>
ServerName garradin.association.fr
DocumentRoot /var/www/garradin/www
FallbackResource /_route.php
DirectoryIndex disabled
DirectoryIndex index.php
<Directory /var/www/garradin>
Options None FollowSymLinks
AllowOverride None
Require all granted
</Directory>
</VirtualHost>
Ce qu'il faut retenir c'est le "FallbackResource /_route.php" qui va
rediriger vers /_route.php les requêtes vers les pages qui n'existent
pas.
Cette instruction est déjà présente dans le .htaccess et aurait donc dû
fonctionner dans ton cas ?
Mais du coup là je l'ai mis explicitement et désactivé le .htaccess
(AllowOverride All) qui réduit la surface d'attaque en cas de souci sur
Garradin, et surtout rends les requête plus rapides (car Apache ne vas
pas vérifier les fichiers .htaccess à chaque requête).
Contrairement à ce que disait le commentaire dans "_route.php", ce
fichier est utilisé pour router les requêtes dans tous les cas, serveur
web intégré à PHP, ou Apache, ou autre. Cette approche est plus
simple / solide que de faire des RewriteRule.
J'ai mis à jour le wiki en conséquence. Tiens moi au jus si ça
fonctionne comme ça pour toi :)
Merci encore,
pour vos indications,
mais la seule chose que je peux vous conseiller en la matière,
c’est de prendre connaissance de notre utilisation Garradin
et d’y regarder, car pour moi tout ce qui m’est raconté
c’est absolument de l’hébreu (si vous n'êtes pas antisémites)
ou du chinois (si vous êtes sinophiles), bref je n’y comprend rien.
Et dans l’association, nous sommes assez béotiens aussi
A bientôt si vous le voulez bien
ou si vous aves encore de la résistance.
Amicalement
Alain
> Le 3 nov. 2019 à 14:14, BohwaZ/Garradin <garradin@garradin.eu> a écrit :
>
>
> Pour info ce tuto n'était pas à jour.
>
> Tu peux virer ta RewriteRule. A la place le VHost doit ressembler à ça :
>
> <VirttualHost *:80>
> ServerName garradin.association.fr
> DocumentRoot /var/www/garradin/www
> FallbackResource /_route.php
> DirectoryIndex disabled
> DirectoryIndex index.php
>
> <Directory /var/www/garradin>
> Options None FollowSymLinks
> AllowOverride None
> Require all granted
> </Directory>
> </VirtualHost>
>
> Ce qu'il faut retenir c'est le "FallbackResource /_route.php"
qui va
> rediriger vers /_route.php les requêtes vers les pages qui n'existent
> pas.
>
> Cette instruction est déjà présente dans le .htaccess et aurait donc dû
> fonctionner dans ton cas ?
>
> Mais du coup là je l'ai mis explicitement et désactivé le .htaccess
> (AllowOverride All) qui réduit la surface d'attaque en cas de souci sur
> Garradin, et surtout rends les requête plus rapides (car Apache ne vas
> pas vérifier les fichiers .htaccess à chaque requête).
>
> Contrairement à ce que disait le commentaire dans "_route.php", ce
> fichier est utilisé pour router les requêtes dans tous les cas, serveur
> web intégré à PHP, ou Apache, ou autre. Cette approche est plus
> simple / solide que de faire des RewriteRule.
>
> J'ai mis à jour le wiki en conséquence. Tiens moi au jus si ça
> fonctionne comme ça pour toi :)
>
> --
> . ____
> / ___| Liste d'entraide des utilisateurs de Garradin
> | | _ http://garradin.eu/
> | |_| |
> \____| Désinscription : http://garradin.eu/aide/
Ahh, en effet, je connaissais pas ce système de FallbackResource.
Bon j'ai mis un peu de temps pour réussir à le faire fonctionner sur mon
install qui pointe direct vers www/admin/ et non pas vers www/, et le
temps de comprendre que FallbackResource demandait une URL et pas un
fichier (c'est ça de pas lire la doc en entier dès le premier coup)...
mais c'est tout bon, j'ai réussi à adapter le tout à mon conf et ça
fonctionne :)
Merci de tout ça !
BohwaZ/Garradin:
>
> Pour info ce tuto n'était pas à jour.
>
> Tu peux virer ta RewriteRule. A la place le VHost doit ressembler à ça :
>
> <VirttualHost *:80>
> ServerName garradin.association.fr
> DocumentRoot /var/www/garradin/www
> FallbackResource /_route.php
> DirectoryIndex disabled
> DirectoryIndex index.php
>
> <Directory /var/www/garradin>
> Options None FollowSymLinks
> AllowOverride None
> Require all granted
> </Directory>
> </VirtualHost>
>
> Ce qu'il faut retenir c'est le "FallbackResource /_route.php"
qui va
> rediriger vers /_route.php les requêtes vers les pages qui n'existent
> pas.
>
> Cette instruction est déjà présente dans le .htaccess et aurait donc dû
> fonctionner dans ton cas ?
>
> Mais du coup là je l'ai mis explicitement et désactivé le .htaccess
> (AllowOverride All) qui réduit la surface d'attaque en cas de souci sur
> Garradin, et surtout rends les requête plus rapides (car Apache ne vas
> pas vérifier les fichiers .htaccess à chaque requête).
>
> Contrairement à ce que disait le commentaire dans "_route.php", ce
> fichier est utilisé pour router les requêtes dans tous les cas, serveur
> web intégré à PHP, ou Apache, ou autre. Cette approche est plus
> simple / solide que de faire des RewriteRule.
>
> J'ai mis à jour le wiki en conséquence. Tiens moi au jus si ça
> fonctionne comme ça pour toi :)
>
Bonjour à vous,
Comment se sésinscrire de cette liste de diffusion?
Je n'en n'ai pas d'utilité pour le moment.
Bien cordialement
A
Le lun. 4 nov. 2019 à 01:48, adresse riseup <adresse@riseup.net> a écrit :
> Ahh, en effet, je connaissais pas ce système de FallbackResource.
>
> Bon j'ai mis un peu de temps pour réussir à le faire fonctionner sur
mon
> install qui pointe direct vers www/admin/ et non pas vers www/, et le
> temps de comprendre que FallbackResource demandait une URL et pas un
> fichier (c'est ça de pas lire la doc en entier dès le premier coup)...
> mais c'est tout bon, j'ai réussi à adapter le tout à mon conf et
ça
> fonctionne :)
>
> Merci de tout ça !
>
>
> BohwaZ/Garradin:
> >
> > Pour info ce tuto n'était pas à jour.
> >
> > Tu peux virer ta RewriteRule. A la place le VHost doit ressembler à ça
:
> >
> > <VirttualHost *:80>
> > ServerName garradin.association.fr
> > DocumentRoot /var/www/garradin/www
> > FallbackResource /_route.php
> > DirectoryIndex disabled
> > DirectoryIndex index.php
> >
> > <Directory /var/www/garradin>
> > Options None FollowSymLinks
> > AllowOverride None
> > Require all granted
> > </Directory>
> > </VirtualHost>
> >
> > Ce qu'il faut retenir c'est le "FallbackResource
/_route.php" qui va
> > rediriger vers /_route.php les requêtes vers les pages qui
n'existent
> > pas.
> >
> > Cette instruction est déjà présente dans le .htaccess et aurait donc
dû
> > fonctionner dans ton cas ?
> >
> > Mais du coup là je l'ai mis explicitement et désactivé le
.htaccess
> > (AllowOverride All) qui réduit la surface d'attaque en cas de souci
sur
> > Garradin, et surtout rends les requête plus rapides (car Apache ne vas
> > pas vérifier les fichiers .htaccess à chaque requête).
> >
> > Contrairement à ce que disait le commentaire dans "_route.php",
ce
> > fichier est utilisé pour router les requêtes dans tous les cas, serveur
> > web intégré à PHP, ou Apache, ou autre. Cette approche est plus
> > simple / solide que de faire des RewriteRule.
> >
> > J'ai mis à jour le wiki en conséquence. Tiens moi au jus si ça
> > fonctionne comme ça pour toi :)
> >
>
> --
> . ____
> / ___| Liste d'entraide des utilisateurs de Garradin
> | | _ http://garradin.eu/
> | |_| |
> \____| Désinscription : http://garradin.eu/aide/
>
C'est indiqué en bas de chaque email que tu reçois :
https://garradin.eu/aide/ tu remplis ton adresse et tu clique sur "me
désinscrire" ;)
merci.
Le lun. 4 nov. 2019 à 10:49, BohwaZ/Garradin <garradin@garradin.eu> a
écrit :
> C'est indiqué en bas de chaque email que tu reçois :
> https://garradin.eu/aide/ tu remplis ton adresse et tu clique sur "me
> désinscrire" ;)
>
> --
> . ____
> / ___| Liste d'entraide des utilisateurs de Garradin
> | | _ http://garradin.eu/
> | |_| |
> \____| Désinscription : http://garradin.eu/aide/
>
On Mon, 04 Nov 2019 00:48:00 +0000 / "adresse riseup"
<adresse@riseup.net> said :
> Ahh, en effet, je connaissais pas ce système de FallbackResource.
>
> Bon j'ai mis un peu de temps pour réussir à le faire fonctionner sur
> mon install qui pointe direct vers www/admin/ et non pas vers www/,
> et le temps de comprendre que FallbackResource demandait une URL et
> pas un fichier (c'est ça de pas lire la doc en entier dès le premier
> coup)... mais c'est tout bon, j'ai réussi à adapter le tout à mon
> conf et ça fonctionne :)
Ah effectivement ton fonctionnement de squeezer le /admin/ n'est pas
vraiment prévu (mais dans la config tu peux désactiver le site public,
ça laisse le /admin/ mais le site public n'apparaît plus), mais content
que ça marche :)
BohwaZ/Garradin:
> Ah effectivement ton fonctionnement de squeezer le /admin/ n'est pas
> vraiment prévu (mais dans la config tu peux désactiver le site public,
> ça laisse le /admin/ mais le site public n'apparaît plus), mais content
> que ça marche :)
Oui, je me suis rendu compte qu'après que ce qui était préconisé, et
pour une raison, c'était de le mettre tout dans un vhost pour lui.
C'est que dans ma conf le DocumentRoot était déjà utilisé pour autre
chose, et j'ai pas vu tout de suite de problème alors je suis resté
là-dessus.
Ce que j'ai fait c'est de faire un lien dans www/admin/ vers _route.php
(ou j'aurais pu le copier) et j'ai abouti sur cette petite modif qui
fonctionne très bien avoir passé un bon moment à me casser la tête :
if (file_exists(__DIR__ . $uri))
{
require __DIR__ . $uri.'index.php';
}
J'ai juste pas testé pour les adresses /f/* ce que ça donnait avec ma
configuration, j'imagine qu'il doit y avoir des problèmes mais pour
l'instant ça dérange pas.