Issues

ZF-11747: Zend_View_Helper_Form omits closing tag when no content is passed

Description

The closing form tag is set only if the content is passed, so unlike false.

Comments

Reproducing Unit Test:


Index: Zend/View/Helper/FormTest.php
===================================================================
--- Zend/View/Helper/FormTest.php       (revision 24462)
+++ Zend/View/Helper/FormTest.php       (working copy)
@@ -167,6 +167,19 @@
         $form = $this->helper->form('FormName', array('action' => '/foo', 'method' => 'get'));
         $this->assertNotRegexp('/]*(name="FormName")/', $form);
     }
+
+    /**
+     * @group ZF-11747
+     */
+    public function testClosingTagIsPrintedWhenContentIsOmitted()
+    {
+        $this->view->doctype('XHTML11');
+        $form = $this->helper->form('FormName');
+        // Check that opening tag was printed
+        $this->assertContains('assertContains('', $form);
+    }
 }

 // Call Zend_View_Helper_FormTest::main() if this source file is executed directly.

Proposed fix:


Index: library/Zend/View/Helper/Form.php
===================================================================
--- library/Zend/View/Helper/Form.php   (revision 24462)
+++ library/Zend/View/Helper/Form.php   (working copy)
@@ -73,10 +73,11 @@
                . '>';

         if (false !== $content) {
-            $xhtml .= $content
-                   .  '';
+            $xhtml .= $content;
         }

+        $xhtml .= '';
+
         return $xhtml;
     }
 }

I don't see any harm in correcting this (obviously) incorrect behavior. Unless there are any objections, I will commit to trunk and merge to release-1.11.

Fixed in trunk r24477 Merged to release-1.11 in r24478

I really dont understand this merge as this just broken numerous projects. Why was this implemented in the first place? For what gain? What was the problem? Why is it a "BUG" that you can render the form decorator WITH or WITHOUT a closing tag.

Now there is no way to render the form decorator APART from the other decorators. Now we are forced to buffer the output of custom form, and pass it as content to the form decorator.

Even when using a custom viewscript, there is no way to render the form now without the closing tag.

I ended up wrapping all the form decorators in a static function which removes the closing tag. Great decision.

No gain, alot of pain. Cool commit

Please re-open, this craves for a revert.

Apologies. That use case was missed while discussing and producing the fix, and the unit tests for Zend_View don't enforce this use case. I will add a test to enforce it so the problem doesn't reoccur.

Fix backed out from release (r24487) and trunk (r24488).

Just broke my project as well. Second bugfix release in 2 months that brakes my project :( Revert please.

@Michiel Please show us your code snippet which breaks your project. Thanks!

I imagine it's this use case (from a view script), which I missed when vetting the fix:


<?php echo $this->form('foo'); ?>
    

In 1.11.11, this now produces the following HTML:



    

As the committed patch closes the tag regardless of whether or not content was passed into the form helper's third argument.

I've attached two methods to fix the v1.11.11 release: * A tarball (ZF-11747_fixedfiles.tar.gz) containing full, fixed versions of both files. Apply:


 * A patch (ZF\-11747_revert.patch) which can be used to reverse the changes.  Apply:

This bug has been listed Resolved as not an issue? Well it is, and it seems to me that the fixed version is also in the trunk. So if that is true, maybe change this status. When is the release coming out?

I'd like to request this 'fix' to be reverted as well. In a big webapplication I use custom view scripts in which I call (from within the view) $this->form() with only 2 parameters, a form ID and an array with attributes, and later in the template I close the form with a manually inserted . I omit the 3rd parameter. Now this suddenly closes the form tag? I've been using this form since ZF 1.5. This release totally breaks my application, so I'll stick to a previous version for now.

+1 for revert this modification. This fix/bug broke all some of our production code. We use a similar rendering to Adam Lundrigan comment. By passing false to the renderer, the closing form tag won't be added.


<?php echo $this->form->getDecorator('Form')->setElement($this->form)->render(false); ?>
    

This will be fixed in v1.11.12 and/or v1.12.0 (not sure if 1.11.12 is axed now that 1.12.x is coming down the pipe soon) Those who want to upgrade to v1.11.11 can, in the interim, follow my instructions above to revert the botched fix (here).

I do sincerely apologize for the inconvenience this has caused to everyone involved.

Sorry, if wasn't reading carefully. It's fixed in r24487 and r24488. Thx for reverting. No problem at all. Was funny to debug. Was looking everywhere (different browser, javascript, ...). ;-)