The classes/ subdir is primarily for the DB_DataObject classes. Stuff
in there can get stomped by various generation scripts.
I've moved the lurkers there -- related to command-handling -- to
lib/. Since auto-loading works fine with lib/, there shouldn't be much
of a visible change here.
We try to handle DB_DataObject errors a little bit better. Previously,
they just spit out a cryptic string to the browser with a suggestion
to turn on debugging (not a good idea!). So, we catch the error, write
the full error message to the log, and then tell users that the can
contact the admins if they need to.
I got a little sick of trying to keep the export data and <head> links
synched in actions, so I made a common method, getFeeds(), which gets
the feeds for both. It returns an array of Feed objects, which know
about what their mime type is, title, location, all that jazz.
I changed the FeedList class so it handles the new Feed objects
instead of the old array of data.
I changed all the actions that show feeds (I think...) so that they
now use getFeeds() for all their feed needs.
Since plugins may define custom actions, we shouldn't require that
there be a file in our actions/ subdir for every action. So, I changed
the (admittedly hackish) auto-loading code in index.php so it instead
checks whether a class exists with the expected name. This, in turn,
uses the increasingly hacking __autoload() function, which I changed
to auto-load stuff named "BlahblahAction" from the actions subdir if
available.
Added two exception classes: one for client errors (= user can fix) and
one for server errors (only admin or coder can fix). The web entry point
now tries to catch exceptions and show them in the browser. The main
code for showing errors in Action class now throws an exception and lets
top-level handle it.
Moved the common_avatar_* functions to the Avatar class. Typically
either as methods on the object or as static methods. Replaced all the
uses of the functions in other modules.
