The latest issue of the Web & PHP Magazine has been published - Issue #10. This issue can be downloaded for free and has articles about:

• Building an Identity Extraction Engine in PHP (Jonathan LeBlanc)
• 5 Deadly Programming Sins (Michael Stowe)
• Physical Security Fail (Arne Blankerts)
• Database Indexing (Cory Isaacson)

You can also download previous issues of the magazine for free after registering or logging in to your account.

On DesignAeon.com there's a recent tutorial posted showing you how to extract URLs from your database and determine which ones are "dead" automatically with the help of cURL.

Checking Deadlinks From the database manually is a Headache ,So why not use a script which return the http status of the particular link and tell us if the link is dead or not.So how do we check the dead links from the database ? How do we programatically check whether the link is dead or not ? To check broken or dead links from Database we will use curl .

Included in the post is a sample script that extracts the URLs from a field in the database (you'd need some extra smarts if you're pulling it from content) and running it though a "checklink" function. If the call to curl_getinfo returns false, the link is marked dead.

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.