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).

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] siteSandy 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.

In his latest post to his siteAlejandro 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.

Matthew Weier O'Phinney has posted the third part of his series about making RESTful APIs with Zend Framework 2 (parts one and two). In this latest part of the series, he talks more about documenting the API and what commands can be executed.

In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.

Over the years I’ve built many different types of websites. These range from being a few pages, to being very customized with advanced features. I’ve learned there is no clear definition in the best way to create a website. But I do think there are advantages and disadvantages to pursuing different methods. This article takes an analytical look at each option. Let’s take a closer look at the different approaches in building a website.

He includes a brief summary talking about each method and mentions things like benefits and downfalls of the approach and what can be involved in their development.