Wednesday, October 9, 2013

Sitecore Users Virtual Summit - October 15 - 16, 2013

The Sitecore Users Virtual Summit is an awesome 24 hour summit happening online on October 15-16 You can check out the schedule. Its online and running 24 hours.

You can tune in for the presentations you want. Check out the schedule Some key ones to check out:

There are two presentations on Active Commerce by Nick Wesselman. CTO at Active Commerce, Sitecore MVP.


One on Automated Testing


One on SheerUI


There are a couple on DMS:


Howard Kim is presenting.  Looking forward to that.


The plus to this Summit is you don't need to travel, you can tune in from anywhere. The presenters are high caliber as are the topics.

I look forward to seeing everyone online taking part in these presentations.

Saturday, October 5, 2013

QuickStart: Deciding what Data Goes Where


One of the biggest factors in a successful Sitecore implementation is determining where data is stored.

These storage locations can be grouped into four types:

a) Sitecore Content Tree
b) Local Data Sources
c) Enterprise Data Sources
d) External Data Sources

The initial tendancy is to place everything in the content tree especially if you are not working with Enterprise Data Sources or External Data Sources.


What To Store In The Content Tree
---------------------------------

The Sitecore Content Tree is a good place to store data that is easily placed in a hierarchy of 1 to 1 or 1 to many item relationships.
It is NOT good at storing data that is tightly related to many other items.  It is also not as great a storing large volumes of direct children unless you take

advantage of such modules as Item Buckets.

The key question to ask when considering placing content in the content tree or media library is:

* Is this content only used by Sitecore or is it used by another application such as CRM, SAP, Sharepoint or some other system?
If this content is only used by sitecore in most cases this data should live in the Sitecore Content Tree, or Media Library.
There are some exceptions such as User Management/Security which may be only used by Sitecore but does not make sense to be in the content tree or media

library.  User Management is discussed in another Blog Article.

* Does this content need to be editable by content editors or is the data edited in external systems or only by users of the website?
If content editors will not be editing this content then the additional overhead would not necessarily be worth it and you are probably better served storing
it in the external system, additional SQL Server database tables, or in another data source.

* Other than for reporting, is this data read by any other website components?
If the data is only being collected by sitecore and then displayed in a report or used by the rules engine, you don't really need to store it in the content

tree.  Storing it in an external table would allow data to be queried more easily for reports or dumped to external reporting applications.

Here are some examples of data to store in the Content Tree:


* Page Hierarchy: By this I mean the website root node and all the pages used to build your navigation.  It makes sense to store this as it helps
  structure your content.

* Static Page Content: This is content related directly to a page.  It may be as simple as a title and a description and whether it is included in sub navigation.

* Resource Strings: These are all the field labels, static descriptions, help messages that are straight text with no formatting.

* General Site Settings: These are settings either related to the entire sitecore instance or per site. These are specifically setting that need to be edited by the

end user.  These settings are instance-wide and do not change often then you would want to place these in the .config files.
 
* Media Items such as images, PDF, Word Documents, PowerPoints, etc should be stored in the media library.

* Semi-static lookup lists.  This includes country lists, departments, regions, currencies, etc.

* Generic content items:  These are content items that will be updated, possibly need approval and then get published.  They can be shared across many pages.
An example would be a an article.  It may exist in an article page, but also be featured on a front page, or in a content rotator.  This single piece of

content would have all the information in one place and be referenced on the multiple pages.


Some examples of what NOT To Store in The Content Tree
------------------------------------------------------

* User Information such as logins, roles etc.

* Reporting Data and Logs are best stored in a local data source as this data will be written once and then reported on.  End users will NOT be editing this data.

* Product lists, e-commerce purchase transactions.



In an external database directly accessed via the Sitecore Web Application (three-tiered of course).  This would also include any imports and extracts
c) Cloud/external data sources (eg. via web services, Sitecore Connectors, etc)



QuickStart: Securing Sitecore

Sitecore is built on the standard .NET Membership Provider.  As such developers will be familiar with how it functions under the hood as far as creating user, profiles and roles.  However, it can become a little more complex when dealing with securing content.  Content needs to be viewed and edited by users who log into the Sitecore Admin, whether it be the page editor, content editor, or media library.  As well, content needs to be viewed and edited by users accessing the public website.  This can be confusing especially if you have not mapped out a roles matrix first.  This Quickstart will help walk you through the steps you need to ensure you have a secure sitecore installation.

Ensure before going to Production that you follow the checklist at the end of this blog post to ensure you have secured your Sitecore Installation.

1) Develop a role matrix

Roles are used to determine which of people will be responsible for reading/editing/publishing content.  Depending on your implementation, certain people may only be able to accessing certain content.
Some may access the page editor, while others need the content editor, and still others need the desktop.  
  
 It is very tempting especially when working with small companies to map users to their access.  Joe is the one uploading pdf files and editing content. Mark will will be the one proof-reading the content and then publishing it.  Rather, Joe is a content editor and Mark is a publisher.  So your role matrix would be:

Role
-----
Admin
ContentEditor
Publisher

RolePermissions
-----------------
/sitecore/content             Admin                          Read/Write/Publish/Admin/Delete
/sitecore/content             ContentEditor               Read/Write/Publish

User Roles
------------
Joe                     ContentEditor
Mark                 Publisher


Production Promotion Security Checklist

1) Important Sitecore provides a default “Admin” user which has unrestricted access. By default, this user has the password “b” (lower case, single letter). You should change the password associated with this account and store the password in a secure location.
2) Ensure /Sitecore is in the robots.txt file
3) Ensure you register your site with webtools and exclude this path there as well.
4) Log in as a user of each role and double check that you cannot read/edit specific content you have secured.  The access viewer can help ensure you see a sea of red.


Quickstart: creating a sitecore package

Although the preferred method for deployment is through Hedgehog, sometimes it it necessary to build a sitecore package to deploy or share your sitecore modules.   If you are deploying a build and You will want to split your packages up to avoid reference issues.  I tend to seperate them into 4 packages: data templates, media library, sublayouts/layouts and content tree.

Note: if you run into conflict issues you may have to break the content package into pages and content then deploy content package before pages.

If you are building a package for a module then you will be including everything in one package.  This would include dll and other physical files.  If you are including config changes always include them in an includes config and dont overwrite the existing config.

STEPS

1 open the browser and navigate to the sitecore admin

2 ensure you click options to and select desktop

3 enter your username and password and login

4 click on the Sitecore menu and click on developer tools

5 click on package designer

6 click on new to create a new package

7 give the package a name

8 save the package

9 enter a name to save the package xml

10 in the menu select static items to add items to your package.

NOTE: although tempting avoid using dynamic packages as you may unintentionally miss content items needed or include more items than you need.

11. Click on the item you need and if necessary choose add subitems.

12 if there are more items in the group add them the same way.

12 click next and enter a name for the items.

13 save the package

14 generate the package

15 once generated click on the globe to download it

When you are ready to deploy the package check out the quickstart on how to install a package using Sitecore ROCKS or how to install a package if Rocks is not installed.




Sitecore QuickStart: Create Visual Studio Project

In Sitecore Training you learned how to create a Visual Studio Project for your Sitecore Instance.  This is an awesome start for your first project, however as you start to share functionality across projects, create your own modules, or start working in a multiple sites per instance scenario, you may need multiple projects per instance.

In the solutions I have architected, I generally will leave the Sitecore instance as is and create projects in their own projects folder.  These projects can then be deployed to the sitecore instance as needed by copying over the dll and any layouts, sublayouts etc.  Architecting the Content Tree and Physical Folders will be in a future QuickStart.

In this blog article, I will be creating a Visual Studio Project that could be used for a single site within the Sitecore Instance.

Step 1: Create a Visual Studio Class Library.

Click on the File Menu and Click New and then Project 


On the left panel ensure you have clicked Windows then on the right click Class Library.  Name your project and directory to store your project.

Step 2: Add References To Sitecore Kernel and Sitecore Logging

In the Solution Explorer Panel, Right click on References then click on Add Reference...

Click on the browse tab and navigate to the bin folder of your sitecore instance.  Select the Sitecore Kernel and Sitecore Logging DLLs.  Alternatively you could place these dlls in a shared folder.  Click OK to Add References.


Add References to your project for System.Web 


Step 3: Create folders for your Sitecore Components
NOTE: This is a very basic folder structure.  Your project may have a more sophisticated structure to represent your solution. However the concept of deployment on build is the same.


STEP 4: Add Build Events

Right click on your project and click on properties


Click on Build Events

In the Post-build events command line paste the following.  

xcopy "$(ProjectDir)Layouts" "C:\inetpub\wwwroot\SitecoreQuickStart\Website\Layouts" /s /I /y
xcopy "$(ProjectDir)Renderings" "C:\inetpub\wwwroot\SitecoreQuickStart\Website\Renderings" /s /I /y
xcopy "$(ProjectDir)Sublayouts" "C:\inetpub\wwwroot\SitecoreQuickStart\Website\Sublayouts" /s /I /y
xcopy "$(ProjectDir)bin\debug\SitecoreQuickStart*.pdb" "C:\inetpub\wwwroot\SitecoreQuickStart\Website\bin" /s /I /y
xcopy "$(ProjectDir)bin\debug\SitecoreQuickStart*.dll" "C:\inetpub\wwwroot\SitecoreQuickStart\Website\bin" /s /I /y

NOTE: Change SitecoreQuickStart to your project name.  You may need to add more dlls to copy, however do not be tempted to do a *.dll as you may end up overwriting other versions of dlls in the Sitecore Instance.  It is better practice to only copy over the dlls you require.  Also, we are copying the Layouts folder to the Sitecore Layouts folder directory.  For larger projects it is better to create subfolders beneath the layouts folder unless the Layouts are needed for Sitecore Admin Applications, but that will be discussed in a future post on creating Sitecore Admin Applications.

STEP 5: Compile Your Solution

From the Build Menu Choose to Build Solution.  Once completed it should have copied your Sitecore Components to the Sitecore Instance or reported errors in the error list.

Now that your Sitecore Project is set up, the next step is to create your Sitecore Components in the Sitecore Content Tree.
















Sitecore How-To: Set the Data Source Property of a Sublayout

The Data Source property of a Sublayout is used when the sublayout needs to use a content item other than the current item.

For example, you may have a landing page with various callouts to other content. These content items would exist in other parts of the tree. For these callout Sublayouts you would not want them accessing the current page item, you would want them pointing at another object that would store the callout title, image and link.

Here are the steps to set the data source on a sublayout on a page.
  1. Login To Sitecore and open the content editor
  2. Navigate to the page you want to edit
  3. Click on Presentation -> Details in the top menu
  4. In the Details Panel click on Edit
  5. Click on Controls to see the list of sublayouts
  6. Click on the Sublayout you want to change the data source for
  7. Click on the data source field. You can either manually enter the path or click browse to choose the content path from the tree dialog
  8. Click ok to save
  9. Click ok to close all the other dialogs