Sitecore Context and Scheduled Task

Something I learned today (the hard way) was about the Task Scheduler and the Sitecore context. The context decides which database to use - core or master. 

A little background, I am working on a project where the scheduled tasks of importing content was already set up.  Not an excuse, only that for this project, I haven't looked into the scheduled task as of yet.

During a release we saw that a scheduled task actually ran under the core context instead of the usual master context, causing the task to fail.  Why all of a sudden did this happen?  Our release had nothing to do with the config, nor did it have anything to do with the task scheduler.

What we found out, the legacy code that the task scheduler runs on, was NOT specifying which context to run under.  So timing was the fluke during the release.  Let me explain.  There are config values of course that tells the task scheduler to run under which database.  The out of the box is located in Sitecore.config, it was later updated (as best practice dictates), in a patch file.

Looking at the: https://DOMAIN/sitecore/showconfig.aspx it showed both the patch file entry and the out of the box core entry for task settings.  The core one was set to run every 10 minutes and the custom one (master) was set to run every 5 minutes.  Timing was why the task failed because the context switcher, switched to core at some point, and our code never set it back to the intended master context. BIG PROBLEM!

So after some research we found a great article on Google from kiranpatils on (https://sitecorebasics.wordpress.com/2014/08/09/scheduled-task-basics/) that stated the best practice.

LESSON LEARNED: Always wrap your tasks calls with the intended context with the using command. 

Once we wrapped the code, all was well and life was once again delightful!

AMP (Accelerated Mobile Pages) within a Sitecore Site

So I was tasked with turning the article section of one of the websites I am responsible for into an "ampy" type site.  First of all, AMP stands for Accelerated Mobile Pages.  It is a very stripped down version of the content that has many strict rules to enable performance of the article to be displayed within a mobile device.

Some of the rules are:

• Cannot embed custom JavaScript
• Cannot link to custom JavaScript
• Only amp provided JavaScript files can be used
• Cannot link to css files
• Cannot have inline styles within the markup
• Cannot have !important in your custom style section
• Image tags need to be represented with instead of
• Ads must be able to be pulled from a provider that honors amp.

Some of my heartaches included first of all how to get my site to recognize an AMP request.  So I plagiarized a great idea from @sitecoreRick at this URL from stackexchange.  Thanks @sitecoreRick!

I created a device type named AMP.  Then I set up a querystring param to recognize when that "device" should be honored.  So when the querystring comes in, the AMP device is triggered, thus using the renderings based upon that device of AMP.

Simple, huh...Well in Sitecore as always, that was the most solid piece of this whole pie.  The rest was modifying the AMP specific renderings to honor the dictatorship rules of the AMP project.

The next heartache was how to test this AMP response locally.  Well thankfully Google Chrome has a plug-in that allows you to test the HTML as you go.  Whew!  Because I had 67 errors on my first test.  

My last errors was converting my hamburger menu to a CSS driven only (no JS) component and that led me to a green button and quite a bit of dancing.

Now we see if the ROI is there for this new(ish) thing called AMP, or is this just another passing web fad...Time will tell!

Does your Sitecore site need professional help?

To be clear, Sitecore is an amazing tool…If implemented correctly.  In the implementations, I have seen and been a part of, there are some good implementations and wow there are some bad ones.  

Here are some signs that your Sitecore site, may need some professional help.

Flat Sitecore tree:

• It is suggested that you organize your content in which makes sense to the content contributors as well as the structure of your site.  If any tree node has more than 100 items in it, then performance will decrease significantly.
• Solution: Try to organize your site early and often, working with your dev team to ensure site stability.  Also try bucketing, it was introduced a few versions back and it is truly an amazing way to find content as well as keep the performance intact.

Use of webforms:

• The webforms methodology is slowly (most say quickly) dying off in the .NET world.  It is heavy on the backend, as well as it is very difficult to handle session state appropriately.  Finding support will and already is tougher and tougher to find as time goes on.
• Solution: Convert to MVC.  Sitecore has really adopted the MVC methodology and the newer the versions, the better it has become.

Minimal renderings (or Sub-Layouts):

• This really keeps the site from being flexible without always having to involve development. 
• Solution: Smaller renderings allow for sections of the site to be built like a puzzle.  This also allows certain sections of the site to have little visible components as needed for mini-sites or campaigns.

Limited usage of the Sitecore datasource feature:

• This typically keeps a rendering from being dynamic and can mean some renderings are not reusable. 
• Solution: When creating renderings, you should always make them flexible and reusable – while towing the line of not being too complex for the Content Authors.  The use of a datasource to drive which content is to be displayed for the rendering is a way to reuse the rendering without hard-coding the source.  

Repeated template fields:

• Templates are just like little data table structures.  If you repeat data fields over and over in different data, then you will have duplicated data structures throughout your site.  Maintaining this becomes increasingly more difficult as it continues to grow.
• Solution: Practice good template inheritance. For instance, if you have a title field, create a titles_base and every custom template that requires a title will just inherit the titles_base template. 

Bonus: If you are on version 7.5 and below

Eventually support will end with older versions from Sitecore.  This means the main response would be to undergo an upgrade.  It will become more difficult to find specific expertise on the limitations of the older versions.

For more information: here is an interesting read:

https://www.cmsbestpractices.com/sitecore-best-practices/

Thanks! 

@kmacnbama

Sitecore Professional since 2009 and aspiring Sitecore MVP

Enterprise Service Bus (ESB) within an environment that includes Sitecore

How would/could an Enterprise Service Bus (ESB) work within an environment that includes Sitecore?

So on #slack I had a great conversation with another Sitecore genius. They are going down the road of implementing a service bus into their landscape.  So I took that conversation and thought I would blog about it. 

First of all, the definition of an ESB:
An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates the features required to implement a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (especially legacy versions) to present a single, simple, and consistent interface to end-users via Web- or forms-based client-side front ends.
(http://searchsoa.techtarget.com/definition/enterprise-service-bus)

Layman’s terms: A tool that can centralize all or some service requests for one or more consumers from the service's source system.

Sitecore comes with a plethora of services via a great API suite.  Sitecore has its own data dictionary that may align with what your corporation needs or not.  Sitecore APIs for the most part mainly touches the Sitecore landscape.  Granted the pipeline customization ability is fantastic to touch other IT assets, but for arguments sake, out of the box Sitecore APIs really only affect Sitecore “stuff”.

In many of my implementations of CMSs (especially Sitecore – because it is supreme), the CMS is only one piece of the pie in each environment.  To tie all of the IT assets together most go with a design pattern that involves an ESB.  

Now this is where the meat of this blog begins.

Problem:

Let’s say we have a custom CRM, an Ecommerce platform, and a Tic-Tac toe score keeping system.  And most importantly your Sitecore CMS.  Many of those systems have exposed services for reusability and API capabilities.  These services can have versions, different contracts, etc that have different data models to adhere to.  How do we solve this potential traffic jam?

Solution:

Your options:

1. Keep track of it in your head (please retire, and enjoy your senile mind-hood which you have probably entered into at this point). Problem of a 1 to 1 contract for each function is needed from source system to consumer exists.
2. Keep up with them in a spreadsheet. (Usually it is recommended that after 50 services – it’s time to mature up a bit in your architecture). Problem of a 1 to 1 contract for each function is needed from source system to consumer exists.
3. Invest in an ESB to be the central hub.  The good ones come with a service registry to keep track of all endpoints and their respective versions.  The ESB usually comes with a translation and queuing layer as well for data model translation and queuing. Problem of a 1 to 1 contract for each function is needed from source system to consumer goes away.

Here is an example of #1 and #2 in play...

Here is an example of #3

Keep in mind, the ESB is a tool like any ole hammer.  Unless you know how to use it, it could be just another thing to nail a nail in.  

Also, this tool if too many people have access needs a bit of governance to ensure spaghetti doesn’t start to take place.  I like to eat spaghetti, but I don’t like to work with it all the time.

Whatever your design strategy is, I hope you follow the KISS principle.  Keep It Simple Silly!

Moving Sitecore items from one system to another

Steps on how to move Sitecore items from one system to another...Remember to use the desired database for this.


Source System

Select the content from the "Source System".  to do this go to the Sitecore desktop and click the "Start Menu" > "Development Tools" > "Package Designer"

Enter the name of the package, and click the "Items Statically".

Select the tree items you desire, then select either "Add with Subitems" or "Add Item".  The click "Next"

Enter the Name in the "Source System" field

After selecting Next and Close.  At the main window, select "Generate Zip".  This is where we create the downloadable file for the target system.

Enter the name desired, and click next and you will see a download icon.  Select that icon and you will now have on your local machine, the zip file with your Sitecore items.

Now to the Target System

From the Sitecore desktop, select the "Start Menu" > "Development Tools" > "Installation Wizard"

Select "Upload Package".  This will allow you to find the downloaded zip file from the previous steps and upload that zip file.

Once uploaded, choose the package, then remember to not choose to restart anything.  Once you are done, navigate to the location in your tree to validate that the package did indeed upload as desired.

SEO and Friendly URLs

Remember the days where the links were structured like so:

http://www.somedomain.com?pageID=12

This made it difficult for Google and other Search engines to properly find and title their search results.

So you saw URLSs turning into this:
http://www.somedomain.com/article/this-is-much-better

NOW, when the SEO algorithms and magic gears and a little bit of pixie dusts runs, then the pages are much easier to find and store for future searches.

This is simply applying a friendly URL instead of the ugly "pageID=12".

Sitecore and WordPress offers that as a part of the package when it comes to Friendly URLs.  Every time a new piece of content is created, it turns the title of the content into a the URL (replacing the URL with dashes).  All the more reason to gravitate to one of these WCM systems.

Try it, you will see your SEO results shoot through the roof!

Enjoy!

Rules In SEO

If you want to build a successful business on the Internet, you can spend as much money as you can afford on a Google AdWords campaign and other forms of advertising. However, it has been proven in the Search Engine Marketing industry that at least 40% of the time, your clients will find you through Google and other search engines.

This fact alone makes it very important for any serious Internet business owner to learn the basics of Search Engine Optimization. If you can’t do it yourself, at least you can’t be left in the dark on the methodologies if you decide to hire an SEO specialist.

And just what are these SEO basics?

Website Design and Navigation

These are the most important aspects of SEO. A website that succeeds with both search engines and website visitors are those that are easily navigated and are designed in simple HTML. When these two elements are combined, they make up for a good visitor experience and easy crawling by the search engine spiders.

Some of the things to avoid in website design are dynamic page and URLs, frames, flash elements, Java script, and image maps for web page interlinking or sitemap generation.

Keyword research

SEO is based on the premise that an unknown number of Internet users are searching for a host of things on Google by typing in search terms called keywords. If you want to know the popular keywords that is appropriate to the business your website represents, research exhaustively on keywords.

In deciding what keywords to use, there is one rule: “the more specific the better”. If you own a dating site, for example, “true love” or “soul mate” might be too broad. Run the keywords on Overture and Wordtracker. You might find keywords that are more appropriate to your site like “True love for marriage”, perhaps?

Keyword Density and Relevance

Search engines, specifically Google, determine what websites go to the top of your search based on relevance. This is determined in part by keyword density, or how many instances a keyword appears in the web page’s content.

Write your content according to density. Do not spam, though. Aside from sounding gibberish, spam content also gets flagged by search engines and websites containing them are removed from the index.

Relevance and Inbound Links

Search engines also consider inbound links to your site (specifically, their number and quality) to determine your website’s relevance to a keyword.

Make time to find the sites related to your website. Also make sure that the hyperlink to your site found on the other website has your keywords in them.

Don’t scoop and link though. Google once penalized websites that linked with 200 to 300 other sites per month.

An Opportunity On Each Page

On each page on your website there is actually an opportunity for you to rank for a different keyword each time. Notice how two different pages by the same website are generated for the same keyword. Go ahead and assign different keywords to each. Write and optimize accordingly.