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!
These items are UI issues, but require changes to the underlying Perl code to make them happen.
"Save Changes to Story?"
There will be 3 options:
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.
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.
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.
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
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?
The following are perl-only issues.
Platform.pmseems to be ok, but
platform/MacOSX/README.MacOSXneeds some revisions.
category_idfor scheduled publish.
--media-onlyoption to work in conjunction with the
--site_idoption and publish only media in that site.
(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.)
fill_template()capability (1.027? 1.028 more likely)
fill_template()will be expanded to make it possible to populate an element's template with all children down to an arbitrary depth.
Everything Krang-related that's not part of the application itself.
A long-term goal would be the eat-your-own-dogfood goal - the site should be managed by Krang. Two major components are needed:
Publish-to-FTP functionality (see above) would also be helpful here. (Not really unless we switched hosts. SF only supports SCP. -sam)