oheric.com

An empty husk of a posting.

Me and Heather are going to make a website! We take lots of pictures of native plants, animals, lichens etc, and this will be a database of amateur sightings. Of course anybody can contribute their own sightings, and we will have a rating system so really neat pictures etc can float up.

Todo:
- temp domain (can't login to dyndns.org?)

collect:
- coordinates (or address)
- Photo
- species tags (free at first?)
maps

http://en.wikipedia.org/wiki/Category:Spoken_articles

I'm listening to the Lego article, it's a good format to listen to while doing something else, not too distracting but you pick up interesting snippets here and there.

Content management

Editing interface

• Filter configuration
• Evaluate rich text editor or simple markup

Image handling

• Attachments
• Aggregate formats
• Insertion
• Blocks

Events

1. Submitted by Anonymous
2. Reviewed by moderator
3. Approved

/base/(head)|(stable)

• Core system + select essential contribs

/sites/[name]

• Drupal sites dir for each site.
  • settings.php
  • database.mysql (prod snap)
  • themes
  • modules
• ACLs prevent snooping.

The auto database backup feature needs some thought. Database/sitename.mysql should always be a recent copy of the production database for the site. The main question is, when are backups made? I'd backups to be user-driven rather than timed. Ideally, checking out a new copy of the site should result in the creation of a db backup. Unfortunately, hooks are only fired on commit, not checkout. Since there are so many questions, we should start simple. I'll just make a script which parses $1/settings.php for $DB params, dumps to $1/database.mysql, and commits $1. Simple and useful. It may be necessary to play with the diff settings to get reasonable patch sizes.

Ok, we're discussing repos structure here. The question is, given Drupal's builtin per-site config dirs, are per-site SVN branches useful? It is possible, for instance, to put site-specific mods in the sites dir. Whether dev versions of mods which already exist in the global mods dir will consistently override the global copy, I don't know. Let's check… [opens editor] ^v^v^ Yes! (includes/bootstrap.inc function drupal_get_filename). So there would seem to be no reason to mainain seperate branches for each site. Awesome! The other thing is access control on the sites dirs. So we have two (or three) branches: prod, test, dev. In each branch we have implemented some acls so that you only get the site dir if you pass muster. That sounds hard. So maybe we store the sites in another repos path. Then you need to explicitly check out the site. And each site is ACLed. Frito pie!

So alot has been happening behind the scenes since my last blog update. I have a beefy new Ubuntu virtual server, which I have been industriously whittling into a kick ass Drupal hosting and development environment. The component which ties the whole system together is the Subversion repository. Whenever a new site branch is created in subversion, a hook is fired which automagically configures Apache and mysql. Sweet! Anyway, I'm working hard on launching some new services, in particular a business homepage with project management, documentation, etc. Cheers