If you are using the MVC version of the WFFM module then you probably know that by default the templates for the fields are located under
/Views/Form/EditorTemplates folder. If you have a multisite implementation then this leads to an issue if you need to render different markup for different sites. Generally speaking, my recommendation has always been to try style around the default WFFM markup rather than bending it to your will only to be struck down later when upgrading, but we should try to follow this same advice for most of Sitecore whenever possible anyway.
But sometimes you really really need something different per site.
With the release of Sitecore 8.1 we have had the added benefit of being able to use MVC Areas. We can take advantage of this feature to allow different markup for forms per site.
One of the most common customizations that I have seen in Sitecore is the addition of custom processors in the
httpRequestBegin pipeline, usually to add is some custom logic to resolve the context item, maybe to deal with custom URLs or wildcard items. Since this pipeline runs for every single request, there are plenty of reasons to customize here.
Most often I’ve seen , you plug in after the
Sitecore.Pipelines.HttpRequest.ItemResolver processor with whatever your custom requirements are. However, if you are using Sitecore MVC (and I hope you are) then you may find that your custom logic has not been applied and the Sitecore.Context.Item has been reset back to default Sitecore logic.
This has come up a number of times on Slack and caught a few colleagues out. It also caught me out a while back when I was doing some wildcard work with MVC:
This wasn’t supposed to be a blog post series, and my original reason for this code was to just offload the hosting of large files. But whilst writing the first draft of the blog post I started to investigate various areas since the potential for this module became greater. It was supposed to stop at part two, but I supposed I suffer from the same thing as most of you: programmers OCD. And so a series is born and expect another post or two to follow until a final solution is attained.
In my previous code I noted that the code did not work with the attach/detach handlers in the Media Library:
This is a continuation of my previous blog post in which we uploaded files into Azure Blob Storage through the Sitecore Media Library. If you haven’t read it yet then first go and do that since this may not make much sense otherwise…
The previous post showed how to upload media files into Azure Blob Storage using a custom pipeline. I started off the post by stating that the requirement was to only store large files in Azure and that was primarily the focus of what we needed to achieve but some small tweaks meant it was possible to store all media in Cloud storage.
We still need to make some small updates to code to allow us to actually correctly link to the media in Azure though, so I’ll present a couple of options we have to do that.
On a recent project we had the requirement to be able to link to large files which the user would be able to download, file sizes could be up to 2GB in size. Far too large to store in Sitecore Media Library, at least in database storage. We had previously used Blob storage in Azure with great success for another (non-Sitecore) site so decided to utilise this again but wanted a seamless, single interface for the user to work with, i.e. everything through Sitecore.
Knowing that Azure has a rich API set and pretty much everything in Sitecore can be hacked into via the pipelines we set on our merry journey.
The following requirements were set in order to help set the boundaries:
- any file uploaded to certain folders would be uploaded to Azure
- any file uploaded and the “Upload as Files” option checked would be uploaded to Azure Blob Storage
There was also an additional requirement to automatically calculate the MD5 of each file which was uploaded. This ties in follows on nicely from my previous post about extending Media Item templates using Glass Mapper. Hopefully the specifics of that post will make more sense after this as well 🙂
Storing SVGs in the Sitecore Media Library is pretty simple, just add a new
mediatype in config. This has been well documented and there are several posts as well as Stackoverflow/forum answers for this. e.g. https://community.sitecore.net/developers/f/8/t/1670
And this works fine and everything renders great, but whilst trying to sort out some servers issues and trawling through the Sitecore logs I noticed it was littered with Errors like so:
5920 15:34:49 ERROR Could not run the 'getMediaStream' pipeline for '/sitecore/media library/github-logo-01'. Original media data will be used.
Message: Parameter is not valid.
at System.Drawing.Bitmap..ctor(Stream stream)
at Sitecore.Resources.Media.ImageEffectsResize.ResizeImageStream(Stream inputStream, TransformationOptions options, ImageFormat outputFormat)
at Sitecore.Resources.Media.ImageThumbnailGenerator.GetStream(MediaData mediaData, TransformationOptions options)
at Sitecore.Resources.Media.MediaData.GetThumbnailStream(TransformationOptions options)
at Sitecore.Resources.Media.ThumbnailProcessor.Process(GetMediaStreamPipelineArgs args)
at (Object , Object )
at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args)
at Sitecore.Resources.Media.Media.GetStreamFromPipeline(MediaOptions options, Boolean& canBeCached)
Recently on Slack Chat a question got asked by fellow MVP Jason Bert about how to prompt a user to save an item from the Sitecore Media Library. Whether a user is prompted to download media depends on a few factors:
- Whether the browser or an associated plugin understands how to process that mime type
- Settings under
mediaLibrary\mediaTypes in the Sitecore section of config
- The response headers sent by the server, and whether
It’s this final header which we need to add ourselves in the Response headers. I shared some code but was pretty surprised when it did not work. Previously in an earlier version of Sitecore I had simply tapped into the
getMediaStream pipeline and then set
Content-Disposition=true header based on a url parameter. Something had obviously changed, or I was going mad. Most likely a combination of both…
About a year or so ago I was working on a project which involved an upgrade from Sitecore 6.4 to 7.0 (the latest version at the time). The upgrade was fairly incidental, the site was (kind of) “working fine” in production. The main reason for touching the codebase was to fix issues due to a poor implementation that was carried out initially, namely:
- Lack of Page Editor support
- Poor coding not following Sitecore Best Practices
- Sitecore section in Web.config modified directly (which made upgrading more difficult)
- Poorly structured Content Tree
- Difficulty applying a good security model for multi-site, multi-editor environment
…amongst others. It wasn’t all bad, just some common mistakes made by developers struggling with Sitecore during a first implementation.
One issue was the poorly structured content tree. It seems there was struggle with getting a handle on how to structure content whilst trying to use that same structure to create the navigation menu on the site. They had the usual “Include In Navigation Menu” checkboxes but the navigation structure did not actually completely match the content structure.
tl;dr A fix for Google Chrome 37+ which removed support for showModalDialog() and broke a lot of functionality in older releases of Sitecore and can be found on Github
11/09/2014: Sitecore have officially released patches for v6.4 to 7.0 for this bug. Glad to see that I was not a million miles off in my implementation though. Please use these patches instead: https://kb.sitecore.net/articles/581527
With the release of Google Chrome 37 we have finally lost our beloved modal dialogs created with showModalDialog(). This is used in all versions of Sitecore up to version 7.1. There is no official workaround for this yet, aside from use EnableDeprecatedWebPlatformFeatures Chrome policy, use a different browser or upgrade as stated in this knowledge base.
There was a fair amount of talk of this issue towards the end of last week, I also contributed on the main SDN thread and it seems we totally missed the issue being raised by Alex Pershteyn a few weeks ago. Well it appears those
showModalDialog() is deprecated messages in the console window actually meant something and apparently ignoring them didn’t make the problem go away 😦
tl;dr Use the Sitecore Configuration Factory to pass parameters to enable Pipelines to only run for specific sites
I’ve been working on a few multi-site Sitecore implementations lately and the majority of the time most brands within the same company umbrella all want similar functionality, which is very nice and easy for us developers. But as you start to work on larger implementations with different brands it will be inevitable that they all have slightly different requirements.
Pipelines provide us a great way to customize Sitecore, but they run for all requests unless we put in some hacky code:
public override void Process(HttpRequestArgs args)
if (!Sitecore.Context.Site.Name.Equals("mysite1") || !Sitecore.Context.Site.Name.Equals("mysite2"))
// run your site specific code