My editor of choice for PHP for the last year or two has been phpEclipse. It’s the best compromise so far between IDE-like features (especially being able to search the entire code base, being able to have multiple projects open at once, and the absolute best class/function inspector in any PHP editor I’ve used so far – I can’t live without these features) and a text editor with acceptable performance (which is where Zend Studio has always lost out; can’t abide an editor that can’t keep up with my typing), syntax highlighting and code layout.
Unfortunately, phpEclipse doesn’t get released all that often (the last official release was 18 months ago now, although there are nightly CVS builds for folks who can afford to risk a broken PHP dev environment, and unfortunately I can’t afford that in my day job). That’s a long time to go without bug fixes and useful new features! It also suffers from that annoying Eclipse-ism of being unable to do anything for 10 minutes or so when you first open a project, whilst the workspace is rebuilt.
So I’m currently auditioning Textmate to see whether it can replace phpEclipse as my environment of choice. First impressions are pretty favourable (it supports projects, its fast, and the syntax highlighting is close enough) but it seems to lack a few useful features that phpEclipse has (like a class inspector – grrr, and being able to use phpdoc to provide context-sensitive help) and the performance seems to suck something awful when working on remote filesystems over 100mbit ethernet.
I was wondering if anyone else who reads Planet PHP has switched to Textmate, and if you’ve got any tips you can share on how to make Textmate a great PHP editing environment. If you do, please leave a comment below.
25 comments »
I’ve just seen Wez’s post about Microsoft’s new Community Technology Preview for their SQL Server 2005 extension for PHP.
Why Is It Important For Microsoft To Support PHP On Windows?
I can’t speak for the rest of the world, but Windows is an important platform here in the UK. About half the customers I work with run their websites on Windows Server. Every customer who prefers Windows Server over Linux automatically wants to use the full Microsoft stack, and that means IIS and Microsoft SQL Server.
Starting with Windows Server 2003 Service Pack 1, IIS became a viable platform for running production PHP sites on. SP1 has a fix for a nasty problem in the Windows kernel which stopped PHP working well as a CGI program under IIS. It’s true, IIS has serious limitations compared to Apache which cost time and money to overcome – chiefly no out-the-box equivalent to mod_rewrite – but it performs well and is simple enough for many folks to admin more easily than Apache (although the new IIS7 admin interface might be a step backwards there). With the new FastCGI support recently released, it’s now possible to further optimise an IIS setup too.
SQL Server is a true heavyweight database server. The most commonly deployed version that I come across is SQL Server 2000, although SQL Server 2005 is starting to appear in various enterprises. It is fast, scalable (in the old-fashioned way unfortunately, which is expensive), and when it comes to old-fashioned replication (as opposed to scale-out) I think that it leaves MySQL for dead. Although expensive to buy outright, if you buy your hosting boxes from places like Rackspace, the cost tends to be much more reasonable.
PHP comes with an MSSQL extension that’s based on the old TDS data protocol, which I believe is a legacy protocol from the old Sybase days (SQL Server is based on Sybase). TDS is also supported on Linux through the FreeTDS project, which allows PHP running on Linux boxes to connect to Microsoft SQL Server running on Windows.
What’s Wrong With The Existing MSSQL Extension For PHP?
… or, why do we need an improved SQL Server extension for PHP? 🙂
The existing MSSQL extension works well, but has a few practical limitations that have to be worked around.
- Limited to varchar(255) support. SQL Server 2000 and later support varchar columns longer than 255 bytes in size, but unfortunately the old TDS-based MSSQL extension can only support up to varchar(255).
- No support for unicode columns like nvarchar. The size of a varchar column is specified in bytes, not characters. If you’re working with UTF8 or UTF16 encoded data, one non-ASCII character takes up multiple bytes of space. This cuts down on the amount of characters you can store in a varchar field, and it makes things like HTML form validation – er – interesting. nvarchar, by contrast, is advertised as a variable-size datatype for storing multi-byte characters. nvarchar(255) holds 255 characters, not 255 bytes.
- No PDO drivers. Although there’s some debate about the performance merits of PDO, PDO’s prepared statement support is a real boon when it comes to preventing SQL injection attacks.
- Poor error reporting. The MSSQL extension doesn’t provide an equivalent to mysql_error() et al, which is a bit of a pain.
At the moment, I’ve no idea whether Microsoft’s extension addresses any of these issues. There’s no documentation online, just a .exe file that isn’t going to run under OS X 🙂 I’ll have a look at it when I get to my Windows PC at work, and see what it can – and can’t – do.
15 comments »
… is this little labeling rule in the file contexts:
/usr/lib(64)?/httpd/modules/libphp5.so -- system_u:object_r:textrel_shlib_t:s0
Does this mean that RedHat is shipping a mod_php5 that isn’t compiled for relocatable code support? (See my earlier post on compiling PHP as relocatable code). If they are, according to this page by Ulrich Drepper (hey, doesn’t he work for RedHat? 🙂 ) then RedHat Enterprise Server 5’s copy of mod_php5 might be using more RAM per Apache process than necessary, which will impact scalability and capacity.
Be the first to leave a comment »
I’ve been playing around with RedHat’s newly released Enterprise Linux 5. This comes with PHP 5.1.6, which I’ve taken off my test box and replaced with a copy of PHP 4 built from source.
After installing PHP 4, the first time I tried to start up Apache, it failed with this error:
Cannot load modules/libphp4.so into server: modules/libphp4.so: cannot restore segment prot after reloc: Permission denied
This is an error message from SELinux (which is enabled by default on RHEL5). The error has been triggered because the PHP runtime code contains text relocations – a situation where the code inside the .so has to be writable in memory.
(The definitive place to look for information about text relocations and the risk they pose to the security of your server is this page from Ulrich Drepper).
The quick workaround is to run this command on your server:
chcon -t textrel_shlib_t modules/libphp4.so
This command tells SELinux to allow text relocations inside the libphp4.so Apache module. (Use the command “chcon -t usr_t modules/lib4php.so” to reverse the effect, if you need to).
There are a couple of serious downsides to this workaround. The first one is that it disables one of the protections that SELinux provides. It makes your server more vulnerable to security exploits targetted at the PHP runtime itself. The second problem is that your server uses more memory per Apache process, because each Apache process ends up with its own copy of PHP.
One fix is to recompile your copy of PHP 4 using the “–with-pic” configure option. This produces a copy of PHP that doesn’t contain text relocations. In theory (I haven’t tested this yet), it should also be able to handle more concurrent connections on a server before the server runs out of RAM. Using Apache’s ab benchmarking app, my results suggest that PHP 4 w/ “–with-pic” is about 0.7% slower – small enough not to matter for many folks.
There’s a second way to avoid text relocations – don’t compile with “–with-pic”, and use the prelink tool instead. This tool, run from the command-line, works out the text relocations once, and then writes the data back to the binaries and libraries. From my testing, this avoids the SELinux error, and performance-wise it’s about 0.1% faster than PHP w/ text relocations, and about 0.8% faster than PHP 4 w/ “–with-pic”. This approach should also bring the benefits of reduced memory usage too that go with the “–with-pic” approach, but I haven’t done any testing to confirm this.
Which approach is the best – PHP 4 w/ “–with-pic”, or using prelink? The downside of using prelink is that this approach is reported to be unsuitable for Linux installs configured to do address space randomisation. You also have to remember to re-run prelink everytime you upgrade or re-install PHP. Using PHP 4 w/ “–with-pic” avoids these issues.
Be the first to leave a comment »
Page 9 of 9« First«...56789