Here at MPP, we’re very big on supporting software companies who make great products that are reliable, trustworthy, and relatively free of bugs. When soemthing comes along that really makes us wince, though, we have to say something about it.

Such is the case with PHP Expert Editor, the PHP IDE from Ankord Development Group. It has very few features that the freeware Dev-PHP doesn’t have, and it has a few things that the others don’t.

• Frequent Random Crashes - At least once a day, the application will simply stop working in the middle of typing a line of code. Repeated inquiries to support netted us zero replies.
• Wonky laptop behavior - Our developers often use two or more monitors on their machines, and we’re all on laptops. If we need to present to a group, we’ll hook up to a projector. With PHP Expert Editor, disconnected or reconnecting an external monitor disables the ability to open a file or create new files until the application is restarted. This is exceedingly annoying.
• Macros that simply don’t work - There is a macro interface, but it’s just an interface. Macros just don’t work, no matter what you do.

Did I mention that it crashes randomly in the middle of writing code? Nothing like losing your work in all unsaved open files randomly and at the drop of a hat for seemingly no reason, definitely.
Normally, we don’t complain about software too hard that we use from day to day. Then again, normally the software works.

Take it from a professional programming house, Ankord’s PHP Expert Editor offering is a lemon, and their support has been abysmal in our experience. Forget purchasing it, get Dev-PHP instead. It has all the same features and doesn’t lock up and die for no reason.

~A!

I've seen a great many questions come in lately on the use of the header() function in PHP. This is just a quick note to describe it's use and some of the issues surrounding it.

There are two basic types of headers when we talk about HTTP Header directives. Request Headers and Response Headers. Request headers are what your browser sends to a server, and response headers are what the server sends back. I've seen more complicated explanations, and they are accurate, but that's the essence of the thing.

When you specify a header with the header() function in PHP, you're sending a response header from the server 99.9% of the time. Most of the time, you're trying to use a header to:

• Relocate to a different page
• Download a file

Headers can be used for a number of different things, including setting cookies, but we're not going to look at that in this article. The cookie functions in PHP can handle everything you want to do with cookies.

Relocation:

When you're relocating to a different page from PHP, the function you use looks like this:

Which will send that header to the browser, causing it to head over to page.php on the somesite.com domain. So, you enter it into your code, and everything works, right?

Well, not always. See, when you don't specify any headers but send output to the browser (with print(), echo(), or just standard HTML), PHP is smart enough to send it's own. (PERL, not so much, but that's a different story). So when you've output anything, including whitespace to the browser, you get message telling you Headers have already been sent.
If you're not sure why, and you haven't output anything to the browser on purpose before the headers you're sending, the first thing to do is check for whitespace right before your opening PHP tag in your code. Resolve that there is none first.

If you want a little cleaner solution, you can use ob_start() and ob_flush() to send everything into an output buffer before it gets to the browser, and have it sent all at once.
One caveat here is that you want to call ob_flush() as soon as possible, because on scripts with large output, you can slow things down considerably.

Example without output buffers:

exit() in the above example stops the script so nothing else will be executed. Without it, you can have the unintended consequence of doing something after you meant to redirect the user to a different page.

Example with output buffering:

~A!

I recently had to migrate a client from PHP 4.3.9 to 5.2 on a godaddy virtual dedicated server running Cent OS4, and I came across a fantastic guide for doing so:

http://www.jasonlitka.com/2006/11/30/upgrading-php-520-rhel-centos/

Unfortunately, I ran into a couple of problems with that guide, including broken links to a couple of RPMS and source packages that I corrected with forum searches and from the author's other posts, which are all fantastic. That is a great site, and Jason should be commended for his commitment to helping people do what they need to on Linux Servers.

I have assembled here the steps I took to upgrade, aggregating the information I got from Jason's site as well as the filling in I had to do.
So, without further ado, here are the steps I took:

1) Log into the server as root

2) mkdir /usr/src/redhat

3) chmod 777 -R /usr/src/redhat

4) yum install wget nano make autoconf automake rpm-build postfix fileutils file libtool gcc cpp gcc-c++ perl-DBI readline-devel libc-client-devel libstdc++-devel bzip2-devel curl-devel db4-devel expat-devel gmp-devel aspell-devel httpd-devel libjpeg-devel libpng-devel pam-devel openssl-devel sqlite-devel zlib-devel pcre-devel krb5-devel cyrus-sasl-devel openldap-devel postgresql-devel unixODBC-devel libxml2-devel net-snmp-devel libxslt-devel libxml2-devel expat-devel ncurses-devel gd-devel freetype-devel

5) wget http://www.jasonlitka.com/media/files/SRPMS/php-5.2.3-jason.2.src.rpm

6) rpm -ivh php-5.2.0-8.src.rpm

7) rpm -ivh php-pear-1.4.9-4.src.rpm

8) wget http://mirrors.kernel.org/fedora/core/6/source/SRPMS/pcre-6.6-1.1.src.rpm

9) rpm -ivh pcre-6.6-1.1.src.rpm

10) cd /usr/src/redhat/SPEC

11) rpmbuild pcre.spec

12)  cd /usr/src/redhat/RPMS/i386

13) rpm -Uvh pcre*

14) cd /usr/src/redhat/SPECS

15) pmbuild -bb php.spec

16) cd /usr/src/redhat/RPMS

17) rpm -Uvh php*rpm

At this point, php installed for me fine and dandy. Next, I updated the php.ini file to reflect the new modules directory, which was /usr/lib/php4 to the 5 version, which is /usr/lib/php/modules

Then I restarted apache to reflect the changes

18) /usr/sbin/apachectl -k graceful

After that, I just checked to make sure it had installed appropriately, and that mysql was working

19) php -v (Should display 5.2.3 for the version of PHP)

You can create a php file to check for the existence of mysql_connect() as I did, or you can create a file that actually connects to your database. Either one proves out the ability to connect to MySQL from your PHP installation.

Great big hat-tip to Jason Litka of http://jasonlitka.com for his doing the heavy lifting on most of this. The only things I had a problem with when following his guide were the PCRE version (it kept asking for >= 6.6) and a broken link to the php 5.2.2 source rpm on mirrors.kernel.org, which he fixed in this post on upgrading to 5.2.3 by providing his own source package.

Hope this helps anyone stuck with an outdated PHP version who wants to use actual object-oriented code and json functions from PHP.

~A!