If $config['site']['openidonly'] is set to true:
* the Login/Register pages will be removed from the navigation;
* directly accesses to the Login/Register pages will redirect to the
OpenID login page;
* most links to the Login/Register pages will link to the OpenID login
page instead.
The user will still need to set a password to access the API and RSS
feeds.
Expanded the ProfileList class so it worked more like a recipe. This
helps to get rid of a lot of special cases and simplifies the code. It
also makes it possible to do things like group block.
Add an array of arguments to isReadOnly() method of actions, to let
them change their results depending on what actions are called.
Primarily used by the 'api' action. Ideally in the future that will be
multiple actions. But this might still be useful.
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.
My attempts here are to mimic the `pagination()` method shared by
actions. I'm tentatively adding the `$count` property to actions so that
we can query the number of notices ''being displayed'' per page prior to
calling the actual `pagination()` method itself, since document
relationship `<link>` elements need to be output inside of `showHead()`,
before `showContent()`, which is where `pagination()` is, gets called.
These extra `<link>` elements only appear on pages where pagination
makes sense. They trigger functionality in some user agents, such as
Opera's Navigation Bar for more easily navigating forward and backwards
across a paged set of notices, messages, or group lists, etc.
