EPiServer Commerce

Redirect to external online payment solution from EPiServer Commerce Enoteca sample site

This is a short post to speed up your development if trying out your custom payment provider in the EPiServer Commerce Enoteca sample site and you have the need to redirect the user to an external online payment solution for example Netaxept.

This post is not about how to integrate to an external system but a tip how you should do the redirect.

Step one

Download the EPiServer Commerce 1 R3 Code Sample Package

Step two

Extract EPiServer.Business.Commerce.PayPal.zip from the sample package and unpack it somewhere on your hard drive.

Step three

Open the unpacked project in Visual Studio.

Have a look at the PayPalPaymentGateway.cs and go to the ProcessPayment method. At the end of the method there is the call to ProcessPaymentCheckout so next move to that method.

At the end of the ProcessPaymentCheckout the redirect url is constrcuted and a call to method RedirectParentPage is done. Move on and go to that method.

In RedirectParentPage method you can see that finally the actual redirect is done but it is done to a page PayPalRedirect.aspx and the target redirect url is passed as a parameter in querystring for it.

Next open the PayPalRedirect.aspx codebehind. There you can see some simple security checks are done that the RedirectUrl actually is to PayPal and if ok then a placeholder control is made visible and the RedirectTopWindow property is set. Have a look at the markup, this is where the magic happens with the help of JavaScript call to set the top window location.

Wrap up

So you should now have understanding how you can do redirect to an external payment solution in Enoteca sample site. Look at the PayPal sample also for the return page from the external site in the sample PayPal.aspx which finalizes the process and uses PayPalPaymentGateway class to redirect to the thank you page (PayPalPaymentLanding.aspx) which uses Enoteca CheckoutConfirmationStep control to display the success.

Update 16.10.2013 make it work in IE

Noticed that the redirect doesn’t work in IE10 (might be also IE9 and earlier versions don’t support the sandboxed iframe). Quick and dirty solution to make the redirect also work in IE is to edit the iframe attributes.

  • find the file /Templates/Enoteca/Units/Placeable/CheckoutPaymentStep.ascx
  • line 106 in markup, there is the definition for the iframe
  • change the sandbox attribute value from sandbox=”allow-forms allow-same-origin allow-scripts” to sandbox=”allow-forms allow-same-origin allow-scripts allow-top-navigation


[iframe id="paymentMethodsFrame" sandbox="allow-forms allow-same-origin allow-scripts allow-top-navigation" seamless="seamless" class="enoPaymentMethodFrame" src="" ][/iframe]

EPiServer

Relocate EPiServer 7 CMS UI

There are blog and forum posts and the official documentation on how to relocate the UI but I haven’t spotted any that mention that you also need to edit the “Welcome Page in Edit Mode” -web form template path and the Recycle Bin -web form template path.

My experience on this is based on that I first created an empty site in Visual Studio and then I wanted to relocate the UI but after relocating the UI the EPiServer root gave me an error when trying to access it and obviously it was looking for the template from the wrong place as I had relocated the UI.

This “guide” is based on my demo site where I used “/mypathtoUI/” as the initial UI path and following are the steps to relocate the EPiServer UI to “/relocated/” path.

First step is to edit the episerver.config

Find your sites siteSettings element and locate the uiUrl attribute. It currently holds the value ~/mypathtoUI/CMS/ so change this value to ~/relocated/CMS/

Next step is to edit the EPiServerFramework.config

I find it easiest to search for sting “mypathtoUI” and replace it with “relocated” in my favorite text editor.

In a default installation there are 2 instances of the string match. One in the ProtectedAddons named virtualpath configuration and the other one in the UI named configuration.

So change the string in these 2 locations (unless you have some customizations and the string exists in more definitions change it in those too)

Third step is to edit the web.config

Same approach as earlier. Use your favorite editor to replace the “mypathtoUI” with “relocated”. There should be 4 hits in the file.

First one <location path=”mypathtoUI”> so change this to be <location path=”relocated”>.

Then there should be <location path=”mypathtoUI/CMS/admin”> so change this to be <location path=”relocated/CMS/admin”>

Third one should be <protectedModules rootPath=”~/mypathtoUI/”> (inside the <episerver.shell> element) so change it to be <protectedModules rootPath=”~/relocated/”>

And fourth hit should be <episerver.packaging protectedVirtualPath=”~/mypathtoUI/” /> so change it to be <episerver.packaging protectedVirtualPath=”~/relocated/” />

Almost there

Now if you navigate to dashboard (http://www.yourdomain.org/relocated) this works ok but if you click the CMS menu item and then the sub menu item Edit you are greated with a nice 404 error message. Notice the requested url : /relocated/CMS/en/,,1_1/

Next go to admin mode as we need to update the Welcome Page in Edit Mode templates Web Form template path.

In admin mode go to the Page Type tab and click the “Welcome Page in Edit Mode” page type

  • click the Settings button
  • change the “mypathtoUI” to “relocated” in the Web Form template path
    • /mypathtoUI/cms/edit/workspace.aspx
    • becomes /relocated/cms/edit/workspace.aspx
  • click the Save button

Next change the “Recycle Bin” page type so click the “Recycle Bin” page type

  • click the Settings button
  • change the Web Form template path
    • /mypathtoUI/cms/edit/wastebasketpage.aspx
    • becomes /relocated/cms/edit/wastebasketpage.aspx
  • click the Save button

The Recycle Bin change is only needed if you for some reason use the old edit view. The new edit views ‘View Trash’ doesn’t seem to care about the template so obviously it is implemented in some other manner.

Now you should be done and you have relocated the UI and everything works as it should.

EPiServer Commerce

Make the Commerce Manager link visible to a group in EPiServer edit view

Just a short post on how to make the Commerce Manager link visible to a custom group.

By default the Commerce top menu link and child sub menu items are only visible to Administrators and WebAdmins roles in EPiServer CMS. But what about if you want to display the Commerce Manages (sub menu item) to your editors without adding them to the WebAdmins ? You certainly don’t want to add users to WebAdmins just so that they can see the link. First I assumed that the documentation would contain this information but I couldn’t find it from there.

So my approach was to dig the Commerce assemblies with ILSpy as I assumed that there needs to be a class that implements the IMenuProvider interface (if not familiar with this, have a look at Jacob Khan blog post).

The menu provider is defined in EPiServer.Business.Commerce.AddOns.Manager.dll assembly in CommerceManagerMenuProvider class. From there I could peak how the permission for the Commerce Manager link was decided. The permission is based on the path access to “Admin/SitePlugin”. From here on this is simple. Web.config has a location created by Commerce installation where the Administrators and WebAdmins roles are allowed to access by default.

<location path="Admin/SitePlugin">
   <system.web>
      <authorization>
         <allow roles="WebAdmins,Administrators,YOUR_NEW_GROUP_HERE" />
      </authorization>
   </system.web>
</location>

So what I did was to create a new group in EPiServer CMS and then I added that group to the allowed roles to the location. This way I could allow the editors to see the link to Commerce Manager but without granting them access to the EPiServer admin view.

As a side note if you would like to editors see the Commerce settings and be able to edit it then you would edit the “Admin/SettingsPlugin” location with a new allowed role (haven’t tried if this is enough to actually edit the settings values, there might be additional permission checks)