As the UX-Team should provide Solutions i can't get enough Parameters. What Joomla need is more Layout for Parameters.

What Joomla need is more Layout for Parameters.

NOOOOOO.
What Joomla needs is this:
https://medium.com/@MIT5O5/solving-joomlas-ux-problems-88bcc8a0690c

With an implementation like:
https://medium.com/@MIT5O5/lets-build-it-then-ca6541b2cc93

to be continued …

@franz-wohlkoenig well for me it will be good if all these params were just discontinued ?

it should look like #14588 … thats why we have UX-Team :-)

Does the UX team even exist? No activity on their github issue tracker and no reports from them on the volunteer portal. Me thinks they are a mystical unicorn

Just FYI, this PR has absolutely nothing to do with the global parameters. It simply removes some of the params from mod_login.

i have been using pre text for years on multiligual sites by just creating a module per language. I am not in favour ofdropping this.

@infograf768 you can create an override, problem solved. Actually this wasn't a problem in the first place ?

pre text is NOT a parameter. It is a convenience.
can you explain to me how to create a module override for multilingual sites? with xml and layout? until now i thought we could only do it for the layout.

1. Create a module override
2. Add your pretext string <?php echo JText::_('MY_STRING'); ?>
3. Add this string in the Language Manager (overrides view)

Add your pretext string

that is such a simplification... thanks for your efforts... it will be a great help and make joomla great again... ?

Not sure whether or not you're being sarcastic, but ok

@C-Lodder @dgt41
I was being sarcastic...

Simplifying for the sake of simplification is not always the way to go.
Evidently, taking off the Tip Module must have a title for the Title of a module is indeed useless, but in this case here please consider this scenario:

With this PR, if a user wants a pre-text for some languages and not others, he would have to add such a code (see below) in an override + create all the lang strings + modify eventually when adding a new language + evidently make sure the module is tagged to ALL languages.

• ALSO eventually condition on Context if the module is loaded in an article for example (I would not know how to code that one) where the user would not need the pre-text, and this only for some languages.

It can become extremely complex and not for the basic user, thus reaching the opposite goal.

Here below ONLY for languages.

		<?php if (JLanguageMultilang::isEnabled()) : ?> 
			<?php $lang = JFactory::getApplication()->getLanguage()->getTag(); ?>
			<?php // Add below manually all content languages where the pretext should not display. ?>
			<?php if ($lang != 'fr-FR' && $lang != 'de-DE') : ?>
				<div class="pretext">
					<p><?php echo JText::_('LOGIN_PRETEXT_STRING'); ?></p>
				</div>
			<?php endif; ?>
		<?php endif; ?>

Honestly, instead of that type of "simplification", better concentrate on important stuff which is not working in mod_login and is working fine in 3.x, for example
3.x

4.0

And should be similar to the login menu item in 4.0

@C-Lodder delete Options and saying "make Override" ignores People without this Skills.

@infograf768 for the first part: sorry I don't follow your example and I strongly support the customisation been done in the overrides instead of the project adds unnecessary lines of code to cover each and every possible scenario.

For the second part: the failing part should be the modal field, will be fixed when we move the modals to the custom elements, so it can remain a plain input for the time being

@dgt41

I strongly support the customisation been done in the overrides

Please let me know how to differentiate the display of this module depending if it is used with {loadmodule etc.} in an article or as a standalone module.

I think you folks just forget basic users. These small lines of code just make it easier on them.

I think you folks just forget basic users.

I think we are confusing basic users with the super advanced users. By the way Joomla doesn't have to provide code for every possible scenario, there is JED for that!

Joomla for sure does not HAVE to provide for every possible scenario, but why take off what has always been considered as basic for the sake of doing it? Simple existing stuff should not require special JED stuff (without exclamation marks ? ).

In any case, I will not comment anymore here. My Donquichotism has limits.

@infograf768 - It's not "for the sake of it" at all. A lot of newbies find Joomla very overwhelming as there are so many options. When we first started working on the J4 templates in the private repo last year, one of the goals was to simplify Joomla as best we could, by removing useless parameters.

If it really means that much to you, I can re-add the pretext parameter

A lot of newbies find Joomla very overwhelming as there are so many options.

While that is certainly true, and I struggle sometimes myself, the parameters in mod_login aren't an issue. We have a whooping 9 parameters for that module and all of them are clear what they do. Those don't confuse any user.

The issue exists in other places, where you have a gazillion parameters spread over multiple tabs where it isn't even clear where to look for a specific parameter.

So be it. I'll re-add them back in, however I still removing "Display labels as text", as this should be the default and only way, for UX purposes. If users want to go against best practices, they can do a template override for that

@infograf768 done ;)

"Display labels as text" should be the default? I'm partial to displaying icons and placeholder text.

You're suggesting taking away options that aren't malfunctioning and nobody is complaining about.

J3.x

J4

This seems perfectly clear to me.

@stutteringp0et - I'm talking about removing an option which is bad UX practice. Forms should always have a label above the input, and NOT a placeholder. The password icon needs to be there as it's actually a feature that allows you to view your typed in password.

I think you're going to singlehandedly make 3rd party login modules popular again.

Isn't there a UX group that makes these design decisions?

This is not about design, this is about accessibility and @C-Lodder is right. At the end of the day joomla promised that v4 will meet WCAG AA level 2 specs, so...

WCAG AA level 2 does not require the field label to be visible

It's not even about a11y, but abouf UX. I believe we looked into this in London during the last sprint

I like the idea to make the layouts simpler. When we want to encourage people to do overrides for simple stuff like a pre text, then we should make the override management much more convenient. For example creating overrides per file and not whole view or showing the original file beside the edited one, even a diff would help here.

Also the detection during an upgrade that the layout override is not accurate anymore when the original file has changed should be supported. Otherwise we get into big trouble when we add new features to layouts.

basically, if we could at least also modify in overrides the xml file (in this case), simple stuff like this pre-text stuff would be much simpler.
the reason i insisted here to not delete this is also because we also have in mod_languages extremey useful pre-text field and taking it off here would be a precedent...
basically we should improve joomla and not systematically get rid of simple stuff which has proven its usefulness. there are other places which need a serious cure of fitness.