Printable View
I guess it's time to ask: What Zen Cart version? What OPC version? Are there template overrides for OPC's template modules?
Update: Noting that while the "Apply" button is just a span, it's got an id that's used by OPC's jQuery to "fire" the request.
Zen 1.5.6c
OPC 2.3.4 (2020-08-28)
Same on Localhost and Production versions. On local I am reverting to 'classic green' so there are no template alterations.
The issue appears to be with the ID then. I am tracking that backwards to see what is what.
Here's the section in tpl_modules_opc_credit_selections.php
Code:if (strtolower(IMAGE_USE_CSS_BUTTONS) == 'yes') {
$secondary_class = 'opc-cc-submit';
$additional_parms = '';
} else {
$secondary_class = '';
$additional_parms = 'name="apply_' . $ot_class . '"' . ' class="opc-cc-submit"';
}
I emerge out of that with:
As expected.Quote:
$secondary_class = 'opc-cc-submit';
$additional_parms = '';
Those values get sent to :
But that will not produce an ID (or a class for that matter). So, I must be missing something, I just don't know what it is.Code:echo zen_image_button(BUTTON_IMAGE_SUBMIT, ALT_TEXT_APPLY_DEDUCTION, $additional_parms, $secondary_class);
(
Just out of interest so far, the critical line in Zen 1.5.0 in html_output reads
$css_button = '<span class="' . $mouse_out_class . '" ' . $css_button_js . $style . ' > ' . $text . ' </span>'; // add $parameters ???
In my version of 1.5.6c it doesn't appear that the 2nd class is actioned at all. But I am going to have to check that.
)
So, with css buttons disabled the behaviour is as expected. The submit button looks like this:
So, I am guessing that the class is what triggers the javascript. But without dismantling the javascript I am not 100% on that. It feels like a glitch in html_output.php rather than with OPC.Code:<img src="includes/templates/template_default/buttons/english/button_submit.gif" alt="Apply" title=" Apply " width="51" height="15" name="apply_gv" class="opc-cc-submit">
Moving forward with that theory:
Changing line 395 of html_ouptut.php to something like the following works for me but I have no idea if that has consequences beyond the scope here.
Code:$css_button = '<span class="'.$sec_class.'" ' . $tooltip . $parameters . '> ' . $text . ' </span>';
Correct; sorry for sending you in the wrong direction on the 'id' attribute. Are you using CSS buttons or not?Quote:
Originally Posted by niccol
Production version - using cssButtons
Local Version - if I turn cssButtons off, then the behaiour is as you describe. Yay!
Local Version - If I turn cssButtons on, then no class is added to <span> and therefore the behaviour is not as expected.
This behaviour makes sense with the code that is in html_output.php
(but also means that at the moment I cannot enable OPC on the production site)
I'm baffled as the majority of my testing on both the zc156 and zc157 series has been with css buttons enabled.Quote:
Originally Posted by niccol
It is weird.
If there was a flaw in html_output then one would have expected it to not remain uncovered.
Going through the versions now.
1.5.4 the line is
This would work because sec_class is included in $mouse_out_classCode:$css_button = '<span class="' . $mouse_out_class . '" ' . $css_button_js . $tooltip . $parameters . '> ' . $text . ' </span>';
Working my way forward now ...
Noting that the current version of OPC doesn't support zc154.
My turn to be confused. My version of html_output.php is the problem.
The critical line does not exist in any version downloaded. So, I am embarrassed. But still puzzled because why would that have changed??
Anyway, it is not your problem so I will get off your thread.
The plugin is great by the way. Particularly the 1.5.7 version :-)