Category Archives: PHP

All things PHP

Server side rendering with phpv8/v8js on Ubuntu

https://vuejsdevelopers.com/2017/11/06/vue-js-laravel-server-side-rendering/ requires phpv8/v8js. Here is how to install the latest (at the time of writing) with php7.1.

Add the latest ppa from this guy: https://launchpad.net/~pinepain

Update the sources:

Install libv8:

Install and compile v8js

Optionally remove the files from the install from /tmp.

After this the SSR of the example vuejs app should work.

Expose all variables in a Twig template in Symfony

Ever worked on a big framework and been new to it.. then you have to somehow figure out a twig tpl without know what variables have been passed?

 

Simple solution, dump all the var keys in the twig tpl:

Injecting twig template names into html source on develop environment

After working on a few big projects, or jumping into existing big projects one trick that helps people get up to speed quickly is highlighting which template has been used at which point in the views. With the Twig tpl system that is reasonably simple:

Assuming a custom php project you can control most from a single render function.

Now you need you twig debug template

 

In the render function you can see I also include some custom twig functions, these come from a file like this:

 

Sort a multi dimensional array

Function to sort php multi-dimensional arrays

eg

Laravel and the lighter sibling

 

Symfony has it’s lightweight sibling, and they called it Silex.

Under the hood of Laravel is Symfony, yet Laravel somehow managed to make a light weight version of the Laravel stack that runs faster that Silex… they called it Lumen:

https://lumen.laravel.com

And as with the Laravel framework it has some beautiful documentation to go with it… Nice work Taylor Otwell!

(Laravel has got to be one of the few if not only frameworks out there that really just works. On top of that, I rarely find the need to stray away from the official documentation either. Why can’t all frameworks be like that! It cannot be that hard can it?)

Laravel 5.4 dropped support to switch out the default blade tags… Use Twig instead, pretty much the same anyway.

Dropping out the default blade syntax used to be as simple as dropping this into the AppServiceProvider->boot function:

But out of the blue, they dropped the setContentTags support..

As a result the migration 5.3->5.4 was either change out all the js tpl syntax for alternatives, or preface every single non-blade with @{{ somethingFromAng }}.

As Twig is basically the same syntax as blade and uses pretty much the same inheritance system, instead of changing any template code, the easier option is to drop blade in favour of twig. Twig is a more flexible tpl language IMHO opinion anyway so win win 🙂

EZPublish migrating content types.

Use this: https://github.com/kaliop-uk/ezmigrationbundle

The basic idea is to write yaml files that act as migration files. If you are familiar with the db migrations from the Laravel 4+ framework you will already have a feel for it.

Each migration is only run once and stored in the database.

First create the migration file after installing with:

Change the content of the YML to something like this simple content type.

Run the migration on the server:

Getting EZPlatform to display google maps in the admin

As of writing ezplatform still cannot handle google maps api keys.

This is a hack till the release is out there to use ( https://jira.ez.no/browse/EZP-26068 )

First up grab yourself a key

  1. https://console.developers.google.com click on the library section in the side nav.
  2. In the top nav should now be a button for enable, you will need to then follow the on screen instruction to get an api key.
  3. Then do the same for Google Maps Geocoding API. This will enable the address lookup for the content type.

Next add your key to the following files where they ref. the google url:
Definitely needed:
ezplatform/vendor/ezsystems/platform-ui-bundle/Resources/public/js/services/ez-googlemapapiloader.js

Might as well whilst you are there:
ezplatform/vendor/ezsystems/platform-ui-bundle/Tests/js/services/assets/ez-googlemapapiloader-tests.js
ezplatform/web/bundles/ezplatformui/js/services/ez-googlemapapiloader.js

That should be it, clear ‘dem cache and you should be good to go. Just remember to repeat this on every environment and after a composer update… although hopefully this should be fixed soon!

 

 

Diagnosing slow PHP execution with Xdebug and KCachegrind

Tracking down a performance issue to the actual PHP app can be hard enough by itself, but what do you do once you’re sure that the app itself is the bottleneck? The excellent Xdebug extension has many useful features for assisting application developers, but today we’ll be looking at one specific feature that can help us see exactly what is slow in the application: profiling.

Profiling a PHP application can explain how much time the server spent in each function, each file, and each code path. It can also show you how many times a function or method was called, which is useful for diagnosing programming errors involving pointless looping. Xdebug generates cachegrind-compatible files (part of the Valgrind tool suite) which can also be used to create easy-to-understand graphs using KCachegrind.

Let’s start off with some very simple PHP code that just loops 10 times so we can get some output out of KCachegrind. I won’t cover the installation of Xdebug here, but here is the configuration that I’m using for it:

; Enable xdebug extension module
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.profiler_output_dir="/dev/shm/trace"
xdebug.profiler_append=On
xdebug.profiler_enable_trigger=On
xdebug.profiler_output_name="%R-%u.trace"
xdebug.trace_options=1
xdebug.collect_params=4
xdebug.collect_return=1
xdebug.collect_vars=0
xdebug.profiler_enable=0
;xdebug.auto_trace=Off

Notice that I’m storing the cachegrind output on /dev/shm/trace. This is so I don’t kill performance on a production system when using Xdebug profiling with autotrace if I’m trying to get a large sampling of data. Not really necessary here, but it doesn’t hurt anything either, so we’ll just stick with it.

Here is the PHP code that we’ll be executing:

for ($i = 1; $i <= 10; $i++) {
    echo $i;
}

This will just print ‘12345678910’ in our browser window when we load the page up. Because of the way we have Xdebug configured, it will only profile PHP execution when we either GET or POST the special string ‘XDEBUG_PROFILE’ . So, assuming our small test PHP script is hosted at http://example.com/test.php , we would want to hit http://example.com/test.php?XDEBUG_PROFILE . This will generate a file called something like this: ‘_test_php_XDEBUG_PROFILE-1296249911_052628.trace’ . Notice how it has the name of the PHP file that was executed, the query string, and the UNIX timestamp (including sub-second timing info). If we open up the file in a text editor, we can see the contents, which aren’t really meant to be human-readable in this mode (although you can change that, refer to the Xdebug documentation for more info).

==== NEW PROFILING FILE ==============================================
version: 0.9.6
cmd: /chroot/home/magbench/magbench1.nexcess.net/html/test.php
part: 1
events: Time
fl=/chroot/home/examplec/example.com/html/test.php
fn={main}
summary: 23
0 23

Let’s see what happens when we run this cachegrind output file through KCachegrind. Because I really don’t like wasting all the space installing the KDE libraries on my Ubuntu system which runs Gnome, I just set up a Ubuntu Server virtual machine and installed KCachegrind and all the KDE libraries on that. I then connect to it using ‘ssh -X user@vmhostname kcachegrind’ which opens up KCachegrind in a new window, similar to if I were running it locally.

Image 1

As you can see, test.php took up 100% of the time and there were no callers or calls to external scripts / functions / methods.

Now, let’s see what happens when we test this with some simple PHP software that we love: DokuWiki (http://www.dokuwiki.org/dokuwiki ):

Image 2

Ahh, now we’re on to something. We can see on the chart that the ‘langsel’ function took ~63% of the processing time when executing the script, so if we wanted to optimise, we would want to look there first.

Here is another example: The main doku.php index page once DokuWiki is installed:

Image 3

We can see the structure of the program from the graph, and while most of it looks normal, I’d be a bit suspicious as to why php::date_default_timezone_get took so long and consider just making that a constant to speed things up (by almost 13% !). This is, of course, with zero real wiki content on the page, so things would change as the content changes, but it’s still an very valuable tool for going deep into why an application is slow.

Next time, I’ll cover the other side of application performance tuning: SQL query profiling with Maatkit.

 

Post found and reblogged from: https://blog.nexcess.net/2011/01/29/diagnosing-slow-php-execution-with-xdebug-and-kcachegrind/