I was using XBlog as nice and simple solution for maintaining the blogs on Sitecore (at least for editors), but unfortunately the original repo has not gone along with the progress Sitecore XP does - the last update dates as 3 years ago for some Sitecore 9 related configs, while the rest of it is 6 years old.
I tried using the 'Sitecore 9' branch of the original repo but unfortunately it did not go well. If installing it from the packages - then it had minor issues even with declared version 9.X, which in fact in fact had the very wide range of changes int between of 9.0.1 till 9.3. Not to say version 10.* therefore:
I decided to refactor it instead!
You may find the successful result of this exercise published at my corresponding GitHub repository, that one worked out for 10.1 and tested well there, but since all versions 10.X share the same runtime it should work universally on all of them.
Few notes on what has been done:
- much unwanted legacy stuff such as support for WebForms has been entirely removed
- the IDs of items have been retained, so that helps upgrading existing solution with 1000s of posts
- there were changes done to reflect reworked Content Search of the XP platform
- found and fixed in Bucket items creation logic, related to events suppression
- serialization changed to the one using CLI, officially released as the part of Sitecore 10
- few more minor changes and improvements in references, runtime, confutation, etc.
Please also note: XBlog uses fast query which declared to get deprecated in Sitecore 10.1, but that particular code works perfectly well, and I cross-tested it in debugger to confirm: the fast queries return that expected result I queried. Just for the future references, fast queries have been used in
The resulted code can be found here: XBlog for Sitecore 10.1
Sooner or later, you'll face it - the need for Sitecore version upgrade. However, each Sitecore instance is unique, there is no universal method for an upgrade, therefore each upgrade path is bespoke.
In the past 10 years working with Sitecore I have done numerous upgrades, resulted in Upgrade Planning Strategy and a set of Upgrade Tips and Tricks. These tips will help saving 2-3 times (!) on spent efforts, comparing to direct approaches.
Last but not the least. versions 10 and 10.1 brought new challenges and options of migrating existing solutions into containers. I will explain your options and propose best approach on this as well.
I have lodged the speech proposal for SUGCON 2021 and fingers crossed to
be chosen, so that I will share the whole presentation and sides
updating this blog post.
There is still no "silver bullet" for Sitecore upgrades, but following tips from my session will eliminate risks, reduce efforts, and bring you confidence while upgrading your instances.
I am going to tell you about:
- How to approach the whole instance upgrade
- What are the upgrade time-wasters
- Common and potential traps to avoid
- Dealing with configuration upgrade, and why that's not as complicated as initially seems to be
- Upgrading your solution codebase, including ORM (Glass etc.) and DI
- Employing automations with PowerShell
- Upgrading databases and how to approach
- Even more automation to add
- How to treat deprecated Sitecore APIs and obsolete code
- Migrating forms from WFFM
- Upgrading to version 10 containers and how 10.1 changes the upgrades
- Testing your upgrade strategies
- Going live
- Summary of tips and findings from this session
Sitecore 10.1 brings new Items-as-Resources option, which raises plenty of questions.
Please find the answers below:
- What it that used for?
- Why did we get it at all?
- Any concerns of using that?
1. Before 10.1 you’ve been given the initial set of OOB items upon the installation in the databases. That includes default templates, layouts, workflows and the rest of scaffolding items.
2. Now with 10.1 all these are supplied as the resources files outside of database. That's correct: all these items are no longer residing in the database. Yes, you still have them in your content tree as normal.
3. Does databases come empty? Not actually - there are just two entries for the default site (page) you normally first see after successful Sitecore instance installation, at the root of URL. It was decided not to put these into resources, as most customers delete that default home page anyway.
4. Are these resource read-only? Yes, Sitecore cannot write back into those resource files. Treat it as if they're written on CD but with an immediate access.
5. So does that mean I cannot modify default OOB items in Sitecore anymore? No, you actually can edit those as normal after "Unprotecting item" from a Content Editor ribbon. What happens in that case is Sitecore will take the delta between initial value stored in resource file and your changes and will store that delta having only changes you’ve done in the database. On item "consumption" the current state of item gets calculated from a resource file and that delta.
6. But you cannot delete these items. Sitecore prompts that it origins from the resource file therefore cannot be deleted. Still good, as leaves less potential for silly errors, anyway..
7. So where are these resource files located? They are based (quite predictably) within App_Data folder -
App_Data\items\<DATABASE_NAME>\items.<DATABASE_NAME>.dat (by default).
8. What format are these resource files? Protobuff (Protocol Buffers) from Google. That is a surprisingly old format which is proven for a decade, at least.
9. How can I create my own resources?
Officially - you cannot. Well, it is technically possible but requires very deep dive into Protocol Buffers, raw database storage and investigating new data provider in Sitecore. But, Sitecore will likely start providing authors of popular modules with the toolset to create such a resources with an ease. So, let's say for SXA you will no longer need installing SPE + SXA packages yourself, instead you'll simply drop the resource files provided by SXA team underneath
items folder, not even need to publish that afterwards.
10. Why no need publishing? That's because you copy the resource file for web database as well - items are alredy on the web database. Of course, all the items created by you will still need to get published.
11. But why at all Sitecore introduced that?
The main reason is to simplify the platform version upgrade process. The way update is done has changed.
You may have notice on the Sitecore download page, "Upgrade options" section have changed: instead of Sitecore Update Packages you now have Sitecore UpdateApp Tool that operates against each specific version you'd want to upgrade from. This tool will remove the default items for each particular legacy version and replace it with the resource files, Of course it also updates the schema with the changes which was already available.
12. The bigger reason for this change was "think containers - think ahead" approach. With such a change it becomes easier to upgrade version of Sitecore when running in containers: everything from the database since now is entirely user's custom data, and can be entirely copied to a never database, while version-specific-and-system-related items get updated by just a resource file substitute.
13. Also you may heard that Fast Query has been deprecated. That is exact reason why - if something isn't in the database, Sitecore cannot efficiently build the graph of the relationship for fast query
14. What is that data provider mentioned above?
That is a new one called
CompositeDataProvider that inherited by
DefaultDataProvider. The name composite assumes that one cares of merging items for Sitecore tree from both DB and the resources. In the configuration you specify it for an individual database under <database> section, you can also change the location for such resources by patching
<filePath> node of
<protobutItems> and overriding the location.
15. For the end-consumer of DataProvider (high level of stack) nothing changes as they still use
DefaultDataProvider from their code. The changes occur at intermediate level and those happen to be internal for Sitecore.
16. That actually opens up a much wider potential for creating some intemediate-level providers to things other than ProtoBuf and SQL Databases: CRMs, DAMs, some other headless CMSs maybe. In any case this is very important and greatly welcomed step ahead for the platform!
Update: there is another great blog post from my MVP-colleague Jeremy Davis on that same topic, where he also tried drilling into these resurce files with ProtoBuff.Net library.