Workaround to the get the customer order view working with email addresses that include a "+" character

[pbek]

This is a continuation of the closed pull request #1199 with suggested changes from @andrerom.

[pbek]

Travis fails with Fatal error: A database transaction in eZ Publish failed.. Since this problem already occured 3 days ago, I guess my pull request has nothing to do with it.

[andrerom]

I guess my pull request has nothing to do with it.

yeah that is not relevant here.

[pkamps]

It would be good to have steps to reproduce that issue.
I want to test if that's related to:
#1360

[pbek]

@pkamps, please see: https://jira.ez.no/browse/EZP-24798

[pkamps]

OK, I will try if I can reproduce the issue. I honestly don't have a webshop site currently.
Would you mind to test the patch in #1360 and see if it fixes the issue for you?

[pbek]

@pkamps, I tested your pull request and it didn't solve the issue of showing customer information with urls like https://your-server/admin/shop/customerorderview/10/test%[email protected]

[pkamps]

@pbek You're right, the patch from #1360 is not enough to fix the issue. I see that you fixed the missing url encoding in the template - that was missing and is not a workaround. I don't think you need to work with a query parameter ?email=. It's probably cleaner to stick with the the ezp ordered parameter.

The additional URL decoding $Email = urldecode( $Email ); is the problem. It's already decoding the query string in: https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezutils/classes/ezsys.php#L1184

So it's safe to just remove that line from the code base.
Verdict: I suggest to add the url encoding in the template and remove the line $Email = urldecode( $Email ); from the module/view.

[pkamps]

Oh, and maybe you still need the patch from #1360 - but I'm not sure, there is a chance it works without that patch.

[mateuszbieniek]

@pkamps @pbek
After some checking I think I found the root of the problem:
We get $Param['Email'] from URI (eZURI), which is initated here:
https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/private/classes/ezpkernelweb.php#L1083
using eZSys::requestURI().

eZSys::requestURI() is initaited using urlencode (https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezutils/classes/ezsys.php#L1184), then passed to eZURI::instance( eZSys::requestURI()) which again uses urlencode (https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezutils/classes/ezuri.php#L89), so we end up with email encoded twice.

So: test%2Btest%40example.com is becoming [email protected], and then test example.com.

But as I see this is exactly what #1360 should be fixing.

[mateuszbieniek]

This will always be true, unless $Email would be set null or false, which won't happen because of the line 10.
I sugest:

$Email = urldecode( $Email );
if ( $http->hasGetVariable( "email" ) )
{
    $Email = $http->getVariable( "email" );
}

[pbek]

@mateuszbieniek, that is what I had before I followed the suggestion of @andrerom in #1199 (comment) 😬

[pbek]

I now changed it back to your suggestion.

[pkamps]

That's how we'll fix the issue in our fork:
mugoweb#119

[pbek]

@pkamps

That's how we'll fix the issue in our fork:
mugoweb#119

that didn't seem to work for me, the urlencoded + didn't get across $Params

[mateuszbieniek]

I have to test it, but it seems like mugoweb#119 alongside with #1360 seems like a good approach and should work.

[pbek]

I would also like if my workaround with the extra get-parameter isn't needed any more.