In a new post from the Delicious Brains site Peter Tasker looks at how WordPress makes HTTP requests with the help of the cURL functionality in PHP.

cURL is the workhorse of the modern internet. As its tagline says, cURL is a utility piece of software used to ‘transfer data with urls‘. According to the cURL website, the library is used by billions of people daily in everything from cars and television sets, to mobile phones. It’s the networking backbone of thousands of applications and services. Unsurprisingly, it’s also a core utility used by WordPress’ own Requests API as well as our own WP Migrate DB Pro.

If you’re curious about the power of the cURL library, how it works with WordPress and what to watch out for (especially on macOS), then you’re in the right place.

He starts by giving a bit of background on what cURL is and some examples of how its used to make requests. He then talks about the cURL integration with PHP via an extension and provides a simple code example fetching an endpoint from the httpbin.org site. With that background defined he moves into the main focus of the article - how cURL and PHP combine in the WordPress WP_Http class and Requests handling to make HTTP requests to remote (or local) resources. Code examples are included showing how to put these pieces to work in a custom script and includes some common issues you might see during your HTTP request development.

On the QaFoo blog they've posted an article that shares some of their thoughts on "when to abstract" in your code - essentially finding that point where abstracting out functionality makes sense.

One of the most difficult challenges in a developers life is finding the "right" abstraction, or at least the best one given the current circumstances. The core problem is that abstraction is a bet on the future development of the software and we know that future is volatile. The circumstances will change, so will the view on the best abstraction change.

But there is another dimension which influences this decision: What kind of software are you developing?

They start off by defining three different types of projects (internal, library and adaptable) and move into how this type changes when/how you abstract things in your code. They give a brief summary for each type and when it usually makes sense, including steps to take (concrete first, then abstract).

In a previous post to the Laravel News site, the latest offering in the Laravel ecosystem, Spark, was introduced. In this post Matt Stauffer takes a "deep dive" into its features and functionality, digging down into the code to see what makes it tick.

If you've been around on the general Laravel-interested Internet over the last month or two, or if you attended Laracon US or Laracon EU, you've probably already heard of Laravel Spark. If you haven't, check out Taylor's introductory video from Laracon EU.

I've held off on writing about it until now, because it has changed a lot over the span of its development. It's released as an Alpha now, so the API has solidified some... but it'll still change quite a bit between now and the release. [...] This is, instead, a deep-dive into how it works and what it does. I'll be writing a more general introduction to Spark once it's actually released, so beware: this is a bit of a deeper dive, for people geeky enough to want to look at an alpha release.

He starts with a recap and a high-level overview of the system, what it's designed to do and how to get it installed (either in a fresh install or an existing application). He then starts breaking down the pieces that make up the system:

• changes made to files in your current application
• details on the contents of the SparkServiceProvider
• the addition of an app.js defining the VueJs bootstrap for the interface

He then starts looking at the interface, showing how to register a new user (with two-factor auth), work with the "teams" functionality to group users and create payment and plan options for your products.

Nikita Popov has posted the second part of a series looking at how PHP 7 represents values internally. In the first part of the series the focus was on the major change from PHP 5: the zval updates and how they're allocated. This new post gets into more of the details on each of the types and how they're handled.

In the first part of this article, high level changes in the internal value representation between PHP 5 and PHP 7 were discussed. As a reminder, the main difference was that zvals are no longer individually allocated and don’t store a reference count themselves. Simple values like integers or floats can be stored directly in a zval, while complex values are represented using a pointer to a separate structure.

[...] In the following the details of the individual complex types will be discussed and compared to the previous implementation in PHP 5. One of the complex types are references, which were already covered in the previous part. Another type that will not be covered here are resources, because I don’t consider them to be interesting.

He goes through a few of the different types including strings and arrays and then gets into detail on how objects have changed from PHP 5 to PHP7. He also talks about "indirect zvals" (the IS_INDIRECT handling) that points to another zval instance rather than embedding it. Finally, he talks about two other constants, IS_CONSTANT and IN_CONSTANT_AST, and how they're used behind the scenes with some example code to illustrate.

Nikita Popov has a new post, the first part of a series, talking about the internal handling of variables in PHP7 and how it has changed from the current/past methods.

My last article described the improvements to the hashtable implementation that were introduced in PHP 7. This followup will take a look at the new representation of PHP values in general. Due to the amount of material to cover, the article is split in two parts: This part will describe how the zval (Zend value) implementation differs between PHP 5 and PHP 7, and also discuss the implementation of references. The second part will investigate the realization of individual types like strings or objects in more detail.

He starts with an introduction to the "zval" struct type and how it relates to the "zvalue" union. He goes on to talk about reference counting on zvals and some of the reasoning/desire to change how these are handled. Finally, he gets to the zval handling coming in PHP7 and the fundamental change in zval handling - they're no longer "individually heap-allocated and no longer store a refcount themselves". This change has several advantages and including improved refcount handling and less pointers involved in determining the actual value. He includes an example of how this new zval structure is defined in PHP7 compare to the previous version too. The remainder of the post looks at other related issues including memory management, supported types and a major change to how variable references are handled.

In his latest post Joe Watkins talks about mocking PHP. No, not making fun of the language but rather mocking internal PHP functions and methods as a part of unit testing your application.

I work on a vast PHP code base, it is 3M LOC of PHP alone. It's somewhere between legacy and modern, work is ongoing. [...] When I joined the current project there were many many tests, they relied upon the kind of unholy magic that runkit allows you to perform, for the most part this worked okay for a while. However, runkit inexplicably caused many of the tests to fault, either at shutdown, or at random.

[...] So we were in a bit of a jam, I've always found runkit to be quite awkward, and now I'm staring its source code in the face knowing it represents a road block to my goal of running the latest stable versions of PHP, with the first decent optimizer that ever existed for Zend. I tackled the problem with code, code which I was allowed by my gracious employer to open source (the uopz extension).

He goes on to talk about what the actual root problem he was trying to solve was (dodging code with built-in functions), the "obvious" way to solve it using runkit or the more modern solution that uses the uopz extension. He provides an example of it in use mocking the fopen function with a "uopz_function" wrapper.

Joshua Thjissen has revisited some of his PHP internal function statistics, an update from this previous post with some results showing the most (and least) used internal PHP functions in several large projects from GitHub.

A lot of people are asking about functions like isset, empty, print, echo etc, as they are not present in the current result list. The thing is, is that these are not really functions, but language constructs. This means that PHP treats them a bit different than normal functions, and this results sometimes in seemingly “strange” behaviour when trying to use them like regular functions.

He's updated his results, though, to reflect the usage of these "functions" and shared the numbers. Not surprisingly, these constructs show up pretty highly in the new "top 22" list he's produced. With the inclusion of the constructs, the number one item on the list is now "isset" by a very large margin. The full results can be found in this gist.

Curious about the usage of the various "internal" (built-in, not user defined) functions in use is a wide range of PHP applications, Joshua Thijssen did some research on GitHub and has shared the results on his site today.

How many internal PHP functions (things like count(), strpos(), array_merge() etc), does PHP have? Depending on which version you use, and how many extensions you have loaded, somewhere between 1000 and 2000 would be a good guess. But how many of these internal functions are you REALLY using?

He created a custom script to fetch the results of a custom query (one that found repos with over fifty stars), grabbed the source and parsed the results looking for these internal functions. He shares the results of his parsing from 967 repos in the remainder of the post, including: the top ten most called, some interesting facts found in the results and some of the "bad" ones in wide use (like "exec" and "mysql_connect").

In Lukas Smith's latest post he looks at one of the magic methods that's built into PHP to help transform objects into strings - the __toString method. In the post he explores what it's for and what it might be used for.

The __toString() belongs to the family of methods and functions called "magic functions". They are magic because for the most part they do not get called explicitly but rather intercept operations. Unfortunately there are limits to its magic, specifically the only "context" the method is aware of is its design contract: to return a string. But its not clear what purpose that is. Should this be for some internal debugging or logging purposes? There one would be most interested in internal identifiers and object state. Is it for some frontend UI where the user will most likely be interested in some textual identifier that isn't too long as to not clutter the UI. There in lies the dilemma in the magic, while useful there is no way to ensure that the given context is passed on.

He looks at use cases for UI output (for consistent output) and contexts as well as the more internal-facing usage, like for logging and debugging purposes. Being able to get the context of the object as a string and pushed into a log at the time of error could be immensely helpful for debugging. He also links to some discussions happening on Twitter about the internal versus external uses of this magic method.

PHPMaster.com has a new tutorial for those interested in how to work with streams, he base resources behind working with things like files and remote connections.

Streams are resources provided by PHP that we often use transparently, but which can also be very powerful tools. By learning how to harness their power, we can take our applications to a higher level. [...] Every stream has a implementation wrapper which has the additional code necessary to handle the specific protocol or encoding. PHP provides some built-in wrappers and we can easily create and register custom ones. We can even modify or enhance the behavior of wrappers using contexts and filters.

They start by introducing two of the most commonly used streams - "file" and "http" as well as some of the wrappers that can be used to work with them. He also talks about the "php://" stream, a special instance that lets you access things like a temporary memory block and stdout/stdin. He finishes up the tutorial with a look at "contexts" - the parameters that can be used to modify the stream wrapper (like his HTTP example).