In this recent post to his site Raphael Stolt shares an example of what he thinks is a "dope" setup for a Composer package (a well-structured, consistent and fully populated package structure).

While contributing to Construct, maintained by Jonathan Torres, I gathered some insights and learnings on the characteristics of a dope PHP package repository. This post summarises and illustrates these, so that PHP package developers have a complementary guideline to improve existing or imminent package repositories. Jonathan Reinink did a good job in putting the PHP package checklist out there which provides an incomplete, but solid quality checklist for open-source PHP packages.

I'll distill the characteristics of a dope PHP package repository by looking at the repository artifacts Construct can generate for you when starting the development of a new PHP project or micro-package.

Included in his list of things every PHP package should include are things like:

• the source (naturally), matching tests/specs and documentation
• consistent naming
• versioning information (via a CHANGELOG)
• Travis-CI integration
• A . gitattributes file for excluding certain files from export

He also makes a few more general suggestions like avoiding the posting of "badges" in the README and some reasons why you should care about the "dopeness" of your repository at all.

The SitePoint PHP blog has posted an article adding to some of the others about the recently released Laravel Valet tool, providing an overview of the product and what it has to offer.

Valet is a tool which makes spinning up demo or discardable projects a breeze.

It’s a tool which combines some of the default software on OS X with some ideas about filepaths and serving of PHP apps, and some additional tools for skipping the need to modify the /etc/hosts file. Additionally, it allows for forwarding of access to the local application over the public internet when needed.

Unlike Vagrant or Docker It offers no isolation, making all apps use the same globally available software. Why this is important to note will be explained below.

The post then gets into some of "the particulars" the tool has to offer, essentially the "lock in" requirements:

• OS X only
• Shared system state (no VMs, only global)
• Automatic virtual host
• No dev / prod parity
• Vendor-lock (with a caveat)
• Live self-hosted preview

They point out that while Laravel Valet can be a handy tool if this is the tooling and setup you're looking for, it might not be for everyone.

On the SitePoint PHP blog they've posted a tutorial from author Nicola Pietroluongo that wants to help demystify regular expressions with a few more real-world examples. He doesn't teach the foundations of regular expressions here and instead opts for a more "cookbook" approach with lots of little examples.

A regular expression is a sequence of characters used for parsing and manipulating strings. They are often used to perform searches, replace substrings and validate string data. This article provides tips, tricks, resources and steps for going through intricate regular expressions.

He starts with some basic tips around creating good regular expressions for your application: knowing the scenario you're matching, planning the requirements and implementing the match itself. His example expressions include matching for:

• simple passwords matching a policy
• valid URL matching
• HTML tag patterns
• finding duplicated words

Each example comes with the regular expression itself and an explanation of how it's doing the matching, breaking it down into each piece of the regex puzzle and how it relates to the match overall.

Loïc Chardonne has kicked off a new series of posts on his site that talk about doing "Symfony Differently" and some things to consider/change to increase your Symfony application's performance.

Symfony is an amazing HTTP framework which powers high traffic websites. Performance shouldn't be a concern when first creating a website, because between the time it is launched and the time it actually has a high traffic many things that we didn't expect in the first days will happen: requirements will change, user behavior will change, even the team can change.

Optimizing applications has an impact over maintenance, and making it harder to change right from the beginning might not be the best option. However when the need of performance actually arises, we need to tackle it. This series of articles is about this specific moment, and how to tackle it in a pragmatic way.

He starts with a basic project (Acme) and works through the process of adding a new feature to it: buying an item. He talks about the team they have to work with and the architecture of his sample application (a frontend application mostly). He then works through the data structure and flow of the new feature and other functionality that should be included. He ends the post with a bit of a wrap-up of this first part and talks about the next part in the series where the application will actually be bootstrapped.

The SitePoint PHP blog has a new post today introducing RAML, a modeling language made specifically for use in APIs to define services available.

n a recent article I introduced Slate, a static site generator specifically designed for writing API documentation. This time around, I’m going to look at something which in many ways is even better. But first, if you’ll indulge me for just a moment, I’d like to begin by quoting myself from that article; "[an] API is only as good as its documentation." I think it’s worth repeating, since it’s all-too-frequently overlooked, and it’s one of the motivations for this short series of articles on some of the tools out there to help you write great documentation.

RAML (RESTful API Modeling Language) provides a structured, unambiguous format for describing a RESTful API. It allows you to describe your API; the endpoints, the HTTP methods to be used for each one, any parameters and their format, what you can expect by way of a response and more.

He starts off with a few things that RAML is particularly good at helping with, including being used to generate other documentation. He then moves into writing up some of the actual RAML documentation, noting that it's a derivative of YAML and is just made from text files. He walks through the creation of a sample RAML document including the overall summary information, describing resources, HTTP methods and response structure. He also includes examples of defining query parameters, request data and any security requirements you might have. Finally, he suggests the raml2html tool if you want to generate some HTML output of your configuration, making it easier for normal humans to read.

In his latest post Anthony Ferrara talks about PHP version requirements and how it's a bit of "chicken and egg" problem. If hosting providers are slow adopting even PHP 5.4, can we realistically bump up the minimum to PHP 5.4+ and potentially shun users not at that level yet?

Most people agreed with me [saying new software with a PHP requirement <= 5.2 is beyond irresponsible, it's negligent], saying that not targeting 5.4 or higher is bad. But some disagreed. Some disagreed strongly. So, I want to talk about that.

[...] Now, these are pretty interesting arguments. It boils down to making the logical argument that if hosts don't support 5.4+, then moving to require 5.4+ would leave the users who use those hosts abandoned. And some projects don't want to abandon users. It's a warm and logical idea; Open your arms to everyone, and include them all. Don't leave anyone behind. Really, it's a good argument. The problem is, is it based on a flawed premise...?

He suggests that it sounds somewhat like an appeal to emotion and that by enforcing a bump up like this would be "abandoning the users". He gets into some of the statistics he worked up regarding PHP versions, WordPress usage and how, because of these large numbers, hosting companies would make the move if only for business reasons. He talks about the "Go PHP5" initiative and the impact it made on versions supported across the board. He also looks at some of the reasons why keeping up with these versions is good for the hosting companies too: security, education of users and the new features that come with later versions.

So I put this to you, WordPress, CodeIgniter and every other CMS and Framework still supporting PHP 5.2 and 5.3 (and earlier versions): Step up and lead. Step up and be the change you want to see. Don't follow and react, lead and be proactive. After all, if we can move forward together, we can all benefit. But if we walk separate paths, we build walls and we all lose...

In this recent post to his site Phil Sturgeon has a reminder that you should select the dependencies for your packages wisely, and not just because they're "cool."

When I say "make sure it is worth it" I mean, don't just switch your arrays from array() to [] just because it looks cool. That was the extent of my original tweet, because I've seen a few packages doing that and it annoyed me immensely. [...] Suffice it to say, if you require a user to upgrade their version of PHP simply so you can use some syntactical sugar inside a package that nobody else is even going to be looking at, then you're an idiot. Beyond that, you're actually hurting the community.

He notes that, by requiring users that are currently only at 3.1% of PHP installs to upgrade to 5.4 just to use your library is a quick way to not have your library used. He points out that PHP 5.4 is "more than just []" for arrays and includes a reminder that several projects are still in PHP 5.3-compatibility mode just because that's the widest audience. He also briefly touches on the "push it forward" comments that people have used to justify 5.4-only packages, but notes that it's still not as much up to the developer as it is the web host.

Lorna Mitchell has a quick post related to some of the OAuth work she's done on both sides, consumer and provider. This latest post relates to the OAuth pages and endpoints that are needed as a part of the authentication process.

This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. [...] OAuth has a little more baggage with it than just passing a username and password to an API.

She lists the five things you'll need for your service and talks a bit about the registration process and how the consumer key/consumer secret keys are generated. There's no strict definition on them, so her example uses a combination of sha1, mt_rand and substr to get the job done. She also includes a sample "consumers" table for your reference.

Simas Toleikis has posted an interesting idea for a validator that would look at the incoming source of an application/script and determine what the requirements for it might be.

How about creating a PHP code validator? Got this idea by looking at tokenizer and reflection extensions. I doubt I will find the time to work on this myself but then someone else might be interested to pick it up. From user’s point of view there will be a form made of a large textarea box and a single file upload input. One could paste code snippet on that textarea or upload a ZIP'ed source code archive (or a single .php file) for validation.

His proposed result would show a list of "Required Extensions", PHP versions, E_STRICT compatibility and possibly total lines of code in the project. He points out a few issues that might pop up in writing such a tool such as the requirement for it to be able to use the tokenizer extension itself (a sort of catch-22 since it's not always installed).

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.