Oct 06 2008

Ektron CMS400 7.0 issues with .NET Framework 3.5 SP1

After upgrading my development machine with Microsoft .NET Framework 3.5 SP1, I noticed a couple things. First, the installer also updated the .NET Framework 2.0 instance to Service Pack 2.

Second, my instance of Ektron CMS400 v.7.0.4.20 (which runs under .NET Framework 2.0) starting having problems. Specifically, I could no longer create library items in the workarea. Attempting to save a library item, for example, a hyperlink would cause the page to postback and the icon bar to disappear:

The postback page after attempting to save the library item

The postback page after attempting to save the library item

There is no error message, but viewing the library item list reveals that the item was not saved.

The culprit was the page /workarea/library.aspx. Viewing the HTML source of this page when attempting to “Add Library”, the form tag’s action attribute was:

library.aspx

… no querystring parameters; so when the page posts back in Ektron, it can’t save the library item and fails.

Viewing the same page on a system without .NET Framework 3.5 SP1 results in an action attribute like this:

 library.aspx?LangType=1033&action=AddLibraryItem&folder=98&type=images

Some background: As it turns out, the .NET Framework 3.5 SP1 installation changes the way the FORM tag’s ACTION attribute is handled. Prior to this upgrade, ASP.NET would ignore whatever you typed for the form’s action attribute in the markup. ASP.NET would instead render the action attribute to match the original page request. Starting with SP1, the action attribute is no longer ignored and will be rendered exactly as input.

Ektron, as it turns out, supplied an action attribute in the library.aspx form tag. Until the release of this Service Pack, it was ignored by ASP.NET.

Two possible solutions:

This may not be an issue in Ektron CMS400 7.5+, but users of v7.0 should be wary, even if they’re not planning on upgrading .NET Framework 3.5 SP1… Windows Update may upgrade you automatically around November of this year.

No responses yet

Sep 05 2008

Joomla vs Ektron

We have been receiving a lot of comparison inquiries lately and I wanted to put this simple Joomla vs Ektron content management systems comparison table out there. Have in mind that much of the decision of which CMS to choose for your company or organization is usually made way before this comparison since the two systems are different in such a fundamental level. However, this is a comparison of those fundamentals plus some of the ‘interesting’ features.

Joomla vs Ektron

Joomla vs Ektron

Feature/Item Joomla Ektron
License Model Open Source Closed Source, Compiled
Price Free Starts at $15,000
Web Platform PHP ASP.NET 2.0
Database MySQL MS SQL (Express version OK)
Extendability Options Plugins, Components, Mambots. Joomla 1.5 went through significant development that now offers many hook-ups for plugins without hacking any core files. Plugins (Observer Method), Ektron API (via ASP.NET code behind), Extensive Web Services API
SEO Options Search Engine Friendly URLs (Joomla 1.5)
Meta tags controls
Full template overrides, clean HTML
Search Engine Friendly URLs (CMS400 7.6)
Meta tags controls and consolidation
Content Tagging
Full template overrides, HTML is often not so clean (part issue with .NET as well)
Social Networking None, unless using a third party component or a plugin. Many features built in: Personal profile, personal area, connections between profiles, forums, blogging.

Thoughts?

One response so far

Jul 30 2008

Ektron: Clarification on User Controls vs API

We recently spotted an article from Bill Roger’s blog (Ektron’s CEO) which discusses usage of the Ektron Server Controls v.s. Ektron’s API. At Activo, we are constantly using both approaches and indeed each approach is a bit different and is used in different situations. The article makes it much clearer that Ektron actually put more effort than we thought before into the Server Controls. Understanding that the Server Controls were made for this sort of usage makes us now feel more secure using this method. Previously, I always thought of this method as a hack and preferred the API.

Frank heads our .NET development team and added the following:

I’ve found it easier to start off with a foundation of one of the server controls and build off of that, rather than using only API calls. The server control acts as a “datareader” which can be used to access the data initially. Many of the custom controls we built to replace XSLT use this model:

  • Add a ListSummary inside the user control/page and set its properties.
  • Access the ListSummary’s EkItems property.
  • Manipulate the data from EkItems, transform it, and output it into a repeater.

This tends to work more reliably than using the API calls. However, if the code needs to bypass the permissions model, the only option is to go direct using the API.

No responses yet