PageEntity for Community 4.0
PageEntities is a custom entity that links EPiServer Community functionality (rating, visits, comments etc) to ordinary EPiServer pages. It was first introduced by Per Hemmingson in this blog post and have since then been a popular addition for several projects. We use it on this website for instance.
The problem is that the code attached in his post is for Community 3.2 and doesn’t work together with the new Community 4 because of changes to the API. For details on the API changes, look for the tech note named:
Migrating EPiServer Community 3.2 to 4.0 and EPiServer Mail 4.4 to 5.0
Since last week we’re running Community 4 on world and in order to do the upgrade we needed to update the code for PageEntities. And since I’m such a friendly fellow I thought I’d share the changes made to the rest of the community. Hopefully I can save time for someone looking to do the same upgrade or adding PageEntities to a new community 4 project.
Changes made
The “big” change is that I removed the usage of SiteId in the code completely. Sites have been removed in favor of the category system in Community 4 and since we used the same SiteId for all our saved PageEntities we didn’t really need it. If you need it you need to make the appropriate changes to the code.
Most of the changes made were similar to this one:
From:
1: DatabaseHandler.RunInTransaction(delegate
2: {
3: DatabaseHandler.GetScalar("spUpdatePageEntity",
4: tpr.ID, (int) tpr.EntityType, tpr.SiteID);
5: UpdateEntity(tpr);
6: });
To:
1: DatabaseHandler.Instance.RunInTransaction(delegate
2: {
3: DatabaseHandler.Instance.GetScalar("spUpdatePageEntity",
4: tpr.ID, (int) tpr.EntityType);
5: UpdateEntity(tpr);
6: });
In other words, we started using the new static instances of the handlers. That was needed on several places but you get a lot of help from the compiler when doing this.
Another thing that was needed was a couple of methods to the PageEntityProvider class. This is because the interface IEntityProvider had gotten a few more methods. Namely: AddEntityInstance, RemoveEntityInstance, UpdateEntityInstance and GetSupportedOperations. They were all implemented similar to this (the difference is what method to use in the return statement):
1: public IEntity AddEntityInstance(IEntity entity)
2: {
3: if (!(entity is PageEntity))
4: {
5: throw new EPiServer.Common.Exceptions.NonCommittedEntityException(entity);
6: }
7: return PageEntityHandler.AddPageEntity((PageEntity)entity);
8: }
All changes are available in the attached .zip file at the bottom of this post.
SQL changes
Observe that the SQL script (PageEntityProviderSQL.sql) is changed so that all created stored procedures doesn’t use any SiteId any more.
Also note that I included a script to move data from one database to another in the same way that the migration script for community work. That script is called: PageEntity-MoveDataInTblPageEntityWithoutSiteId.sql
The script moves all data in your old database to the new excluding any values in the SiteId column.
There is no error handling in that script and it requires you to run the PageEntityProviderSQL script first to create the correct table in the new database. Remember to backup any database affected before attempting to run these scripts. The script don’t delete anything, but it’s better to be safe than sorry.
Great job!
Great, this will be very useful.
A note, if you've removed the SiteID from the database, you should probably remove it from the nhibernate xml-mapping file as well, or queries won't work I think.
Thanks Mattias!
You are correct regarding the nhibernate mapping. I had totally forgot about that. The zipfile has now been updated with a new version of the PageEntity.hbm.xml file where the siteID is removed.
Thanks again.