Blog

Training for your Sitecore project

To mis-quote Benjamin Franklin ‘By failing to train you are training to fail”.  You can provide the best tools in the world but unless people know how to use them, they are useless.  And the more complex the tool the more apparent that becomes.  I think Sitecore is a simple, intuitive tool but then I have been delivering training on Sitecore for eight years.  I’m now familiar with the system. But I do know that at first sight it can appear overwhelming.

So, how best to use training to mitigate risk in your Sitecore project, or any other for that matter? 

I recommend a three-phase approach starting as early as possible in the project.  If it is possible start before the vendor is decided.  Phase one is pretraining.  Phase two shortly before Go Live or UAT. And finally phase three is ongoing maintenance to allow for staff churn, new features etc.

Let’s look at each phase in a bit more detail. 

Phase One/Pretraining

Phase one is the first tranche of training.  As stated above it should be undertaken early in the project.  Assuming you are starting the project by selecting the vendor for a software project; once you have a short list consider sending key stakeholders to classroom training on each of your shortlisted vendors.  While it may be considered an unnecessary cost it will provide a good insight into the real-world use of the various offerings.  And also consider that the cost of pretraining is insignificant compared to the cost of a failed project.

Once you have decided on a vendor, if they have not already, key business and technical staff should attend appropriate training for their role.  Selection should be based upon who will be working with the implementation partner.  Training at this early stage will equip the team with the skills to work with the implementer.  It also shows attendees the capabilities of the chosen platform; they know what to ask for. 

If an implementation partner hasn’t been selected yet training this early can also be useful in their selection.

Delivery for this tranche should be public classroom training, unless you have the numbers to make a private course worthwhile (hint 6+ staff is the tipping point from a public class to a private one).  Classroom training allows for questions to be asked and a good trainer can adapt the delivery to ensure the learning outcomes are achieved.

Phase two/Go Live

Phase two is where the bulk of your users receive training – this is because you are about to go live with your new website.  By now it should be possible to train on, or at least reference, your application as it will be implemented.  Various options are available.  eLearning, although to be fair I am not a fan of eLearning, it is too easy to click through and be distracted by other incoming tasks and emails without absorbing the information.  However, it is cheap and repeatable.  For business users, you could even consider bespoke eLearning.  While the initial cost is high you own the content and there are negligible ongoing costs plus it covers maintenance training or phase three.  Classroom training such as public courses will be generic and provide a good understanding of the features of the chosen application – it will probably be useful to have an internal follow up to familiarise business users with their application.  Developers should be fine with just a public course and some time to get to know the code.  It is, again, possible to get customized or completely bespoke training delivered in a classroom – where your lesson is about the application you are implementing within your organisation.  Delivery costs should be approximately the same as attending public courses but there will be development costs involved; how much will depend on the degree of customisation required

Phase three/Maintenance

Once your website is live and all the users and developers are trained, we move to phase three or maintenance.  Additional training maybe required if you upgrade the version of the application or introduce new features (depending on the enormity of the changes). 

Phase three training is primarily needed for staff churn.  Developers should start by attending the public courses and then learn peer to peer, consider pair programming here.  For business users it is beneficial to attend public classroom training to get the solid foundation to build on.  Just peer to peer onboarding, while tempting, can perpetuate bad habits and often leaves knowledge gaps in the real understanding of the application.  At the very least you need a set of learning objectives that must be ticked off preferably by your in-house super user.

Aceik is a Sitecore training provider.  We teach public courses around the country.  You can view the public schedule here: Upcoming Courses New courses are being worked on constantly so if you do not see what you want please enquire here or email David Newman at the link below.  We also provide custom or private training email David Newman in the first instance or if you are an Aceik customer already contact your account manager.

Season’s Greetings and 2019 Wrap Up

‘Tis the season to be jolly and over at Aceik, we certainly have a lot to celebrate these holidays. What a year 2019 has been! For starters, we celebrated our 5th anniversary. But then we celebrated so much more:

Partnerships

We partnered with a number of new clients including RAA, City of Yarra, RACQ, Chisholm Institute and CMYKHub. Our partnerships with clients like Toyota, CPA, Unisuper and ANZIIF continued with new and exciting projects.

Team Growth

Our team and capabilities grew with the addition of 8 incredibly talented individuals. We added speciality skills in Sitecore Commerce and UX/UI. Aceik also welcomed Tim O’Neill, formerly of digital services agency Reactive and Accenture in an advisory capacity and Nicole Stirling, formerly Sitecore’s Marketing Director to assist with our marketing activities.

Recognition

Sitecore announced that two of the four Australian Sitecore Technology MVPs were on the Aceik team, Jason Horne and Thomas Tyack.

Events

We organised the first SUGCON event in Australia & New Zealand region and presented at Sitecore User Groups in Melbourne and Queensland.

Product Development

Our development team built two Sitecore modules and we shared these openly with the community. Aceik became a Contentful partner and built a new gym website on this platform. And we wrap up 2019 with the launch of our new training practice. Our first courses will be available from January 2020 and you can sign up here.

What are we getting up to in 2020?

Our 2020 plans are equally exciting and we’d love to share a couple with you:

  • Aceik is aiming to double the number of Sitecore MVPs on our team.
  • Sustainable growth is based on insuring our 100% customer success record. We are planning to continue to grow our team, starting with a new Senior Front End Developer (if you know of anyone who is looking, please let them know that we’re hiring!)

I know I say this a lot, but I truly mean it when I say, ‘thank you’. Your support has been invaluable and I’m looking forward to continuing our work together in 2020.

I wish you and your family and friends a safe and happy holiday.

Cheers

Jason Horne & Aceik team

JSS – Some Key Takeaways

Introduction

In the following outline I will take you through some learning points that Aceik discovered on our first JSS project. Some of this is personal opinion and based on our experience with the Angular framework.

Disconnected Mode – Get started quickly

If your team is just starting out and you want to see JSS in action you will likely start out running in Disconnected Mode. This seems like a great way to get non Sitecore developers up and running without them needing to run an actual Sitecore instance. A key benefit is also that front end developers in your team can work on the project without having any Sitecore skills.

It has been mentioned by Nick Wesselman in the global Sitecore slack (Hi Nick, hope its ok if I quote you) that:

“*I wrote the import process for JSS and I can tell you it was not intended for anything beyond quick start for front end devs and short lived campaign sites”

and  ….

“Sitecore-first was always the intended workflow for anything non-trivial”.

I have to be honest I was disappointed when I read the above comments as we did get a fair way into the project supporting our front end Devs and our backend Devs. It does make sense though that Disconnected mode has its limitations. Your not going to get all the bells and whistles available that Sitecore provides, without actually having Sitecore itself. Still the opportunity to support those developers that don’t know Sitecore is a big draw card and I for one see Disconnected mode as something that is very useful.  

Disconnected Mode – Example usage

From personal experience building out a member portal in Angular we were able to mock up secure API calls in Disconnected mode by detecting which mode the app was run in. The workflow involved building individual components that were verified to be working in Disconnected mode by front end developers. These same components were then verified in Connected mode running in Sitecore. Some people may consider this to be double handling in some ways. I still think the the benefits of continuing to support front end developers has its advantages.  

GraphQL Endpoints

GraphQL is a paradigm shift from traditional APIs in that you have a single API endpoint that you can run queries and mutations against to produce results and updates.

Custom GraphQL Endpoints

A couple of things that took us a while to figure out were

  1. Adding multiple schemes to our single endpoint.
  2. Sending mutations with complex object structures (Nested POCOs)
    1. See Example Mutation Query
    2. See Example Variables that match the above query
    3. See Example Schema in C#

How to Turn on Mutations

If you need to send updates to the server by convention in GraphQL you write these as mutations.

You won’t get far unless you actually enable mutations in your JSS app config. This might seem obvious but it took us a while to find an example and work it out.

See Example Line 128

            <mutations hint="raw:AddMutation">
              <mutation name="createItem" type="Sitecore.Services.GraphQL.Content.Mutations.CreateItemMutation, Sitecore.Services.GraphQL.Content" />
              <mutation name="updateItem" type="Sitecore.Services.GraphQL.Content.Mutations.UpdateItemMutation, Sitecore.Services.GraphQL.Content" />
            </mutations>

Secure vs Insecure Graphql Endpoints

Something we required in the case of our member portal project was custom GraphQL endpoints for logged in users and in some cases insecure endpoints for data that did not require an Authenticated user.

Essentially in Angular we solved this using multiple Apollo clients. A full example is available here: (along with detailed explanation)

https://sitecore.stackexchange.com/questions/22229/in-jss-how-do-i-support-both-secure-and-open-graphql-endpoints/22230#22230

Conclusion

That’s a wrap for some of our key JSS learnings so far. We may come back and add to these over time as we learn more. Happy JSS-ing !!

Install Sitecore 9.2 from Scratch

Introduction

In this post I’ll provide you with instructions to install Sitecore 9.2 from scratch. This article is aimed at developers who may never have installed Sitecore before and need to work through all the prerequisites before installing Sitecore. It also takes the simplest approach possible to get a working installation of Sitecore 9.2. Sitecore 9.2 includes a Graphical User Interface (GUI) that turns the actual installation into a wizard driven process that is much easier than earlier versions of Sitecore 9.x

The starting point is a clean updated installation of Windows 10 Professional. I have also installed Firefox and Edge Developer Trial. This is the Beta Chromium based version of Edge.

Prerequisites

You are going to need the following programs in order to proceed, and instructions are provided below on how to access and install them.

  • IIS
  • Java
  • Solr
  • SQL Server
  • Visual Studio and Sitecore Rocks
  • Sitecore license or Sitecore Developer Trial license (60 days access)

IIS

The first thing to do is turn on IIS. Go to the Control Panel -> Programs and Features and click on “Turn Windows features on or off” Locate Internet Information Services in teh Windows Features popup and click the checkbox. It will not show a tick, just a square to indicate that not all features are enabled by default

The default settings will be fine for our needs.

Open a browser and enter http://localhost you should see the IIS Welcome splash screen.

Java

Java is required to run Solr so if it is not installed you will need to download and install.  Download the latest version here: https://www.java.com/en/download/windows-64bit.jsp Once the download has completed run the .exe file to install Java

Solr

Download Solr-x.x.x from Apache https://www.apache.org/dyn/closer.lua/lucene/solr/8.2.0/solr-8.2.0.zip Extract the zip to the root of your C drive..  You can check that Solr has ‘installed’ correctly and is working by starting it from an elevated command prompt.  Elevated is when you are running the command prompt as Administrator, right click on the command and select Run as administrator. Navigate to the bin folder that is in the Solr folder. Run the command solr start -p 8984

You should now be able to access the Solr Admin page by entering http://localhost:8984 in your browser of choice. You should see:

Assuming your installation of Solr is working correctly, stop Solr from the command prompt using solr stop -all

If you are working on a VM now is a good time to take a snapshot.

To work with Sitecore 9.2 Solr must use https and must be running as a service. This is going to involve creating a self-signed certificate and editing a configuration file to set up Solr to use https.

In an elevated PowerShell window run:

New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -DnsName "localhost", "127.0.0.1" -FriendlyName "SolrCert" -NotAfter (Get-Date).AddYears(10)

Use the Cortana search bar to locate and open ‘Manage computer certificates’. Open the Personal -> Certificates folder and export the newly created certificate by right clicking on it and selecting ‘all tasks -> Export’ Select ‘Yes, export the private key’ and ‘Include all certificates in the certification path if possible’ Set a password, I am using the traditional ‘secret’.  Select a location and name for the exported certificate, for example ‘C:\solr-8.2.0\solr_ssl_cert.pfx’.  In the MMC navigate to ‘Trusted Root Certification Authorities -> Certificates and Import the newly exported certificate.

Edit ‘C:\solr-8.2.0\bin\solr.in.cmd‘ and uncomment and edit the HTTPS section so it looks like this (in my case, edit to suit your environment):

Use a command prompt to start Solr using the command solr start -f -p 8984. You should now be able to connect to the Solr Admin page using https://localhost:8984. Note that Firefox may give a warning because it is a self-signed certificate, you an disregard or add an exception. Stop Solr by pressing Ctrl C in the command prompt window.

Finally we need to set Solr to run as a service. Download NSSM (a great little free tool to create and manage Windows Services) from here: https://nssm.cc/download and extract the contents of the .zip file to an appropriate location; I used C:\ so my path to nssm is C:\nssm-2.24\win64\nssm.exe.

In an elevated command prompt run C:\nssm-2.24\win64\nssm install solr82 in the popup enter the path to solr.cmd and the arguments -f -p 8984. Click Install service. The -f argument makes the service run in the foreground so nssm has access to stop and start it. The -p sets the port.

As a final check that everything is working as expected restart the PC (The Solr service should start automatically) and connect to https://localhost:8984

SQL Server

Go to https://www.microsoft.com/en-au/sql-server/sql-server-downloads to download SQL Server, I am using 2017 Express. Download and launch the installer.  I left it on the standard options.  Install SQL Server Management Studio (SSMS), download from https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms You should now be able to launch SSMS and connect to the SQL Server.

There is a little bit of configuration required before it will work with Sitecore though.  The default installation uses Windows Authentication and we need SQL Authentication enabled and the ‘sa’ account activated. Login to SQL Server using SSMS and right click on the Server to access the Server Properties.

On the Security tab ensure that SQL Server and Windows Authentication mode is selected.  Next go to Security -> Logins and open the Properties dialog for ‘sa’. Set a password and ensure that Login is enabled on the Status tab.  It will be necessary to restart the SQL Server service before the changes take effect.  This can be done easily using the Services app:

Finally, we need to allow Contained Database Authentication.  Click New Query and run:

sp_configure 'contained database authentication', 1;

reconfigure;

Visual Studio & Rocks

Download and install Visual Studio, I am using the 2019 Community edition obtainable from https://visualstudio.microsoft.com/vs/

Install Sitecore Rocks extension.  Use the Extensions -> Manage Extensions tool to add Sitecore Rocks.  Restart Visual Studio.  You should now be able to locate Rocks under Extensions:

Sitecore 9.2

Sitecore 9.2 ships with a Graphic User Interface (GUI) that can be used to make the installation process simple if you do not need to customise the installation.  We will be using the GUI for our installation .

You will need permission to access the Sitecore Developer site (https://dev.sitecore.net) and download assets. You will also need a valid Sitecore license to be able to install and use Sitecore. If this is an issue for you consider joining the excellent Sitecore Developer Trial Program. This free trial will allow you to use Sitecore for 60 days.

If have not already, download Sitecore 9.2.0 rev. 002893 (Setup XP0 Developer Workstation rev. r150).zip from dev.sitecore.net, extract the zip into a folder, I would suggest C:\Installer, for example, referred to as the installation folder.  Copy your license into this folder.

Because we are going to use the GUI to install Sitecore most of the needed values are entered during the installation, however, if we want to install Habitat in our new instance of Sitecore there is one small edit required. Habitat is a demo site that follows the Sitecore best practices described in Helix (https://helix.sitecore.net/)

In the installation folder open setup.exe.config in a text editor. Alter the line <parameter name="SitecoreSiteName" value="{Prefix}sc.dev.local /> so that it reads <parameter name="SitecoreSiteName" value="{Prefix}.dev.local /> this will make our site name match the name expected by Habitat.

In the installation folder right click on setup.exe and select Run as Administrator.  Do not skip the Prerequisites stage, it is required to install SIF (if needed) and several Windows and .Net components that are not part of the default Windows installation.  If you run the Sitecore GUI installer again you can skip this step.  Now it should be just a case of entering the values requested by the wizard and allowing it to install Sitecore. 

In my environment the Summary screen looked like:

That’s it! You have now installed Sitecore 9.2 and you are ready to start exploring this great tool.

Sitecore PaaS and Ansible

Sitecore PaaS and Azure is a good match and the idea is to blend in Ansible for Sitecore PaaS infrastructure set up on Azure and vanilla Site deployment.

Why would you use Ansible? Using Powershell scripts with parameter files is the common approach. Ansible is a very valid alternate approach for organisations who have Ansible in their tech stack already or for those that prefer it over Powershell.

Let’s start with a brief overview of Ansible. Ansible is an automation tool to orchestrate configuration and deployment of software. Ansible is based on agent less architecture by leveraging the SSH daemon. The Ansible playbook is a well defined collection of scripts that defines the work for server configuration and deployment. They are written in YAML and consists of multiple plays each defining the work to be done for a configuration on a managed server. 

Ansible Playbooks help solve the following problems:

  1. Provision of Azure Infrastructure required to run Sitecore and the deployment of Sitecore. Ansible supports the ability to seperate the provision of the infrastructure from the deployment of the Sitecore packages into “roles”. These roles can then be shared between different playbooks essentially allowing for re-use and the configuration of different playbooks for different purposes.
  2. Modularise the environment spin up into tasks/plays instead of one monolithic command doing everything in one go.
  3. By executing a single playbook, all the required tasks are coordinated to be executed to result in a fully operational instance of Sitecore up and running and ready to be customised by the organisations development team

Ansible Playbooks help with workflow between teams:

  1. Provide flexibility for Developers and DevOps teams to work together on separate piece of work to achieve a common goal. A DevOps team can work on the Azure Infrastructure set up and Developers can work on Application set up and vanilla deployment  
  2. Once the environment is provisioned hand it over to Development team for each site to deploy the custom code and configuration on Vanilla site.

Ansible has list of pre-built modules for Azure that can be leveraged for Azure Infrastructure Spin up and deployment. A list is available here https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html#azure.  

We have used the azure_rm_deployment module during the setup journey. The best thing I liked about Ansible was the ability to structure the parameters in a clean and organised fashion to ensure future extensibility is maintained. Ansible supports the use of multiple parameter file. This allows for both shared and environment specific parameter files. You will see the example later in the blog. 

All the ARM templates, play books and tasks are source controlled and Ansible tower can be hooked into the Source control of your choice.

This allows/enforces all changes to the templates, play books and tasks to be made locally and then commited to the source control repository using familiar tools. Asnible will then retrieve the lastest versions of these files from source control as the initial step on execution.

This option is more streamlined than having to manually upload the updated files to an online repository like a storage account and have Ansible/Azure access them using URLs.

Below is one of the example of the playbook. The roles mentioned here are just an example. You will need more roles for a complete azure infrastructure and Sitecore deployment 

Note the variables {{ env }} and {{ scname }}. They are passed from the Ansible tower job template into the playbook. This variables needs to be configured in the Extra VARIABLES field as shown below in the example job template. 

The env name is your target environment for which you want to spin up the Sitecore Azure environment. This could be dev, test, regression or production and the site name is the name of your website. This allows you to use same playbook to spin up multiple sites for multiple environment based on the extra variables passed in the job template in Ansible tower. This combination forms the path to the yml file which contains the definition of the parameters, per site, per environment. Below is the snapshot of the variable file structure. 

  • Each role in the Playbook is a Play/Task and the naming convention is fairly self-explanatory. 
  • Each task has a yml file and ARM template (json file). However it is not mandatory to have an ARM template for each of the tasks.
  1. Create the resource group just to have the tasks yml file and no arm template. 

2. Create the Redis Cache resource that will contain both the tasks yml file and the ARM template. 

There are tons of resources available in the Azure ARM template repo https://github.com/Azure/azure-quickstart-templates to get you started. You can then customize it to suit your projects requirements. Sitecore ARM templates are a good starting point which you can utilize to get some ideas. The idea is that you can grab snippets from these example to form your own ARM template. 

I will be writing more blogs on Azure and Sitecore so stay tuned.

SXA Speedy – Supercharge your SXA Page Speed Scores in Google

We are excited to preview our latest Open Source module. Before jumping into the actual technical details here are some of the early results we are seeing against the Habitat SXA Demo.


Results:

Results

Before:

After

After:

Before
* Results based on Mobile Lighthouse Audit in chrome. 
* Results are based on a local developer machine. Production results usually incur an additional penalty due to network latency.

Want to know more about our latest open source SXA Sitecore module …. read on ….


I’m continually surprised by the number of new site launches that fail to implement Google recommendations for Page Speed. If you believe what Niel Patel has to say this score is vitally important to SEO and your search ranking. At Aceik it’s one of the key benchmarks we use to measure the projects we launch and the projects we inherit and have to fix.

The main issue is often a fairly low mobile score, desktop tends to be easier to cater for. In particular, pick out any SXA project that you know has launched recently and even with bundling properly turned on its unlikely to get over 70 / 100 (mobile score). The majority we tried came in somewhere around the 50 to 60 out 100 mark.

Getting that page score into the desired zone (which I would suggest is 90+) is not easy but here is a reasonable checklist to get close.

1) Introduce image lazy loading
2) Ensure a cache strategy is in place and verify its working.
3) Dianoga is your friend for image compression
4) Use responsive images (must serve up smaller images sizes for mobile)
5) Introduce Critical CSS and deferred CSS files
7) Javascript is not a page speed friend. Defer Defer Defer

The last two items are the main topics that I believe are the hardest to get right. These are the focus of our new module.

Critical_plus_defer

Check out the GitHub repository.

I have also done an installation and usage video.

So how will the module help you get critical and JS defer right?

Deferred Javascript Load

For Javascript, it uses a deferred loading technique mentioned here. I attempted a few different techniques before finding this blog and the script he provides (closer to the bottom of the article) seems to get the best results.  It essentially incorporates some clever tactics (as mentioned in the article) that defer script load without compromising load order.

I also added in one more technique that I have found useful and that is to use a cookie to detect a first or second-time visitor. Second-time visitors naturally will have all external resources cached locally, so we can, therefore, provide a completely different loading experience on the 2nd pass. It stands to reason that only on the very first-page load we need to provide a deferred experience.

Critical + Deferred CSS Load

For CSS we incorporated the Critical Viewport technique that has been recommended by Google for some time. This technique was mentioned in this previous blog post. Generating the Critical CSS is not something we want to be doing manually and there is an excellent gulp based package that does this for you.

It can require some intervention and tweaking of the Critical CSS once generated, but the Gulp scripts provided in the module do seek to address/automate this.

Our module has a button added into the Configure panel inside the Sitecore CMS. So Content Editors can trigger off the re-generation of the Critical CSS when ever needed.

Generate Critical button added to Configure.

Local vs Production Scores

It’s also important to remember that the scores you achieve via Lighthouse built into Chrome on localhost and your non-public development servers can be vastly different than production. In fact, it’s probably safest to assume that non-production boxes give false positives in the region of 10 to 20 points. So it’s best to assume that your score on production will be a little worse than expected.

Conclusion

It’s a fair statement that you can’t just install the module and expect Page Load to be perfect in under 10 minutes.  Achieving top Page Load Speed’s requires many technical things to work together. By ensuring that the previously mentioned checklists are done (Adequate Servers, Sitecore Cache, Image Loading techniques) you are partway over the line. By introducing the deferred load techniques in the module (as recommended by Google) you should then be a step closer to top score.

For more hints please see the Wiki on Github.

This module has been submitted to the Sitecore Marketplace and is awaiting approval.


Author: Thomas Tyack – Solutions Architect / Sitecore MVP 2019

The 4 most common Sitecore issues we have found our clients are facing

Sitecore is often referred to as the Rolls Royce of CMS platforms, but its power and flexibility come with a caveat – that flexibility can lead to solutions which are functional, but have inherent structural problems. Over time this can lead to anything from slow page performance to the site completely falling over on what should be a small deployment. This can leave you feeling like you’ve paid for a Rolls Royce but received a Ford Pinto.

We here at Aceik perform a lot of work around auditing third party implementations, analysing and remediating these ‘fires’. We are one of, if not the most technically capable Sitecore specialist agencies in Australia, with two out of the total four Australian Sitecore Technology MVPs in our roster and a 100% project success rate across over 50 engagements. As you can imagine we’ve seen all manner of issues.

With this in mind I thought I’d compile some things we’ve often encountered in our travels and send it to you to see if we can help.

1. Not using the license to its full (or even partial) capability

Easily the most common issue we see is implementations which have been developed in such a way that the powerful analytics, personalisation and workflow capabilities of Sitecore are either not turned on, or outright broken.

Compounding the problem is that often the client doesn’t even know what they are missing! The original Sitecore demonstration of these features may have happened in another time long ago with different stakeholders, and the current marketing team is not aware of the capability at their fingertips.

Ultimately what I tell clients is that if all you want is a fast, slick website then you can achieve that in any myriad of technologies. If you are paying for Sitecore – the ‘Rolls Royce of CMS platforms’ you should be getting bang for your buck and capitalising on the ‘platform’. If you look at the image below, you’ll note that the website is only a tiny part of the platform.

analytics

The real value, and what you are ultimately paying for is the ability to track every interaction with your brand, build it into a robust ‘golden record’ of each customer, and then action this information; drive conversions, learn more about your customers, provide them with a better experience and learn where you should spend your marketing dollars.

We guide customers to using their license to the fullest by evaluating where opportunity exists to use Sitecore features, working with them to segment customers and define engagement values and then progressing through a strategy to use that data.

2. Performance Issues

Sitecore features a pretty robust model for caching and squeezing out performance increases – but you have to actually use it! In our experience the caching model Sitecore uses is not well understood by many developers, and encountering a slow website which isn’t actually caching anything is a common occurrence.

My colleague (and Sitecore Technology MVP) Thomas Tyack wrote a great blog on this topic which you can find here.

Outside of this, a lot can be said about developing a site in best practice and understanding the consequences of certain architectural decisions. Something as simple as deciding which method your code will use for retrieving Sitecore items can have dramatic performance costs when users actually start hitting your website. Likewise a deep knowledge of indexing strategies is needed to tune the way search will work to your particular organisation and context.

3. High deployment risks and large cycle times

Another thing we’ve seen time and time again are Sitecore clients that have had so many issues with deployments that what should be an empowering experience – pushing new features to be customer facing, has become a risky, anxious ordeal. One customer hadn’t pushed a feature to their live environment in over a year!

  • Sitecore uses what can be a particularly error prone method of configuration so it’s imperative that deployments have:
    Appropriate Continuous Integration/Continuous Improvement setup that removes the need for anybody to manually log into Sitecore instances and make manual changes. The environments should be ‘what you see is what you get’ setups with no configuration or infrastructure drift between them. This is probably a good time to plug Aceik Express – our best of breed CICD pipeline we endeavor to use on all projects. Each environment is destroyed and recreated from scratch on deployment so everything deployed is tracked and reproducible
  • Business practices in place to empower multiple teams to develop concurrently. This encompasses the structure of the solutions to enable global, reusable components while managing risk around features which have platform wide implications such as Sitecore Pipelines. We also provide guidance as to the best, risk free practices around synchronising content from your live environment back to developers, testing methodology and graceful disaster recovery.

4. Transparency around solution

It’s often said in finance ‘the market can handle good news, it can handle bad news but what it absolutely can’t handle is uncertainty’. So it is with Sitecore development. The platform is so vast, with so many different options for configuration that it is often difficult for clients to have a clear understanding of the state of their implementation. You may be surprised to read this is not even limited to companies without a strong internal Sitecore team. The nature of the platform is such that unless you are developing across many different, varied implementations you may not be across the gotchas and implications around upgrades, integrations and the various technologies which can be used with Sitecore.

For this reason most of our clients engage us with a Technical Account Manager agreement – essentially a pool of hours with a senior architect which the client can use for technical strategic planning around new features, pre-upgrade analysis or just deep dive questions.

Typically we also start our engagements by performing our robust solution audit, a top to bottom investigation of every issue, gotcha and recommendation we have encountered across our cumulative experience with Sitecore. The output of this audit is a prioritised and sized backlog of issues which can blend with your current product backlog and determine dependencies.

Through these two offerings our clients enjoy the clarity to see where they are on their development roadmap, and plan ahead realistically.

I hope this has been food for thought and allowed you to briefly assess where you are on the totem pole of Australian Sitecore implementations. If you think you’re towards the bottom, or even at the top (and want to stay there!) do let us know if we can help.

We have dedicated architects in Melbourne, Brisbane and Sydney and travel interstate frequently to put a friendly face to our Technical Account Managers.

Thanks for your time,

Michal Strzalkowski
Chief Technical Architect – Aceik.

Creating a custom SXA rendering with variants

In this blog post we’ll step through the process of creating a custom SXA rendering with variants.  For this example, we’ll create a rendering that is used to display information about cars.  By using a rendering with variants, we can add a Car rendering to our page, and depending on which variation we choose, we can display it with a different appearance and different fields.  We’ll create a Car rendering with 3 variations:

  • Summary
  • Specifications
  • Full Details

Template

The first thing we need to do is create the template.  Even though some of the variations only display some of the fields, the template will have all of the fields for a car, and the variations will use only the fields they need.

Template

This template was created in /sitecore/templates/Feature/Cars/Car.

Rendering

The next step is to create the rendering.  Ours was created at /sitecore/layout/Renderings/Feature/Cars/Car.  The rendering should be a Controller Rendering.  Set the Controller (this one has been set to “Car”), and set the Controller Action to “Index”.  Set the Datasource Template to be the template we’ve just created (in this case, /sitecore/templates/Feature/Cars/Car), and the Datasource Location to “query:$site/*[@@name=’Data’]/|*[@@templatename=’Car’]”.  It’s important to set “Editable” to true so that the rendering will be available in the Toolbox.

Rendering

To make the rendering appear in the toolbox, we need to add it to Available Renderings.  The Available Renderings folder is  found under the Presentation folder of your SXA site.  First add an Available Renderings item under the Available Renderings folder.  In this case, I’ve added one called Cars.  Once you’ve added the Available Renderings item, click “Edit” on the Renderings field, and add your new rendering (“Car”) to the list of renderings.

AvailableRenderings

It doesn’t really matter what you call the Available Renderings item, or which Available Renderings item our rendering is added to, because the Available Renderings item is simply for filtering/organising the rendering in the content tree.  It doesn’t actually determine where it appears in the Toolbox.  The folder structure of where the rendering is located determines this.  For example, because this rendering is at /sitecore/layout/Renderings/Feature/Cars/Car, it will appear in the Toolbox under a new category of “Cars”.

Toolbox

Rendering Variants

This is where we setup the 3 variations of the rendering.  To start off, create a new Variants item called “Car” under the Presentation/Rendering Variants folder of your SXA site. Under that item, create 3 Variant Definition items for each of the variants we need.

When the variants have been added, they can be selected from the Variant dropdown list in the Experience Editor:

ListVariants

Under each of the Variant Definitions, we need to insert the fields to be displayed.  The desired layout of these fields will determine how we add the fields.  The fields can be grouped into sections, and the order and hierarchy of the fields directly matches the order and hierarchy of the HTML elements that get rendered.  This, coupled with the “Css Class” field allows you to have full control over the layout and appearance of the variant.   The beauty of this is that once this initial setup has been done, you can add as many variants to this rendering as you like without having to write any more code at all.

When adding the fields, it is important that the value of the “Field name”  matches the name of the field in the template.

As an example, the Summary variant has been created using this following structure:

SummaryVariant

The Css Class for the Image field has been set to “col-xs-3”, and the Css Class for the Car Details section has been set to “col-xs-9”.  The Tags for all of these items are using the default of “div”.  This configuration translates to the following HTML:

<div class="component car">
   <div class="component-content">
      <div class="col-xs-3 field-image">
         <img style="margin:0;" src="/-/media/458B8369BE6D40489797D75DDA8BB79D.jpg?h=114&la=en&w=200&hash=641FD08747F050B6AF1779E77E5BF2C24AB2CEC0" alt="" width="200" height="114" />
      </div>
      <div class="col-xs-9">
         <div class="field-make">Holden</div>
         <div class="field-model">Commodore</div>
         <div class="field-year">2007</div>
      </div>
   </div>
</div>

And it looks like this:

SummaryVariantRendered

As an example, we can have a completely different look for the same rendering by selecting the Full Details variant, which has been setup like this:

FullDetailsVariant

And it ends up looking like this:

FullDetailsVariantRendered

There’s a great article that covers this in more detail at http://www.markvanaalst.com/sitecore-experience-accelerator/the-power-of-the-variants/

Code

This section covers the code that needs to be created in your solution.

First add a new Feature module to your solution, then add the following items:

IRepository

using Sitecore.XA.Foundation.RenderingVariants.Repositories;

namespace YourBusiness.Feature.Cars.Repositories
{
   public interface ICarRepository : IVariantsRepository
   {
   }
}

Repository

using YourBusiness.Feature.Cars.Modes;
using Sitecore.XA.Foundation.Mvc.Repositories.Base;
using Sitecore.XA.Foundation.RenderingVariants.Repositories;

namespace YourBusiness.Feature.Cars.Repositories
{
 public class CarRepository : VariantsRepository, ICarRepository
  {
     public override IRenderingModelBase GetModel()
     {
         CarModel model = new CarModel ();
         FillBaseProperties(model);
         return model;
     }
  }
}

Model

No need to add our template fields in this instance

using Sitecore.XA.Foundation.Variants.Abstractions.Models;

namespace YourBusiness.Feature.Cars.Models
{
   public class CarModel : VariantsRenderingModel
   {
   }
}

Controller

Keep in mind that the controller must inherit from Sitecore.XA.Foundation.Mvc.Controllers.StandardController.  The Standard controller will handle the routing with default action result “Index”, so there’s no need to add our own, although we can override “Index” if we need to.

using YourBusiness.Feature.Cars.Repositories;
using Sitecore.XA.Foundation.Mvc.Controllers;
using Sitecore.XA.Foundation.RenderingVarients.Repositories;

namespace YourBusiness.Feature.Cars.Controllers
{
   public class CarController: StandardController
   {
       protected ICarRepository CarRespository
       {   get; set;   }

       protected IVariantsRepository VariantsRespository
       {   get;  set;  }

       public CarController(ICarRepository, carRepository, IVariantsRepository variantsRepository)
       {
           this.CarRespository = carRepository;
           this.VariantsRespository = variantsRepository;
       }

       protected object GetVariantsModel()
       {
           return VariantsRespository.GetModel();
       }

       protected override object GetModel()
       {
          return CarRepository.GetModel();
       }
   }
}

View

It is important that all SXA components should be wrapped in “component” and “component-content” divs. “Model.Attributes” adds styles from the rendering parameters.

@model YourBusiness.Feature.Cars.Models.CarModel

@if (Model.DataSourceItem != null || Html.Sxa().IsEdit)
{
<div>
   <div class="component-content">
      @if (Model.DataSourceItem == null) 
      { 
         @Model.MessageIsEmpty 
      } 
      else 
      { 
         foreach (VariantFieldBase variantField in Model.VariantFields) 
         { 
            @Html.RenderingVariants().RenderVariant(variantField, Model.Item, Model.RenderingWebEditingParams) 
         } 
      }
   </div>
</div>
}

Config

<?xml version="1.0" encoding="utf-8"?>

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
    <sitecore>
        <services>
            <configurator type="YourBusiness.Feature.Cars.Pipelines.RegisterCarServices, YourBusiness.Feature.Cars" />
        </services>
    </sitecore>
</configuration>

]

Pipeline

Here we register the dependencies.

using Microsoft.Extensions.DependencyInjection;
using YourBusiness.Feature.Cars.Repositories;
using Sitecore.DependencyInjection;
using Sitecore.XA.Foundation.RenderingVariants.Repositories;

namespace YourBusiness.Feature.Cars.Pipelines
{
   public class RegisterCarServices : IServicesConfigurator
   {
      public void Configure(IServiceCollection serviceCollection)
      {
         serviceCollection.AddTransient<ICarRepository, CarRepository>();
         serviceCollection.AddTransient<IVariantRepository, VariantRepository>();
      }
   }
}

 

Part 4: Instant profiling/personalisation

This is the last part in a four-part series on Customising the Experience Profile. This last part covers off Instant Personalisation.

You can view Part 1, Part 2, Part 3 via the respective links.

Essentially the story goes that as a marketer you sometimes already know things about your visitor before they reach your website. Posting an ad on Facebook or other social media channels is a great example of this.  By enabling a custom code pipeline we can achieve this via a parameter on the inbound link from social media.

The solution involves a custom analytics pipeline that is executed before the page is loaded.
  • It can be activated by adding a query string on the end of any URL.
  • For example http://www.scooterriders-r-us.com.au?pr=scooterType&pa=fast
  • This would look in the “scooterType” profile and assign the key values for the “fast” pattern card.
  • We set it up so that a user can potentially be added to three different profiles from an inbound link   ?pr=scooterType&pa=fast&pr2=safety&pa2=none&pr3=incomebracket&pa3=budget
  • Some of the logic used was derived from this StackOverflow ticket.

Now for the Technical Implementation:

Test it out by:

  • Creating a profile with a pattern card (or several combinations)
  • Setup a page with a personalised content block that will change based on different Profile Pattern matches.
  • Creating a new inbound link to your page using the link parameters explained above.
  • Open a new incognito window so that a new user is simulated.
  • You should now see the correct personalisation for that user on the very first-page load.
  • Confirm that pattern match inside the Experience Profile for that recent user.  Note that if Experience Profile is not set up to show Anonymous users this last step requires some configuration changes.  This is mentioned in part 1.

Conclusion:

By adding a very simple customisation to Sitecore we can give marketers that ability to leverage social media to achieve personalisation very early on.

Part 3: External Tracking via FXM and Google Client ID

In this third part of our Experience Profile customisation series, we look at how we might integrate FXM into a third party website.  For the purposes of this blog, we assume the third party website is not built with Sitecore.

You can view Part 1, Part 2 and  Part 4 via the respective links.

A great example of where you might want to do this is if you link off to a third party shopping cart or payment gateway. In this particular scenario, you can use FXM to solve a few marketing requirements.

  • Pages Viewed: Track the pages the user views on an external site.
  • Session Merge: Continue to build the user’s Experience Profile and timeline.
  • Personalise content blocks in the checkout process.  Great for cross promotion.
  • Fire off goals at each step of the checkout process.
  • Fire off goals and outcomes once a purchase occurs.
Note: In the examples that follow we also show what to do in each scenario for single page application. View the footnote for more details about how you might support these with regards to FXM.

So let’s now examine how each requirement can be solved.

Pages Viewed

Page views are a quick win, simply injecting the beacon will record the page view.

For a single page application, each time the screen changes you could use:

SCBeacon.trackEvent('Page visited')

Session Merge

If you inject the Beacon on page load you get some session merging functionality out of the box. If you have a look at the compatibility table for different browsers it’s worth noting that Safari support is limited.

Here is a potential workaround for this notable lack of Safari support:

  • Follow the instructions in Part 1 to identify a user via Google Client ID.
  • When linking to the external website pass through the Google Client ID (see part 1 for more details) as a URL parameter.
  • ?clientID=GA1.2.2129791670.1552388156
  • Initialise google analytics with the same Client ID.  This can also be achieved by setting the Client ID on the page load event in the GTM container.
  • function getUrlVars(){var n={};window.location.href.replace(/[?&]+([^=&]+)=([^&]*)/gi,function(r,e,i){n[e]=i});return n}
    ga('create', 'UA-XXXXX-Y', {
      'clientId': getUrlVars()["clientID"]
    });
  • Inject the FXM beacon
  • Setup a custom Page Event called “updateGoogleCid” in Sitecore.
  • Hook up a custom FXM procesor that will merge the session.

The process above works for single page applications as well.

Trigger Goals

Out of the box triggering a goal is easily achieved by ‘page filter‘ or ‘capture a click action‘.

For single page applications, you can use the following API calls in your javascript.

SCBeacon.trackGoal('Checkout')

Trigger Goals and Outcomes on Purchase

Out of the box triggering an outcome is achieved via a ‘capture a click action‘.

For the purposes of checkout, you are likely to want to see the dollar value purchased for that particular user in the Experience Profile. In order to achieve this, you need to use the javascript API to pass through the dollar value.  Be sure to create an outcome in Sitecore called ‘Purchase Outcome’.

SCBeacon.trackOutcome("Purchase Outcome", 
{ 
monetaryValue: revenue, 
xTransactionId: transactionId
});

A great tip that we received from the SBOS team in Australia was to trigger goals at checkout that had engagement value staggered according to the amount spent.

So, for example, you may have some javascript logic that looks like this:

if(revenue <= 99)
{
     SCBeacon.trackGoal('lowvalue')
}else if(revenue >= 100 && revenue < 500)
{
     SCBeacon.trackGoal('midvalue')
}else if(revenue >= 500 && revenue < 1000)
{
     SCBeacon.trackGoal('highvalue')
}else{
     SCBeacon.trackGoal('veryhighvalue')
}

For single page applications, you will need to use the javascript API.


 

Conclusion: In order to use FXM on any external website not built on Sitecore you need access to insert the Beacon code. If the external website is not a Single Page Application (also note some other limitations) you can use the FXM Experience Editor to achieve much of the desired functionality.

For those external websites containing Single page applications, ideally, you can also get access to either the GTM container or get the external website to insert some javascript for you. Using some clever javascript coding you can still record marketing events using the FXM javascript API. 

To continue reading jump over to Part 4, where we cover off a handy way to get personalisation working on the very first-page load.


Footnote: Single Page Applications

It’s important to note that out of the box FXM does not support single page applications. Look a bit further under the hood however and you will realise that FXM includes a great Javascript API.  After mentioning that you might now be thinking that if its a third party website you’re unlikely to get access to the source in order to implement any API calls.  At the end of the day, your going to need some sort access to inject FXM in order to achieve any sort of integration.

At the end of the day, your going to need some sort access to inject FXM in order to achieve any sort of integration.

This will likely place you in one of the following scenarios:

  1. Not a single page application, in which case you just need the external website to include the FXM beacon. (instructions)
    • This is by far the simplest scenario and happy days if your in this category.
  2. A single page application, with which you have access to make changes.
    • In this case, inject the FXM beacon on page load and use the Javascript API to trigger events, goals and outcomes.
  3. A single page application, with which you have no direct access to make changes, but can request changes to the GTM container.
    • In this case, a great backup is using the GTM container to inject the Beacon. You can then write custom javascript that uses javascript listeners to talk with the FXM API.
    • With some single page application frameworks (Angular, React, Vue) hooking into the existing javascript listeners will prove difficult. Your last remaining option may turn out to be inside the GTM container again. If the application is already sending back telemetry to Google Analytics, make good use of it. This could be achieved by either:
      • Writing a custom javascript snippet that looks for changes in Googles datalayer.
      • If events are configured directly in GTM, simply ask for changes to each event to include an FXM API call as well.
  4. If your unlucky and you have no access to make changes at all …. well …..
    •   shrug