The PHP Rountable podcast, hosted by PHP community member Sammy K Powers, has posted their latest episode - Episode #80: PHP Internals: Preloading, FFI & More. In this episode, Sammy is joined by core developers Sara Golemon and *
Nikita Popov*.

We'll be deep-diving into some PHP internals goodness that you won't want to miss. We'll go behind the scenes of preloading, a possible foreign function interface (FFI), typed properties, a password hashing registry and more.

You can catch this latest episode either using the in-page video player or by watching it directly on YouTube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

TutsPlus.com has posted the latest part of their series focusing on the WordPress REST API. In this new part of the series they look at some of the internals of the API code and the customizations you can make on the data returned.

In the previous part of the series, we learned about creating, updating, and deleting content remotely through the WP REST API. It allows us to create platform-independent applications that work seamlessly with a WordPress powered back-end, providing a rich experience to the user.

In the current part of the series, we will take a look at the internals of the WP REST API and how they work together to power the API. After that, we will learn to modify server responses for the default endpoints to include custom fields.

They walk you through a few different topics around the API including the internal classes that power it, how to modify the server and making custom fields editable. There's a bit of code involved when it comes to modifying the custom fields in the response and registering an editable field. The rest is mostly about configuration and what methods are doing what during the request.

The Laravel project has traditionally held discussions about the internals of the framework in an IRC channel on the Freenode.net network. The decision was made recently, however, to move the development over to GitHub (most likely to make it more accessible).

There's already several issues that have been posted on the Issues list in the GitHub repository including things around:

• improving typecasting
• decoupling Carbon (the date handling library)
• a fluent interface for validation
• enhancing the localization functionality

You can give feedback or start your own discussions by adding an issue to the list or just sharing your thoughts on current topics.

The PHP Rountable podcast has posted their latest episode recorded live and looking at HHVM - Episode #31: Checking in with PHP & HHVM internals. In this episode host Sammy K Powers is joined by Julien Pauli, Sara Golemon, Bob Weinand and Nikita Popov.

We chatting with some PHP & HHVM internals folks to learn what's been going on in the world of internals.

You can watch this latest episode either through the in-page video player or directly over on YouTube. If you enjoy the show, be sure to subscribe to their feed for information about their latest episodes as they're released. They're recorded live too, so be sure to also follow them on Twitter to find out where and when the next one will be recorded.

In a post on the SitePoint PHP blog author Daniel Sipos takes you on a trip through the Drupal 8 execution structure, from request to response, in the internals of the tool.

In the first article on Drupal 8 module development we looked a bit at the routing aspect of this process. We’ve seen that creating pages with paths is now a matter of declaring routes that match up with controllers. The latter, as we’ve seen, can return a render array that gets interpreted into markup and displayed in the main content area of that page. However, did you know that under the hood, Drupal actually transforms that array into a Response object according to the dictates of Symfony’s HTTPKernelInterface?

In this article, I would like us to go deeper into the internals of Drupal 8 (and Symfony2) and look at what actually happens (and can happen) from the moment a request is made by a user to the one in which they see something returned in response.

He starts at the initial point of the request, the front controller, and talks about the creation of the Request instance and it's handling by the HTTPKernel. He moves into the kernel and talks about the events that are triggered during execution and provides an illustration of the flow of the request all the way through to the response. He then "goes deeper" into looking at render arrays and the HTMLRenderer handling to manage the output of the page on the Drupal side.

Julien Pauli has a new post today sharing an interesting function optimization he found using the Blackfire execution profiler.

This blog post is a technical explanation of a PHP optimization found with BlackFire profiler into a PHP script. The related post is located here : http://blog.blackfire.io/owncloud.html

He found that a replacement of a call to strlen with an isset optimized the script by about 20%. It's not typical though, he explains. He points out that the optimization worked so well because the call was part of a loop. He gets into some of the "under the covers" details of why this speed boost happens and even includes the op code output showing the difference. He then starts getting deep into the internal code for PHP and walks through each step made in the evaluation of a string's length. He finishes the post looking at isset (not technically a function) and how it handles its data checking. He also includes information about opcode caching and how to best maximize its impact.

Pascal Martin has posted his latest edition of the happenings on the PHP internals mailing list for the month of September. In this latest edition he covers some of the major topics discussed this past month including:

• the "Implicit isset() in Shorthand Ternary Operator" RFC (or, as it came to be known, the "Null Coalesce Operator" RFC)
• An RFC for a "loop + or control structure"
• an opinion to make PHP 7 transtyping operations more strict
• the RFC to "Remove alternative PHP tags"
• another RFC proposed to "Fix list() behavior inconsistency"

There's links to lots of other topics and various messages on the list including lots of other RFCs and plenty of discussion around them. Check out the full post for more great information and links around last month's php.internals happenings.

The Three Devs & A Maybe podcast has released their latest episode today - Episode #40, News on PHP 7, and how PHP internally works with special guest Joe Watkins. In it the guys talk about the upcoming (major) version of PHP and some of the work Joe's been doing related to Unicode and other parts of the language.

In this weeks show we are very lucky to have Joe Watkins on again to discuss all things PHP 7. Starting off with the decisions behind calling the next release 7, we delve into the reasons for 6 being abandoned. Moving on from this we look into what PHP 7 currently has scheduled to offer, including the PHPNG patch, an AST and maybe Joe's own Unicode String class. We then discuss how a PHP script is internally lexed, parsed/compiled and cached, - including how a JIT would speed up certain use-cases. Finally we touch upon the much requested String type hinting and how a solution similar to Java's could be implemented with minimal hassle.

Other topics mentioned in this episode include: the last PHP 5.3 release ever, PHPNG and upgrading extensions from PHP5 to PHPNG. You can listen to this latest episode either through the downloading the mp3. If you enjoy the episode, consider http://threedevsandamaybe.com/podcast.xml">subscribing to their feed and get the latest shows as they're released.

Phil Sturgeon has posted about something he calls the "neverending muppet debate of PHP 6 versus PHP 7. As the PHP language moves forward, the PHP 5.x series is coming to a close. The discussion as started up whether to name it "PHP 6" or "PHP 7" and both sides have their proponents.

There are a few major, important conversations happening in the PHP internals mailing list as we speak: The Facebook lot heading up a specification based off of PHP 5.6 Should phpng be moved into master to be the base of the next major PHP version How can we best go about scalar typehinting? There is also another conversation: Should it be PHP 6 or PHP 7 Wait... what?

He goes on to provide a little context, pointing out that back in 2010 PHP 6 was being slated for release as the next major version of the language (this was around the PHP 5.2 days). Unfortunately, it stalled out and some of what was planned went into PHP 5.3. This didn't stop publishers from releasing books and articles about "PHP 6" though. It's already being put up for a vote with "PHP 7" pulling ahead. Phil also includes more context around the discussions, sharing the main points of each side and snippets from the RFC and mailing list thread currently ongoing.

As anyone who subscribes to the php.internals mailing list knows, there can be a lot of drama around some of the discussions for the future of the language, both in its features and surrounding technical concerns. Daniel Cousineau has posted a lighter take on some of this drama and is issuing his own "RFC" for a proposed mascot for internals - the DramaLlama.

Branding and PR is an increasingly important factor in programming language viability and adoption. Visible instability in the core team is off-putting to large organizations who depend on long term reliability and support and only encourages them to look to languages and tools with more stable and professional core teams. This RFC proposes that the PHP core team get ahead of the issue and introduce a logo, separate from the public facing project, to provide a sense of professionalism that is lacking. I humbly submit the DramaLlama as the superior candidate.

His proposed mascot, shown here, bears the PHP logo on the side of a cartoon purple llama. As Daniel puts it, the llama is a "proud, capable animal" that can deal with a lot and still stand up under a heavy burden.

By not adopting a logo, the PHP core team risks losing the respect and trust of the end user community. However it could be argued that the core team has survived without this and could do so indefinitely.

The post is practically dripping with sarcasm, but it's a good mood-lightener around some of the drama that can come from the clash of multiple personalities in the PHP internals community.