Remi ColletPHP on RHEL-8 (16.11.2018, 08:16 UTC)

RHEL-8 Beta is announced and is available for download for whom want to try it.

This is an opportunity to look at PHP installation and how modules work.

1. Installation

ISO image is available for everyone, see the README file.

Don't forget to enable the Beta repositories.

# dnf repolist
repo id                               repo name                                                     status
rhel-8-for-x86_64-appstream-beta-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) 4594
rhel-8-for-x86_64-baseos-beta-rpms    Red Hat Enterprise Linux 8 for x86_64 - BaseOS Beta (RPMs)    1686

2. Installation of PHP

PHP is not part of BaseOS which is the base of the Operating System, reduced to minimal, but is available in AppStream, i.e. as a module.

# dnf module list
Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs)
php                  7.1          devel, minimal, defaul PHP scripting language
                                  t [d]
php                  7.2 [d]      devel, minimal, defaul PHP scripting language
                                  t [d]                  

You can see that both versions 7.1 and 7.2 (default) are available.

Installation of version 7.1

# dnf module install php:7.1
Dependencies resolved.
 Package            Arch     Version                        Repository                               Size
Installing group/module packages:
 php-cli            x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms   2.9 M
 php-common         x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms   624 k
 php-fpm            x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms   1.5 M
 php-json           x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms    70 k
 php-mbstring       x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms   547 k
 php-xml            x86_64   7.1.20-2.el8+1700+11d526eb     rhel-8-for-x86_64-appstream-beta-rpms   187 k
Installing dependencies:
 httpd-filesystem   noarch   2.4.35-6.el8+2089+57a79027     rhel-8-for-x86_64-appstream-beta-rpms    32 k
 nginx-filesystem   noarch   1:1.14.0-3.el8+1631+ba902cf0   rhel-8-for-x86_64-appstream-beta-rpms    23 k
Installing module profiles:
Enabling module streams:
 httpd                       2.4
 nginx                       1.14
 php                         7.1

Transaction Summary
Install  8 Packages

Total download size: 5.9 M
Installed size: 20 M
Is this ok [y/N]: y


# php -v
PHP 7.1.20 (cli) (built: Jul 19 2018 06:17:27) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

And you can switch easily to  7.2

# dnf module install php:7.2
Dependencies resolved.
 Package         Arch      Version                         Repository                                Size
 php-cli         x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms    3.1 M
 php-common      x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms    653 k
 php-fpm         x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms    1.6 M
 php-json        x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms     73 k
 php-mbstring    x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms    580 k
 php-xml         x86_64    7.2.11-1.el8+2002+9409c40c      rhel-8-for-x86_64-appstream-beta-rpms    188 k
Switching module streams:
 php                       7.1 -> 7.2

Transaction Summary
Upgrade  6 Packages

Total download size: 6.2 M
Is this ok [y/N]: y


# php -v
PHP 7.2.11 (cli) (built: Oct  9 2018 15:09:36) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies

3. Web usage

3.1 with Apache HTTP Server

Truncated by Planet PHP, read more at the original (another 1504 bytes)

Evert Pot400 Bad Request (13.11.2018, 15:00 UTC)

400 Bad Request is the first error code. Every status that starts with a 4 indicates that the client did something wrong. If the status starts with a 5 it means that the server did something wrong.

400 Bad Request is used as a generic error code. It’s a useful default error code if there’s no specific error code that’s a better fit.

There’s often a lot of discussion about which 4xx code is the most appropriate for any different situations. This might be because there’s many, and it’s not always super clear what the distinctions between them are.

The most important thing to remember when selecting the appropriate code is: “can a generic client do something with this response?”. If the answer is no, it might not matter as much which error code is returned.

For example, when a client sees a 401 it might know to show a login window. When a client sees a 403, it might know to tell the end-user that the reason their operation failed, was because of permissions-related issues.

Those are good reasons to show an error code, but those reasons don’t always exists. For those cases it’s fine to just use the generic status code 400.

Response bodies

When returning any error, you should also return a response body with more information about the failure. If your client is a browser, this might be user-friendly HTML page. If your client is some kind of JSON-based client, it might be good idea to use the standard application/problem+json response code.


HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

  "type": "",
  "title": "Request was not polite enough",
  "detail": "HTTP requests must be made using a 'Please' HTTP header.


larry@garfieldtech.comBook review: Functional Programming in PHP (12.11.2018, 21:29 UTC)
Book review: Functional Programming in PHP

I was asked by php[architect] a while back to review "Functional Programming in PHP, 2nd Ed" by Simon Holywell. I've been sitting on this review for a while, so it's time to finally get it done.

Continue reading this review on SteemIt.

Larry 12 November 2018 - 4:29pm
Evert PotGoogle Trends for REST, GraphQL and RPC (10.11.2018, 18:52 UTC)
<script type="text/javascript" src=""> <script type="text/javascript"> trends.embed.renderExploreWidget("TIMESERIES", {"comparisonItem":[{"keyword":"rest api","geo":"","time":"today 5-y"},{"keyword":"RPC","geo":"","time":"today 5-y"},{"keyword":"GraphQL","geo":"","time":"today 5-y"}],"category":5,"property":""}, {"exploreQuery":"cat=5&date=today%205-y&q=rest%20api,RPC,GraphQL","guestPath":""});

If you don’t see a diagram, your browser might be blocking it. See the source here.

PHP: Hypertext PreprocessorPHP 7.1.24 Released (8.11.2018, 00:00 UTC)
PHP 7.1.24 Release AnnouncementThe PHP development team announces the immediate availability of PHP 7.1.24. This is a bugfix release.All PHP 7.1 users are encouraged to upgrade to this version.For source downloads of PHP 7.1.24 please visit our downloads page, Windows source and binaries can be found on The list of changes is recorded in the ChangeLog.
PHP: Hypertext PreprocessorPHP 7.3.0RC5 Released (8.11.2018, 00:00 UTC)
The PHP team is glad to announce the next PHP 7.3.0 pre-release, PHP 7.3.0RC5. The rough outline of the PHP 7.3 release cycle is specified in the PHP Wiki. For source downloads of PHP 7.3.0RC5 please visit the download page. Windows sources and binaries can be found on Please carefully test this version and report any issues found in the bug reporting system. THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. Internal changes are listed in the UPGRADING.INTERNALS file. These files can also be found in the release archive. The next release would be RC6, planned for November 22nd. The signatures for the release can be found in the manifest or on the QA site. Thank you for helping us make PHP better.
Evert PotWhich redirect do I choose? (7.11.2018, 15:00 UTC)

The 3xx status-codes are a bit of a mess. There’s a lot of confusion and mis-use, so I thought it might help to sum all of them up in a single article.

Choosing the right redirect

Are you responding to a POST request, and instead of returning a status immediately, you want to redirect the user to a confirmation page?

Use 303 See Other.

Did the resource move to a new path, or a new domain, and you want to make sure that any HTTP client repeats the exact same HTTP request on the new location?

Use 307 Temporary Redirect if the move was temporary, or 308 Permanent Redirect if the move was permanent.

Did the resource move, but you only care about GET request? (perhaps because this is a website).

Use 302 Found if the move was temporary, or 301 Moved Permanently if the move was permanent.

Do you want to send the user somewhere else, but you’re not sure where because there’s more than one option, and you’d like the user to decide:

Use 300 Multiple Choices.


Voices of the ElePHPantInterview with Jonathan Wage (6.11.2018, 17:04 UTC)

This episode is sponsored by


The post Interview with Jonathan Wage appeared first on Voices of the ElePHPant.

Evert Pot308 Permanent Redirect (6.11.2018, 15:00 UTC)

308 Permanent Redirect is similar to 301 Moved Permanently. Both indicate that the resource the user tried to access has moved to a new location. In both cases the client should update any bookmarks they had from the old to the new location. Search engines respect these statuses too.

The difference between 301 and 308 is that a client that sees a 308 redirect MUST do the exact same request on the target location. If the request was a POST and and had a body, then the client must do a POST request with a body on the new location.

In the case of 301 a client may do this. In practice, most clients don’t do this and convert the POST request to a GET request.

The 308 is relatively new, and is currently marked as experimental in RFC7238. Most modern clients support it, but you might run into some issues with older clients.


HTTP/1.1 308 Permanent Redirect
Server: Apache/2.4.29


  • RFC7238 - Status Code 308 (Permanent Redirect).
Matthew Weier O'PhinneyFixing Redis background-save issues on Docker (4.11.2018, 13:52 UTC)

I've been running redis in Docker for a number of sites, to perform things such as storing session data, hubot settings, and more.

I recently ran into a problem on one of my systems where it was reporting:

Can't save in background: fork: Out of memory

A quick google search showed this is a common error, so much so that there is an official FAQ about it. The solution is to toggle the /proc/sys/vm/overcommit_memory to 1.

The trick when using Docker is that this needs to happen on the host machine.

This still didn't solve my problem, though. So I ran a docker ps on the host machine to get an idea of what was happening. And discovered that, somehow, I had two identical redis containers running, using the exact same configuration - which meant they were doing backups to the same volume. Killing the one no longer being used by my swarm services caused everything to work once again.

mwopFixing Redis background-save issues on Docker was originally published 4 November 2018 on by .
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP