[MGNLSTK-752] Login form field labels are hardcoded Created: 09/Mar/11  Updated: 10/Oct/11  Resolved: 19/Aug/11

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: paragraphs
Affects Version/s: 1.4.2
Fix Version/s: 1.4.5

Type: Bug Priority: Major
Reporter: Magnolia International Assignee: Christian Ringele
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MGNLSTK-752.patch    
Issue Links:
causality
is causing MGNLSTK-798 Upgrade from Magnolia 4.4.1 to 4.4.5 ... Closed
relation
is related to MGNLSTK-729 Login form should not show up if the ... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Date of First Response:

 Description   

stkPURLogin.ftl is now much better (at last, I don't need to remember how the login field should be named!!), but users should still be able to customize (and translate!) the labels of the username and password fields. The submit button currently uses a resource bundle for its label, and arguably that should be editable by editors too.

This form also now suffers from the same inconviences noted by MGNLFORM-73/MGNLFORM-80: the marker and its description are hardcoded, and it's not possible to "hide" them.

Likewise, it has a formText property which is not used.

It's also fairly confusing that this specific form has an "edit" button, whereas all other forms have a "edit form settings" button.



 Comments   
Comment by Magnolia International [ 18/Mar/11 ]

Here's a patch that

  • shows the complete form, when in edit mode (so editors can see what they're editing despite being logged in)
  • shows the form title and text (only in the "login" part - perhaps the "logout" part would need its own title and text)
    (i.e it does not fulfill the problems raised in this issues entirely)
Comment by Magnolia International [ 22/Jun/11 ]

Using the regular form dialog would also kind of help here. Not sure why there still is a stkPurForm dialog AND a stkPurLoginForm dialog. The former uses the regular form dialog and adds one tab. The latter has only 2 fields, which are not "compatible" with the patch provided here.

Comment by Magnolia International [ 02/Aug/11 ]

The "login.infomessage" messages are a good idea, but their contents need to be reviewed: 1) the login form is not hidden in preview mode out of security reasons, but simply for consistency. 2) the line bits are most likely going to disrupt any and all layout. Worst case, you should use a <hr> tag, but I'm not even convinced about that. Not sure if we have a generic style for such "author information" (similar to the "unresolved link" case)

Good job on the update task, although you should use the appropriate InstallContext to get the module's config node rather than hardcode its path in there. The Javadoc should reflect what the update does (not necessarily in detail, the code is there for that) as well as the task name/description (it doesn't need to be passed as an argument, since there is one and only usage and use-case)

Lastly (pffewww), it is regrettable that the diff of the .ftl file is unreadable (the patch was!) - simply because indentation was modified so much in places unrelated to this issue. With other svn/diff tools, this can be read better (ignoring the whitespace doesn't seem to be an option on our svn-view), but it'd be good practice to keep unrelated code-style changes for separate revisions.

Comment by Christian Ringele [ 19/Aug/11 ]

Removed the security part.
I think p-tags are very unlikely to be design breakers, especially when fckContent is rendered in the paragraph 'header'. And if breaking design, you don't need to leave it turned on.

Thnx, noted.

Diff in Eclipse handles that quite well. But noted and will try to separate.

Comment by Christian Ringele [ 19/Aug/11 ]

Added render test.

Generated at Mon Feb 12 07:30:04 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.