Recently a customer of mine had a problem with the MySite. The whole SharePoint 2013 farm (Windows Server, SharePoint Server and SQL Server) was installed with English components. The MySite for the user was also created in English with 6 additional language packs installed. If a user had set his display language in his MySite profile to German she was receiving her status messages from the SharePoint Farm (news feed updates etc.) in German. The display language was set for every user to German by a PowerShell script. The MySite also contains the default MySite blog which was used by some users.
If a user adds a post to his MySite blog the Newsfeed of the user is updated with a link to the new blog post:
The URL to this blog post ("Test Eintrag") looks like this:
If I click on the link my browser opens ViewPost.aspx. ViewPost.aspx starts a redirect to the following URL (traced with Internet Explorer Developer Tools):
That is the point where the 404 error occurs. The cause of the 404 is the name of the blog list. The real name of the blog list is "Posts" and not "Beitraege". It seems that the ViewPost.aspx is using the display language value of the MySite profile settings to use a localized name of the blog list, and that is wrong. If I change the link to the blog post from
the URL is working without any problems. If I change the display language in my MySite profile back to English, create a new blog entry and click on the link, the error persists, the redirected URL still points to the list with the name "Beitraege".
The content type for the blog list has three configuration fields to set the URL for the display form, the edit form and the new form. The picture below shows the 3 fields of the content type in SharePoint Designer:
The users with the 404 problem have the URL of the display form set to "Lists/Beitrage/Post.aspx" despite the fact that the name of the list is "Posts" and not "Beitrage". I changed the URL of the display form of the blog list content type to "Lists/Posts/Post.aspx" and the problem disappeared. I had a lot of users with that problem so I decided to write a PowerShell script that identifies the affected MySites and sets the display form of the content type to the correct url.
Surprisingly when I checked the content type from the PowerShell script it was always showing the correct URL but it was wrong in fact. It seems that the only way to see the wrong URL is by using SharePoint Designer. So I decided to always set the URL to the correct value with the PowerShell script even if it looks like it is already correct. That fixed the problem for all affected users.
I attached the PowerShell script to this blog post