Categories

Bluetrait
        Bluetrait
                Bluetrait
                    Coding
                    Geek
                    General
                    Videos
                    Solar
                    Coding
                    Geek
                    General
                    Coding
                        PHP
                        Bluetrait
                        PHP
                        Bluetrait
                        WordPress
                            Plugins
                        PHP
                        Bluetrait (Program)
                    Geek
                        Juniper
                        Cisco
                        IBM N2200 8363
                        PCs
                        Spam
                        IPv6
                        Apple
                        NetScreen
                        Internet
                    General
                        Uni

Thu, 24 May 2007 6:17 PM

Bluetrait 2

Michael Dale

I've decided to rewrite Bluetrait.


It's had a good run.


Getnews (the blog script that I wrote before Bluetrait) was aimed at providing a very basic blog with commenting support. It did this well, but a lot of it was hardcoded to my domain/style so it wasn't really useful for anyone else.


I wrote Bluetrait 1 as to allow others to easily use/install it. It had/has a very basic template type system. Over the revisions it has been slowly upgraded and now includes:


  • Good spam filtering. I think I'll finally got to a stage where I'm happy with it.

  • Awesome looking admin panel thanks to Stuart.

  • Event Viewer (which I really like having)

  • Basic RSS support

  • User management.

It has worked well on my site for almost 3 years! But it has some limitations that are starting to annoy me. The biggest problem I currently have with it is the way the CMS side works.


There is no way to categories pages and as my project page grows it is becoming an issue.


So I'm going to take what I've learnt with Bluetrait 1 and rewrite it.


I'm aiming to make Bluetrait 2 able to cope with all kinds of content for example:


  • RSS

  • Atom

  • Content/CMS

  • Blog

The idea is that the core of Bluetrait will have a section that allows people to design their own plugins which allows the system to handle any kind of data output.


Bluetrait 2 will also require PHP 5 as I'm using the PDO database class to allow for almost any kind of database (mysql, sql lite etc).


So the coding has started. Plugin support is almost done. I don't expect to have anything finished this year, hopefully early next year.


Comments

On Thu, 24 May 2007 at 11:04 PM, Josh Street (of michaeldale.com.au) wrote

Can you solve the tagging problem everyone (read:WordPress core team) seems to struggle with? Categories are easy, tagging (in a high-performance, scalable kind of way) seems to be a little harder. I'm a little interested as to why you feel compelled to do this from scratch... learning experience or genuine competitor to existing things?

PHP5 rocks socks.

1: Comment Link

On Fri, 25 May 2007 at 9:30 AM, Stuart (of michaeldale.com.au) wrote

If you're starting a Bluetrait 2, I want to start redesigning the Admin Panel to make it suit the new Bluetrait.org design that's ready to implement.

Talk to me some time.

2: Comment Link

On Fri, 25 May 2007 at 10:09 AM, Michael Dale (of michaeldale.com.au) wrote

I haven't yet looked into how I'm going to handle categories. Although the following link should help: Managing Hierarchical Data in MySQL.


I don't really understand the technical difference between tags and categories. They seem pretty similar to me. Tags are kind of like meta data for your post(s) were as categories have a bit more structure to them.


I have a project hopefully coming up that will make use of categories. Although I don't think I needs tags just yet.


I'm writing this from scratch as I've learnt heaps since I started Bluetrait. There is too much old code for me easily upgrade everything.


In terms of competition, I don't think any of the current CMS/blog tools do what I want. I've decided I need something that is closer to a CMS than a blog.


And Stuart I'd love to see the design stuff you've got in mind.

3: Comment Link

On Sun, 27 May 2007 at 3:18 PM, Josh Street (of michaeldale.com.au) wrote

Tags are like categories only there are lots more of them. On personal (1-user) sites it's not a big deal (because performance doesn't matter), and on enormous (millions of user) sites it's not a big deal (because it's automatically more efficient from unintentional re-use of tags, plus there are generally more resources to go around). For the in-between sites, it seems... potentially problematic. You either define each tag in a separate record (with potentially more records for metadata than for actual data!), or store them with the record they describe as comma separated keywords (or whatever), in which case your searching *should* become lots less efficient (opening all records to return only a few). Yeah, write operations are more intensive, so option 2 seems better... but for mid-sized usage scenarios the proportion of tags to content could rapidly become absurd -- and, consequently, any tagging metadata will potentially become less useful the more abstractly related they are to one another. Large usage deals with this by volume of tagging and the 'burying' effect (observed with user ranking of feedback on Slashdot, Digg, etc.)... but where less users are contributing (measured in users per item of content), I'm really not as certain about tagging's benefits.

It offers an exciting way to traverse related information that conventional 'search' may not, but where there's a low user:contributor ratio it may be self-defeating. Tagging works great because it achieves 'consensus' in keywords in large communities, not by establishing conventions (e.g. I am viewing this website on a: monitor/screen/display/lcd/crt - choose one and one only to tag this article with), but by fulfilling them _all_ in a way that _is never going to happen_ in a smaller environment.

And I know you didn't suggest tagging, but I'm still curious about that vs. categories.

Cool reasoning re: why from scratch. I'm intrigued by the observation that none can do what you want, but okay! Ever looked at ExpressionEngine? I'm considering it for some future adventures because it's a little heavier. My number-1 blocking feature is Akismet support, but even that's been taken care of... so it'll be getting a workout on the next small-medium sized site I get my teeth into!

4: Comment Link

On Sun, 27 May 2007 at 6:19 PM, Michael Dale (of michaeldale.com.au) wrote

I spent a few hours the other day working out how I'm going to cope with categories.


You either define each tag in a separate record....or store them with the record they describe as comma separated keywords....option 2 seems better...


Not sure if I agree with you there.

Why? How often do you post a comment verse how often does a user go through categories/tags.

Personally I don't think it matters all that much about how long it takes to insert the new tag. Because you're only dealing with a really small amount of data (compared to that in the database).

Plus you can easily setup two mysql servers, one for read, one for write.

My plan with categories is to have full breadcrumb/search features. The plan being to have heaps of sub categories that you can browse through.

Back on to the topic of tags. I think it would be difficult to sort tags based on how popular they are with your second approach.

With a tags_to_posts table it is a very simple count query.

I do think your second way would be quick for displaying a single post (or the posts on your front page), but I don't think it would be significant enough to justify it.

I've decided to use this category library for Bluetrait 2. Although I think I'll need to rewrite most of it.

5: Comment Link

Comments?

HTML allowed: <a href="" title="" rel=""></a> <b></b> <blockquote cite=""></blockquote> <em></em> <i></i> <strike></strike> <strong></strong> <li></li> <ol></ol> <ul></ul>
ie: <b>bold</b>

Your comment may need to be reviewed before it is published.

Message

Name

Email (not shown)

WWW (optional)

Allow contact form email

Remember details