In a new post to his site Frank de Jonge makes a distinction between packages versus components, pointing out that components are always packages but packages are not always components, and what it really boils down to is a problem of dependency.
The PHP landscape has fully transitioned into its Package Age™ […] However, due to PHP’s nature, there are some problems. While packages are great for re-use outside of frameworks, dependencies are still an issue. Namespaces resolve conflicts between classnames, but they do not offer a solution to package versioning. Especially in a framework-context, this can become very problematic. A real-world-example for this is Guzzle.
In his Guzzle example he describes the main problem – when packages restructure or make changes incompatible with prior versions and dependencies conflict and both must be installed. He also points out that, while this is bad for just packages, it can be made even worse working with components (his name for framework-based packages). Problems he mentions are the previously mentioned dependency conflicts but also some unexpected quirks with how Composer chooses to install packages. He gives an example of this second one with the installation of the Symfony EventDispatcher component and how, upon closer inspection, Composer seems to be installing two versions of the library at once.
On the Symfony Finland blog there’s a new post showing you how to serve PHP over HTTP/2 with HHVM and H2O. H2O describes itself as a „new generation HTTP server providing quicker response to users when compared to older generation of web servers“.
This article is not about improvements made in HTTP/2 – as there are plenty of locations for you to read up on the internals. It’s a hands on article to get started using HTTP/2 today with popular tools such as Symfony, WordPress and Drupal with the HHVM PHP runtime from Facebook. You can just as well use PHP-FPM.
They start with a bit of a look at the current state of PHP and HTTP/2 on the various major web server types. H2O, while younger, natively supports HTTP/2, he does offer the caveat that „waiting won’t kill you“. Despite this, they go on to show you how to set up the PHP+H2O+HHVM combination complete with configuration examples and what to look for in the logs to ensure HTTP/2 functionality.
If you’ve wanted to contribute something back to PHP but aren’t familiar with C (or don’t feel comfortable enough with it) Sammy Powers offers another solution. In his latest post he shows you how to contribute to the PHP documentation and update the manual for new features, missing information or fixes to current code examples.
If you’ve been wanting to contribute to PHP internals, starting with the documentation can be a great entry point; especially because it doesn’t require dusting off those old C books from college. But knowing where to start can be tricky since information on how to contribute to the docs is scattered across the internet. This article is a step-by-step guide of how to contribute documentation to the PHP manual.
He starts with the „quick and dirty“ way of editing the manual through the edit.php.net site, but points out that it’s really only useful for smaller changes, not large documentation updates. The rest of the post shows you how to set up the documentation locally and generate the results to validate your changes. He talks some about the DocBook format they’re written in, the build process with the PhD (PHP docs generator) and running the php.net test suite against the changes. This ensures that nothing else has broken on the site in the process.
He shows you where to make your changes, how to generate it from either a skeleton or using the docgen script and submitting the changes back to the repository. There’s also a few other random changes to make before committing the files back via SVN and pushing them back upstream. He ends the post talking about the GoPHP7-ext project and how to find extensions that are missing documentation or where it’s incomplete (easy thanks to an included „check-missing-docs“ file included in the repository).
Hafiz Waheeduddin Ahmad has a new post to his site, part three of a series he’s posted on API testing, looking at the use of Codeception for testing API output and functionality.
In this post, we will have a look on how we can use Codeception for API testing.
He starts by helping you get Codeception installed through Composer through a „require“ command line call. He then walks you through the setup of the project and how to use the „codecept“ command line tool. He covers the generated directory structure the bootstrapping created and how to set up a sample configuration for your API. He then gets into writing an example test, showing how to check things like authentication, HTTP header information, response codes and response contents. Finally he shows how to run the tests in both a normal and more verbose way.
In remembrance of the 20th anniversary of PHP, the Zend Developer Zone has created a new post sharing tweets from the PHP Community Twitter account covering the history of PHP.
My friend – and PHP Community Old Guard – Ben (@ramsey) Ramsey did something awesome for PHP’s 20th, he tweeted out the PHP timeline. I’ve gathered them all here to celebrate both PHP and the work he put into this project.
The post shares a long list of the tweets from the account mentioning the happenings of the last twenty years. It starts with the first release of the language back in 1995 (by Rasmus Lerdorf) and goes all the way up through the present day. It’s been quite a ride over the last 20 years. If you’re new to the PHP community or just want to relive some of the memories of the past, check out the full post!
In a new tutorial on the NetTuts.com site they show you how to use a Digital Ocean PHP SDK to manage your cloud instances from a PHP-based application.
The Digital Ocean API allows you to manage Droplets and resources in a simple, programmatic way using HTTP requests. All of the functionality that you are familiar with in the Digital Ocean control panel is also available through the API, allowing you to script the complex actions that your situation requires. For this tutorial, we’ll integrate developer Antoine Corcy’s Digital Ocean V2 PHP API Library into a Yii-based console application.
They walk you through the full process of the setup – getting your access keys, getting the PHP SDK and setting up a component as an interface for the rest of the Yii2 application to use. From there, he shows three examples of the types of commands to can issue:
- Fetching Droplets
- Fetching Images
- Automating Snapshots
Each example comes with the code to implement it and screenshots of both how the same functionality looks in the Digital Ocean control panel and the output of their script.
In a new post to the ServerGrove blog they look at linting tools for various circumstances including standard PHP, Twig templates and Composer configuration.
Today’s projects are built up from dozens of different components, configuration files, third-party libraries, tests, build scripts, etc. And even if you have the greatest test suite, bad things can happen sometimes. It’s important to catch bugs as early as possible, and syntax validators can be a great (and easy) addition to your continuous integration system. You would be surprised at how many problems are caused by syntax errors. At ServerGrove, we see these kind of problems with our clients almost every day.
Their list shows you how to lint (syntax check) several different types of content:
- standard PHP code
- Twig templates
- Composer configuration
- XML files
- Bash scripts
- JSON files
- YAML files
Some of them use tools that already come built-in (like PHP’s „-l“ or Twig’s „twig:lint“) but others require the use of external software such as xmllint or melody. Command examples are also included for each.