Pecl was giving me some problems so I needed to install APC for PHP manually. Pecl was compaining that apxs was not found during the config process, so I had to install it myself so that I could pass it the proper path.


wget http://pecl.php.net/get/APC-3.0.19.tgz
tar -xzf APC-3.0.19.tgz
cd APC*
phpize
./configure --enable-apc --enable-apc-mmap --with-apxs=/usr/local/apache2/bin/apxs
make
make install


Make sure you actually use your correct path to apxs. If apxs isn’t installed then you need to install the httpd-devel package, which usually works just fine through yum install httpd-devel

Then, just add the so path to your php ini and restart.


vi /usr/local/lib/php.ini
extension=apc.so


Then restart your server and should be done! Try running phpinfo(); to see if APC reports as installed and enabled.

I’ve been looking at the Habari Project, a new blogging tool developed specifically for the current state of the web and is supposed to become a Wordpress killer. (I’m using wordpress 2.5 for this blog).

The first issue I encountered was the requirement that the mbstring php extension be installed. This extension is not enabled by default, although most web server companies enable it for you in their installation. It was not the greatest experience having to recompile php to enable this, but since it won’t affect most users, I don’t see a large issue with it. However, I’m curious as to how the project will change when PHP6 is released, with improved Unicode support.

The second issue was that the system required me to use an SQLite database during the install which runs on files written by the web server to the file system. I usually don’t like use flat file system for personal reasons. The documentation lists MySQL as an option, but it wasn’t available as a choice during the install.

I’ve also noticed that the software is extremely slow on a CentOS machine. I’ve been using a pentium three with 256mb of ram for application development for months, and no private or public application takes as long as this application to run. Portions of the install process even take up to twenty seconds to load.

By default, the output format of the blog is HTML Transitional. I’ve read in their documentation that it was decision that was debated, but I cannot agree with their reasoning on why they chose HTML versus XHTML, and even beyond that why they would choose Transitional over Strict. My development partners and I are very strong supporters of using xhtml strict in every project and we’ve found that it’s provided the best results in accessibility, user interface development, and integration with server languages.

The user interface is very clean and a welcome relief over the wordpress administration tool. However, I can see the UI becoming cluttered as the application grows and, like Wordpress, the navigation may loose it’s current usefulness.

The speed of the application itself ran as expected, and I did not experience any slowness.

Overall I feel that it’s decent blogging application and would be a joy to use for custom development for clients. Unlike Wordpress it was developed only for PHP5 and by my quick glances at the templates and the API, I feel like it’s got a better quality and more robust codebase.

One thing I’ve learned with the larger-scope projects is that you need to estimate in time for providing assistance using them to the client. I always included training time in the estimates and for larger projects that was decent, but I’ve done several projects lately where clients have specifically requested the ability to change or re-use portions.

What I never considered is the level of support they’d need when attempting to re-use the product. Even though it’s ten minutes here and there, that time builds up, so you need to be able to estimate that out.

If you find it difficult to estimate, then perhaps it would be better for you to offer a monthly recurring fee similar to a retainer. This allows you time to provide support, brain storm about changes or improvements, etc.

After dealing with some weird update issues trying to do this with a manually-download rpm file, I finally figured out that performing the following worked just fine:

# rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
# yum -y install lighttpd lighttpd-fastcgi mysql-server
# chkconfig --levels 235 lighttpd on
# /etc/init.d/lighttpd start

I did decide to change the port to 81 so that apache could still run on 80:


# vi /etc/lighttpd/lighttpd.conf


Could have sworn that I’ve posted about this before, but it seems to be missing. To change the minimum word length that MySQL uses for a fulltext index search, just set a configuration and restart.


$ vi /etc/my.cnf


Then add in:


ft_min_word_len=3


Or whatever minimum word length you’re looking for. Then, restart:


/etc/init.d/mysqld restart


Then rebuild your fulltext index.


ALTER TABLE `mytable` DROP INDEX `myfulltext_index`
ALTER TABLE `mytable` ADD FULLTEXT `fulltext` (
`myfieldname` ,
`anotherfieldname` ,
)