Alessandro Nadalin has a new post to his blog looking at the Composer project and using it to manage packages and dependencies in PHP applications.

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.

Stuart Herbert has put together a series of posts detailing how to get the Phix component creation and management tool installed on various operating systems.

Phix makes it extremely easy to create and maintain your own PEAR-installer compatible components for reuse in your PHP applications. Installation takes just seconds, and it's both open-source and framework-agnostic!

The OS guides help you get it installed for:

• OSX
• Fedora
• Ubuntu
• Debian
• CentOS

For more information about Phix (including helpful "getting started" details) check out the project's website.

Jason Gilmore gets "back to basics" in a new tutorial with a look at managing configuration in your ini file to tune it to just what you need.

While PHP's configuration capabilities are indeed powerful, the sheer breadth and different ways in which these configuration directives can be set are often confusing and downright intimidating to newcomers. So in this article it worth meandering from the typically intermediate-level discussion and instead offer some insight into PHP's configuration-specific infrastructure.

He starts by mentioning the phpinfo function that generates the complete list of current settings for your installation. With that in hand and an idea of what settings are out there, he starts going through some of the basics of working with ini settings - updating the php.ini, setting values via a .htaccess file and chancing them directly in the executing script.

Chris Jones has a new post to his OTN blog today pointing to two new articles by Eli White about managing malicious website use:

The techniques Eli covers will always be applicable in one form or another. They should be a fundamental part of any website architect's bag of tricks.

The first article focuses more on methods for preventing and dealing with the inevitable spamming that comes with running a larger site. Eli's experience at Digg has provided him with recommendations like creating hurdles for spammers to get past and evaluating the content (services like Defensio or Akismet are useful for this).

The second article talks about something a bit harder to deal with - when users "game the system" and find the loopholes. His recommendations to combat this sort of abuse include rate limiting, pattern matching and leaving "traps" by tracking user usage.

New on NetTuts.com there's a tutorial about using cron with PHP and how to manage the jobs your server currently runs.

The cronTab, or "Cron Table", is a Linux system process / daemon which facilitates the scheduling of repetitive tasks thereby easing up our day to day routine. In this tutorial, we'll create a dynamic PHP class that, using a secure connection, provides us with a means to manipulate the cronTab!

They explain the cron format (time and script to run) and how to set up a crontab management class that uses the ssh extension for PHP to communicate with the remote server. Their class includes methods for setting up jobs, writing them out to the cron file, removing existing jobs and dropping the entire cron file at once.

Till Klampaeckel has posted a few suggestions for you if you'd like the take the reigns of a PEAR package when it's not maintained.

One of the more frequent questions I see on the mailing lists and IRC is, "How do I take over a package?". Very often people start to use a PEAR package and then at some point encounter either a bug or they miss a certain feature. The package's state however is inactive or flat unmaintained.

He recommends a few different courses of action - first asking if there's a way to help out, then stepping it up and pushing the fixes in yourself and, finally, deciding if you really do want to maintain the package (and show it by contributing).

Brian Moon has a new post to his blog that pulls together some of his thoughts on monitoring PHP applications and how to handle the error that might be thrown.

PHP errors are just part of the language. Some internal functions throw warnings or notices and seem unavoidable. A good case is parse_url. The point of parse_url is to take apart a URL and tell me the parts. Until recently, the only way to validate a URL was a regex. You can now use filter_var with the FILTER_VALIDATE_URL filter. But, in the past, I would use parse_url to validate the URL. It worked as the function returns false if the value is not a URL. But, if you give parse_url something that is not a URL, it throws a PHP Warning error message. The result is I would use the evil @ to suppress errors from parse_url. Long story short, you get errors on PHP systems. And you don't need to ignore them.

He talks about the two-step process he's upgraded to to help monitor and handle the errors that pop up - an error handler that logs human-readable and json versions of the errors and something like Circonus to do metric tracking. He also mentions some external services recommended on twitter - HopToad and Loggly.

On PHPBuilder.com there's a new tutorial on layouts in Zend Framework applications. The tools the framework gives you makes things much simpler when it comes to changing layouts and updating the general structure of your site.

Gone is the need to devise strategies for important tasks such as maintaining page headers and footers, separating the bulk of a page's logic from its interface, and managing the code repeatedly used throughout the site to carry out special formatting actions. Instead, you can just embrace the framework's conventions and move on to the next battle. This article introduces you to some of the fundamental concepts behind managing layouts within your Zend Framework-driven applications.

He shows how to enable the layout management tools and how to create a sample layout to ensure it's working. You can also switch layouts, disable them and use a few of the helpers that come with the tool to make it simpler for you and make your development time faster.

In this new post from the IBuildings blog today Ivo Jansch looks at content management systems and how you can start to find that right fit for your and your company/organization.

At the moment, Wikipedia's list of content management systems features 137 unique CMS products. 59 of these are written in PHP. And that's only the ones that Wikipedia finds 'notable', which means these are the ones that have significant usage or large enough communities to be mentioned. [...] The sheer size of the CMS market is interesting when you consider that one of the most frequent questions we get at Ibuildings is: "What CMS do you recommend we use?"

In an experiment in his recent talk (at the IMS conference) he asked the audience which car he should purchase from his list of four. Of course, their answers were wrong because of one fact - no one asked about his requirements.

This is a definite first step to anyone looking for a CMS to fit their needs (or really any kind of software). He also mentions other criteria to consider like cost of ownership, technology required, features and functional requirements.

In his latest post to his blog Lukas Smith looks at what things users and developers seem to hate about most of the content management systems available today (not just PHP-specific either).

This is just a quick start for a brainstorming of what we all hate in todays CMS (I am including portal/community software here as well and I guess most also applies to web shops) software out there. I have written a very small CMS application myself ages ago so I do not have experience in what its really like writing and maintaining a big one. All I know is that its insanely painful to deal with any of them, though if your site is all about having admins managing tons of static content or end users wanting to interact, there is little way around these ugly beasts.

Other "hated things" he mentions include the way that admin settings set stored in databases, the choices most of the software have made on their model layer and the lack of a quality API to extend the base functionality of the application.