Project

General

Profile

Actions

Bug #32463

closed

Epic #69036: EXT:form - Optimize layout rendering

New Form ext throws error on missing wraps

Added by Gone With the Wind almost 13 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Form Framework
Target version:
Start date:
2011-12-12
Due date:
% Done:

0%

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

Description

When removing the wrapper elements in the following 2 segments in the layout section, a FE error is thrown:

layout {
elementWrap (
<element /> // removed the li-wrapper (or dt..)
)
containerWrap (
<elements /> // removed the ul-wrapper (or dl...)
)
}

#1: PHP Catchable Fatal Error: Argument 3 passed to tx_form_View_Form_Element_Abstract::replaceNodeWithFragment() must be an instance of DOMNode, null given, called in /[path]/typo3/sysext/form/Classes/View/Form/Element/Abstract.php on line 127 and defined in /[path]/typo3/sysext/form/Classes/View/Form/Element/Abstract.php line 286 (More information)

t3lib_error_Exception thrown in file
/[path]/t3lib/error/class.t3lib_error_errorhandler.php in line 105.


Related issues 5 (0 open5 closed)

Related to TYPO3 Core - Bug #31951: Own checkbox layout breaks HTML mailClosed2011-11-20

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 - Feature #69176: Fix Layout handling for Form generationClosedMarc Neuhaus2015-08-19

Actions
Actions #1

Updated by Gone With the Wind over 12 years ago

anyone who could look into this? Thanks!

Actions #2

Updated by Franz Koch over 12 years ago

  • Target version set to 4.7.0-RC2

The issue is far greater. Your layout settings for rendering the form on your website are also used to render the HTML output - and this a) throws this error and b) once fixed borks completely your HTML mails. The "fix" for me was to XCLASS the mail postProcessor and feed the LayoutHandler (gladly a singleton here) with a fake "layout." array that overrides any custom layout changes.

Edit - I've set the target version because I think this needs to be fixed for 4.7. At least add my mentioned temporary fix/workaround until a nicer solution was found.

Actions #3

Updated by Christjan Grabowski over 12 years ago

Do you have piece of code or an extension for the xclass?

Did you xclass "tx_form_system_postprocessor_mail"?

Actions #4

Updated by Benjamin bunse over 12 years ago

Christjan Grabowski wrote:

Do you have piece of code or an extension for the xclass?

Did you xclass "tx_form_system_postprocessor_mail"?

I'd also like to see the workaround solution here. Could you show the xclass (extension?), the layout you defined in TypoScript and the "fake" layout you feed the LayoutHandler? I think that could help a lot here!

Actions #5

Updated by Steffen Ritter over 12 years ago

  • Target version deleted (4.7.0-RC2)
Actions #6

Updated by Mathias Schreiber almost 10 years ago

  • Target version set to 7.5
  • Is Regression set to No
Actions #7

Updated by Björn Jacob over 9 years ago

  • Category changed from Form Framework to 1602
Actions #8

Updated by Björn Jacob over 9 years ago

  • Category changed from 1602 to Form Framework
Actions #9

Updated by Ralf Zimmermann over 9 years ago

Could someone provide the typoscript snipped to reproduce this error?

Actions #10

Updated by Björn Jacob about 9 years ago

  • Status changed from New to In Progress
Actions #11

Updated by Björn Jacob about 9 years ago

  • Status changed from In Progress to New
Actions #12

Updated by Björn Jacob about 9 years ago

  • Parent task set to #69036
Actions #13

Updated by Björn Jacob about 9 years ago

  • Status changed from New to Closed

I've tested the described problems:

  • elementWrap: still cannot be "empty". Since we're moving to a new rendering solution based on fluid we are not fixing this issue.
  • containerWrap: just tested it. It can be "empty". No problem here.

Having different renderings for the form, confirmation and email is possible when merging #69176.

I'm closing this issue. We're having it on our roadmap :)

Actions

Also available in: Atom PDF