Si surement aussi, mais si ils faut se baser sur l'extension xml de php ca réduit le public quand même

Mais je suis aussi fade d'aller chercher

Sorry pour le retard, beacoup de boulot au taf.

Alors dans le désordre;
le .htaccess
- les pattern ne vérifient pas la fin des url. Du coup, http://bepolytech.be/news.htmlblabla fonctionne également, mais aussi, et c'est plus gènant, http://bepolytech.be/news.html/blabla ce qui rend les chemin des images faux car ils sont en relatifs et non en absolu.

le fichier SQL
- un auto incrément de 4, totalement inutile.
- pas d'index sur pubdate alors qu'il y a une requète dessus.
- tous champs sont a NOT NULL, alors que selon les specs, seul title, link et description sont requis.
- tous les champs ont une default à '', ce qui est stupide si on considère qu'ils doivent être non nul. D'une part, s'il sont remplis grace à un formulaire html, les champs seront d'office initialisés, d'autre part, si c'est par requète SQL, cela implique de mettre explicitement default dans la query, ce qui est plus long à écrire que '', sinon on sort de la norme SQL.
- un longtext pour description, alors que le but du RSS est d'être LEGER...
- un varchar pour pubdate alors qu'il s'agit typiquement d'un timestamp ou d'un datetime, qui sont plus léger.

le php (news-rss.php)
- les paramètres de connexion ne sont pas centralisé, d'où multiplication dans les différents fichiers, et donc un risque d'erreur accru, lors de modification du mdp par exemple.
- un select * qui retourne TOUTE la table, donc le fichier rss va grossir comme une vache au fur et à mesure, devenir lourd à traiter pour le serveur et pour le client. Une simple clause LIMIT avec un ORDER BY ou, mieux, une selection des news n'exédant pas 5 jours aurait été tellement simple...
- un select max sur un champs non indexé, ce qui implique une aggrégation et un parcours complet de la table sur un champ texte. En plus selon les specs, il s'agit de la date de publication du channel, pas de la date de la news. Mettre l'heure courrante aurait été bien suffisant et plus léger à tout point de vue.
- des tests pour tous les champs alors que dans la table ils ne peuvent pas être nul. Et puis même s'ils pouvaient l'être, rien n'interdit dans le rdfs de rss de mettre des balises vides, ca économise du temps et le surpoids est négligeable.
- beaucoup trop de xml inclu dans le php. Au plus on écrit hors des balises php, au plus on soulage le serveur et on est rapide.

Et c'est du même acabis pour les autres fichiers php.

Y en a assez ou je continue avec la gestion des erreurs, inexistante?

Ca c'est du débrif..

Gizmo> Merci, au moins c'est détaillé, si c'est pas constructif ca

tuuuuuuuuuuuuuuuuuuuuut.....

comme dirait Brice de Nice, casséééééééééééé !

Grazie mille, Gizmo c'est clair que c'est constructif ca.
En effet beaucoup de lacunes et erreurs de gestion à corriger.
Je tâcherai d'être plus rigoureux et appliqué la prochaine fois ou prochaine version

++