As of version 6.14, Drupal works with PHP 5.3, but many essential modules still issue warnings (usually due to passing expressions by reference). If your Ubuntu 10.04 (Lucid Lynx) server is running 5.3, this script will automate the downgrade to the latest 5.2 by telling aptitude to use the source lists for Ubuntu 9.10 (Karmic Koala).
Thanks to Nick Veenhof, mrkandy, and their many commenters, from whom this script is derived.
php_installed=`dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`
# remove all php packge
sudo aptitude purge `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`
# use karmic for php pakage
# pin-params: a (archive), c (components), v (version), o (origin) and l (label).
echo -e "Package: php5\nPin: release a=karmic\nPin-Priority: 991\n" | sudo tee /etc/apt/preferences.d/php > /dev/null
apt-cache search php5-|grep php5-|awk '{print "Package:", $1,"\nPin: release a=karmic\nPin-Priority: 991\n"}'|sudo tee -a /etc/apt/preferences.d/php > /dev/null
apt-cache search -n libapache2-mod-php5 |awk '{print "Package:", $1,"\nPin: release a=karmic\nPin-Priority: 991\n"}'| sudo tee -a /etc/apt/preferences.d/php > /dev/null
echo -e "Package: php-pear\nPin: release a=karmic\nPin-Priority: 991\n" | sudo tee -a /etc/apt/preferences.d/php > /dev/null
# add karmic to source list
egrep '(main restricted|universe|multiverse)' /etc/apt/sources.list|grep -v "#"| sed s/lucid/karmic/g | sudo tee /etc/apt/sources.list.d/karmic.list > /dev/null
# update package database (use apt-get if aptitude crash)
sudo apt-get update
# install php
sudo apt-get install $php_installed
sudo aptitude hold `dpkg -l | grep php5| awk '{print $2}' |tr "\n" " "`
#done
Of course, make sure to restart Apache when you’re finished.
There’s one primary distinction between Drupal and WordPress. In Drupal, URLs map to PHP functions. In WordPress, URLs map to documents (or, quite often, collections of documents). The former can certainly be powerful and easy to work with. The latter, once you get used to the paradigm, can provide an incredible simplicity, powerful in its own way.
I was building a website today that has a location-based search component. Basically, I have a collection of posts with addresses, and I need to be able to search for addresses within a given distance of a queried address, and sort them by said distance. To be honest, that’s hard to do with WordPress. But it is possible…
Continue reading →
Building on my previous post about creating archive pages for custom post types, there’s another piece to add to the puzzle.
You archives pages will use the default index.php template. If you want to use a different template, you’ll need to hook into the template_redirect action to specify your template file. I like to use a file name like type-MY_POST_TYPE.php (although that’s easily changed), using the function below.
Continue reading →
When you create a new post type in WordPress using register_post_type(), WordPress does not automatically create a page for listing the archives of that post type. It’s possible to create one, though, without too much hassle.
For example, you can create an post type called article, and set the permalink for that post type to articles (i.e., an article will have a URL like http://example.com/articles/my-article-title).
Where do you go for a list of all articles, though? You might assume http://example.com/articles/, but you would be assuming erroneously. You could create a page with the slug articles and use a custom template for that page, but that doesn’t work with paging (e.g., http://example.com/articles/page/2/).
Instead, you need to fiddle with WordPress’s rewrite rules. (And thanks to Andrew Wilson for helping me understand this.)
Continue reading →
I’ve recently begun digging into CodeIgniter for a new project I’m working on. One of the first things that strikes me is the lack of a good way to set up your database tables. The standard method seems to be, in a nutshell: point and click in PHPMyAdmin or import a SQL file from the command line.
So, step 1: create an Install controller. This is a pretty basic controller that you access at http://example.com/install (and which you’ll disable after developing the site). All it does is create the database tables you’ll need and add any initial values you might want. You can figure the rest of it out on your own.
But I have a problem. I want to auto-load the session library for all of my controllers. That’s easy enough: just add $autoload['libraries'][] = 'session'; to your autoload.php file. The session library, though, requires a properly-defined table to exist in the database before it can be used.* If you auto-load it, though, it will also auto-load for the Install controller, which won’t work, since the tables haven’t been installed, yet.
*Technically, it can work without a database, but then I’d have to keep changing a configuration setting every time I want to re-install the database, which I’m doing rather frequently in the early stages of building this app.
So, I made a hack to get around that. Please note that I do not recommend this on a production site. This is for development purposes only.
Continue reading →
