Friday, October 26, 2018

SXA Data folder behavior

Let me start of with a general clarification for those of you who have little to no experience with SXA.
With Sitecore Experience Accelerator, data sources can still be stored in multiple places. And by default, your page's datasources will be stored either under a site-wide data folder node or the data folder located underneath your actual page.
Meaning that everything related and uniquely linked to a page is simply nested underneath that page and those blocks of content that allow further re-use are found on a higher data-repository level.

When adding a new component you are presented with the following option to select or create a new piece of associated content:



However, from time to time some unexpected behavior might pop up. Sitecore, by default, will use the Sitecore GUID as reference point for the datasource location in your presentation properties.
However, with SXA, the relative path of your datasource is used instead


SXA chose this approach to make the behavior more logical for end-users. Because when you copy a page with this approach, you actively create new nested datasources that can be modified within the scope of that page and that page alone.
When a reference is made based on the datasource Id, copying a page A to create page B results in cross references between B and A. So when a block of content is modified on page A, that same change will become visible on page B as well.

Now, back to the essence of this blogpost ;)


One of our customers had reported strange behavior with one of the created pages. 
Out of the blue one of the pages was displaying the wrong information inside the Experience Editor whereas the information portrayed on the published site was still correct.

On detailed inspection we came to the first conclusion that the datasource that pointed to the Data folder (in this case: local/Data/Text3) did not actually use that datasource...
Inside the Experience Editor if you clicked the : "Edit associated content" the editor jumped into an item nested underneath another item (an SXA redirect in this case) that had its own Datafolder with a Text3 item...

Changing the name and location of this Text3 item did indeed change the behavior of the Experience Editor to use the correct child datasource item again. Meaning that the problem must be somewhere in how Sitecore resolved which datasource to use.

So, what was going on? The customer had created a redirect page with the same name as another item in Sitecore (our problematic page) but had assigned a display name on that item.
Since the redirect page was higher up in the hierarchy of the Sitecore tree, when the Experience Editor was resolving the datasource for Text3 it was doing this by path. And apparently SXA replaces "Local" by the actual full Sitecore path instead of looking for child items.

This resulted in the redirect item to be found as the actual item where new and existing changes for the datasources should be created and searched.

The solution was a simple as the reason that this problem came to be: change the name of the problematic page to the displayname that das been assigned.
Since the redirect item handled the original url/path it could now safely redirect to the target page, which in turn was able to resolve it's datasources to it's own child pages.

Conclusion 

Be careful around the current implementation of path-based datasource resolution. As Sitecore allows for items to have the same itemname (GUID is different so Sitecore is fine) resolving paths will always end up with the first hit in the hierarchy.

Switch between Path or Guid datasource


Keep in mind however that SXA provides script that help you switch from the path based approach into the ID based approach. 

So, if for any reason, the path approach is not sufficient you can use the following:



Thursday, June 28, 2018

Setting SXA security roles (with a small twist)


General setup 

 After setting up your SXA project, one of the next things you typically want to do is follow a myriad of guides to help finalize your setup.
One of these is to set up Security based on the SXA sites.
In order to do this, a number of the powershell scripts exist that are offered by the SXA product out of the box to help you set up the Tenant as well as the Site Security.

You can find all relevant information her:
https://doc.sitecore.net/sitecore_experience_accelerator/setting_up_and_configuring/setting_up/set_up_security_for_a_tenant_and_a_site

After you do this, I did however notice a problem...

We created a number of editors that had the 'Site author' and 'Site designer' roles.
However, the created users were not able to do all necessary actions immediately.

This user is now indeed able to log in and see and edit that SXA site.


First issue


But when we performed the following test:

Create a new page (Page type) > go into the Experience Editor > Add a (default) Promo block
At this moment the experience editor gives a popup that lets you create site content or content under the Data folder.
> We click the Create button next to the Data folder ...




And there we get a popup warning screen that says that this users does not have access to create that content...

This immediately felt like a problem in the SXA setup since I tested this on a vanilla SC9 and SXA 1.7.1 installation...

After some investigation and great support from the Sitecore SXA team they acknowledged this as a bug on their side and we found the following solution:

As a workaround for the issue, you can try the following steps:

1. Go to the item: /sitecore/system/Settings/Foundation/Experience Accelerator/Local Datasources/Virtual Page Data
2. Add the permission for the "Create" security right for all the needed users or role.  (In this case that is the SXA Author created role)

Publishing Issue

Just another thing to keep in mind is that with these rights, the editor is not able to perform any publishing. This might be by design for the users you just created.

If you do want to grant the publishing rights, then just assign the Sitecore Client Publishing role and they are good to go.

HOWEVER
If your intent is to take away publishing as a whole then there are some next steps.
As you will notice, the Publish section on the Ribbon is indeed as good as empty and no publishing is possible from there out.

However, right clicking on the Content Tree in Sitecore will still give you the option to publish. As well as the Publish button on the Experience Optimizer section in the Experience Editor that is still available...

Clicking this will however result in the following error:



So, actually apart from confusing the editors they are virtually unable to ever publish anything.

If you want to resolve this, make the following modifications to the security on the roles:

 1. Go to the Security Editor;
2. Select the sitecore\Sitecore Client Designing role;
3. Navigate to the  /sitecore/content/Applications/Content Editor/Context Menues/Default/Publish Item item.
4. Forbid rights inheritance as described in the below screenshot:



5. Select the sitecore\Sitecore Client Publishing role;
6. Allow the Read access explicitly as shown on the below screenshot:



7. After that, assign the sitecore\Sitecore Client Publishing  OR sitecore\Sitecore Client Advanced Publishing roles to your user.




There you go, you should be all set and ready to go :)