Panels 3 / CTools TODO list:

This is a rough TODO list generated from my personal notes regarding tasks that remain to be done for Panels 3 to complete the alpha stage. This does not include the obvious tasks of find/fix bugs/trim the issue queue.

Delegator tasks

• We have node view and node edit; we do not have taxonomy term. This is easy except we need to be aware that we also override feeds, so we need to be sure there's an option to redirect feeds appropriately as well as handle the taxonomy page
• Low priority -- currently taxonomy_term override simply passes feeds through; also Views can override feeds. However, we probably want a taxonomy term feed override that lets us use handlers. But instead of a panel context handler, we'll need an RSS feed handler that will allow us to add views or something. This may require some good design thought, and since the current situation probably works 98%, priority is low.
• User edit override -- this one is difficult because we don't have the user edit forms as content types the way we do node edit. And with user.module being a bit of a mess, that is a very scary prospect.

Page subtask
The custom page subtask has a couple of outstanding items:

• beta blocker Locking. Task handlers have locking properly implemented (disallowing user edits if another user has a lock) but page does not actually have this. The break-lock feature is there, but locks are not enforced.

Access plugins

• Taxonomy by vocabulary. This is basically just like node by type, only using vocabulary. Should be easy.

Task handlers

• beta blocker A preview widget. This likely ties to arguments, so it's a bit extensive, but there really needs to be a widget so that a given task handler can be previewed, running through the access control mechanism. The argument can provide a selector to get arguments, or we can go with no real selectors and just enter manual arguments the way we used to.
• Mass export. We need a mass export tool that works like the old Panels export tool -- and in fact could probably completely deprecate the old panels_export tool which still exists.
• Display export. Task handlers (of the context type) have their own display; it would be nice to be able to export/import just a display from handler to handler. I'm not sure how high a priority this is; I don't think this feature is a beta blocker.
• Enable/disable should work on content types in the database as well as default content types. The only reason they don't is historical.

Panels cleanup
These are probably some of the most intensive tasks remaining.

• beta blocker Provide upgrade path from panels_page to delegator pages. This means analyzing the old arguments for 'own displays' and provide multiple task handlers. This is by far the most important beta blocker there is.
• Re-organize plugins.inc -- since a lot of functionality moved, this file has had a lot of code removed.
• Redo the panel content modules (mini panels, panel node content) to use .inc files just like everyone else for clarity.
• Redo display save to use drupal_write_record and schema info.
• Redo mini panel to use exportables rather than its own export mechanism.
• Remove simple cache module and replace it with a basic plugin that does the same thing. This will, I hope, more easily demonstrate the idea.
• Move content types out of Panels into CTools. Re-organize them at the same time.
• Fix flexible layout to use cached CSS.
• Fix rounded corners style to use cached CSS.
• Evaluate styles for re-org. Probably each style should have its own directory.
• Pie in the sky: Figure out if we can make it easy to iimplement color.module or a color.module clone with styles to create a style template that lets designers plug in a few images so that panels users could pick a style and then change its colors, thus allowing a much larger variety of pane decorations. Not a blocker but could be fun!
• Use a dropdown for settings on the edit content page; this will allow separating some of the forms down.
• Use access plugins for pane visiblity.
• Put something more interesting in the pane portlet (the collapsible) such as detailed information about what is in the pane, where it comes from, etc.
• Document the plugins Panels provides via advanced help to facilitate more authors writing them.
• Add advanced help links throughout Panels and CTools in favor of the blocky chunks of texts we've had in the past.
• Pie in the sky: Some kind of integration with admin_menu that allows us to administer the display we are viewing regardless of if it's a task handler, panel node, og_panel or other. This could be somewhat difficult to design but also could be both very fun and *very* rewarding.

Context updates

• UI selector for term context. This is hard because autocomplete only works for a single vocabulary; we need to be able to choose any term from any vocabulary without requiring a dropdown. Autocomplete does not allow for changing the autocomplete path from a second widget. This may require a custom autocomplete widget or something. Ideas needed!
• UI selector for user context so you can embed j. random user into a display. This is just your basic user autocomplete.
• Context converters (for Views). Right now context to views argument conversion is bad. We need contexts to allow (probably expandably) ways to convert a context into an argument for Views that is user selectable.
• beta blocker Context keyword expansions. Right now context gets one keyword substitution -- %key -> $title. But what if we had %key-nid -> $nid, %key->foo bar. This is a complex situation that maybe requires token (though token uses a different syntax than we do; we can possibly switch if needed).
• Create 'js' and 'css' autoload mechanisms on any plugin that uses the modal, so that items which use js/css within the modal can have the proper data handy.