Mokka mit Schlag » PHP

I’ve decided the time has come to move several sites out of my spare bedroom and off this box and onto a shared host somewhere. I probably should have done this years ago, but there’s something nice about having a server you can personally reboot or stick a CD into when necessary. I need to be able to serve three sites:

• xom.nu (static HTML)
• The Cafes (WordPress)
• www.elharo.com (static+WordPress+custom PHP)

These sites are not mission critical, but I would like them to stay up. Reliable backups that I can download periodically are a must. I would like them to respond much faster than they do currently. (Xom.nu is pretty fast, but the two blogs can be dog slow at times.)

Traffic is not too heavy, though I don’t track hard numbers. I would like to be able to quickly ramp up to withstand a Digg effect if necessary.

These sites can all live on the same IP address. (They do now.)

I’d like the flexibility to install my own Apache modules and custom PHP extensions and modify the various config files such as httpd.conf and php.ini. Ideally I’d like to be install other frameworks such as Ruby on Rails or eXist if I feel like playing with them. That is, root access to the box would be very helpful, even if it’s virtualized. However I can probably live without that if it raises the price too high. Alternately, I could perhaps live with 24/7 phone support from a reliable sys admin who can make changes like that for me. However the ability to install and manage my own WordPress extensions and modified code is a must.

Any suggestions? So far here’s who I’ve looked at:
(more…)

I’m still finding this site to be unmanageably slow at times. One other trick that’s been suggested is to install eAccelerator to cache the compiled PHP scripts. (WP-cache only caches the output pages.) I’ve now done that. At first glance it does feel like a dramatic speed-up, but we’ll have to see how it handles under load. Please holler if anything seems broken.

The install was shockingly easy for a Unix server program: took me about ten minutes total including time to write this entry. That’s less time than it took me to install PHP in the first place.

Things do seem to be faster, though I’m still seeing occasional timeouts requesting pages. I really wish there were some decent profiling and logging tools that could tell me exactly where the system is bottlenecking.

My PHP error logs are filling up with errors like this one:

[05-May-2007 06:11:56] PHP Notice: Undefined variable: livePreviewDivAdded in /var/www/thecafes/wp-content/plugins/live-comment-preview.php on line 24

so I decided to see if I could fix it. I think the problem is this line:

$livePreviewDivAdded == false;

I’m using this post to test that.

I have written a WordPress plugin to rearrange the buttons in the post editor (the regular one, not the fancy WYSIWYG one) in a way more to my liking. It changes the names of some buttons, removes others I rarely use, and adds a few more I do use.

The code involves some really awful hacks and is a confusing mix of CSS, JavaScript, and PHP. I use CSS to hide the buttons I don’t like, and JavaScript to change the names of existing buttons and add new ones. PHP integrates this whole mess into WordPress. WordPress wasn’t really designed to support this level of customization. That’s why I have to use JavaScript to change the buttons after the page is loaded.
(more…)

Testing for some plain text problems in WordPress title formatting. Hmm, looks like this one is OK. WordPress turns the double quote into a curly quote which does not terminate the attribute value. The greater than sign is escaped inside the attribute value. so the problems only arise if there’s real markup.

The curly quote may be an accidental fix. I’m not sure what would happen if I figured out how to publish a real straight double quote in a title. I wonder if there’s a preference for that somewhere?

More interesting results from yesterday’s experiments with dumping some markup in the title of a post and seeing what breaks. I noticed the markup made its way into the WordPress Admin section. Is that just because the markup I used (strong and span tags) was relatively innocuous or is there a potentially deeper problem? Let’s find out.
(more…)