Most of this release revolves around scalability and indexing. The Lucene index have been updated to allow even more impressive performance and even higher scalability. The old Sitecore 6 would easily swallow 1.000.000 items. Sitecore 7 have almost no limitations. Even on folder level, where the old Sitecore 6 stalled at around 200 items at the same level; Sitecore 7 implements a revamped version of Sitecore Item Buckets, allowing you to have an infinite amount of items at the same level.
So what’s next on my wish list? Could I ask for more? Of course. More wants more. Here is the areas where I would like Sitecore to focus on for the first update of Sitecore 7:
SITECORE PAGE EDITOR
AN EXTENSIBLE PAGE EDITOR
We need the Sitecore Page Editor to be extensible, like the rest of Sitecore.
If you wish to add a new field to the Sitecore shell, you write some code, put it in a DLL and points to the field. No modifications to Sitecore itself.
This is bad and very Sitecore-unlike behavior. Sitecore is a platform. You never modify the platform. You extend it. Except for the page editor. Sigh.
PAGE EDITOR LINK FIELD TYPE NEEDS TO ALLOW LOOKUP FIELDS
If you would like to have a link popup box in the page editor, you must have a general link field. The page editor should have a popup for all lookup fields, so you can have fields where only internal links are allowed.
PAGE EDITOR SHOULD HAVE A BUTTON FOR THE MEDIA LIBRARY
A button that opened the media library would be nice please. It’s 10 lines of code. I can give you the code.
PAGE EDITOR SHOULD BE ABLE TO EDIT NON-VISUAL FIELDS
Not all fields are visible. But you should be able to edit them anyway. Thomas Stern made a solution. This should be standard.
PAGE EDITOR SHOULD BE ABLE TO PUBLISH EVERYTHING THAT’S INCLUDED ON THE PAGE
The publish button on the page editor will only publish the current item (and it’s subitems). But most pages have included components. These components are not stored on the item, and often not as children to the current item. When publishing from the page editor, these components should be published as well. Otherwise you cannot publish them from the Page Editor at all.
PAGE EDITOR SHOULD BE CHEAPER TO DEVELOP FOR
This is not a no-brainer. The Page Editor is the coolest thing since sliced bread. Customers are requesting page editable websites more and more often.
Unfortunately, if you are aiming at building a page-editor only website (a website that is edited completely using the page editor) costs explode. The number of lines explode, as you have to consider many more states and exceptions.
You have to add code to allow fields that is hidden if empty to be shown, only in page edit mode. And how do you make a carrousel page editable? And what about the metadata fields?
How do you allow the customer to version pages, if the page consists of components?
All of these simple, little decisions complicate your code, making it more expensive to develop, and more expensive to test.
ADDING COMPONENTS USING THE SHELL
If you wish to use the Sitecore DMS in it’s full extent you are bound to make a Page Editable website. Why? Because the Page Editor is the only place where you can add components to a page. Components are necessary if you would like to use A/B Testing and Real Time Personalisation.
We need the dialogs for adding components to a page available in the Sitecore Shell.
I would expect the Sitecore Shell to contain the full set of functions, and the Page Editor to be a subset of functionality.
Yes I know that I can use the Presentation->Details button to open the Layout Details and from there I can add my components. But my customer cannot. It’s a developer tool and way too complicated to use.
Please make a user friendly way of adding components to a page from the Sitecore Shell.
The sc:FieldRenderer should be able to get a NULL item without crashing. This would remove half of my code lines in my components.
The sc:Link should be able to use lookup fields and not only the general link field.
The sc:EditFrame should accept a Sitecore item instead of a Item path in the DataSource property.