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:

You can find the script here: https://www.dropbox.com/s/7kmru7wm75utumc/SXA%20-%20LocalDataSources.zip