Sitecore

The curse of the PNG’s


When Sitecore released version 5.0 of the CMS, it included a major overhaul of the design in the editor, which featured a set of icons purchased from an external icon design company. These PNG icons are also included in the version 6 of the CMS.
Sitecore already in version 5 decided to include the complete icon package into the software, although only a subset of the icons were used – why? Maybe as a service towards the developers or maybe just because it was easier for them just to include them all, who knows. Anyway, the complete icon library can be used – and in version 6 even browsed – from with the Sitecore editor. Nice feature – but from my point of view, at a very high price.

The following table shows the number of files, just in the /sitecore/shell/themes/standard folder for some randomly picked versions of Sitecore CMS:

Version 5.0:    11.100 files
Version 5.2.0:    13.357 files
Version 5.3.0:    13.745 files
Version 5.3.2:    18.133 files
Version 6.0:    18.244 files
Version 7.0:    ??

I have about 5-10 different Sitecore projects on my hard disk which I am actively working on, I constantly create and delete Sitecore projects for testing purposes and our build system continuously and nightly surveys, builds and copies 20+ active Sitecore projects in our company. All of these tasks are heavily burdened by the icon library.
A clean Sitecore 6 version contains approx. 24.000 files of which approx. 18.000 are icons (and approx. 5.000 are related to the HTML editor). This means that 75% of the files in Sitecore are icons. In terms of megabytes, this number is only 40%. But still, you get my point?

Sitecore, please, please, please consider alternate ways of including the icon library. How about a compiled resource with all the icons? Or maybe included in the media library in the core database? Whichever way you choose, the life of me – and a lot of my fellow Sitecore developers – will be so much easier. Thank you!

Standard

16 thoughts on “The curse of the PNG’s

  1. I think we’ve made a resource library at one point, which ended up being a 70+ megabyte dll file. For reasons I don’t quite remember it didn’t work out too well, maybe because of the performance.

  2. I appreciate the fact that there is a lot of backwards compatibility to deal with and that this issue is not as easy to fix as it seems.
    I just get REALLY frustrated over the fact that copying or deleting a Sitecore project takes soo long… 🙂

  3. I know Per from Codehouse actually did this. Compiled all the icons into a resource DLL and wrote a small HTTPModule to intercept the media requests and stream them off the DLL.

    While performance may suffer a bit, this is not really (very) relevant to a development environment – I would surely also happily trade my current 160.000+ icon files for a slight performance drop.

    Live servers can just remain as they are.

  4. Per Bering says:

    Close Mark 🙂 – I’ve made a zip file of the themes folder and the a httpmodule which read the requested icons from the zip file.

    Almost forgot about that, maby it is time to take a look at it again 🙂

    But I agree, please sitecore do something about my 60++ sitecore solutions x 11->18.000 small pngs!

  5. Matt Hovany says:

    If you compiled to a single resource file, you’d really only need the largest (48×48, 128×128) of each icon since you can scale & cache it in the media handler. That could bring the resource file’s size down a bit from 70MB.
    Do icons scale well? Or do they get fuzzy?

  6. Jakob Christensen says:

    Hi all

    I have a lot of Sitecore installation as well, of course. What I do is to use IIS virtual folders for all icons folders and point to a central repository of icons. That way the millions of icons are shared across installations. This really helps with subversion and moving projects between work and home.

    The standard icons folder are not changed between releases as they are a package we have bought from a 3-party vendor.

    The only problem with this solution is it is tedious to create all the virtual folders for each site.

    I have solved this using an NAnt script. I do not think the god-like developers on this blog will have any problems getting an NAnt script to work.

  7. Jakob Christensen says:

    <?xml version=”1.0″?%gt;
    <project name=”sitecore” default=”run”%gt;
    <!– Modify begin –%gt;

    <property name=”web.site” value=”localhost:83″ /%gt;
    <property name=”log.file” value=”build.log”/%gt;

    <!– == ooo RUN ooo == –%gt;
    <target name=”run” description=”Runs the build”%gt;
    <record name=”${log.file}” level=”Debug” action=”Start” /%gt;

    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Applications” vdirname=”sitecore/shell/themes/standard/Applications” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Business” vdirname=”sitecore/shell/themes/standard/Business” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Flags” vdirname=”sitecore/shell/themes/standard/Flags” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Network” vdirname=”sitecore/shell/themes/standard/Network” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Other” vdirname=”sitecore/shell/themes/standard/Other” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\People” vdirname=”sitecore/shell/themes/standard/People” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Software” vdirname=”sitecore/shell/themes/standard/Software” appcreate=”None” /%gt;

    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Control” vdirname=”sitecore/shell/themes/standard/Control” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Core” vdirname=”sitecore/shell/themes/standard/Core” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Core2″ vdirname=”sitecore/shell/themes/standard/Core2″ appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Core3″ vdirname=”sitecore/shell/themes/standard/Core3″ appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Databases” vdirname=”sitecore/shell/themes/standard/Databases” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Imaging” vdirname=”sitecore/shell/themes/standard/Imaging” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\Multimedia” vdirname=”sitecore/shell/themes/standard/Multimedia” appcreate=”None” /%gt;
    <mkiisdir iisserver=”${web.site}” dirpath=”e:\icons\WordProcessing” vdirname=”sitecore/shell/themes/standard/WordProcessing” appcreate=”None” /%gt;

    </target%gt;

    <target name=”failure”%gt;
    <record name=”${log.file}” action=”Close” /%gt;
    </target%gt;

    <target name=”success”%gt;
    <record name=”${log.file}” action=”Close” /%gt;
    </target%gt;

    </project%gt;

  8. Jakob Christensen says:

    BTW: I can see there is a lot of questions in posts here. Let me see if I can answer some of them.

    We did make a resource assembly at one point which contained all the icons – this is the Sitecore.Resources.dll if you have seen it. It was 64MB and our initial testing indicated that it worked fine. Unfortunately it turned out, that this assembly was loaded into memory and doubled in size, eating 128MB of memory. This is clearly unacceptable.

    I really like the solution with zip files and an http handler (Per: Could you send it to me?).

    We cannot just use the 48×48 sizes as lower resolution icon are not just resized, but are hand-crafted to improved readability (or so the vendor says).

    The media library idea was considered, but we would have problems with databases and staging – we do not want them in the master database and the core database may not be available on the front end servers.

    In the end we chose the simplest solution.

  9. Eldblom says:

    Not a bad idea with the virtual directories – especially with the nAnt integration. This is something we can automate in our build env. (build locally = virt. folders, deploy to test = real folders).

    Note that some features in the Sitecore editor, e.g. the icon browser, will not work with the virtual folders, zip or resource hack. Take a quick Reflector look at the Sitecore.Shell.Applications.ContentManager.Dialogs.SetIcon.GetFiles() method and you see why 🙂 (Wonder if anyone ever actually succeded in creating an alternate theme for the Sitecore client :-))

  10. Acutally, I thought that was the whole point of FileUtil.MapPath()… to return a true physical path regardless of whether it was given a physical or virtual path, was it not?

    It certainly does a lot of checking beyond just mapping to Server.MapPath()

  11. Eldblom says:

    No, FileUtil.MapPath merely makes sure the slashes are correct, that it is not a URL and if the HttpContext is not found (e.g. in a scheduled task), it defaults to the app domain path.

  12. Pingback: Sitecore Fetch Squad » Blog Archive » The curse of the PNG’s

  13. Well I found a way better solution than the zipfile/httphandler combo. How about this in Application_Start:

    HostingEnvironment.RegisterVirtualPathProvider(new SimpleVirtualPathProvider(@”/sitecore/shell/themes”, @”d:\sorted\themes”));

    Bang! Now go move the themes folder to a common place and it will now be provided by ASP.NET as a physical folder.

    Write me at pmb-at-codehouse-dot-dk it you want to try it out or look at the VirtualPathProviders i ASP.NET 2.0 a do one yoour self, its 30 lines of magic 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s