This is documented in the CI user guide already, but there's a fair bit of choice on the format for your .htaccess file. This is what mine looks like:
# jedd 2009-02 - obviates requirement for index.php in URLs RewriteEngine on RewriteCond $1 !^(index\.php|files|assets|robots\.txt) RewriteRule ^(.*)$ ./index.php/$1 [L]
Observations ... I have directories in my root called files and assets that I don't want CI messing with, and you can easily add more in there as you need. I call ./index.php - but you could hard code the PATH in there if you prefer (I like it this way as I never have to change it for a new project).
And don't forget to change the the config/config.php file:
$config['index_page'] = "";
I really dislike using a _model suffix on my Model names, so instead I shop around for synonyms (where applicable) or just rely on the fact that my models (which typically front several database tables) don't really need to clash with my controllers (which present a user perspective of a particular resource).
Model and Controller names, as well as table and column names in my DB, are consistently singular.
Controllers tend to be nouns, and their methods tend to be verbs. This aligns with the 'controller is a resource manager', as well as the 'method is a way of doing something' approaches. People who don't follow this approach, as a very general rule, at least if the forums are indicative - are usually much more confused about their controller design.
There's two popular PHP documentation utilities out there, and I happen to have discovered phpdoc first.
It is a script, that uses the PHP command line interpreter, that runs through your code and produces a set of web pages that describe all your functions and classes and stuff.
All that's required on your end is to put in those comment blocks that you've probably seen used everywhere already - they look like this. If you don't put these blocks in, you'll still get some useful pages out of phpdoc, but they won't be as useful.
/** * Forum * * Handles public message forums * * @link Message (Model) - which handles all message-related tables * @package pdb * @version v0.9 * @author jedd * @link http://my.web.site/trac/pdb **/
With CodeIgniter, or I guess any framework, the trick is to only include the bits of the framework that you need to in order to have your code doco make sense without overloading it with the framework's methods and classes. In my case I want CI's Controller and Model, but none of the other CI libraries included in my documentation set.
My phpdoc shell script (for Debian GNU/Linux, but would work on any distro I guess, and probably OSX - but no idea how you'd go about doing this on MS-Windows) lives in my project root directory, and the output is to a peer directory. In this case my project is in /var/www/devel/pdb and my phpdoc dumps its output into /var/www/devel/pdbdoc.
I run this manually, but it's an ideal candidate for a cron job - the thing takes about 4 seconds on a 2Ghz box with 2GB.
#!/bin/bash phpdoc -d /var/www/devel/pdb/app \ -f /var/www/devel/pdb/system/libraries/Model.php \ -f /var/www/devel/pdb/system/libraries/Controller.php \ --defaultpackagename "pdb" \ --parseprivate \ -t /var/www/devel/pdbdoc/ \ -ti DOC-pdb # stuff I might put back in later ... # --output "HTML:frames:phpedit" \
There are lots of resources out on the Intergoogle about setting up and using git - and I recommend this one for starters: Git for the lazy person.
git is insanely easy to set up - pretty much 'git init' - and it's about a half hour to get your head around the basic functions. Perhaps less if you're already familiar with Subversion or something similar.
git lets you easily revert to (and come back from just as easily) a 'given point in time copy' - assuming you get into the habit of committing your changes regularly - and that alone is worth the price of admission.
Yes, you'll use a smidgen more space, but disk is cheap, and you are likely doing regular backups of your development environment anyway. This just makes those backups even more useful (note - it doesn't replace the need for backups - oh no).
This is yet another tool that people assume works best for multi-people projects, but I find it's handy to have one dedicated to each project, even little ones. It's inexpensive (it uses sqlite) and easy to set up, and gives me a place to make notes to myself about wishlist items and bugs that I've found but haven't got around to fixing yet. It's also a great source-code browser, with plugins for git and svn and a few other CVS suites.