Bug #31951

Own checkbox layout breaks HTML mail

Added by Michael Feinbier over 10 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2011-11-20
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hey,

I configured a form with 2 Checkbox groups. In the example shown on the screens below I only checked item 1 and item 3 of the first Checkgroup.
This is fine so far.

But if I try to rewrite the layout for checkboxes via

checkbox (
            <input />
            <label />
        )

The HTML part of the sent mail breaks totally. It seems, that the <input /> isn't replaced with an empty string or what else. The two screenshots show the correct rendering and the wrong rendering with own checkbox layout. Both form had the same state (item1 and item3 as explained above)

The HTML of the mail in the broken example is as follows (excerpt):

<table cellspacing=3D"0">

      <tbody>
        <tr>
     =
     <td colspan=3D"2">
            <table cellspacing=3D"0" style=3D"=
padding-left: 20px; margin-bottom: 20px;">
              <thead>=

                <tr>
                  <th colspan=3D"2" alig=
n=3D"left">Ich interessiere mich f=C3=BCr</th>
                </tr>=

              </thead>
              <tbody>
           =
     <tr>
                  <input/>
                  <em>item1=
</em>
                </tr>
                <tr>
         =
         <input/>
                  <em>item2</em>
             =
   </tr>
                <tr>
                  <input/>
   =
               <em>item3</em>
                </tr>
             =
 </tbody>
            </table>
          </td>


Files

forms-checkbox-working.png (48.7 KB) forms-checkbox-working.png Working HTML Mail Michael Feinbier, 2011-11-20 13:02
forms-checkbox-broken.png (70.5 KB) forms-checkbox-broken.png Broken HTML rendering with own checkbox layout Michael Feinbier, 2011-11-20 13:02
broken_form.jpg (15.7 KB) broken_form.jpg Toni no-lastname-given, 2014-05-06 13:39
form_using_different_layouts.diff (6.54 KB) form_using_different_layouts.diff Cornel Boppart, 2014-05-28 08:08

Related issues

Related to TYPO3 Core - Bug #32463: New Form ext throws error on missing wrapsClosed2011-12-12

Actions
Related to TYPO3 Core - Bug #37349: Layout change modifies email outputClosed2012-05-21

Actions
Related to TYPO3 Core - Bug #39138: sysEXT:form checkbox send as input field in EMailClosedPatrick Broens2012-07-20

Actions
Related to TYPO3 Core - Bug #58598: tx_form breaks on custom labelClosed2014-05-07

Actions
Related to TYPO3 Core - Bug #45606: Forms: Mail-Layout destroyedClosed2013-02-19

Actions
Related to TYPO3 Core - Bug #42500: Sysext form output not adjustable via ts in 4.7.5Closed2012-10-29

Actions
Related to TYPO3 Core - Bug #60995: tx_form PostProcessor - wrong layout handlingClosed2014-08-15

Actions
Related to TYPO3 Core - Bug #70086: EXT:form - Bring back view specific layout settingsClosedRalf Zimmermann2015-09-24

Actions
Has duplicate TYPO3 Core - Bug #57830: Mailform Closed2014-04-11

Actions
Precedes TYPO3 Core - Bug #59549: Broken tests due to modified PostProcessor constructorClosed2014-06-13

Actions
#1

Updated by Jigal van Hemert over 10 years ago

  • Status changed from New to Needs Feedback

As far as I can determine it should be <inputvalue /> instead of <input />. Can you test this?

#2

Updated by Michael Feinbier over 10 years ago

I did the layout override because I wanted in the form the input before the label. According to the manual this is the correct way. If i use <inputvalue /> no Checkbox is rendered in the form.

#3

Updated by Christjan Grabowski over 10 years ago

Same Problem:

tt_content.mailform.20 {
    layout {
        radio (
            <input /><label />
        )
        checkbox (
            <input /><label />
        )
    }
}

FE-Rendering of the form is correct. The email after submit does not contain the selected options. Instead there are rendered input fields.

Typo3 4.6.3

#4

Updated by Franz Koch about 10 years ago

this issue is related to #32463 - custom layouts a) can cause exceptions and b) bork your html mail layout. Solution is described in #32463

#5

Updated by Alexander Opitz over 8 years ago

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.1)?

Or is this a duplicate of #32463 ?

#6

Updated by Leon de Rijke over 8 years ago

I can confirm this issue still exists with 6.1.5:

tt_content.mailform.20 {
    layout {
        checkbox = <input /><label/>
    }
}

Front-end rendering is correct. The email contains rendered input fields.

#7

Updated by Leon de Rijke over 8 years ago

Alexander Opitz wrote:

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.1)?

Or is this a duplicate of #32463 ?

Although this issue is related to #32463, I don't think it is a duplicate. #32463 deals with a fatal error, this issue deals with borked HTML mail output. Maybe the solution would be the same.

#8

Updated by Alexander Opitz over 8 years ago

  • Status changed from Needs Feedback to New
  • Is Regression set to No
#9

Updated by Felix Nagel about 8 years ago

I can confirm this issue in TYPO3 4.7.17.

#10

Updated by Ben Walch about 8 years ago

This issue still exists with 6.2.beta:

tt_content {
    mailform.20 {
        layout {
            form (
                <form role="form">
                    <containerWrap />
                </form>
            )
            containerWrap (
                <div class="csc-mailform-container">
                    <elements />
                </div>
            )
            elementWrap (
                <div class="form-group">
                    <element />
                </div>
            )
            textline (
                <label />
                <input class="form-control" />
            )
            textarea (
                <label />
                <textarea class="form-control" />
            )
            textblock (
                <p class="help-block">
                    <textblock />
                </p>
            )
            submit (
                <input class="btn btn-primary" />
            )
        }
    }
}

This layout example above to have nice bootstrap-like form elements will brake the Html Mail Message.
Following the Manual, the tt_content.mailform.20.layout TypoScript is a layout definition (override) for the Frontend which works like a charm..
The bad thing is, that the AbstractElementView.php in form/Classes/View/Mail/Html/Element also respects a layout override for the frontend like above to render the HTML Code for the mail message.

This is a serious problem. The solution should be simple:
give the opportunity to define different layouts for the frontend as well as for the html mail, like

tt_content {
    mailform.20 {
        # Layout Override for the Frontend HTML View
        form {
            layout {
                elementWrap (
                    ...
                )
            }
        }
        # Layout Override for the HTML Mail Message
        mail {
            layout {
                elementWrap (
                    ...
                )
            }
        }
    }
}
#11

Updated by Gerrit Code Review about 8 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#12

Updated by Anja Leichsenring about 8 years ago

  • TYPO3 Version changed from 4.6 to 6.2
  • PHP Version deleted (5.3)

Sorry to say this, but the patch does not solve the issue. Please provide
the form configuration of your form, the typoscript of your overridden layout and maybe some thoughts, how you developed the solution provided here, to get me in the right direction.

Additionally this means (probably) a breaking change to existing form configurations, and this is something that we need to avoid.

#13

Updated by Benjamin Kott about 8 years ago

From my point of view and different testcases the layouts are not useable at all in its current state so whatever gets decided how to solve this problem it will not break any functionality somewhere.

The only way to get the ext:form working correctly at its current state is to xclass every view model and change the default layout directly in the model.

Views in 6.2
- Form (uses layout)
- Confirmation (uses layout)
- Mail (is a postProcessor)
-- Html (uses layout)
-- Plain (does not use layouts)

Example Default Layouts why the system breaks:

TextlineElementView (Form)

    <label />
    <input />

TextlineElementView (Confirmation)

    <label />
    <inputvalue />

TextlineElementView (Mail/Html)

    <td style="width: 200px;">
        <label />
    </td>
    <td>
        <inputvalue />
    </td>

The problem here is when you try to what the different views do not support all elements in its parseXML functions,
for example the <input /> is not handled by the confirmation or the mail views under certain conditions the system then will break.

An example of an breaking ext:form configuration can be found in the bootstrap_package that comes with the introduction distribution.

tt_content.mailform.20 {
    layout {
        form (
            <form class="form-horizontal">
                <containerWrap />
            </form>
        )
        containerWrap (
            <div>
                <elements />                
            </div>
        )
        elementWrap (
            <div>      
                <element />
            </div>
        )
        fieldset (
            <fieldset><legend /><containerWrap /></fieldset>    
        )
        label (
            <label>
                <labelvalue />
                <mandatory />
            </label>
    )
        error (
            <span class="help-block text-danger"><errorvalue /></span>
        )

        textline (
            <div class="form-group">
                <div class="col-sm-3 control-label">
                    <label />
                </div>
                <div class="col-sm-5">
                    <input class="form-control" />
                    <error />
                </div>
            </div>
        )
        textarea (
            <div class="form-group">
                <div class="col-sm-3 control-label">
                    <label />
                </div>
                <div class="col-sm-5">
                    <textarea class="form-control" />
                    <error />
                </div>
            </div>
        )
        submit (
            <div class="form-group">
        <div class="col-sm-offset-3 col-sm-9">
                    <input class="btn btn-primary" />
        </div>
            </div>
        )
        checkbox (
            <div class="form-group">
        <div class="col-sm-offset-3 col-sm-9">
                    <div class="checkbox">
                        <input />
                        <label />
                    </div>
                    <error />
        </div>
            </div>
        )
    }
    stdWrap.wrap = |
}

Suggestion:
Introduce new strict seperation for the form layout and correct the typoscript settings for this.

- form.layout used only for form
- confirmation.layout used only for confirmation
- postProcessorDefaults.mail.layout used only for postprocessor mail layout
- postProcessorDefaults.Vendor\ExtensionKey\PostProcess\CustomPostProcessor.layout for example usage in custom postprocessor

Map current layout to -> form.layout so that nothing will break when someone already uses this.

tt_content.mailform.20 {
    form {
        ...
        layout {
            ...
        }
    }
    confirmation {
        message = TEXT
        message {
            value = Check input
            wrap = <p>|</p><hr/>
        }
        layout {
            ...
        }
    }
    postProcessorDefaults {
        mail {
            layout {
                ...
            }
        }
        Vendor\ExtensionKey\PostProcess\CustomPostProcessor {
            layout {
                ...
            }        
        }
    }
    postProcessor {
        1 = mail
        1 {
            recipientEmail = {$plugin.tx_form.mail.recipientEmail}
            senderEmail = {$plugin.tx_form.mail.senderEmail}
            subject = {$plugin.tx_form.mail.subject}
            messages {
                success = Mail send.
            }
            mail {
                layout {
                    ...
                }
            }
        }
    }
}
#14

Updated by Toni no-lastname-given about 8 years ago

I can also confirm the bug, tried lots of things but nothing worked.

I attached the mail i get after submitting my form, cant get any info unless i inspect whole mail and i cant ask my client to do that.

Btw, any way of to enable plain mail from form in 6.2 form?

#15

Updated by Cornel Boppart almost 8 years ago

With this patch it is possible to configure custom layouts for the form, confirmation, and each type of post processor.
The backward compatibility is given, because this does not override or break already existing configurations but provides some more options to configure specific steps of the form process independent of each other.
Therefore it prevents from breaking the layout of the confirmation view and the HTML mail.

tt_content.mailform.20 {

    // Fallback and compatibility

    layout {
        ...
    }

    // Custom layouts

    form {
        layout {
             ...
        }
    }

    confirmation {
        layout {
             ...
        }
    }

    postProcessor {
        mail {
             layout {
                  ...
             }
        }
        ...
    }
}
#16

Updated by Gerrit Code Review almost 8 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#17

Updated by Gerrit Code Review almost 8 years ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#18

Updated by Gerrit Code Review almost 8 years ago

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#19

Updated by Gerrit Code Review almost 8 years ago

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#20

Updated by Gerrit Code Review almost 8 years ago

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#21

Updated by Gerrit Code Review almost 8 years ago

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28526

#22

Updated by Cornel Boppart almost 8 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#23

Updated by Bjoern Jacob almost 7 years ago

  • Category changed from Form Framework to 1602
#24

Updated by Bjoern Jacob over 6 years ago

  • Category changed from 1602 to Form Framework
#25

Updated by Benni Mack over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF