pages "posts" et "comments" sans contenu en cas d'erreur.

[Gvx]

En cas de génération d'une erreur par

$core->error->add()

la page "posts" génère les erreurs suivantes:

2015-08-16 11:11:37	WARNING	C:\wamp\www\dc2-unstable\admin\posts.php:244	in_array() expects parameter 2 to be array, null given	1	/dc2-unstable/admin/posts.php
2015-08-16 11:11:37	NOTICE	C:\wamp\www\dc2-unstable\admin\posts.php:244	Undefined variable: sortby_combo	1	/dc2-unstable/admin/posts.php

et la page "comments" reste blanche.

Le problème vient du fait que l'affichage ne se fait que s'il n'y a aucune erreur.

Dans le cas ou une erreur est générée avant les tests de la page, (par exemple un plugin) la page ne s'affiche pas ou génère des erreurs PHP

une solution pourrai être:

En début de page on compte le nombre d'erreurs (posts.php ou comments.php)

$error_count == count($core->error->getErrors())

et modifier le test comme suit:

if (!$core->error->flag() || $error_count == count($core->error->getErrors()))

[Gvx]

Euh...

Le test doit même pouvoir être simplifié comme suit:

if ($error_count == count($core->error->getErrors()))

[Gvx]

Dans le fichier post.php le test est fait 2 fois:

• a Creating filter combo boxes
• a l'affichage

[Gvx]

Autres pages concernées:

• pages.php
• blogs.php
• users.php

[Gvx]

Après réflexion, la solution proposée n'est pas pérenne dans le cas ou un callBehavior est intercalé.

Je pense qu'il va falloir utiliser une variable de status

[nikrou]

La vraie question est à mon sens : que veut-on afficher lorsqu'il y a une erreur, quelle qu'elle soit ? 1) une page sans contenu, juste avec l'erreur 2) une page la plus normale possible avec l'erreur

[Gvx]

En fait il y a deux notions:

• la gestion générale des erreurs qui sert principalement a affichage des erreurs
• la gestion d'erreur "locale" qui permet de prendre des décisions (affichage / non affichage etc...)

Hors dans ces pages on utilise la première notion pour la prise de décision de la seconde notion.

Une erreur informative dans un plugin ne doit pas empêcher l'affichage standard de la page.

Par exemple:
Si un plugin veux signifier par $core->error->add() qu'il manque un fichier et/ou un manque de droit et/ou ... cela ne doit pas empêcher l'affichage la page standard puisque cela n'as pas d'influence sur la page standard.

C'est au plugin de gérer l'affichage ou non de sa partie en fonction du contexte d'erreur, et non a la page de décider de ne rien afficher si une erreur hors contexte apparait

[bruno]

Dans la mesure ou on a un core->error dans la page, il est aussi possible qu'on ne puisse rien afficher du tout (ex : une exception levée lors du getPosts). Actuellement, les cas de figure ou on a un core->error :

• Une récupération des listes de base (catégorie, utilisateurs, langues, ...) échoue
• Une récupération des billets échoue
• Un plugin vient mettre la grouille dans un des 2 cas précédents

Dans ces 3 cas, on ne sait pas si on peut afficher quelque chose ou pas, je serais limite d'avis de patcher lesdits fichiers d'admin pour qu'ils affichent l'erreur, et un lien de retour vers l'accueil.

[Gvx]

Voir le Pull request proposé  https://bitbucket.org/dotclear/dotclear/pull-requests/99/specific-error-handling-fixes-2125/diff

• Qui corrige un problème d'initialisation dans post.php
• Ajoute un bouton retour a l’accueil
• Gère des contextes erreurs

[franck]

Si c'est encore pertinent, une PR sur le nouveau dépôt ( https://git.dotclear.org/dev/dotclear) sera la bienvenue !