fredag den 13. november 2015

Issues you might run into when upgrading Sitecore

Recently we have been working on migrating one of our customers solution from Sitecore 6.6 to 8.0 (Yes, I know 8.1 has been released, but it wasn't when we started the upgrade project).


Here is some of the issues we have run into, and what we have done to fix them.
  • Moving the items to the new master database:
The best way we have found to move the templates, media items, items etc. to the new solution, is to copy the current master database to the same database server as the new databases, and then change the connectionstring for master to point to the old database.


Then, log into Sitecore and create packages containing the things you need (remember to keep the package file size below 2GB, or Sitecore will fail to install it, since it cannot parse the zip file if is that big...) - you most likely need these items: Templates (Remember to only include your own templates, not the ones Sitecore comes with), Layouts (sublayouts, renderings etc.), System items, Media Items (make several separate packages containing these, to stay below the size limit) and content.


Once the packages has been created - change the connectionstring back, so master points to the new master database (the reason for this, is that the packages must be made from items in the database named "master" to be able to install them into the database named "master"), and install the packages - Start with the package containing the templates, so the rest of the content is supported).
  • Different DLL's from Sitecore Support:
I don't think there exists any Sitecore solution, that doesn't have at least a few DLL's from Sitecore Support (not suprising, since it is made by humans, and humans make mistakes).


However, when upgrading Sitecore, there is a good chance that some of these issues has been fixed - so start by contacting Sitecore Support, and ask them which of the Support DLL's that is still needed.


Once they have told you which one of them that is still needed - test them and see if they still works (Sitecore Support will most likely say that they works, but experience shows that they don't test them before saying that they work - so do your own testing!)
  • Some media items no longer works:
Somewhere while developing Sitecore 7.x, replacers has been changed to also work for media items.
This means, that if you for instance has a replacer that replaces " " with "-", to make URL's more SEO friendly, this now also impacts media items.


So, if there is any media items (or media folders), containing some of the characters you are replacing, they can no longer be opened by users.


An easy fix is to make a small tool that runs through the media library, looks for items with those names (remember to check display names for all languages, if useDisplayNames is set to true on the LinkManager), and then rename them.
  • Some items does not have any version (and therefore cannot be published):
When installing the items using the packages, some items might end up without any version (we had to add an version to some folders inside the Layouts folder, to be able to publish them and get the site working).


Again, make a small tool that crawls the entire solution and look for items without any version at all, and create an English version (or that ever your default language for the solution is).
  • WFFM forms:
If you have to move WFFM forms from Sitecore 6.6 to 8.0, do note that the data the users has entered will not be moved, so make sure that is okay with the customer (most likely it is old data, and okay to not move along).


You might run into some issues when moving them, but they are solution specific, so be prepared to get some help from Sitecore Support.


That is all the problems we have run into, but nothing that cannot be fixed, which is okay.
Just remember to account for it, when estimating how long the upgrade is going to take you.

tirsdag den 10. november 2015

Certain users suddenly cannot insert components using the page editor

Okay, this was an interresting issue to debug.


One of our customers was having an issue with one (and only one) of their users not being able to insert components on pages using the page editor.


First we tried comparing permissions, role membership with other users (they matched btw.), and nothing helped.


To solve it, we wrote a small aspx page, that changed the current user context to the broken user (to avoid having to ask the user for her password, since she is loaded using the AD module, getting her AD password is a big no-no).


Then, as soon as we had the user context, it was pretty easy to open the page editor, and see for ourselves.


For some reason, if the user has unchecked the Design checkbox, the New Component button is just disabled (hint to UI designes - if you disable something, add a tooltip that tells why it is disabled!).


That also explains why it only happened to her, since it is saved on her Sitecore profile.

onsdag den 4. november 2015

When the From field in WFFM is not being used

If you might happen to be running Sitecore 6.6 still, and be using WFFM for your forms, you can run into this issue.


It seems that, for some reason, the WFFM module ignores the From field defined locally on a form, and always use the one defined on the Send Email Message save action.


This has been fixed in WFFM 2.4 rev. 150619, but if you are using Sitecore 6.6, you cannot upgrade to this version of the module.


So to fix this, you need a single DLL from Sitecore Support (just ask for the file "Sitecore.Support.420165.dll", and change the Save Email Message save action to use this Assembly and Class: "Sitecore.Support.420165.dll" and "Sitecore.Support.Form.Submit.SendMessage"


They publish the save action to the web database.


Now the save action will be sending mails using the locally defined From, and only fall back to the one on the save action when needed.

fredag den 4. september 2015

How to write data from Sitecore (an other sources) to a CSV file that Excel understands

From time to time, our customers wants to export data from Sitecore to CSV, to be able to view it in Excel.

Depending on where in the world you live, this might not be an issue for you, since people in the english speaking countries will just be using ASCII and there will be no issues.

But, if you like me live in one of the nordic countries (or alot of other places), you will be running into having to deal with text with letters, such as 'æ', 'ø', 'å' among others.

If you write strings containing any of these charaters into the CSV file just like that, it will come out malformed when the file is opened in Excel.

This is due to the encoding of the file, which confuses it.

Here is how to do it the easy way:

public static class CsvWriter
{
    public static void WriteToCSVFile(string[][] dataRows, string fileName)
    {
        using (FileStream stream = new FileStream(fileName, FileMode.Create, FileAccess.Write, FileShare.None))
        {
            using (BinaryWriter writer = new BinaryWriter(stream))
            {
                WriteByteOrderMarker(writer);

                foreach (string[] dataRow in dataRows)
                {
                    WriteLineSegments(writer, dataRow);
                }
            }
        }
    }

    private static void WriteByteOrderMarker(BinaryWriter writer)
    {
        byte[] BOM = { 0xef, 0xbb, 0xbf };

        writer.Write(BOM);
        writer.Flush();
    }
            
    private static void WriteLineSegments(BinaryWriter writer, string[] lineSegments)
    {
        writer.Write(Encoding.UTF8.GetBytes(string.Join(";", lineSegments) + "\r\n"));
        writer.Flush();
    }
}

First save the data in the 2D string array, and call the WriteToCSVFile function with the filename to save the data to.

First a byte order mark is written, which tells Excel (and other applications), that the content of the file is UTF-8 encoded.
Then, when each line is written, it gets encoded, so it matches.

That way, all programs should be able to read it, as long as they understand the BOM in the start of the file :-)

When WFFM forgets to include Checkbox List fields in Send Email save actions

Okay, so one of your editors just created this great new form using the Sitecore WFFM module, and it looks great!

But then you want to make it send an email when the user submits the form - and all the sudden, the great looking form generates broken emails.

The problem is, that there is a Checkbox List field in the form, and for some weird reason, the Send Email save action does not care about that field type, so it just ignores it completly.

But, the help is near (no, not Ghostbusters this time) - just contact Sitecore support, and ask for the support package attached to the issue #442870 .

Simple and easy, right? :-)

Just upgraded, and now the page editor is broken? This might be why!

A little while ago, I finished upgrading a customers solution from Sitecore 6.4.1 to Sitecore 6.6, and all the sudden, the page editor stopped working. (The editors could not enter any text into any of the text areas)

It turns out, that there is a small note in the release notes for Sitecore 6.5 that mentions, that renderings and top level text notes should be wrapped in a div or span tag.

This can also happen if there is a sitecore placeholder placed at the top level of a usercontrol - so in this case, you also need to wrap it in a div tag.

So here you have it - it's a small thing to do, but it took quite a while to figure it out - hopefully this can save you from that, if you run into the same issue.

torsdag den 18. juni 2015

The case of WFFM going double escaping

This one is quiet interresting - a while ago, we had a customer which wanted to use the Send Email save action in WFFM.

They had designed the form with several fields, including a field called Mail, in which the user should enter their email address.

In the save action, they had selected the Mail field in the CC section, so the user would be CC on the mail that got send out.

The way this works, is when you insert a field into here, it is wrapped with square brackets, so it becomes [Mail] .

Now, when they clicked OK to close the save action, and opened it again, Sitecore had changed it to [[Mail]], which made it fail with an exception when the user filled out the form.
Changing it back and saving made not difference, since it kept changing it to [[Mail]].

We contacted Sitecore Support, and got a fix for it - so if you run in to this issue, please contact them, and say you want the fix from issue #436119.

The version we had the issue with is 2.3 rev.140617, so if you are using another version, it might work for you without the fix.