ben ca c'est le problème...

mais tu ne dois certainement pas changer ces liens-là manuellement vu qu'ils sont générés automatiquement par le portail...

Donc si je comprends bien, une fois l'url-rw activé, tu peux accéder à livreor.htm mais pas à indexu.htm ?

Si la réponse est oui, dans ce cas j'exclus un problème dû au .htaccess. Je pencherais donc plutôt pour un problème que j'ai réglé pour la version 1.1 mais dont je ne me souviens plus de l'origine. Ou alors c'est tout autre chose.

Si la réponse est non, c'est peut-être un problème d'url-rewriting sur un serveur différent (encore un) de ceux sur lesquels j'ai pu tester le SWP.

Dans les deux cas, faudra qu'on s'organise une bouffe sur ton swp un de ces quatre. Comme ça tu relanceras l'url-rw pour que je voie de mes yeux le problème et puisse en relocaliser l'origine.

Dernier détail, les pages d'accueil de section peuvent être appelées via les adresses indexu.htm u_indexu.htm et index.php?niv=u Le petit message d'information sur index.php?page=pagesectionpost est effectivement problématique (c'est déjà réglé pour la version 1.1).

Et pour finir, les pages que tu as créées sont stockées dans la db (table swp_pagessections) et mises en cache dans des fichiers placés dans le dossier cache/. A chaque nouvelle publication de la page, la version en cache est mise à jour et remplace la précédente.

Ok..
j'ai saisi (en partie) mon problème... Si les autres pages fonctionnaient avec l'url-rewriting activé, c'est bien parce que les liens n'avaient pas changés. Je pensais que tous ces liens (ceux qui sont inhérent au swp et qui n'ont pas été créés par mes bon soins) fonctionnaient avec les adresses changées au type url-rewriting mais en fait, une fois l'url-rewriting activé, les liens restaient les mêmes, hormis ceux des pages de sections qui ont été créés par la suite, qui eux changeaient pour s'écrire du type url-rewriting.
Celà me faisait penser que l'url-rewriting fontionnait sur mon serveur, avec un stuud pour les pages créées..

J'ai essayé d'accéder à livreor.htm en tapant cette adresse et non en cliquant sur le lien (une fois l'url-machin activé) ainsi qu'a d'autres pages, mais à chaque fois c'était la page 404... Donc, en conclusion: pas d'url-rewriting chez moi...

Merci doc'

Voila qui clôt ce post

Petite note pour ceux qui souhaitent déterminer si oui ou non leur serveur accepte l'url-rewriting : Exécutez la fonction phpinfo(); sur votre serveur et cherchez dans la rubrique Apache la ligne Loaded Modules. Dans cette case regardez si l'expression mod_rewrite s'y trouve.

Si oui, vous pouvez activer l'url-rewriting.
Sinon, ben tant pis pour vous

Petite note en passant, si quelqu'un connait une fonction permettant de déterminer automatiquement si le module mod_rewrite est chargé, qu'il se dénonce... j'ai essayé avec extension_loaded() et ini_get() en vain.

Je me dénonce j'ai fini par trouver une idée. Je ne sais pas si c'est le moyen le plus efficace, mais au moins il fonctionne...

Voici la fonction que je me suis écrite :

Code :

function detect_urlrewriting()
{ // Détecte si l'url-rewriting est activé sur le serveur et renvoie true ou false
  // on met phpinfo() en mémoire tampon et on recherche la chaîne mod_rewrite
  // si elle est présente, le module d'url-rewriting est chargé.
    ob_start();
    phpinfo(); 
    $string = ob_get_contents();
    ob_end_clean();
    ob_end_flush();
    return preg_match('/mod_rewrite/', $string);
}

Edité par ChMat

Je remonte le fil juste pour signaler que si mod_rewrite n'est pas présent dans la liste des modules apache chargés, il vous reste encore une chance pour que l'url-rewriting soit activé. En effet, certaines versions de php fonctionnent en cgi et dans ce cas, mod_rewrite peut ne pas être indiqué dans la liste et fonctionner pourtant.

Enfin bref, si vous le souhaitez, un test d'évaluation de votre serveur pour swp est disponible dans la rubriques "distributions du portail" de la page Téléchargemens.