Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

SitePoint PHP Blog:
Hello, Laravel? Communicating with PHP through Phone Calls!
Jun 20, 2017 @ 11:50:54

The SitePoint PHP blog has a new tutorial posted by author Christopher Thomas showing you how, with the help of Twilio, create a Laravel-based application that lets users communicate with it via phone calls.

Twilio is a SaaS application which enables developers to build telephone applications using web technologies. In this two-part series, we will leverage Twilio to build a weather forecast app that is accessed using the telephone system. The backend will be written with the Laravel framework (an exploratory video course is available for purchase here, or in the form of written tutorials here).

In this part, we will create a simple program that will allow a user to call a phone number that we buy from Twilio, enter a zipcode, and receive the current weather forecast.

You'll need to have a Laravel project already set up and a development environment to work in as well as Composer installed versions of Guzzle and the Twilio SDK. With that all set up, he dives right into the code, setting up routes and creating the "Weather" service class. This class is what's used to interact with the Twilio API and respond to user prompts with weather data from the weather.gov API. Next up is the controller that provides the endpoints for Twilio to hit and return the weather data back to their waiting connection. A bit of middleware is set up to sent the Twilio request signature each time and instructions are included on how to test the local system with the public Twilio API (using Ngrok).

tagged: laravel twilio phone call communication weather tutorial

Link: https://www.sitepoint.com/hello-laravel-communicating-php-phone-calls/

Toon Verwerft:
Optimizing PHP performance by using fully-qualified function calls
Dec 22, 2016 @ 12:27:55

Toon Verwerft has a post on his site with details about a micro-optimization you can use in your PHP application by using fully-qualified function calls, specifying the namespace even for root level PHP functions.

Today, a little conversation on Twitter escalated rather quickly. Apparently PHP runs function calls differently depending on namespaced or non namespaced context. When calling functions in a namespaced context, additional actions are triggered in PHP which result in slower execution. In this article, I'll explain what happens and how you can speed up your application.

The conversation started with [this tweet]. To understand the difference between global and namespaced function calls better, I'll explain what is going on under the hood.

He starts with this "under the hood" functionality, showing an example of a user-defined, root level function and the opcodes that result. He compares this to the opcodes generated when a namespaced function is called and the extra checking that goes into it (including checking both the namespace and the root levels). Another tweet implied that, because of this difference in checking, fully-qualified function calls would result in a performance increase. He set out to prove it as fact and used the phpbench tool to run four tests with various namespaced and non-namespaced examples. He includes the code he used for the testing and the results from a sample execution. There is, in fact, a slight performance gain from the fully-qualified version. He finishes up the post with some suggestions on using this knowledge including the root-level namespacing for built-in PHP functions.

tagged: performance optimize fullyqualified function call benchmark

Link: http://veewee.github.io/blog/optimizing-php-performance-by-fq-function-calls/

Stoimen Popov:
PHP: Don’t Call the Destructor Explicitly
Jun 27, 2016 @ 12:52:39

In a new post to his site Stoimen Popov makes the recommendation to not call the destructor explicitly in your code and provides some alternatives.

PHP 5 introduces a destructor concept similar to that of other object-oriented languages, such as C++” says the documentation for destructors. [...] Well, as you can not call the constructor explicitly [...] so we should not call the destructor explicitly. The problem is that I’ve seen this many times, but it’s a pity that this won’t destroy the object and it is still a valid PHP code.

He talks about __destruct and it's role in PHP's set of "magic methods" and what they exist to do. He then gets into a few examples of what code could look like that uses a destructor and the difference between normal handling calling the destructor explicitly. The main differences is that calling it explicitly does not destroy the object, it's basically like calling any other method. He does include an interesting method for destroying the object - setting it to null - and notes that the destructor fires then too. He also points out a few interesting things about cloning objects and how object references work when setting nulls as in the previous example.

tagged: destructor explicit call object destroy null tutorial

Link: http://www.stoimen.com/blog/2011/11/14/php-dont-call-the-destructor-explicitly/

Anna Filina:
Testing Methods That Make Static Calls
Jan 13, 2016 @ 09:03:40

Anna Filina has posted a quick hint around testing methods that make static methods calls to other parts of your application. Static method calls are notoriously difficult to test, especially with PHPUnit.

I had trouble testing a particularly painful codebase. It had static calls and implicit dependencies all over the place, to name just a few problems.

One of the things that it often did was to call static methods that would increment counters in the database and cache stuff. Example: Record::incrementViews() It was making things difficult. To avoid messing with the original codebase too much, I came up with this quick and dirty way to ignore those dependencies.

Her solution makes use of a mockStaticDependency method that then turns around and redefines the class in question (like her "Record" above) with a __callStatic through an eval. She points out that usually using eval is "evil" but in this case it made testing the functionality much simpler when no feedback was needed from the static method. In the comments on the post, someone also makes a recommendation of the Patchwork library for PHP that allows for "monkey patching" and modifying classes/functionality to redefine functions and methods in a similar way.

tagged: unittest method static call monkeypatch eval callstatic example

Link: http://afilina.com/testing-methods-that-make-static-calls/

Julien Pauli:
On PHP function calls
Jan 22, 2015 @ 09:58:39

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.

tagged: function call strlen loop isset internals opcode cache performance

Link: http://jpauli.github.io/2015/01/22/on-php-function-calls.html

Andrew Podner:
Overloading: Create PHP Class Methods on the Fly
Mar 06, 2013 @ 11:51:57

Andrew Podner has a new post today looking at dynamic class method creation in PHP - aka "overloading" with the __call magic method.

What is overloading and what would I need it for? [...] In most languages, overloading just means you can have multiple methods with the same name, but they just had a different number/type of arguments. In PHP, it is a little different. Overloading in PHP means that you can actually create dynamic function names and the behavior will be dependent upon the function name that is used.

He gives an example through a sample application, first stating the requirements the business has for it then showing how to use the "__call" method to handle "getBy" requests made to a database class. It searches the database based on the field (ex. "getByusername" searches on "username") and he includes two examples of it in use. He also briefly touches on the use of the "__callStatic" magic method for handling static method calls similarly.

tagged: method overloading magicmethod call callstatic getby


Marcelo Gornstein's Blog:
Making your ivr nodes (call) flow with PAGI
May 14, 2012 @ 12:09:50

Marcelo Gornstein has returned to his "IVR with PHP" series in this latest post (see others here and here). In this new post he shows you how to create a full flow of interaction for your callers:

The last article was about how to create call flow nodes for asterisk, using pagi and php, to easily create telephony applications. It's now time to add a layer on top of it, and create a complete call flow with several nodes.

He talks about NodeControllers to control execution flow, results from their execution, available actions and an example of creating a controller and adding nodes. He builds on this simple controller and shows how to handle a few actions including responding to user feedback, adding multiple menu options and some more complex logic using a closure to contain the functionality.

tagged: ivr node controller call flow tutorial asterisk


Marcelo Gornstein's Blog:
Advanced telephony applications with PHP and PAGI using call flow nodes
Apr 04, 2012 @ 11:21:54

Marcelo Gornstein has a new post to his blog (in his PHP and PAGI series) showing how you can use call nodes to create more complicated telephony applications.

Now, since version 1.10.0, PAGI comes with a neat feature, which is a small abstraction layer over the pagi client, called "Nodes". Also, the "NodeController" will orchestrate how those nodes interact with each other. Nodes are essentially call flow nodes. These new features will allow you to implement complete call flows in no time, and maybe even without using the pagi client by yourself. In this article, I'll introduce the nodes by themselves (and how to unit test them), and will talk about the node controller in a latter article.

He introduces the concepts of these Nodes and shows how to create a simple client, make a node off of it and read in the user's input. Code is also included for a basic IVR menu, working with pre-prompt messages, digits, datetimes and calling card PIN numbers. There's also some examples of calling validators on the input, making callbacks, tracking the nodes via in internal system and mocking out the nodes for testing purposes.

tagged: pagi telephony application call flow node tutorial


Stoimen Popov's Blog:
PHP: Don’t Call the Destructor Explicitly
Nov 16, 2011 @ 11:56:43

In this new post to his blog Stoimen Popov talks about calling the "destructor" method of an object and why doing it directly could lead to some issues - like not actually destroying the object before the script ends.

At the end of the script the interpreter frees the memory. Actually every object has a built-in destructor, just like it has built-in constructor. So even we don’t define it explicitly, the object has its destructor. Usually this destructor is executed at the end of the script, or whenever the object isn’t needed anymore. This can happen, for instance, at the end of a function body. Now if we call the destructor explicitly, which as I said I’ve seen many times, here’s what happen. As you can see calling the destructor explicitly doesn’t destroy the object. So the question is...how to destroy an object before the script stops?

He points out that one way to "destroy" an object is to null it out and remove the structure from memory. This is tricky, though, because a clone of the object will still exist in memory, just not the original.

tagged: destructor call directly null clone object


Artur Ejsmont's Blog:
How to properly secure remote API calls over SSL from PHP code
Sep 19, 2011 @ 13:56:00

Artur Ejsmont has a new post with a passionate call to arms for anyone who thinks that just because their URL has "https" in it, it's secure. He presents his suggestion on how to properly secure SSL API calls for your PHP application.

Lets make something clear from the very start: JUST BECAUSE THERE IS https:// IN THE URL OF THE REMOTE SERVICE IT DOES NOT MEAN THE CONNECTION IS SECURE! I am sorry for the tone of this post but i am enraged by how popular this issue is online. If you ask why i suggest a little experiment [involving changing your hosts file and using a self-signed certificate].

The issue he spotlights is all too common - a server serves up SSL pages but doesn't actually verify the certificate in the process. He gives a bad example of how some scripts handle this issue using the CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to turn off this verification - a very bad idea. To protect yourself from any kind of man-in-the-middle or DNS hijack issues, you should leave these on.

tagged: ssl certificate api call protect verification