Edit Bug on the Send Gift Certificate Confirmation page using CSS buttons

Hello there!

I believe there is a bug in Zen Cart 1.3.5 on the Send Gift Certificate Confirmation page.

Here's how to replicate the problem: (1) Log in with a Balance in your Gift Certificate Account and go to the Send a Gift Certificate page. (2) Fill in the form and click "Send Now". (3) You are taken to a "Send Gift Certificate Confirmation" page to review your message before sending it. But wait! You're supposed to be able to click "Edit" if you would like to re-edit your message before you send it. However, when I click "Edit", Zen Cart sends the Gift Certificate! Oops. :unsure:

This is happening for me with the default template so I don't believe it's any code that I've changed. Can any one else confirm that this is a bug in Zen Cart that needs fixed?

Thanks!

I cannot replicate this error ... :unsure:

I tell it send $25 ...

I click Edit ...

I get taken back to fill out the info ...

Would be helpful to know what browser and operating system you're using, as well as what hosting platform (windows/linux) and what version of PHP is on your server.

Thanks for the quick feedback! You guys are great!

I think I found the catch -- I have CSS buttons enabled. It seems to work great when I disable CSS buttons.

Sooo, when CSS buttons are disabled, I get this code and everything works fine:

<input type="image" src="includes/templates/template_default/buttons/english/small_edit.gif" alt="Edit" title=" Edit " name="edit" value="edit" />

But, when CSS buttons are enabled, I get this code and the EDIT button submits the form instead of editing it:

<input class="cssButton small_edit" onmouseover="this.className='cssButtonHover small_edit small_editHover'" onmouseout="this.className='cssButton small_edit'" type="submit" value="Edit" style="width: 80px;" />

Hmmm. Peering into tpl_gv_send_default we see the following:

<?php echo zen_image_submit(BUTTON_IMAGE_EDIT_SMALL, BUTTON_EDIT_SMALL_ALT, 'name="edit" value="edit"') ?>

And so, it looks like CSS buttons aren't picking up that necessary last parameter in the zen_image_submit, eh? So, running over to html_output.php, I take a look at the zen_image_submit() function. On line 262 (in my file at least) I noticed the $paramters variable is commented out:

if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class /*, $parameters = ''*/ );

I don't think I did that. So why is it commented out? Well, looking at the zenCssButton() function on line 320 (in my file at least) we see:

$css_button = '<span class="' . $mouse_out_class . '" ' . $css_button_js . $style . ' > ' . $text . ' </span>'; // add $parameters ???

So the $parameters variable, even if it was passed to the zenCssButton() function, still wouldn't print. I would guess, then, that it's a feature still needing to be worked out?

Anyway, all this to ask, do you think it might be a possibility to use CSS Buttons and still have the Gift Certificate edit button work? Any creative solutions would be really appreciated. This "bug" is really "bugging" me. :smile:

Thanks a lot!

OK, everybody, if you want to enable CSS buttons and use gift certificates (doesn't anybody else out there use both of these features?) the only solution I've found to fix the "Edit" link on the Send Gift Certificate Confirmation page is as follows (applies to ZenCart 1.3.5):

1. Open up includes/functions/html_output.php and change this line:

if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class /*, $parameters = ''*/ );

to this:

if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) return zenCssButton($image, $alt, 'submit', $sec_class, $parameters);

2. Open up includes/modules/pages/gv_send/header_php.php and, in both places where it is found, change this line:

if (isset($_POST['edit_x']) || isset($_POST['edit_y'])) {

to this:

if (isset($_POST['edit_x']) || isset($_POST['edit_y']) || isset($_POST['edit'])) {

3. Finally, open up your template at includes/templates/YOUR_TEMPLATE_FOLDER/templates/tpl_gv_send_default.php (if it doesn't exist there, copy the file there from includes/tempmlates/template_default/templates/tpl_gv_send_default.php)
   Change this line:

<div class="buttonRow back"><?php echo zen_image_submit(BUTTON_IMAGE_EDIT_SMALL, BUTTON_EDIT_SMALL_ALT, 'name="edit" value="edit"') ?></div>

to this:

<div class="buttonRow back"><?php echo zen_image_submit(BUTTON_IMAGE_EDIT_SMALL, BUTTON_EDIT_SMALL_ALT, 'name="edit"') ?></div>

I know it's an ugly fix (modifying two untemplated files!? gasp) but it's the only way I can find to fix the problem. I'm still testing the results to make sure it doesn't break anything else on the site.

Ajeh? DrByte? Any better solution? Please?

The $paramaters var was commented out by me in a beta version of the CSS buttons contrib. Unfortunately that version was added to the core code.

The reason to comment out the $parameters in the first place was that any inline settings, like inline CSS for example, could mess up the buttons. That is why the $parameters are still commented out for link buttons in the current css buttons contrib (although I doubt if recent Zen versions really use this $parameters for any of the buttons). But for input buttons the $parameters values indeed are important in some cases.

I am suprised by the other modifications though, which seem to be needed to make that button work :blink:

I did a test and the edit button indeed appears to sent the certificate :shocking: (also with the css contrib that has the $parameters enabled).

Not sure if this is related, and where it comes from, but I noticed that: value="Edit" i.s.o. value="edit".

<input class="cssButton small_edit" onmouseover="this.className='cssButtonHover small_edit small_editHover'" onmouseout="this.className='cssButton small_edit'" value="Edit" type="submit"></div>

:blush: :blush: Oooooops, the parameters are not passed in the latest version of the contribution either (the function accepts $parameters, but no $parameters are passed to it).

The cause of theproblem seems to be with another issue though (also something I overlooked :shocking: ): the button type is set to submit "submit" by de css buttons function, while the original type is "image", when I change it to type="image" the button work as it should, but....... pfft it's bedtime here.

Hi Uncle Bob,

if you still feel like testing :-)

Could you try only making change 1. and after that line add:

if (strpos($parameters, 'name="edit"')!=false) $parameters = ' name="edit_x"';

But without the 2. and 3. changes!

I am not saying that this would be the final solution, even if it works perfectly. But it would help to pin point the problem. And removes the need to edit any other code than the css buttons function itself.

I noticed something which seems a bit strange here:

if (isset($_POST['edit_x']) || isset($_POST['edit_y'])) {

Why does it check for edit_x OR edit_y ?Why not just for edit? The _x and _y's are added by type="image" inputs, but why are those being used if the name="edit" value is available?

When I add the parameters (step 1.) and change the GV code to:

if (isset($_POST['edit'])) {

It seems work fine again......

Wow paulm! It looks like you've done a lot of testing recently. Thanks for all of your helpful observations.

This, unfortunately:

if (isset($_POST['edit'])) {

doesn't seem to work for me when CSS buttons are disabled, though it works fine when they are enabled. I suppose any input type="image" submits *only *the added _x and _y's. Thus the need to test for both plain "edit" (input type="submit") and "edit_x" or "edit_y" (input type="image"). Do you find this to be true as well?

Regarding your earlier idea of only making one change (and that change being to the zen_image_submit() function in functions/html_output.php) this implementation of what you suggested seems to work for me:

if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes' && strlen($alt)<30) {
		if (strstr($parameters, 'name="edit"')) $parameters = ' name="edit_x"';
		return zenCssButton($image, $alt, 'submit', $sec_class, $parameters);
	}

I'm not sure if that's a better way than modifying all three files or not. The logic feels a little bit shaky to me. But it works. What do you think?

Hi Bob,

I posted my last comment just before I went to bed, and the first thing I thought about when I woke up again was "edit v.s. edit_x edit_y ???" :wacko: :wacko: and it indeed became clear what was happening.

I actually never use input type=image buttons myself , but you are right of course (and now your first solution makes sense to me, while at first I did not understand why you were editting all these files to fix the problem), the image button type indeed takes the name and sends name_x and name_y in stead of the name itself :shocking: That in itself seems wacky to me, but of course there is nothing we can change about that now :-)
(I assume it's done this way for historical reasons or something).

So it seems there are three options:

1. Add a hack (to the ccs-buttons function) so that it sends name_x and/or name_y for every button to make it simulate image buttons.

or

2. Edit the Zen Cart core files so that both image and submit buttons are accepted (the first fix you posted).

or

3. Change the css-buttons function so that it returns the image button type.

(+ fixing the missing $parameters of course!)

3. Seems the best solution in one way (compatibility), but the worst in several others ways. Would it be (semanticly) correct to create image type buttons that aren't images at all? Probably not. And another issue is that it messes up the current styling of those buttons, probably because the browser renders image type buttons as images (edit: while there is no image to render in this case) which are treated different that input submit buttons.

2. Does not seem bad either, except for the amounts of edits needed to correct this.

I am not sure about 1.. The hack I suggested is indeed ugly, and was intended for testing only. But if every image button posts name_x and name_y it seems logical to add the same POST values if a css button is submitted. Or not?
(probably best not not by using the dirty strpos hack, but by using some fancier code :-) I was thinking about adding one or two hidden input fields that send the name_x and/or name_y values ).

Of course it's up to the Zen devs to decide how they fix it. But one of the reasons I am interested, more than avarage, is that I am still working on a css buttons contrib, and it would be nice to make it as much compatible with the zen version as possible of course :-)

Hello paulm, sorry it has taken me so long to post back here. I agree with your analysis and would definitely go with options 1 or 2. I tend to prefer option 2 but if there was a way to accomplish option 1 with some "fancier code" as you said, that might end up being a cleaner fix.

Hopefully the "Zen devs" are now aware of the problem (at least I think they are) and will fix this in a future release. In the meantime, we can use either of the methods mentioned earlier to temporarily patch it ourselves. Thanks for your help on this!

Hi Bob,

inspired by your reply I took another look and was trying out a better fix (maybe), but while I was testing I found another strange thing.

Zev versions < 1.3.x.x have (part of tpl_gv_send_default.php):

        <td class="main"><?php echo zen_back_link() . zen_image_button(BUTTON_IMAGE_BACK, BUTTON_BACK_ALT) . '</a>'; ?></td>
        <td class="main" align="right"><?php echo zen_image_submit(BUTTON_IMAGE_SEND, BUTTON_SEND_ALT); ?></td>

While the newer version up to 1.3.5 have:

<div class="buttonRow forward"><?php echo zen_image_submit(BUTTON_IMAGE_CONFIRM_SEND, BUTTON_CONFIRM_SEND_ALT); ?></div>
<div class="buttonRow back"><?php echo; zen_image_submit(BUTTON_IMAGE_EDIT_SMALL, BUTTON_EDIT_SMALL_ALT, 'name="edit" value="edit"') . '</a>'; ?></div>

Especially the last part seems "interesting"

'name="edit" value="edit"') . '</a>'; ?></div>
```:blink:

**1.) What is that closing anchor tag doing there?!!**

2.) The parameters** name="edit" value="edit"** appear to be added in 1.3.x.x versions (which, i.c.w. not adding the parameters, explains how the bug was born :-) )

No time now anymore :( 
But I will get back to it later!

Maybe Ajeh or DrByte can confirm this:

paulm:

**1.) What is that closing anchor tag doing there?**It seems a bit overkill to create a bugreport for this minor error (without confirmation I will report is as bug, unless I forget ......). Not that this small error causes the buttons bug (probably it does not cause any real bug, yet...)

@Bob I have done some more testing.

I have now changed the submit part of my css buttons function to read this (probably the Zen code for it is similar):

  if ($type == 'submit'){
  // form input button
    $css_button = '<input class="' . $mouse_out_class . '" ' . $css_button_js . '  type="submit" value="' .$text . '"' . $parameters . $style . ' />';
    // bof hack to simulate image button! (add _x and _y parameters to $_POST)
    // needed for gv name="edit" button (other named buttons are name="btn_submit" and name="submit1" and ...??)
    if (strpos($parameters, 'name')!== false){
      $s=strpos($parameters, '"', strpos($parameters, 'name'))+1;
      $e=strpos($parameters, '"', $s);
      $name = substr($parameters, $s, $e-$s);
      $_SESSION['buttons_name_array'][] = $name; // debug
      $css_button .= "\n" . '<input type="hidden" name="' . $name . '_x" value="1" />';
      $css_button .= "\n" . '<input type="hidden" name="' . $name . '_y" value="1" />';
    }
    // eof hack to simulate image button!
  }
```So I re-added the $parameters to the css buttons and added the part between **// bof hack to simulate image button!** and  **// eof hack to simulate image button!**. All other core files may be reverted to their original state after this change.

Probably getting the name value can be done easier by using a regular expression, but it works fine as it is now (I am not really gooed at reg. expressions ;-) ).

Willing to test it once more Bob? :-)

So I think the above would be a nice fix for 1.3.0.1 1.3.0.2 and 1.3.5. (and I will probably update the css buttons contribution using this fix, or something similar). If and how it will be fixed in 1.3.6 or a newer Zen version, we will see when whenever it's released :-)

Ahhh! Good observation there paulm. Now I understand why nobody ever found this "Edit Bug on the Send Gift Certificate Confirmation page using CSS buttons" bug before. It was introduced in a recent Zen update.

By the way, you are right about that '</a>' being out of place. Looks like someone mistakenly left it in the code when they made the recent changes. It's not the cause of our edit css button problem but it definitely should be removed. And it might be worth filing a little bug report since it does invalidate the XHTML compliance of the page. By the way, how would one go about filing a bug report? Would that be on the ZenCart SourceForge page? Maybe I should file one in regards to our "Edit Bug on the Send Gift Certificate Confimration page using CSS buttons" bug that we've been trying to work around.

In regards to the code you wrote into your css buttons function, there was one problem. It worked nicely to insert the hidden input form fields. Unfortunately, those form fields are submitted when either the Edit button or the Send button are clicked. So, while using it, I am unable to submit the gift certificate -- both buttons take me back to the edit page. Oh, well. Nice try, though.

About the bug report, I just meant the "Bug Reports" board on these forums: http://www.zen-cart.com/forum/forumdisplay.php?f=140

But since both Ajeh and DrByte have replied to this thread, I was hoping we would not need to copy this information to the bug reports forum.

In regards to the code you wrote into your css buttons function, there was one problem. It worked nicely to insert the hidden input form fields. Unfortunately, those form fields are submitted when either the Edit button or the Send button are clicked. So, while using it, I am unable to submit the gift certificate -- both buttons take me back to the edit page.That's strange :shocking: It certainly should not do that, and it does not do that on my testserver. Do you happen to have an url to look at? (I can mail you the url of my testshop if you like, maybe you can see a difference in the HTML source for example?).

(Are you testing on 1.3.5? Or on another 1.3.x version?)

I'm testing 1.3.5.

The reason your latest code solution isn't working for me is because both the "Edit Gift Certificate" button and "Send Gift Certificate" button submit the exact same form.

Your code solution inserts hidden fields for edit_x and edit_y so that these values are submitted with the form. However, they are submitted whether one presses Submit or Edit since both buttons submit the form.

Does that make sense? Perhaps you've inserted more code somewhere else to fix this problem on your site.

Keep up the good work!

Hi Bob,

I might be overlooking something, but I did not make any changes to the gv files in my 1.3.5 testshop, or at least not that I remember ;-)

And both buttons send the same form, but the edit button uses the name "edit" and the submit button does not (no name at all), at least not on my test installation.

I think these are the lines of code what it's about (tpl_gv_send_default.php):

<div class="buttonRow forward"><?php echo zen_image_submit(BUTTON_IMAGE_CONFIRM_SEND, BUTTON_CONFIRM_SEND_ALT); ?></div>
<div class="buttonRow back"><?php echo zen_image_submit(BUTTON_IMAGE_EDIT_SMALL, BUTTON_EDIT_SMALL_ALT, 'name="edit" value="edit"') . '</a>'; ?></div>
```(taken from an unaltered 1.3.5 zip)

I added the changes to the latest version of my css buttons mod, and I hope to get some feedback about it concerning the gv buttons. (Since doing tests over and over again is not a hobby of mine (and in this case has a quite low priority ;-) )).