On thePHP.cc site today they have a quick post that looks ahead at the future of the PHP language towards PHP version 8 and one planned feature - the deprecation of some multi-byte character handling.

Since the attempt to create a Unicode-based PHP implementation has failed, PHP 7 – just like PHP 5 – does not handle Unicode strings natively. The commonly used UTF-8 encoding, for example, is a multibyte encoding, as opposed to ASCII, where each character is represented by one single byte.

[...] UTF-8 is a variable-length encoding and each character (code point, to be exact) is represented by one to four bytes. For ASCII characters, everything works smoothly, because UTF-8 is a superset of ASCII. The problems start with non-ASCII characters.

The post covers some of the common issues with multi-byte Unicode characters in PHP and the role that the iconv and mbstring functions play in their handling. It shows how the mbstring handling allows developers to "cheat a little" and where, when PHP 8 comes around, the main issue will lie: the deprecation of thembstring.func_overload setting in the php.ini.

Caleb Porzio has put together a post for those out there either considering using Microsoft's Visual Code Studio IDE or just want to see what it would be like for PHP development. In his post he shares his setup since making the switch over to the IDE full time.

I’m using VS Code as my primary editor these days and am really digging it. My setup is by no means perfect, but I've made lots of little tweaks along the way that you may benefit from.

I've set up these nifty categories, so feel free to jump around and try stuff out as you go, or come back later and use it as a reference.

Categories in the post include useful extensions, "must-have" settings, changing up the look and useful keybindings. There's plenty of links, output examples, screenshots of the IDE and the configuration options you'll need to change to update the settings to match his.

In a new post to his site Nikola Posa shows the PHPStorm users out there how to keep metadata about your projects away from the source (the content in the ./idea directory it creates by default).

I fell in love with PhpStorm only few months ago ago when I switched from NetBeans, my favorite IDE by then. One thing that I was missing from the very start is the ability to separate project metadata (.idea/ directory) from sources, because I like to keep away everything that is unnecessary from my project directory, as well as from the .gitignore file. It turned out that something like that is possible, but in contrast to NetBeans it's not so evident and requires a little more effort

It's a pretty simple four step process and he shows what settings to change:

• Create new project in a directory where you would usually keep metadata
• Open Settings / Preferences dialog and click on Directories node
• Click Add Content Root button and select project sources directory
• Remove content root that keeps project metadata

Screenshots are also included for each step to help make sure you're in the right place at all times.

On the Stovepipe Systems blog there's a new post from Yannick de Lange that suggests using bitwose operations instead of booleans to evaluate an on/off setting.

The naive way of storing many boolean options (in a database) is to create for each option a field and storing a 0 when it is false and 1 when it is true. Which of course works, but adding options will require a new field, which might require creating a compatibility layer for your old data. There is an easier way to do this and it's even more efficient at checking fields.

This brings me to an old topic which I have to explain to all the new people at some point and even once explained not everybody understands how it actually works. So in this post I'm going to explain how to use bitwise operators and how it works internally.

He starts with a common example using the 0/1 storage method and refactors it a bit to use different values that are more compatible with bitwise operations. He includes the usage of this system and how to works to evaluate multiple potential option values.

In a new post to his site Aaron Saray has shared two tips that can help you protect the information in your PHP sessions - two configuration options to enable that can enforce stricter standards and options enhancing their overall security.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

The two configuration options he mentions are ones that:

• force the session identifier to use cookies (versus also allowing it from the URL)
• enforce "strict mode" on the sessions

Each comes with a bit of description as to what the setting does and the recommended setting is to provide the most protection. One note, though: strict mode is only included in PHP 5.5.2 or greater.

The SitePoint PHP blog has posted the next article in their "eBay Trading API" tutorial series today. In this new tutorial they show you how to configure your store's settings.

In part 1, we explained the different parts of eBay’s developer dashboard and configured our test application. We also created our database. Now we’re ready to create a project. In this part, we’ll focus on store settings. In part 3, we’ll add new products to our store.

They include the "composer.json" contents you'll need to install all of the libraries they'll use for the tutorial. With those installed they start in on the code, creating a basic Slim application that uses Twig views and some custom configuration options. Then he starts in on the classes, creating an "Ebay" class to handle the application settings and creating a "post" method to handle the API request. He adds in a few other helper methods and builds a database object/query to get the application details from the database. Next up are the templates for the main page and the controller to handle the default, session and token requests. He adds in some additional route configurations, makes a "view action" for the store settings and to request the user preferences from the API.

Kevin Schroeder has posted the results of some research he did around using the "AllowOverride" setting in Apache. He found some interesting differences when it was set to "all".

Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server’s behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

Kevin Schroeder has a new post to his site today wondering about the "max_input_time" setting for PHP and why some recommend it being a large number despite the (usually) fast time PHP has accepting input.

I asked a question on Twitter on why some of the recommend max_input_time settings seem to be ridiculously large. Some of the defaults I’ve seen have been upwards of 60 seconds. However, after thinking about it I was a little confused as to why a C program (i.e. PHP) would take so long to process string input. The reason I was thinking about this was because I was thinking about ways to protect PHP from denial of service attacks.

So he ran some tests to see just how effective changes in this setting could be and how much time a typical PHP request would need to take in input. Using a Zend Framework 2 HTTP client, he simulated POSTS and tracked the start and end times for a file upload. He includes the timing results in the post based on both this setup and a change to only post regular text-based form data.

Rob Allen has a new post to his site sharing some examples of the configuration possibilities for the ZendServiceManager module of the Zend Framework 2.

ZendServiceManager is usually configured in two places: an array in a config file or a method within your Module class. In either case, you provide a nested array of configuration information. [...] Within the service_manager array, there are a set of nested arrays which are generally used to configure how you want a given class to be instantiated. the names of these sub-arrays are hardcoded, so you just need to learn their names and the difference between them.

He lists out each of the options and includes a brief example and description for each. Values include "invokables", "aliases" and "initializers". He also touches on controllers, view helpers and controller plugins and how they hook into the ServiceManager.

On the ServerGrove blog, there's a quick post with a handy tip for the Symfony2 + Assetic users out there - how to get it to recognize the "less" module.

Unfortunately the Symfony documentation does not provide any details on how to configure Assetic to use LESS. There is a blog post by Dustin Dobervich that gives some pointers, but after following the instructions, Assetic issued the following error: Cannot find module ‘less’. We searched around without much success. After several tries, we nailed the configuration.

It's an easy two-step process: first you be sure you have "npm" (the package manager) installed on your system, then you modify your Symfony app.yml file to point to the Node modules path.