• $host
• $user
• $db
• $password

That is your database access information. Now to change your admin password. When you connect to your database (using the mysql command line client on your server most likely), go to a table called jos_users and look for the admin user:

select id, name, username, password from jos_users;

Somewhere in those results should be a user called ‘admin’ in the ’username’ column. If not, you should probably see which account was acting as the admin superuser, and that is the one you want. Now change that password to ‘changeme’ like this, and note that I had to run the string ‘changeme’ through MD5 first as all passwords in Joomla are hashed:

update jos_users set password = '4cb9c8a8048fd02294477fcb1a41191a' where username = 'admin';

Now you can login to the Joomla backend as admin / changeme, and IMMEDIATELY change your password.

For this very reason I keep a simple PHP script on my laptop that has a form that posts a text field and echos the output after an MD5 hash. That way I can generate MD5 hashes of known strings when I need to reset a password, for instance.

Hope you find this useful, and please pipe up in the comments if this post needs more detail.

Since I’ve been bemoaning the sorry state of Joomla as a blogging platform, I’ve been politely told that I can in fact use Joomla as a blogging platform, and it’ll actually work like, you know, a blog.

So I’m investigating extensions and such to add the following features to a Joomla site:

• comments
• trackbacks
• pings
• tags

I know there are commercial platforms that can do some or all of these things, how about open source ones? The few things I HAVE tried were awful.

When I got it all figured out I’ll relaunch the blog, and document how it was done.

What is it now?

Right now this site is running WordPress with a few additional goodies:

• Pyrmont V2 2.0.7 by motta
• About Me 3000
• Twitter Widget
• My TwitPics
• Contact Form 7
• Dean’s Code Highlighter
• Google Analytics for WordPress
• Google XML Sitemaps
• Sociable

I tried the WordPress Events Calendar but it didn’t work; and ditto for my experience with a variety of book plugins, who either had absolutely horrific markup and display or broken code.

My favorite app in this whole experience ended up being the WordPress for iPhone app – which does exactly what it says, and allows you to manage posts, pages and comments all from your iPhone. Best of all you can incorporate photos in your content, making it more than just a “in case of emergency” tool.

Once I figure out what I’m going to do for a Joomla-powered blog, I’ll post as well. And this time I’ll include some redirects for old URLs from the WordPress instance, and keep the old content and comments. Wish me luck.

Frameworks were created by developers, for developers – with the main intent to streamine the effort needed to create features and functions that were common across the vast majority of websites that they developed in their day to day work. Login, database access, caching, templating, session management, filtering of user input, the list goes on and on. However there are different approaches to how a framework can be used to your advantage, and the difference can be sometimes subtle.

NOTE: I’ve found another good reference on web frameworks, with a different view.

Now what was I saying? There are really two main kinds of frameworks: stack and glue.

Stack ‘em up, bartender

The concept of stack frameworks – sometimes referred to as scaffolding frameworks – is to generate the majority of the base code needed to produce a full-featured environment for the developer to be as productive as possible. The concept is to provide the full stack, with deep integration and workflow suited specifically to benefit the needs of the developer.

On the one hand, stack frameworks can be wicked fast for prototyping, and you can also take advantage of the stack to quickly add additional features to an existing application. As well, many developers appreciate the completeness of the stack approach as upgrades are easy to perform, and are usually done as one atomic operation.

On the other hand, stack frameworks are also referred to as opinionated software, meaning the framework has a strong opinion about how things are to be done; and if you have a different opinion then you’re not going to get along very well. It is commonly said – and commonly debated – that stack frameworks are more vulnerable to performance and scale issues as they attempt to do too much for too many… And ultimately fail to meet the needs of everyone to great satisfaction.

Notable stack frameworks are Ruby on Rails (the real pioneer in this regard), CakePHP, and Symfony.

Sniffing glue

Glue frameworks are for the do-it-yourselfer – you glue together the parts specifically required by your application, and nothing more. This takes a much more hands-on approach for the developer, and usually means prototyping is not as insanely fast as a stack framework, however prototyping is still very rapid. Most importantly the performance and scaling of glue framework applications usually can be mitigated by extending an existing part of the framework, or replacing it altogether. For this reason a lot of developers prefer glue frameworks, having lived through painful customization efforts on less flexible platforms. Glue frameworks are usually very modular in nature, and that provides the additional benefit of having a large array of additional add-ons that developers can take advantage of.

The main drawback for glue frameworks is that they do require more effort from the developer. If you are light on development resources, or are more worried about the ongoing maintenance of your application once it is up and running, then this can be of significance.

Notable glue frameworks are Zend, Joomla! 1.5, Code Igniter, and KohanaPHP (my current favorite).

But wait, there’s more

“Joomla! 1.5 is a CMS“, you say. Technically you’re right. However Joomla! 1.5 is actually two Joomla!’s – the framework, and the CMS. Speaking of CMS, we must include both Joomla! and Drupal here, as IMHO they provide an even bigger benefit to the client – software longevity and maintenance.

As a developer, you usually don’t worry about what happens after launch. For the folks that live and die by this application however, that is of paramount importance. For them, they need to know that their investment is protected from bit rot, or the slow decay of unmaintained software. What exactly does a CMS like Joomla! or Drupal do in this regard?

First, they provide a base platform that in essence is a finished and complete starting point for your application platform. That means you are able to run a basic website out of the box, with minimal or no modification. Additionally, each also boast a rich array of third party goodies that can be added for instant gratification – forums, integration with social media services, photo galleries, you name it.

If you are diligent about your development practices, you should also be packaging up your software as an extension to these environments. This provides the additional benefit of reuse, so software you write once might find a second life for another website or application purpose.

Finally, these are complete environments that are maintained by a group of folks dedicated to furthering that software project. This is living software, or software that takes on a life of its own as a variety of different people contribute to the evolution and maintenance of that software. By basing your website on one of these platforms, your client can take advantage of every update and enhancement this community produces for that software project.

There are a great many frameworks out there that are not covered, and that is merely because I cannot keep track of all of them. What other PHP frameworks deserve mention? Did I miss one that really deserves mad props?

In short, they are bad. Not bad like mixing parachute pants with knitted sweaters, but bad like trying to eat a Volvo because you are hungry.

Auto increment, how much do I hate thee? Let me count the ways:

1. Firstly they encourage lousy design. If you are going to use a relational database, you need to bother yourself with learning basic relational theory.
2. They blow a hole in the push for a more semantic web. They are just numbers, and have no meaning.
3. They make sharding really really hard. Hope that site of yours never gets very successful.

Put more bluntly, right now the only databases that use auto increment are MySQL and Microsoft Access. Yes, there is a reason, and it ain’t a good one.

First lets cover the ‘lousy design’ angle.

Don’t forget your keys, honey.

When you are building a table, you need a primary key.

(You’re still with me, right? Good.)

Now this key needs to be unique for every row. Maybe there is a user table in your website, and there is a column called username.


+----------+---------------------+
| id | username                  |
+----------+---------------------+
| 62 | admin                     |
| 63 | amy                       |
| 64 | charlie                   |
| 65 | hasselhoff                |
| 66 | dracula                   |
| 68 | caroline                  |
| 69 | peter                     |
+----------+---------------------+


That’s unique, right? Then why are you leveraging a number that has absolutely no meaning? In the good ol’ days when I had to walk to school 20 miles each way in the ice and snow, naked, disk space was expensive and RAM was even worse. Then this kind of approach would have been appreciated as a cost cutting move. Nowadays? Fuhgeddaboudit.

If you are building a relational database, you need to know what a relational database is in the first place. There are tons of free resources out there to help you along. Trust me, knowing how to take advantage of a relational database and actually using one is akin to getting a drivers license and actually driving. Otherwise, you’ll make no friends plowing into someone’s living room with their car.

The worst part about this approach is now whenever you insert a record into that table, you gotta make a second call to find out what the id was. Pretty sure it would be a lot more efficient to know when you inserted the row what the primary key was, now don’t you think?

Say what you mean.

Using the above example, when I am referring to a user on your website I am not going to say “hey man, did you help out user #41432995?” I’m going to ask you about the user “funkychicken” or “the dude with the MIT email address.” (For the record, anyone from MIT referring to themselves as funkychicken is okay in my book, ‘s all good with me.)

If you refer to a particular record by a column in that table, most likely that is your natural primary key. Why ignore that for an artificial one?

Slicing and dicing, gone horribly wrong.

When you start dealing with websites that got too big for their britches, the first point of major pain is almost always the database. Relational databases can be scaled, but it is hard, and can only go so far. Most big websites in this situation can either migrate to a different platform (more on that in subsequent posts) or chop their data into smaller chunks so it is easier to manage. This practice is called sharding.

With that out of the way, sharding is really really hard when all of your information is linked with arbitrary numbers with no meaning. Sharding approaches are unique for every shop and website, so instead of making a passionate argument here, I’m going to leave you to your own devices. Try it yourself, and within a couple hours you will be nodding in complete understanding (and agreement).

There’s always somebody who refuses to fit in.

That’s right, there are plenty of scenarios where auto increment is doing you a favor. It was actually meant to do that favor for you. They just never envisioned an entire database schema littered with nothing but random numbers as primary keys.

Comments, for example. I’ve seen databases where articles go in one table, and comments go in another. The comments are not necessarily unique, maybe except for the timestamp and email of the person making the comment. Instead of making a composite key and additional index overhead, auto increment makes sense here. Besides, you are always going to be fetching based on the article_id or some such, right?

But wait, it’s just not that easy.

“Your users example is no good for me though, as I have multiple records with the same username (one is an old disabled account, or whatever). This doesn’t make sense to have a composite key of username and status!”

You’re absolutely right. And that’s why I think you should consider a different datamodel. This one maybe makes sense if you are auto increment happy, and I’d say over-reliance on auto increment is what got you into this jam in the first place.

Try it – design a database from scratch, with absolutely zero auto increment columns. It is a good exercise, and I promise that even if the resulting database is worthless, you will have learned a few things.

Next up I’m going to talk about a couple different approaches that are leaving the realm of tomorrowland and starting to percolate in today’s consciousness.

JTable, in this specific instance, won’t let you change the values in the jos_users.id column. Unfortunately that was exactly what I needed to do. In the end, I had to hotrod my authentication plugin to check to see if the jos_users.id was the same as the id coming over from the REST calls – and if not, manually update jos_users and jos_acl_aro_map.

I created an authentication plugin that consumes the REST service. In the onAuthenticate method I take the results of the REST call and stuff them in the session thusly:

For the user plugin, I created an onAfterStoreUser method that takes the values stuffed in the session above, and compares them to the existing JUser object properties. Right now all I am really looking for is the jos_users.id as that is what I cannot take care of with the stock facilities provided by Joomla. The method looks strikingly like this:

Now you have a system that fetches user data from a RESTful service, and populates the Joomla tables to make JUser happy.

Look ma, no core hacks!

One ugly ‘feature’ of this system is that on the first login, the user finds themselves in a state where they attempt to authenticate with one id and it gets updated. Since I have no way to tell JUser to reload itself, you have this strange experience of logging in twice and then everything is golden.

Interested in hearing how others have dealt with this problem.