Posted by EvanDonovan on March 26, 2009 at 6:35pm
| Project: | CustomError |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
It would be helpful if the error message that CustomError returns when Error Reporting is not set up properly would say how to fix the problem. Something like:
<?php
if (variable_get('site_' . $code, '') != 'customerror/' . $code) {
drupal_set_message(t('Error reporting is not set for error !error. Please ensure that the default !error page is set to be customerror/!error at !link.', array('!error' => $code, '!link' => l(t('here'), 'admin/settings/error-reporting'))), 'error');
}
?>
Comments
#1
Agreed. For example, we are using LoginToboggan, and 403 errors point to its "toboggan/denied" page. Which is not the CustomError page, and so it says "Error reporting is not set". Which confuses my users to no end, because there is "error reporting" set up - it's just not the CustomError flavor. Language that was a bit more specific, and more of a warning/notice, would be helpful. Like:
To use the CustomError settings for 403 errors, you must go to the Error Reporting page and set the path for 403 errors to "customerror/403"
or some such. I realize how difficult it is to write a universally unambiguous sentence.
Somewhat of a secondary issue: I noticed that if I removed all the values for 403 errors - no title, no text, nothing - I still get the "Error reporting is not set" message. You might consider removing it in that circumstance.
#2
sorry, thought it would just add the 5.x-1.2 version, not change the main one.
#3
No problem. I wish that this interface provided a way to indicate that an issue applies to multiple versions, especially when the module is essentially the same on 5.x and 6.x.
#4
It should EXPLICTLY SAY, you must go to
admin/settings/error-reporting
set the 403 error to
customerror/403
and set the 404 error to
customerror/404
or the module will not work. It might also be a nice touch to have a procedure that will do this for the user. I wasted quite some time trying to figure out what it wanted that page set to. Be specific in the message if it has to be a certain string, please.
#5
@verta: My code snippet from the original post fixes the issue. It would just need to be rolled into a patch. If anyone is interested in doing that, that would be great. As for me, I have stopped using the module, so I don't need it.
#6
Thanks for clarifying. I don't know how to roll a patch, but I do know how to apply them, so I can test it if someone will roll it ...
#7
this is the code from the original post - i made it a bit more verbose.
i've also attached the patch that we are using, in case it might be of use to people. it's more complicated, because it checks to see if you have tried to use Custom Error for a given code before it warns you that you are not using it correctly. so for instance if all the Custom Error 403 fields are empty, it does not warn you that error reporting is not set to customerror/403. when it does warn you, it also tells you what the current error reporting setting is.
#8
Committed the simpler version to the module.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.