
See that lil' radio button that says "Structure and data"? Well. If you're backing up a database table using SQLyog, make sure you check that if you plan on dropping the original table.
Oops. Sorry JC

See that lil' radio button that says "Structure and data"? Well. If you're backing up a database table using SQLyog, make sure you check that if you plan on dropping the original table.
Oops. Sorry JC

He insists on standing in my way whenever I'm using the computer. Jerk.
Hopefully by now you know what Subversion, aka SVN is. It's a version control system that keeps track of changes made to files like source code and documentation. It's similar to CVS, but with some major advantages. We've been using it at work for awhile, and I really like it. Changes don't get lost, we can easily keep track of released versions, and once we get around to implementing it SVN will tie into our bug tracking system.

We usually have two servers for a project, one as the development server, and the other a production server. We all have a working copy checked out on the development server. Using virtual hosts with Apache we all have our own sub domain. So for example on our dev server we'd have:
With each pointing to that developers working copy. We make our changes on the dev server as we're making the site, when we finish a task we check it in, and everyone does an update often to avoid conflicts.
When we are getting ready to push a release out to the production server we have to be careful since a lot of the time there are people using the site. We don't want to have errors pop up on the production server. To make sure it runs on that server as well as it did in our working copies, we have a staging area. It's on the same server as the production copy, but only we have access to it.
So we do an export to the staging area, click through the site and run through a checklist of things to check for and once we're sure it's running ok we copy that to the production area and it's live.
Since we want to keep track of the versions we push out to the production server, we give that release a version number, tag it in our Subversion repo, and update our project wiki.
This workflow has worked well for us and if we have a problem we can always roll back to a previous release. We can also use the Change Report feature of SmartSVN to do a kind of code review when others commit code. If we see something a little strange we can fix it, or if's completely crazy we can roll back quickly.
This is just how we do it, if you do it differently I'd love to hear about it so just leave a comment. In the future I'd also like to look into using Git in a similar way.
I never get comments, or requests, so this is for Peter.
Here's a sample controller for CodeIgniter. This is pretty much the structure and it doesn't do much. When you go to yoursite.com/blog, anything in the index function will run.
If you added a function called edit, and went to yoursite.com/blog/edit, then that would run.
All this controller does is load the links from the links table, get the page content for the current page ID, and then passes that to the views. In your views folder you would have 2 files, sidebar.php and content.php. Those would be your template files.
$links would be a variable available in the sidebar view that just contains the result of the database query from _load_links().
And then the view for the sidebar can be anything, like:
EllisLab released the latest version of CodeIgniter on January 30th. They've made plenty of improvements and bug fixes, and you can check out the changelog on their site. I've been using CodeIgniter for projects at work for about six months and I love it. It's made my code much more organized and easy to modify. If you aren't using CodeIgniter, or some other kind of PHP framework, I suggest you try it out. It's lightweight, easy to learn, and the documentation is fantastic.
One feature that I've always wanted is multiple views. Most web sites are split up into chunks like the header, sidebar, main content and footer areas. With regular PHP, you'd just do a require() to load the part you want, but with CodeIgniter it always felt a bit messy doing that.
Now if you want to load multiple views, you can do the following:
That's a great improvement, but today I was working on something where I want to have the loader return the view instead of render it right away. I loaded up the code for the loader and found out that it's already there. I didn't see it mentioned in the wonderful user guide, but I tried it out and it works great. So if you want to load a view but have it return the view as a string instead of rendering it, all you have to do is:
I'll be using this all of the time now. It's a great feature that just makes sense a lot of the time.