[Join] or [Login] to make requests and vote. Accounts are free and we will respect the little personal information you give us, not pass it to others or send you unsolicited mail.
Mainly the edit side needs tidying up.
We need pages at:
/admin/posts/$year/
and
edit pages that work at
/admin/posts/$year/$short_name/(explain/)?
The soon-to-be-finished blog module should let you save a half-finished post as a draft, and it only appears on the admin-side.
Must set the added_at when the draft is finished; I think the originally-started-at date should just be thrown away.
I imagine this would be done using a secondary submit button on the browser-side.
On the DB-side, we could just store a flag in the db and then filter or use a view for all the public access (as with gallery_store vs. gallery_pictures), or make a separate table (as with gallery_store vs. gallery_uploads). Since there's a serious difference in the constraints, I lean towards the latter, although you could always make a more complex compound constraint.
Feeds should be available for each section of the blog and for all sections together. The feeds should:
Optionally:
Attach a picture from gallery, which should have choices of:
The picture should have an optional title, which would default to the gallery title, but the default could be overridden.
Optionally:
Allow blog posts to be split into sections, which either goes
/$year/$section/$foo/
or
/$section/$year/$foo/
at the user's config choice.
The default should be to 302 one to the other, to avoid confusion, although a user may want to override that.
Post short_names are scoped by section.
Allow a user-editable list of tags, and store a map for tagging posts.
Build some handy function-callable heat-map/fontsize-navigation, with sensible bubbled up information.
Allow a config option to call them tags or keywords at the user's choice.
The you are here nav, like:
Up to: Foo home / Bar / Zim
are made differently on:
This will cause pain in future, as they all want the same basic behaviour, and there are some odd edge-cases with security (especially where the breadcrumbs are shown on a templated page for a 404 or similar).
Should just be a few define() options and a simple breadcrumb call.
We need some admin interface for comments, in particular to delete anonymous comments.
Should be configured by a few define()s on a per-site basis to say who may delete things.
Some of this already exists in the gallery code.
As with the branch of the code running on gallery, users should - in general - be able to edit the comment if there's is the last added in the conversation.
Given that we're pretty hooked on the notion of user-contributed short names to go in URLs, we should offer more core support for what we do when we change them because the original supplied was crummy.
Gallery has its own way of doing this, that's quite hairy, since we've also been doing gallery-mergers.
This may be as simple as a db-driven list of redirects and codes. If we did that we should have a fairly easy way of hooking it into Apache. We may want to hook into it at the mod_rewrite level.
By defining a linkable_sections function you can get some spiffy behaviour out of format_text_as_html where <space>/<sectionname>/<space> is replaced with the right link, with proper link text.
The pattern should be looser to allow /foo/ at the start of a line.
Mail-based notifications for changes on a site.
At the very minimum we need to stop it from bombarding a user annoyingly, or getting out of its tree.
In beer-chatter so far this has led to some agreement that types of mail should be rate-limited and batched.
I believe the appropriate way to do this is to send the first notification immediately (so infrequent changes go straight out) and then schedule a bot to check again for that sort of message after some user/site-defined delay. When sending messages then, if the last one was sent ages ago (outside the delay limit) it goes now, otherwise it gets stuck somewhere so it can be batched up in a pleasant manner to be sent as a collection when the bot runs.
Needs thought about:
Would like to restrict to plain-text mail, at least in the first bash, to avoid having to worry about much MIME fun & games.
Have out-of-the-bag simple permissions, based wholly on presuming clean, hierarchically nested URLs, and delegating to the most specific stem which has a declaration.
A small fixed number of permissions:
Avoids the full on permission/membership/object hierarchies that were hard to get to grips with in ACS 4, but covers all the cases I really care about:
I generally wouldn't use it for item-level permissioning, although you could, as I'd be inclined to keep that as a function of some attribute of the particular content row.
A simple way to reflect a column referencing users into the straight permission lookup would be very handy - but not essential.
A module to run polls, with a set of options, plus possible 'write-in' candidates, which are displayed to people only if they get a certain threshold of votes (number/percent).
The simple-comments package is all well and good, but we encourage people to allow commenting at any URI that ends /comment/. We should instead find a way to assert that the prior page actually has a call to simple_comments on. Perhaps by some magic in the simple_comments() call which registers the page in the the db.
Probably really want something smarter that hooks up to mod_rewrite properly. Could do that with a map that holds a db-connection, but would need to figure out the performance hit of doing it on many sites.
Also, would need some mechanism for pulling sites.
Suspect this will all become part of a larger scheme for managing the rewrite rules from a Web interface.
Should be able to borrow code from PEPAdb for db-driven rewrite-maps.
Roll the events site's top n lists back in to the toolkit proper so you just specify a query and an optional formatting function, limit to display and a link for more if there are more than that.
Be especially handy for this site, to address [requests:useful-front]