In a recent post to his site Leonid Mamchenkov has shared a few links to packages that provide country and currency lists and a new one he's discovered that does an even better job.

Many software projects deal with the lists of countries and currencies. Some of the most common tasks include country an currency dropdowns, country flags next to the IP, or pre-filling country codes in phone numbers.

All of that information is of course standardized and you often just need a library or two to provide and use it. And there are many of those. [...] Today, however, I came across a better option – antonioribeiro/countries, which is a collection of country and currency information for Laravel PHP framework. Laravel is not required though.

The package, easily installable via Composer, provides information for over 250 countries and 250 different currencies. There's also flags, maps, states, cities and more. Check out the repository for the full list of data it offers.

In a new post Larry Garfield makes an interesting suggestion related to the use of arrays in PHP. He suggests that you should never type hint arrays in your method definitions.

Let's be controversial: In modern PHP, you should never type-hint an array. Before you start throwing tomatoes, hear me out.

PHP allows you to specify the type of a function/method parameter or return value. These return values can be any legal PHP type. [...] PHP has a data type that it calls array, although it's not really an array as any other language would define it. [...] And you should almost never use array as a type hint. Why? Because there's always a better, more generic option.

He starts off talking about the use case where arrays are used as a "single complex value" and how,. more often than not, a class is actually a better option. He then covers the other main use of arrays: as an ordered sequence of values. To replace this he recommends a more structured collection that can apply some logic to its contents. With these other options out of the way, he then talks about what arrays are actually useful for and some other potential typehints to allow arrays and other potential inputs. He ends the post talking about array operations included in PHP and how, with a minimal amount of effort, they could be reproduced with simple methods for use on actual collection instances instead.

In this new tutorial posted to the TutsPlus.com site author Sajal Soni shares "the complete guide" to handling pagination in a CodeIgniter framework application using built-in tooling included with the framework.

The benefit of using any full-stack web application framework is that you don't have to worry about the common tasks like input handling, form validation and the like, as the framework already provides wrappers for those features. Thus, it allows you to concentrate on the business logic of the application rather than reinventing the wheel over and over again.

Today, we're going to explore an important library in the CodeIgniter framework—the pagination library.

The tutorial walks you through three main things: the basics of the pagination functionality, options you can use to customize it and the configuration options available for the component. Each section comes with code and configuration examples showing how to use the component.

The Zend Framework blog has continued its series of posts focusing on the use of the Zend Expressive framework with a new tutorial covering handling OPTIONS and HEAD requests in an Expressive-based API.

In v1 releases of Expressive, if you did not define routes that included the OPTIONS or HEAD HTTP request methods, routing would result in 404 Not Found statuses, even if a specified route matched the given URI. RFC 7231, however, states that both of these request methods SHOULD work for a given resource URI, so long as it exists on the server. This left users in a bit of a bind.

[...] In the case of a HEAD request, the specification indicates that the resulting response should be identical to that of a GET request to the same URI, only with no body content. This would mean having the same response headers. In the case of an OPTIONS request, typically you would respond with a 200 OK response status, and at least an Allow header indicating what HTTP request methods the resource allows. Sounds like these could be automated, doesn't it? In Expressive 2, we did!

The tutorial then shows you the code you'll need to add to your Expressive v2 application for handling each kind of request. It involves some custom middleware using the route handling on the HEAD request type for one and the other for OPTIONS. The HEAD requests return an empty response while the OPTIONS requests return the data from a manually defined array (no automatic generation from routes or anything).

Following up on his previous post about anonymous classes and a factory to generate them, Mark Baker has posted about the results of some additional research he's done on the topic and four options he's come up with.

A week or so ago, I published an article entitled “In Search of an Anonymous Class Factory” about my efforts at writing a “factory” for PHP7’s new Anonymous Classes (extending a named concrete base class, and assigning Traits to it dynamically); and about how I subsequently discovered the expensive memory demands of my original factory code, and then rewrote it using a different and (hopefully) more memory-efficient approach.

Since then, I’ve run some tests for memory usage and timings to assess just how inefficient my first attempt at the factory code was, and whether the new version of the factory really was better than the original.

His four options that finally worked somewhat as he'd wanted were:

• A factory that returns an instance of a concrete class using the traits he wants
• A factory that returns an anonymous class extending a concrete class that uses the traits
• His original Anonymous Class factory and extending the result with the traits
• His second version of the Anonymous Class factory that creates the instance, caches it and returns a clone

He also includes the code he used to run the tests of each factory method and shares some of the resulting benchmarks (with a few surprises).

With the recent (well, not too recent) announcement from MailChimp about the shift to a paid model for their Mandrill email service, PHP developers have been busy looking for alternatives. In this post to the php[architect] site Sandy Smith explores some of the other options out there, how they compare and what they have to offer.

n case you might have missed the announcement, MailChimp is changing Mandrill to be an add-on to paid MailChimp accounts, thus eliminating the generous free tier. We’re big fans of MailChimp and use its mailing list service for our own announcements, but a full MailChimp account isn’t going to be for everybody. [...] Many people also know Mandrill by reputation and will need options in the future. For you, we’ve put together this list of viable transactional email alternatives with PHP and major PHP application support.

Included in their list are services like:

• SparkPost (includes a special plan for current Mandrill users)
• SendGrid
• Amazon SES
• Mailgun
• Postmark

For each service he includes a paragraph talking about what integrations and libraries there are for their use as well as what's included in their "free" levels.

In his latest post to his site Alejandro Celaya shares some suggestions about how to make a good, safe persistent login feature for your application. This is usually referred to as the "remember me" handling and is widely used to help improve the overall user experience.

I'm sure you are familiar with those "remember me" checkboxes in login forms. They are a common way to allow a user to keep his/her session in a web application for an extended period of time when he is in a trusted computer.

One could think that it is a small and easy-to-implement feature, but it has indeed a lot of considerations. [...] In this article I’m not going to show you how to implement a persistent login in one or another programming language, but what are the good practices that should be followed when you implement it in the way you want.

He starts off with some thoughts about the wrong way to handle the persistent login (like just making a long-life cookie) and what some of the consequences could be. Instead he suggests using a cookie (with a random generated token) that's long running, maybe 2 weeks. The difference here is that this token is then refreshed once the token is validated and reset. This reduces the risk of an older token being used on another source too. He also shares some other security concerns to think about in this setup including the use of one-time tokens, potential multiple persistent sessions and when it might be good to re-prompt for the password.

In a quick post to her site Lorna Mitchell reminds us that you can modify the options on the internal PHP streams (like for HTTP requests), more specifically to add a "Bearer" token value for OAuth2 integration.

For OAuth2, all I had to be able to do was to send an Authorization header with my web request from PHP. My second-favourite way of making API calls from PHP is to use PHP's stream handling, so I did that. It's not code you see very often but it's super-simple and it works on every PHP platform I've tried so far

She gives a few lines of code to show how to modify the options to add in the token value, basically using an array of options and a call to stream_context_create to create the context. This can then be used in future calls (like the file_get_contents she shows) to automagically send this information along with the request.

The ServerGrove blog has posted another in their spotlights on specific Symfony2 components. In this latest post they look at the OptionsResolver component.

In the 13th post of the Symfony2 components series we will be talking about one little but extremely useful component: OptionsResolver. This component helps us to reduce the boilerplate code required to create an options system with default parameters. As stated in the official docs, is array_replace on steroids.

They start with a common situation, wanting to use options from user input, but only if they exist, and otherwise provide a default. This includes the use of the array_replace function but with the OptionsResolver there's an even easier way. A simple example is included showing how to use it to define options (and throw an exception when an undefined one is set). They show how to use a closure to set defaults on a specific option with more complex logic and how to use the validation and normalization handling.

Russell Walker has a post on his site sharing some suggestions about effectively dealing with global data in your PHP applications.

Almost every web application needs to handle global data. There are certain things that just have to be available throughout the entire code base, such as database connections, configuration settings, and error handling routines. As a PHP developer, you may have heard the mantra 'globals are evil', but this naturally begs the question 'what should I use instead of global variables?'

He includes four different options (five including the actual use of global variables):

• Static classes
• Singleton
• Registry
• Dependency injection

For each of the options he includes summaries of both the advantages and disadvantages as well as some sample code showing their use. Ultimately, he points out that it's up to the developer of the application which option fits best.