WIP PR https://github.com/mantisbt/mantisbt/pull/2009

@dregad @vboctor
Before going on to work on this and changing a lot more places from string_display_line to string_attribute, I would like to be sure that I am not on a wrong track with this.

The change in terms of $g_html_valid_tags_single_line is clear and certainly what is wanted.
The change is also good in terms of performance, as

• there is no parsing for the $g_html_valid_tags_single_line
• there are no events triggered for plugins

But I am a bit worried, as the current code is used since many years (of course, not clean as string_attribute was already used at some places).
Do you agree that triggering the plugin event EVENT_DISPLAY_TEXT is not needed / wanted?

If yes, I would continue my work.

$g_html_valid_tags_single_line / string_display_line should just be considered for the values of

• Standard "Summary" field
• Custom field values of type String

I agree.

I can't think of any other places where string_display_line() should be used at the moment. We don't have so many free-text, single-line fields (os/os_build/platform, version fields), and even for those it does not necessarily make sense to allow formatting.

But I am a bit worried, as the current code is used since many years (of course, not clean as string_attribute was already used at some places).
Do you agree that triggering the plugin event EVENT_DISPLAY_TEXT is not needed / wanted?

Of course such change has the potential to introduce regressions for anyone expecting a field's value to be formatted, but I think that's an acceptable risk and we can always advise if and when someone complains.

years ago I made a plugin (it is not public and only used in our company) to change the display text of a custom field's name and with the now missing signal of EVENT_DISPLAY_TEXT it is not workig anymore. (updating from 2.25.1 to 2.27.1)
do you see any workarounds of this? I would really like not to use JS for this.

the function to replace the field's names is tied to that event and reads like this:

public function replace_custom_field_names($event, $original_text) {

        $display_text = $original_text;

        if(isset($this->all_custom_fields[$original_text])) {

            $custom_field = $this->all_custom_fields[$original_text];

            if (isset($custom_field["alternative_name"]) && $custom_field["alternative_name"] != "") {
                if($custom_field["alternative_name"] == "[blank]") {
                    $display_text = "";
                } else {
                    $display_text = $custom_field["alternative_name"];
                }
            }

        }

        // at customfield config page add the original name
        if(basename($_SERVER['SCRIPT_NAME']) == 'manage_custom_field_page.php' && $display_text != $original_text) {
            $display_text .= " (".$original_text.")";
        }

        // when there is nothing to replace, return original text
        return $display_text;

    }

@chadmiss

a plugin [...] to change the display text of a custom field's name

The official, recommended way of altering a plugin's display name (label) is documented in the Admin Guide
https://mantisbt.org/docs/master/en-US/Admin_Guide/html-desktop/#admin.customize.customfields.localize

I'm not sure why a plugin would be needed for this.

it is a historically grown function within my plugin (that manipulates the appearance of customfields much more than just changing the display name)
I don't think it is not necessary to re-add the event hook.

if someone else is looking for a similar solution in the future here is how I fixed it in my specific case:
now instead of using the hook EVENT_DISPLAY_TEXT I am using EVENT_CORE_READY to execute a function that manipulates the language vars:

    public function load_custom_strings() {

        require_api( 'lang_api.php' );
        global $g_lang_strings;
        $t_lang = lang_get_current();

        if( !isset( $g_lang_strings[$t_lang] ) ) {
            $g_lang_strings[$t_lang] = array();
        }

        $g_lang_strings[$t_lang][my_custom_field] = "new display text";

    }

thanks for pointing me in the right direction!

EDIT: formatting code is hard

the now missing signal of EVENT_DISPLAY_TEXT it is not workig anymore. (updating from 2.25.1 to 2.27.1)

Just for the record, this was introduced in 2.27.0 by 0034463