Krang Todo List

The following are bugfixes/enhancements in Krang that we're looking to address. If there are more items that should go on the list or if you want to help, let us know!

HTML/Perl Items

These items are UI issues, but require changes to the underlying Perl code to make them happen.

• Changes to Save functionality (1.10x?)
  
To help prevent lost saves, the message in the JavaScript window should say:

  "Save Changes to Story?"

There will be 3 options:

1. Yes
   
Yes, will save the changes and send you to the desired page.
2. No
   
No, will not save the changes and send you to the desired page.
3. Cancel
   
Cancel, will not save changes and you will remain on the same page

• New Template - Element Chooser (1.200?)
  
When creating a new template - the element chooser pulldown is nearly useless - it doesn't offer any concept of context.

The pulldown should be replaced with a Category-Chooser-style Element Chooser, one that shows the hierarchtical relationships between elements. The current category chooser (built by Krang::Widget) can be used as a guide.

• Template UI - variable browser (1.200?)
  
One of the hardest parts of template development in Krang is that the CMS provides no way for template developers to see what variables are available to them, or what their makeup is.

Some kind of element-variable browser would be extremely helpful. How it looks and how the user interacts with it still needs to be determined, but something useful should be possible.

• Fixing Stylesheet issues in the Krang UI/Making Krang resizeable (1.200?).
  
At the moment, the Krang UI is fixed at 800 pixels wide, and has chunks that make it incompatible with certain browsers (IE 5 on the Mac is one example).

There are a number of flaws in Krang's HTML/CSS that need to be corrected - some are template-based, others are in the HTML built by various perl modules (Krang::HTMLPager for one).

The final goal would be a cleaner HTML/CSS implementation of the UI that would support more browsers and be easier to maintain and skin in the long run.

• Better version control in publish (1.200?)
  
There is a desire to be able to keep a version from publishing before a specific date/time - this allows for time-sensitive content to be entered beforehand, without it being published until the proper time.

This would require changes to a number of areas:

First, API additions would need to be added to Krang::Story (perhaps as simple as an accessor/mutator of < $story-earliest_publish_date() >> or equivilant).

Second, Krang::Publisher would need to honor the API addition.

Finally, this needs to be integrated into the UI - how does this fit into the current story edit UI?

• Contributor Types UI (1.200?)
  
There is currently no UI to edit the various Contributor types. This is a fairly simple CGI that just needs to be banged out.

Dev-only Items

The following are perl-only issues.

• Mac OSX Support (1.102?)
  
Krang does compile and run on Mac OSX, but is still a little rough around the edges - someone needs to clean up the process. The Platform.pm seems to be ok, but platform/MacOSX/README.MacOSX needs some revisions.
• New Story - Story Type pulldown should be alphabetized.
  
The Story-Type pulldown should be in alphabetical order.
• System Administrator Functions
  
• Full publish via Krang Scheduler (1.101?)
  
Allow Krang Scheduler to specify site_id or category_id for scheduled publish.
• krang_publish Enhancements (1.101?)
  
Allow the --media-only option to work in conjunction with the --site_id option and publish only media in that site.

• Krang::ElementClass::HTMLArea (1.10x?)
  
Adding a new elementclass of HTMLArea. Behavior would be akin to Krang::ElementClass::TextArea, but it would use HTMLArea to give developers a limited (but configurable by element developers) set of HTML widgets for formatting.

(Plus Three has a working HTMLArea prototype, but we're not planning to release it. Instead we're planning to develop a replacement using a non-dead HTMLArea work-alike and use that.)

• FTP Publish (1.200?)
  
Sending preview/publish output to a remote FTP server.
• Default fill_template() capability (1.027? 1.028 more likely)
  
Krang::ElementClass->fill_template() will be expanded to make it possible to populate an element's template with all children down to an arbitrary depth.
• Cleaning MD5 Salt issues (1.200?).
  
The MD5 Salt should be built at install. Care is needed to make sure this doesn't break existing installs on upgrade.
• Krang::DataSet isn't fully compatible with the new Add-On System
  
In particular, creating a replacement for a class via the class.conf file won't cause Krang::DataSet to load data using that class. This should be fixed. Once this is done it would make sense to look for new schema's in addon schema/ directories.
• Krang::History isn't fully compatible with the new Add-On System
  
Krang::History stores class names in the database which interacts in unfortunate ways with the new class overriding system. The fix here isn't particularly clear but one is obviously needed.
• Add-on scripts should get #! handling
  
Krang fixes the #! line on scripts in bin/ to point to the Perl used to install Krang. AddOns should get similar processing during install.
• Add-ons should be able to include their own platform/ files
  
Add-ons may ship with requirements which need additional porting. For this purpose add-ons should be able to have their own platform/ modules which inherit from the ones in KRANG_ROOT/platform.

Other

Everything Krang-related that's not part of the application itself.

• The Website
  
The current Krang website was put together in a couple days by a Perl progammer. It needs a redesign. Getting rid of the IFrames would be a nice start.

A long-term goal would be the eat-your-own-dogfood goal - the site should be managed by Krang. Two major components are needed:

An element library & templates to serve the site
A script to take Krang POD (both in /lib and /docs) and add it to the site - the element library would need a good 'POD Article' story type.

Publish-to-FTP functionality (see above) would also be helpful here. (Not really unless we switched hosts. SF only supports SCP. -sam)

• Documentation
  
Krang is still missing some key documentation. The biggest hole is a real user guide, something that could be handed to non-technical users to help them use the site.