CodeIgniter is fairly logically laid out, but lacks a public asset folder. You can of course create a public folder in your web root for these and did so for many years, but when it comes to things as robots.txt and SE verification files they needed to stay in the web root. I’ll so you how with htaccess modification you to can keep all your static assets in the public folder and nothing but core files in the web root.
What I mean by a “public” folder is nothing more than a folder called public to hold all your static files. These include: css; javascript; images; html pages; etc. Basically anything that CodeIgniter isn’t generating. Regrettably the url to retreive these is http:///public/
. That’s totally fine to when retrieving images, stylesheets, images etc, but doesn’t work so well when SE call http:///robots.txt or even http:///sitemap.xml. CodeIgniter will 404 for these types of files.
Of course you could place these in the web root but then you have to manage files both there and in the public folder. Myself I would rather keep like files together so with a few changes to the htaccess file you can serve http:///robots.txt from the public folder with no problem.
In your htaccess file add this below the RewriteBase / statement:
RewriteCond %{REQUEST_URI} !public/(.*)\.
RewriteRule ^(.+)\.htm$|^(.+)\.html$|^(.+)\.txt$|^(.+)\.xml$|^(.+)\.xml.gz$ public/$0 [NC]
That command statement instructs Apache to disregard any request that doesn’t include the public folder. If the request isn’t looking for assets in the public folder and the extensions includes .htm, .html, .txt, .xml, .xml.gz then redirect to the public folder.
So now you can have the robots.txt file placed into the public folder along with all your other static files, yet served up from a request of the root url.
Tags: CodeIgniter, php
As a single developer on a single application running different environmentsспални комплекти I find it tedious to have to duplicate my database changes everytime, whether they are permanent or not. When working with a group of developers and all of use making changes to the database schema it becomes even more hectic as to what was changed.
Since I am writing PHPDbMigrate as a PHP database migration manager and since ateI’m working with CodeIgniter almost exslusively I decided to incorporate PHPDbMigrate as a way for me to manage the applications database schema into CodeIgniter.
Now as I make the needed schema changes I only have to do it in a migration file. From which I can easily update all my environment databases. Along with that the other developers can easily see what I have changes, and I can likewise see their changes. Additionally PHPDbMigrate supports code blocks for running native PHP code in the migration for added help!
In the event we need to roll back those changes we have the option to do so to specific versions. This is an extremely important aspect to a failed production deploy where the code needs to be reverted as well as the database.
Installation is fairly straight forward. Choose the tar or the zip type downloads below and extract into your application. I have a README in the root folder to explain the rest on the install.
Currently PHPDbMigrate only supports Mysql(i). I’m bringing on more database types soon.
PHPDbMigrate-CodeIgniter zip file
PHPDbMigrate-CodeIgniter tar file
Tags: CodeIgniter, database, migrate
This morning I’ve finally released PHPDbMigrate RC 2.
The changes to this utility include:
all migration functions work in MySQL
mysql and mysqli database adapters supported
You can find the code here: http://code.google.com/p/phpdbmigrate/
I’ve still got work to do in support other database types and updating the wiki.
Tags: active migration, activemigration, database, php