M in message should be capitalized.

@Quy will cappitalise the m in message once I figure out how to.

Joomla.renderMessages({ error: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);
Joomla.renderMessages({ danger: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);
Joomla.renderMessages({ message: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);
Joomla.renderMessages({ success: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);
Joomla.renderMessages({ warning: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);
Joomla.renderMessages({ notice: [Joomla.Text._('JGLOBAL_WARNCOOKIES')] }, undefined, false, 6000);

From the above, the only one that has a capitalised title is the error, so how sure how this works

@wilsonge @SharkyKZ perhaps one of you may know more about this.

The only alerts where the title's first letter is capitalised is an error. The language strings are defined here: https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/language/en-GB/joomla.ini#L42-L46

It means the JS string is missing. Add it using Text::script('MESSAGE');.

Please move plugins/user/token/src/Field/layouts/token.php outside of src directory.

@C-Lodder you need to add here

Text::script('ERROR');
Text::script('INFO');
Text::script('NOTICE');
Text::script('MESSAGE');
Text::script('WARNING');

@SharkyKZ Moved layout outside of src directory

Lang string fixed now, thanks.

Do we have other situations where a copy button would be useful for an input field? The base of the question is wouldn't it make more sense to have this as a parameter to our normal input field or use a more generic name instead of "token"?

I have tested this item ✅ successfully on e368ef8

Works as described.

If merged then the styling issue will need to be resolved - its a quick fix

As for using this functionality elsewhere - I am not aware of anywhere else that this would currently be useful.

I have tested this item ✅ successfully on e368ef8

RTC

Setting back to Pending. @Fedik's comment needs to be addressed.

I've added return parent::getInput();

If I use return $this->getRenderer('token')->render($this->getLayoutData()); in the getInput() method, the field doesn't get displayed.

This is done in other plugins too:

https://github.com/joomla/joomla-cms/blob/4.0-dev/plugins/user/terms/src/Field/TermsField.php#L46

https://github.com/joomla/joomla-cms/blob/4.0-dev/plugins/system/privacyconsent/src/Field/PrivacyField.php#L45

If I use return $this->getRenderer('token')->render($this->getLayoutData()); in the getInput() method, the field doesn't get displayed.

I suspect something mixed up with layout name and layout path, the rendered cannot find the layout, and so renders nothing.

This is done in other plugins too

That crazy, there also wrong ?
That need to fix someday by someone ?

All that need for render a custom layout is a property with layout name, no need override getInput().
so just

/**
 * Layout to render the form field
 *
 * @var  string
 */
protected $renderLayout = 'plugins.token.token';

Btw, the layout name for the token field will be plugins.token.token (not token)
and because of this, the method getLayoutPaths in this pull also incorrect, because it search for <base/template>layouts/token.php but should search for <base/template>layouts/plugins/token/token.php

And a default layout file itself need to be under layouts/plugins/token/token.php, not in plugins/user/token/layouts/token.php.

If it work as it is, it is good, but better if we make it correct, because other people will copy this for sure, and then show as "good example" ?

A bit later, I try to look in detail, and try to help.

Thanks Fedik, I'll look into it again today or tomorrow

Layouts can be in the plugin directory, as long as those paths are included. Either way works.

That is true. However I have seen that other core plugins use root /layouts/plugins/blabla,
I prefer to keep it consistent

@Fedik Updated the PR. Is that ok now?

Label is missing, layout is still broken and overrides don't work.

Looks good,

Now you can remove methods getInput(), getLayoutPaths(), getRenderer()
They will inherit from parent class, with the same functionality. That should fix override issue found by @SharkyKZ

I try to test this evening or next days

@C-Lodder see C-Lodder#14 for fixing label issues.

I have tested this item ✅ successfully on 38e9e03

I have tested this item ✅ successfully on 38e9e03

RTC

Thanks!