SitePoint PHPBest PHP Framework 2015 Survey (27.2.2015, 17:00 UTC)

Almost a year and a half ago we published the results of a framework survey on the PHP channel. The survey, while producing fewer entries than our IDE survey still provided us with valuable insight into our audience and the state of individual vs. team developers out there.

With Laravel 5 fresh out of the oven, Phalcon being kickstarted into full-time development, and others reaching a much anticipated maturity, it’s only natural we’re curious about your preferences - have they changed? Do they remain unbudged? Do you wish you could switch so hard you can taste it, but aren’t allowed to by your company? We’re interested in all these points and much more.

Continue reading %Best PHP Framework 2015 Survey%

Link
Derick RethansXdebug 2.3: Moar var_dump() (27.2.2015, 08:57 UTC)

Xdebug 2.3: Moar var_dump()

This is the first article in a series about the new features in Xdebug 2.3, which was first released on February 22nd.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0.

Which means that instead of:

array(4) { [0]=> int(42) [1]=> string(6) "string" [2]=> bool(true) [3]=> float(3.1415926535898) }

You get:

Nothing new so far.

Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

You can include this information, by setting xdebug.overload_var_dump to 2. If the xdebug.overload_var_dump setting is set to 2, the overloaded var_dump() output now looks like:

As you can see, the file name and line number of where var_dump() were called are prepended to the output.

An already existing setting, xdebug.file_link_format, allows you to format file name and line number information so that Xdebug generates a link. This same setting is also respected by the inclusion of the file name and line number in the enhanced var_dump() output. Setting xdebug.file_link_format to xdebug://%f:%l will then link the file name to xdebug:///home/httpd/html/test/xdebug/overload-var-dump.php:4. If we look at this as an image, we will see:

In a future version of Xdebug, it is likely that I will either wrap in the file name/line number information in the overloaded var_dump(), or change the default value of the setting to 2.

Link
Ilia AlshanetskyPHP Excel v1.0.1 Released (26.2.2015, 16:12 UTC)
The long awaited v1.0.1 of PHP-excel extension is finally out, lots of changes in this one.
You can download the source code at: https://github.com/iliaal/php_excel/archive/1.0.1final.tar.gz
the Github repo is available at: https://github.com/iliaal/php_excel

Full ChangeLog is Below:


Continue reading "PHP Excel v1.0.1 Released"
Link
thePHP.ccConFoo 2015: It's that time again (26.2.2015, 07:00 UTC)
Link
Nomad PHPKeeping the Code Monkey Fit (25.2.2015, 19:13 UTC)

Speaker: Rebecca McGrane @RebeccaMcGrane 30 seconds can end backaches, neck strain, eye fatigue carpal tunnel and other common pains of being a full time programmer, or as I lovingly call mine Code Monkey. In 10 minutes I will share everything you need to know to stop pain, improve your cardiovascular health, boost brain cells (AKA …

The post Keeping the Code Monkey Fit appeared first on Nomad PHP.

Link
Nomad PHPError Handling in PHP (25.2.2015, 19:09 UTC)

Speaker: Ian Littman @iansltx A 500 with blank output is scary. Though the magic of setting exception and error handlers, I’ll show you how to, using PHP’s core error handling functions, turn the White Screen of Death into a prettier, more informative output that’ll help you solve your app’s problems rather than freak out over …

The post Error Handling in PHP appeared first on Nomad PHP.

Link
SitePoint PHPExploring the Cache API in Drupal 8 (25.2.2015, 17:00 UTC)

Drupal 8 comes with many improvements over its predecessor we have grown to both love and hate. Next to prominent systems such as Views in core, configuration management or a useful translation service, there are also less known changes but that are equally important to know and use. One such improvement has been the cache API that solves many performance problems we have in Drupal 7.

In this article, I want to shine a bit of light over the new cache API. To this end, we are going to look at how we can use it in our custom modules as we are encouraged to do so much more in Drupal 8.

Additionally, I have prepared a little demonstration in the shape of a module you can install for testing the impact of the cache API. It’s a simple page that in its rendering logic makes an external API call (to a dummy JSON endpoint) and caches its results. The page then displays the actual time it takes for this to happen, contrasting the external call time vs. the cached version time.

The new cache API

Bins

The new cache API (with the default DatabaseBackend storage) is stored in multiple bins which map to tables that start with the prefix cache_. When interacting with the cache, we always start by requesting a cache bin:

$cache = \Drupal::cache();

Where $cache will be an instance of the DatabaseBackend object that represents the default bin (cache_default). To request a particular bin we pass in the name in the constructor:

$render_cache = \Drupal::cache('render');

Where $render_cache will represent the render cache bin (which is new in Drupal 8 and is supposed to improve render performance across the board).

Continue reading %Exploring the Cache API in Drupal 8%

Link
Stefan KoopmanschapSolving 'convert: delegate library support not built-in `white' (LCMS) @ warning/profile.c/ProfileImage/853' (25.2.2015, 13:05 UTC)

Another quick fix documented here simple because it may help me (or someone else of course) in the future.

Context

For a project I’m working on right now I need to crop an image using ImageMagick. We’re using the commandline instead of Imagick because we need to execute a custom command with a lot of extra options for this specific action, since the image will eventually be used for high-quality printing. As I was testing the command, tweaking the parameters, I eventually ended up with an error:

convert: delegate library support not built-in `white’ (LCMS) @ warning/profile.c/ProfileImage/853

The solution

It turns out this was very simply to solve: I used homebrew to install imagemagick, and I installed it simply by doing:

brew install imagemagick

Apparently, this is wrong. At least when you want to specify your own profile (for instance by using -profile /path/to/sRGB_IEC61966-2-1_black_scaled.icc). The solution? Install it —with-little-cms:

brew install imagemagick —with-little-cms

With thanks to clee704 on Github who came up with this solution.

Link
Cal EvansInterview with Larry Garfield (25.2.2015, 05:00 UTC) Link
Evert PotThe problem with password_hash() (24.2.2015, 22:37 UTC)

PHP 5.5 introduced a new set of functions to hash and validate passwords in in PHP: password_hash(), password_validate() and friends.

These functions have several things going for them:

  1. They have a great API.
  2. They solve a problem that is solved incorrectly often in PHP, making many PHP applications vulnerable.

For projects where I'm able to require PHP 5.5 as a minimum version, I use these functions, and for projects that require PHP 5.4, I use password-compat library, which implements the exact same API in PHP and does so quite excellently.

However, the initial introduction and rfc for these functions made me uneasy, and I felt like a lone voice against many in that I thought something bad was happening. I felt that they should not be added to the PHP engine.

I think that we should not extend the PHP engine, when it's possible to write the same API in userland, or there are significant benefits to do it in PHP, such as performance.

Since the heavy lifting of the password functions is done by underlying libraries that are already exposed to userland-PHP, it didn't make sense to me to expose it as well in the core.

There's several drawbacks to writing things in C for PHP:

  1. The release schedule is tied to the release schedule of PHP. Lots of people can't or won't update their PHP, so if a vulnerability or bug is introduced in the functions, they have no easy option to upgrade.
  2. I'd argue that it's easier to introduce buggy code in unmanaged languages such as C, as opposed to PHP.
  3. By adding it to the language, it also extends the 'PHP specification' and forces alternative implementations such as HHVM to duplicate the API, adding more work for everyone involved and also increasing the surface of potential vulnerabilities again in the future.

I can't think of any technical reasons why it would not be better written in PHP. In fact, there is a PHP version that does the exact same thing, and is actually also recommended on php.net for older PHP versions.

So what are the non-technical benefits?

  1. Adding these functions to PHP may give them more legitimacy.
  2. Adding the functions to PHP perhaps give them a broader audience and more visibility.

I think those benefits are perfectly valid, and especially considering that this is a security-related topic, probably outweight the drawbacks of adding it to the PHP engine.

But it also illustrates that the PHP community has a problem. Python, a language in many respects similar to PHP also comes with a large list of default modules containing API's that python developers can generally depend on.

The difference is that many of these modules are written in Python, and not C. Why are we not 'eating our own dogfood' in PHP? Perhaps PEAR was once that, but there's no real replacement.

If code for PHP is required to be written in C to be considered legitimate and dependable, I think we need to admit we have a problem.

Link
LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP