| 7:29 pm on Aug 3, 2013 (gmt 0)|
you could just try doing a preg_replace on the URL
$payment_error_return = preg_replace("/&/", "&", $payment_error_return);
i dont think it will work though. it looks like you've got two functions called tep_redirect and tep_href_link. they might be encoding the link themselves. you should have a look at those two functions and see what they do -- that's probably where it's happening
| 7:50 pm on Aug 3, 2013 (gmt 0)|
Thanks for the reply!
I don't really want to mess with the functions themselves if possible. This is in a live shopping cart and I don't want to mess anything up.
Is there a way for me to send the & through that function in a format that will result in it being translated to & in the final url?
I tried & and %26 but it just gets treated as text and gets further encoded...
This would be ideal since then I could repair that one bug locally and in this file without touching the functions.
Thanks for the help!
| 8:31 pm on Aug 3, 2013 (gmt 0)|
I don't speak php either, but isn't it the "urlencode" command that's doing it? Encoding should be constrained to the "path" part of the URL, before the query. Matter of fact, if the code is wholly concerned with generating a query, do you need to encode at all?
| 8:43 pm on Aug 3, 2013 (gmt 0)|
Hi! Thanks for the help, I think the urlencode is only applied to the $error variable:
'&error=' . urlencode($error)
The trouble is with the '&error=' part, it ends up being &error= in the URL once it's in the address bar.
I guess my main question is now: How to do I pass the & in '&error=' so that it ends up being &error= in the address bar? (and not &error=)
| 9:49 pm on Aug 3, 2013 (gmt 0)|
thats what i think the functions are doing, they are encoding the url, because when you pass $payment_error_return to the function its not encoded
if its just the error part thats a problem, then maybe you could try moving the error part to the start of the string -- then it wont need an & in front of it (change the order of payment_error and error)
| 10:03 pm on Aug 3, 2013 (gmt 0)|
Well, there are other parameters after error that need to be parsed as well...
| 5:41 am on Aug 4, 2013 (gmt 0)|
The URL in the href of the link should show with
& when you view the HTML source code. However, it should show as a plain ampersand in the browser address bar after that link is clicked.
Is the page being sent with the correct character set encoding? Use the Live HTTP Headers extension for Firefox to check the HTTP Headers returned.
Is the ampersand perhaps double-encoded
&amp; in the HTML source code?
| 10:26 am on Aug 4, 2013 (gmt 0)|
Looking at that code in cincin's original post, I don't think the problem is with a link click.
I'd hazard a guess that tep_redirect is issuing a Location header, and tep_href_link is converting to html entities.
If Location: recieves entities, it sends you to entities.
| 10:46 am on Aug 4, 2013 (gmt 0)|
that might be your solution. if you dont want to amend the tep_href_link function then you dont have to -- just copy it and create a new function with a different name. but include an extra preg_replace at the end to convert the ampersands back before you return the url. then send it through the other function like normal
| 10:54 am on Aug 4, 2013 (gmt 0)|
For simple replacements Londrum, you should avoid using preg_replace.
str_replace('&', '&', $string);
Will accomplish the same result, whilest being significantly faster as it doesn't need to load the regex engine.
| 10:58 am on Aug 4, 2013 (gmt 0)|
So, to add to that post, this may solve your problem cincin:
tep_redirect(tep_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false));
tep_redirect(str_replace('&', '&', tep_href_link(FILENAME_CHECKOUT_PAYMENT, $payment_error_return, 'SSL', true, false)));
| 7:05 pm on Aug 4, 2013 (gmt 0)|
Ladies and gentlemen, thank you.
This does precisely what I need. Problem solved.
| 10:18 pm on Aug 4, 2013 (gmt 0)|
You should also report this issue on the official forum of the CMS (osCommerce, ZenCart, whatever) you're using. You might have uncovered a new bug.