Needs work
Project:
Customerror
Version:
8.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Jan 2011 at 22:56 UTC
Updated:
10 Jan 2025 at 03:31 UTC
Jump to comment: Most recent
Comments
Comment #1
pawel_r commented+ 1
Comment #2
anil614sagar commentedComment #3
gisleNobody has worked on this issue for more than three years, and there does not seem to be much demand for this feature (currently, the issue has four followers).
One of the design objectives is to have a lean module, which means that not all feature requests will be honoured.
The current maintainer does not see a the benefit of being able to toggle the input format, so it is time to close this feature request.
Comment #4
mlncn commentedWould like to re-open the conversation on this functionality for Drupal 8— in particular in the context of dropping support for PHP. That is, I don't want to have a special case of allowing PHP code in the custom error text area when the contrib PHP Filter module (it's been thrown out of core, with prejudice) is enabled. But if we use Drupal's text format system, people who want to enable the PHP Filter module get this functionality for free— and of course the huge host of other capabilities built onto the text format system, including WYSIWYG, which is in core in Drupal 8, and so much more of an expectation for all text areas than was the case for past versions of Custom Error.
Comment #5
mlncn commentedMay want to make sure this, if implemented, is done with/compatible with #1430600: i18n support
Comment #6
_tarik_ commentedComment #8
_tarik_ commentedI changed field type for errors and fixed coding standarts
Comment #9
gisleWe need someone who wants this feature to review the MR.
Comment #10
mlncn commented@tarik thank you for the work and apologies for the two-years-late review. There were a lot of code style changes and improvements that will have to be handled separately from this change.
The decision taken in the code is to hard-code the format to
full_htmlwhich is defensible, but i don't think we can be guaranteed to have that format. Also existing messages need to remain as the default 'no-format' raw HTML.