Joshua Thijssen has shared a handy tip for those using Zend Server on a pupptet-ed server - using a Facter plugin to check for the ZS install and only install what's needed (rather than end up with multiple PHP installs).

This means you should not install the default PHP package for your distribution when the distribution also runs on Zend Server. This Facter plugin will allow you to use the $zendserver fact inside your own manifests to check if Zend server is installed, so you can take measures against installing stuff that is taken care of by ZendServer itself.

You can download the plugin from his github account, https://github.com/jaytaph/puppet-facter-zendserver, and easily install it into your puppet setup.

In a new post to his blog Brian Moon describes a need he had for detecting if the client or user calling a PHP script was using an interactive terminal (TTY) or not:

Let's say I am trying to find out why some file import did not happen. Running the job that is supposed to do it may yield an error. Maybe it was a file permission issue or something. There are other people watching the alerts. What they don't know is that I am running the code and looking at these errors in real time.

Since the errors were being sent to the log file, they were lost to the client/user on the other end left staring at their script wondering what went wrong. He ended up with a solution (a pretty simple one too) that uses posix_ttyname and posix_isatty. He includes the little snippet of code he puts in his prepend file that checks for errors then checks for a TTY. If both are there, it turns off logging the errors to the file and sends them direct instead.

Sameer Borate, in the wake of having security issues with his site, has posted a hint you could use to help detect when something has changed in important files in your application by checking their hash.

Today a couple of hours back my site got compromised. Not much changes to the code, but the .htacces was changed and some code [...] was added to the .htaccess file, which redirected the traffic coming from search engines to a malware site. It has now been removed and to prevent any such changes to the .htaccess file in the future, I've written a small php script that compares the hash (SHA1) of the two major files that usually get compromised and compare them to the one originally stored.

It's not a preventative measure by any means, but it can help you keep track of if something's changed. Several issues have popped up in the major blogging engines that allow for changes to be made directly to files. These changes result in the sha hash to be different and can be used to trigger a security alert. His sample code shows a basic call to mail an alert, but it could be as complex as you'd like (possibly even logging to a database or the like).

Michelangelo van Dam has started a new series of posts on his blog about quality assurance in PHP projects with this introduction and a look at the first tool on his list PHPLint.

Quality Assurance has become an increasing important part of web application development, especially with PHP applications. [...] Luckily there are a lot of tools available that allows you to increase quality of these web applications, and the best part is they are all based on PHP! Let's have a quick look at what tools are interesting to start improving quality assurance on your PHP projects.

The first tool, PHPLint, helps you validate code against syntax errors and is built into the command-line PHP you already have. He describes its use, both on the command-line and in a pre-commit hook on his git repository

For more PHP QA-related information, he also points out the book from Sebastian Bergmann and Stefan Priebsch as a good reference too.

On the NETTUTS.com blog today there's a new post that includes a list of sixteen things you need to be sure to check before releasing your WordPress theme.

Releasing a WordPress theme on a marketplace, such as ThemeForest, where the audience is so large and diverse, has some challenges. You cannot test a solution directly with the client. You need to plan in advance for all edge cases, and ensure that your theme is as customizable as possible. If you're inexperienced, chances are that some things will unfortunately slip through the cracks. Luckily for you, we have drawn on our hard-earned wisdom to help you avoid repeating the same mistakes we made.

Among the things they suggest checking are things like:

• Don't Display Comments on Protected Posts
• Introduce Right-To-Left Support
• Make Paginated Entries Work
• Do not Forget wp_footer() and wp_head()
• Support Custom Menus
• Make User-Visible Strings Translatable

Each item on the list comes complete with a description and code (when it's needed).

In a recent post to his blog Brian Teeman asks the question of Joomla users and developers - "can you trust your Joomla extensions?"

Sadly in the last 6 months there have been two published circumstances where an extension provider has been hacked and malicious code inserted into the extensions that they offer. This meant that as soon as you installed the extension your site was vulnerable to defacement etc. If there have been two published cases perhaps there have been more that we don't know about. So is there anything we can do to prevent this?

There is a sort of checking system in place with the md5sum matching but it's not widely supported currently. Sites like the Joomla Extension Directory would be prime candidates for sharing this sort of information to help protect those with Joomla installs all across the web.

Brian also suggests a way to make it even more seamless - integrate the md5sum checking into the Joomla code itself to make it even simpler for users to verify they they've gotten the write package from the right source (with the right code inside).

On the Content with Style blog, there's a "quickie" you can drop into a subversion hook as a part of your check-in that will run the lint command on only the changed files (not your entire repository).

If you haven't done it in a hook already, here's the quick way to check all your changed files for syntax errors.

This sort of command would be the most useful in a pre-commit hook to ensure that everything passes correctly. Their example only looks for ".php" files, but can be modified easily if you happen to use ".html" or another custom extension for your pages too.

Cody Taylor has a quick post to his blog about bit checking in PHP:

PHP makes life a lot easier for quick or dirty maintenance scripts, cron jobs or web applications but how does it do for older, not so straight forward problems dealing with bits and bytes? I was surprised how easy it was to manipulate bits in a byte with php. Here is an function that made my life a fair amount easier when having to check for a specific bit in a byte.

The function takes in the value and, after casting it to an int, checks to see how it compares to eight and returns it. This result can be passed through decbin function for output. A handy table of the bitwise operator definitions is also included.

On the DeveloperTutorials.com site today there's a new tutorial showing the creation of a port scanner with PHP - a tool that, given some of the familiar ports that services (like web or email servers) run on, can check to see if they're responding.

While building web applications, it's often important to keep an eye on the other services running on your server. Having access to the current status of public servers can empower your applications to make decisions and respond to problems automatically. Acknowledging a service is offline can also save endless support emails. In this tutorial, I'll show you how to keep track of your server status by scanning ports on your server with PHP.

Their example makes a socket connection to the remote port to see if there's a valid hookup. The wrap this inside a loop for ports 1 through 1000 to see what ports are open and responding on your local machine (doing this on a remote machine is just asking for trouble).

Their full example defines some of the common ports in an array and loops to check on their status. It sets out a base you can build on top of with things like their suggestions - logging scan results, repoting downtime and running a service-specific task.

Felix Geisendorfer has posted two new items to the Debuggable blog looking at suppressing errors in your applications - and no, that doesn't mean using the @ operator either.

As of late I am getting sick of some best practices I have taught myself. Never using the @-error suppressing operator quickly moving to the top of the list. Before you start crying out loud (I know you will), let me say this: I do not mean to encourage anybody to use the @-operator. Applying the practice herein introduced may result in permanent damage to your coding habits and could serve as a gateway behavior to writing shitty code.

He gives an example in the first post of a place where he failed to properly check to ensure an element existed before checking a element of it. The second post provides an interesting solution to the same problem - using empty on the element/subelement to check its existence.