So, I've set up a personal blog

When setting it up, I first looked to see if there was any existing single person, developer focused blog features or install profiles. I was unable to find one, at least not on drupal.org. So I had a few choices to consider.

I could use one of the generic blog features that are not tuned toward either single person or developers. This I quickly rolled out; I don't want to burden myself with a feature that doesn't offer me what I need but does offer me with what I don't need. Using a generic feature because it exists isn't necessarily a good reason. The power of features is people can make single sets of configuration that cover specific use cases, and while 'a blog' is a use case, it's too broad to create a really useful feature. The idea that there should be a single 'blog' feature that everyone uses is a bad idea (I still somewhat believe in).

I believe it's rooted in anti-druplication, generally a good thing. The druplication in modules is bad because it splinters efforts (e.g. instead of one great module, a few crappy modules are) and confuses site builders on what module they should be using. However, theoretically, features should be effortless -- just groups of configuration that can be thrown together and updated quickly. The effort in them should be focused in design of how they function (how best to fit the use case, how best) and development of modules the feature configures/uses, not on the actual feature or feature generated code itself, so it's not a loss of effort in development time, and design time is focused on meeting specific use cases -- not a loss either since it's designing for different things. It also doesn't contribute to site builder confusion as long as features are clear what use case they are seeking to fit -- the generic blog feature, however, does because it *has* a very generic use case it's not necessarily clear on.

While it's a nice thought that a generic 'blog' feature could fit even a majority of use case for blogs, it doesn't seem that is the case or should be the case. Instead, there should be a few blog features tailored, perfected even, to specific use cases, even though they'll likely they will be using the same or similar contrib modules and have similar components being used.

Or at least, that's currently how I've been thinking.

So, the first option, using an existing feature, I threw out.

Next option was to just throw together a content type + some views + some modules, and go on with my day. However, that doesn't help the void of there being no developer, single use focused features/install profiles.

I should create one. However, I'm not happy with my thrown together views/content type -- it doesn't seem it'd meet the use case completely yet. If only there was a way for people to offer suggestions [feature requests] on how to improve this to fit the use case... -- like a d.o issue queue! (I'm being sarcastic and making the point that throwing together what I do have and putting it on d.o would allow others to contribute to making this feature better satisfy the use case.)

Anyhow, I may do that, assuming I remember all of this in the morning.

Comments

The latest blog post on my blog covers similarly. My solution was to put it on github. You might find what you want there. Links are in the blog post.

Add new comment

Filtered HTML + code filter

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.