Been using a CMS called Immediacy, or rather it's new name of Alterian CMC, and with any system of it's kind, there are several idiosyncracies that must be overcome at first.
I've listed my findings below, if you find any are inaccurate or I am mistaken, then leave a commend and tell me so!
It
doesn’t like to run under IE8, even on compatibility mode...
...
well, most of the times it does, but there might be that one template (see
event details page for an example) that is completely goosed. Of course,
it doesn’t even boot up in Chrome/FF/Safari, so your safe choice is to run this
via genuine IE7. Either a virtual m/c or Citrix install should be good
for this.
It
can’t handle <div> tags within the editor...
...
well, it sort of can, but will result in a bizarre problem where any plug-in
which spits out <div> tags, and is then subsequently enclosed in
<p> tags will fail to persist any changes. Use tables in your
<%--> <--%> tags in the Form.htm or templates.
Page
preview looks weird in IE
When
you preview, it creates its own stylesheet called “PagePreview.css”, hoovers
all the styles from your actual stylesheets and puts it in here. Of
course, if you’re over-riding styles to tweak IE, these are going to be
over-written, and your page is going to look like a Cubist masterpiece.
Thankfully the preview will work in Firefox, so just copy + paste the URL and
you’re able to see what the page actually looks like.
Don’t
use hyphens when providing Ids to plug-ins
For
example, don’t use the following:
<imm:area
name=”unique-name” runat=”server” id=”unique-ID”>
The
Application caches the root address the first time it is accessed
If
you have two distinct URLs which resolve to the same application, for example
“mysite.co.uk” and “10.100.104.40” then note that the FIRST
TIME you access the site, whichever way you access it will be cached by the
system. This can result in the problem whereby it will try and fetch
resources using an invalid (unavailable) path.
For
example, if the IP address used above is only accessible internally, then clients
accessing via the external URL are served up paths to the internal IP address,
which results in the editor application seizing up.
The
CSS is cached until you completely terminate the session
And
simply logging out doesn’t seem to do this, you must close Internet Explorer
entirely. This only happens with CSS, so if you make a change to the CSS,
log out and back in again, these changes are not reflected. Note that
page and plug-in templates (though the code-behind has to be re-compiled) are
not cached in this way.
Editable
Areas must be nested within divs that have explicit widths set
A
page might preview perfectly well, but within the editor the editable area will
only show as a thin dashed line, not allowing the user to edit or see what’s
going on at all. We solved this by explicitly defining a width on the
container div.
If
you get a SOAP error on loading the application/plugin
Browse
to <website>/_immediacy/editor/plugins.ashx
One
of the most useful tips to take note of.
Plugins
don’t like capital letters in the fields.
I
reckon it’s also safer not to use auto-properties.
If
“Please Wait” appears for more than 10 seconds on loading up the editor...
...
it’s likely hung and you need to hit refresh to give it a jolt. Be
careful not to just quit IE, or you might get the problem below.
User
is already logged in message appears
You
need to unlock the user by going into Admin|Web Site|User locking. This
often happens when the app closes without being able to successfully log out.
“This
plug-in cannot be edited”
The
plug-ins load asynchronously, so you will likely get this message when you’ve
just rebuilt the binaries. Give it 30 seconds or so to finish doing what
it’s doing and try again.
These are my findings so far, and I’m
willing to give the product the benefit of the doubt due to my inexperience –
some of these problems might manifest themselves due to invalid configurations
or code. Hope this does help anyone who uses this system for the first time.