New Marie Curie ‘In Your Area’ Search Functionality

For the past two weeks here at Marie Curie we’ve been working on new functionality for searching for Marie Curie services across the United Kingdom. It has just today finally gone live and now we can serve our supporters with better information about the key services and events in their area.

‘In Your Area’

new_inyourarea

On launch we have included the following:

  • Fundraising Groups
  • Fundraising Offices
  • Marie Curie Shops
  • Marie Curie Hospices
  • Events we run

Results are ordered by distance from the location you have entered and can be navigate by either the result list of the result map. Clicking on a¬†result item on one result section, highlights it’s twin in the other.

The page is also fully responsive allowing you to view the search results and map as separate views.

new_inyourarea_mobile_listnew_inyourarea_mobile_map

Click here to go to the live search

Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.

Challenges

Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way ūüôā

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.

Strategy

We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test¬†on¬†feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as¬†we¬†rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches¬†should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Property Injection & Action Filters in EPiServer 7 CMS

I spent a bit of time putting in some custom implementation to support Property Injection on to my Action Filters before realizing that EPiServer 7 already provides this functionality for me. Doh.

In order to take advantage all you need to do is set¬†your DI controlled interface to the generic type property of¬†the Injected class. This will lazily set the¬†interface when the property is used…awesome.

public class CustomFilter : ActionFilterAttribute
{
public Injected Service { get; set; }
}

Architect – Technical Design Workflow for Creating New Fundraising Page using JustGiving API

JustGiving provides an API that allows charities to create fundraising pages from their own website. Charities benefit from this by being able to integrate this functionality into their own user journeys.

I designed a user journey workflow for a user to create a JustGiving Fundraising Page in remembrance of someone for where I currently work.

From a technical perspective I worked on this taking into consideration the capability and limitations of the JustGiving API. This is so I could empower our UX guys with the right information in order to make the user journey as efficient at possible and not to get hindered by technical limitations later on in the process.

My initial thought was I needed to create a journey that allowed the user to take a minimum amount of actions to get to the end goal of creating a fundraising page. Anything after that could be included as an enhancement or additional requirements from the business that hold value else where.


This what I took into consideration is:

  • You require an active Just Giving account to create a fundraising page. The workflow supports users who do and do not have a pre-existing account.
  • At this point (as standard with any account functionality) the workflow it forks out and forks back in again ending up with the user¬†that¬†is logged in with an account.
  • We then describe the required fields we must expose and¬†the optionals ones that we could take advantage of.
  • Each relevant step also mentions the correct API call that is needed.

Architect - Design Workflow for Creating New Fundraising Page using JustGiving API

Manipulating an EPiServer Page Programmatically

Creating a Page

Here’s how you can create a page in code from a page type you’ve already defined.

First create a new instance of the page type under another page in the form of a link:

var newBlogPost = ContentRepository.GetDefault<BlogPostPage>(parentLink);

Then set whatever properties you wish to the newBlogPost object.

newBlogPost.Subject = "Creating an EPiServer Page Programmactically";
newBlogPost.Content = "Meta";

Finally call the Save method on EPiServer’s content repository.

ContentRepository.Save(newBlogPost, SaveAction.Publish)


Updating a page

The structure to updating a page is thankfully very similar to creating one.

Load the page you wish to update from the Content Repository. 5 is the id of the page.

var contentReference = new ContentReference(5)
ContentRepository.Get<BlogPostPage>(contentReference);

Create a writeable clone of the update. This allows you to update it’s properties:

var clone = (BlogPostPage)page.CreateWritableClone();

Update a properties of the cloned page

clone.Subject = "Creating an EPiServer Page Programmactically";

Call the Content Repository to Save the page and public it at the same time:

ContentRepository.Save(clone, SaveAction.Publish);


Troubleshooting

When creating a new page and / or block you may get the following exception:

The INSERT statement conflicted with the FOREIGN KEY constraint 'FK_tblContent_tblContentType'. The conflict occurred in database ' ', table 'dbo.tblContentType', column 'pkID'.

This commonly gets throw when there are two developers working against the same database but have different versions of the page / block you are trying to save.

HTML with in-line Razor

This little gotcha keeps biting me in the ass every time I move away from Razor¬†for a while. So I’ve decided to blog so this¬†time I’ll remember.

When you want to insert some razor syntax in-line within a HTML tag. Make sure you include the @ delimiter on any further statement.


Following example attempts to add a class based on a bool value in the model.

The class show does not render:

<div class="@if(Model.Show) { Html.Raw("show") }"> 

The Html.Raw helper method is returning a MvcHtmlString however it will not output the value unless you tell it to by prefixing the statement with @. Now it renders !

<div class="@if(Model.Show) { @Html.Raw("shoe"); } }">

EPiServer 7 CMS – Import and Exporting Content between Environments

At Marie Curie we have several environments that sit across our infrastructure.¬†Occasionally¬†we get a requirement to shift content from one environment to another. This could be because we’ve auto generated pages via scheduled job or that QA have created a string of pages and want it replicated in another environment without having to key them all in again. Here are the basic steps required to do this.

Export Data

The EPiServer admin section exposes two tools which allow you to do this, Import Data and Export Data. On your source environment navigate to the Export Data tool.

EPiServerAdmin Import Export Data

Content items, content types even property definitions can be exported. What we are interested in is Export Content Items. Tick this box then hit the lookup button. This will make a pop up window appear with your website’s tree structure. Choose the page you are interested. Hit Select then hit Export.

EPiServerAdmin Import Export Data

The export data screen will show in real time the number of items that have been exported and your browser will automatically down a zip file.

EPiServerAdmin Import Export Data

Import Data

Switch to your target environment and once again head to the admin section but this time click on Import Data. here you can select the zip file you just exported and destination of the content. When you are ready click Begin Import.

EPiServerAdmin Import Export Data

Done! You will see that all the content items have been successfully imported.

EPiServerAdmin Import Export Data

I would not recommend this method as part of a permanent solution. It should be used for more one off circumstances. Remember that the target and source environment should have matching content types and property definitions otherwise you may not get all the data transferred correctly. Enjoy!