Gallery2:Roadmap:2.3 - Gallery Codex
Personal tools


From Gallery Codex

Revision as of 14:03, 29 March 2007 by Zimzat (Talk | contribs) (Modules to finish and include: Notification)

This is a draft of some thoughts and ideas for 2.3:

Areas for focus

  • Performance
    • MPTT
    • Break language packs out of core
    • Reduce # of class files required for an individual page load
    • Locate, Analyze and Optimize db queries using most CPU time
  • Page size
    • Examine all javascript
  • Data Integrity and Robustness
    • Provide an integrity check / repair module
    • On platform errors, try to chmod and try again before failing hard
    • Make certain filesystem operations transactional (create, move, delete) coupled to the DB transactions
  • Package size
    • Stop shipping locale hierarchy (4091+ directory entries in the full package!)


Do we want to try to maintain API compatibility with 2.1 and 2.2? This will give module developers and themers a little more breathing room to develop new themes.

API breaking changes we could make

  • Move color packs down into themes, so each theme has its own set of color packs
  • Move GalleryUtilities into the GalleryCoreApi
  • Make GalleryCoreApi non-static
  • Unify rendering to new getRenderer / renderer pattern
  • Add return status to canBeViewedInline and less hardcoding in there (to make it a lot easier to extend existing item types to new mime-types and customization)!
  • Change the handling of GalleryStatus code to support warnings. Maybe something more OO like typed exceptions extending a base class.
  • Register event listeners in the database, like registered factories, instead of loading all modules on each request.
  • An object's "entity type" should never disagree with it's class name, otherwise when the object is unserialized, the framework will import the class file corresponding to the entity type and unserialize an object whose class is not available. This causes PHP to halt with a fatal error.
  1. Drop the GalleryEntity::setEntityType setter. If it's ever called, Gallery will probably eventually have a fatal error, for instance if the object is cached.
  2. Drop the GalleryEntity::getEntityType getter. Use GalleryEntity::getClassName instead.
  3. Rename the "entityType" member "className" and ensure it always agrees with the value returned by GalleryEntity::getClassName.

These changes would eliminate any possible discrepancy between "entity type" and class name by dropping the concept of "entity type" in favor of class name.

API consistent changes we could make

  • Allow themes to override any .tpl file (there's a task for this)
  • AJAXify all admin pages
  • AJAXify the progress bar (make it a popup instead of an interstitial page)
  • Move GalleryUtilities into the GalleryCoreApi, but allow the old code to delegate back. (this might not be API compatible-- requires some thought)
  • Extend the allowable number of permissions from 31 to 256. (Hopefully this will be API compatible).
  • Get rid of the g2_statusId and g2_navId from the urls. If this means deleting those two features, I'm totally ok with it. They're marginal at best (especially statusId) but they clutter up our urls.

Modules to improve

  • Rewrite: The current model of centralizing the rule management in a single module is flawed. We wind up causing the module developer to write complex rules that the rewrite module can parse in order to manage the rewrite rules on our behalf. It would be far easier to settle on having the rewrite module insert one rule into .htaccess that parses the entire short url and then dispatch it to the individual module in a way that it can easily parse and use. The module generated the url, it can parse it just as easily. There's no need to try to codify everything in such a way that the rewrite rule can understand it.
  • RSS: This is way, way, way too complicated. It needs to be much easier to install and setup for the common case.

New modules

  • Watchdog module: we need a way to be able to track errors that are happening in g2, that aren't user visible so that an admin can get a reading on the health of their site. Example usages:
    • Images that fail to build
    • Failed login attempts
    • any errors that bubble up to main.php
  • Scheduler module: we need a way to do asynchronous site maintenance. See this forum discussion
    • Cleaning watchdog table
    • Cleaning sessions
    • Cleaning cache
    • Notifications (daily, weekly, monthly)
    • Expiring / Unpublish content
    • Publish content / Notify author of content that is scheduled to be published in 1 day
    • Different scheduler trigger engines: cron, autorefreshing page, low-CPU check on every page impression, ...
    • Contact ckdake about "expire" module by the Department of State and see sfvote to update dependent RFEs when the scheduler is available

Modules to finish and include

  • XMLRPC (needs update, refactoring, review, and probably a bit more)
  • jpegtran (needs review)
  • cmmigrate (needs review)
  • embed (needs update and refactoring)
  • Notification (Needs major rewrite)


  • Need a way for modules to easily add content to <head>/<body> header/<body> footer

Nice-to-Have's from G2.2