Sitecore 7.5 brings some changes to the way images are resized on the server, and it may mean that you’ll find some images on your site aren’t being resized after upgrading. These changes are intentional, and provide better security for media requests, but depending on your past implementations…you may see this issue on your site.
Sitecore has always been able to resize images on the server by passing parameters to the image rendering controls, <sc:image> and <sc:FieldRenderer>.
In the past, the resulting image URL of this was the normal image path with a query string appended showing the parameters.
i.e http://mywebsite/~/media/System/Simulator Backgrounds/Android Phone.ashx?w=50
(trimmed for display here)
Shinks down to this….
From Sitecore 7.5 onwards, if you attempt to load an image URL directly (by just appending a query string like the one above), the image will not be resized, and the full image will be shown.
Sitecore 8 has changed the way renderings on a page are stored on an item. A page’s full presentation can now be updated (hopefully through the Experience Editor) for an individual version…meaning those changes can go through workflow to be approved. It also means layout changes can be rolled back to previous versions easily.
Note: Screenshots and investigation for this post has been done using the Sitecore 8 Technical Preview handed to Sitecore MVPs. The final result may change for the initial release of Sitecore 8.
A while ago a good friend of mine, Dave Nicolson, created a utility that assists front-end developers with Sitecore development. The tool watches changes to front-end files in your Source directory, and copies them over to your Website directory….saving the need for a full Visual Studio build, and thus, no App Pool recycle.
Download CopySauce here.
Note: Basic documentation is included in the download.
CopySauce was branded by Igloo (now Authentic Entertainment), and my original post of the utility can be found here.
IntelliSense in Visual Studio is a fantastic auto-complete feature that greatly improves your Sitecore development, however I’ve occasionally seen this not working in my MVC solutions.
In particular, I was seeing the following error highlighted around any calls to the @Html.Sitecore() helper:-
‘System.Web.Mvc.HtmlHelper<Model>’ does not contain a definition for ‘Sitecore’ and no extension method ‘Sitecore’ accepting first argument of type ‘System.Web.Mvc.HtmlHelper<Model> could be found.’
This would mean that I could not get auto-complete on the @Html.Sitecore() helper, nor would I get auto-complete for my properties on my Glass Models.
Sitecore 7.2 Update-2 (rev.140526) was recently released, and one of the entries in the Release Notes was this:-
- Layouts and renderings
- The Select the Associated Content dialog did not handle multiple data sources correctly. It only used the first data source and ignored any additional data sources. This has been fixed. (389483)
A while back Thomas Stern wrote a post detailing a way to allow for queries in Datasource locations, so that the Associated Content dialog could be more flexible for multi-site solutions.
I tested out his solution back when the post was written, and it worked perfectly. However I found that it was broken in both Sitecore 7.0 and 7.1.
This is a fix for the Sitecore 7.1 upgrade process, where Rules fields may not have their Source (Rules Context) updated correctly during the upgrade. The fix was originally posted on my Github repo and should be used when upgrading from Sitecore 7.0 to Sitecore 7.1.
It has been assessed and approved by Sitecore Support.
How to Fix the normal process
Follow the initial steps (Steps 1 to 9) in the Sitecore update installation instructions here.
Before installing the Sitecore 7.1 update package in the Update Installation Wizard (Step 10,11):-
- copy the
Hedgehog.SC71Upgrade.DLL file from the __install files directory into your Website’s
- make a change to the
App_Config/FieldTypes.config file with the following change.
<fieldType name="Rules" type="Sitecore.Data.Fields.TextField,Sitecore.Kernel" resizable="true" />
<fieldType name="Rules" type="Hedgehog.SC71Upgrade.Data.Fields.RulesField,Hedgehog.SC71Upgrade" resizable="true" />
- Note: This change can be seen in the example file located here __install files/FieldTypes.config.
- Now install the normal update package (Step 10,11 in the Sitecore update installation instructions) and complete the remaining steps for the upgrade.
Update: I found a bug in the Sitecore 7.1 Upgrade Process that causes the issue mentioned in this post. An explanation and a fix for the process can be found at my Github repository, https://github.com/SaintSkeeta/Hedgehog.SC71Upgrade.
I previously posted about the Sitecore Upgrade ‘Post Step’ code that gets executed on items when upgrading Sitecore to a newer version. The Post Step code in the Sitecore 7.1 upgrade processes the Conditions and Actions items for Rules fields…meaning your existing Rules fields may be affected during the upgrade process.
When Sitecore 7.1 was released Adam Conn wrote a blog post about the changes to how Rules work in the new update. With everything shifted around in the content tree, I knew there would be some sort of Post Step to update existing Rules items.
My LaunchSitecoreTDS repo (taken from the Launch Sitecore demo site) has a custom action that automates the enrollment of a user in an engagement plan, so with the package originally being built for Sitecore 7.0, something was going to happen with the items when upgrading to Sitecore 7.1.
The ‘Enroll in Automation State’ item had moved from:-
The action was originally setup to be executed on the Register Goal in the Marketing Center.
But now Rules fields respond to their ‘Rules Context’ (their Source on the field), allowing developers to limit what conditions and actions are available for a given rules field….
So now our custom action cannot be added to any other similar Page Events we setup, because it isn’t set as the Source for any field. Read More
Charlie Turano recently told me a lesser known fact about Sitecore’s upgrade process. There is a block of code that gets executed to update existing items in the database. This is what’s known as an installation ‘Post Step’, and it gets triggered after the new or changed items are added to the database.
For example, Sitecore 6.5 updated the ‘Placeholder Settings’ items to have a new ‘Placeholder Key’ field.
The Sitecore Instance Manager (SIM) tool is a fantastic tool for quickly setting up local Sitecore installations. I love using it for quick setup when sandbox testing features, or new shared source modules from the community.
It’s so simple that you just click on the ‘Install Instance’ button, fill out the information for the site you want, and off it goes, extracting the webroot, attaching databases, setting up IIS and everything. It’s great!
One thing I found when setting up my sites was that the Data folder was saved within the actual Web.Config, as opposed to it being patched in with an App_Config/Include file.
Here’s a way to map a custom Link List field in Sitecore to Glass.Mapper.Sc, for easy usage.
The following was used for Monoco’s Link List field but can also be used with the Field Suite’s General Links field by Velir, as it stores the same raw value.
(Note: for Monoco’s Link List field, it’s better to download the LinkList package from the Monoco site than the Sitecore Marketplace, as the Marketplace version is outdated at the time of writing this post).
For more information on Data Handlers, check out the Data Handler tutorial on the Glass Mapper website here.