Pragmatism in the real world
I find the Whoops error handler page in Expressive quite hard to read and particularly dislike that the error message displayed in the top left is hidden if it's more than a few words long. To fix this, I discovered that you can provide a custom CSS file to the PrettyPrintHandler and then override to your heart's content! One way to do this is to add a delegator factory to add the additional functionality, so… continue reading.
When developing an Expressive application, if you use var_dump(), echo, print_r(), etc when you get this error: Fatal error: Uncaught RuntimeException: Output has been emitted previously; cannot emit response in /www/dev/rka/example-app/vendor/zendframework/zend-diactoros/src/Response/SapiEmitterTrait.php:31 This occurs after your data has been displayed and makes perfect sense as Expressive is unable to send headers as you've already started sending the body. To solve this, you need some middleware. It looks like this: <?php namespace Akrabat\Middleware; use const Webimpress\HttpMiddlewareCompatibility\HANDLER_METHOD; use… continue reading.
If you're not using the Whoops error handler with Expressive and are using the Twig renderer, then you are given no information about the problem that occurred, even in debug mode. To fix this, I changed error.html.twig to this: {% extends '@layout/default.html.twig' %} {% block title %}{{ status }} {{ reason }}{% endblock %} {% block content %} <h1>Oops!</h1> <h2>This is awkward.</h2> <p>We encountered a {{ status }} {{ reason }} error.</p> {% if status… continue reading.
My favourite tool for working with APIs is curl, though I recognise that lots of people like HTTPie and seem very keen to tell about it every time I mention curl… With curl, I particularly like using the -i switch to view the status line and headers too without the additional cruft of -v: This generates an output that looks like this: $ curl -i https://api.joind.in HTTP/1.1 200 OK Date: Wed, 04 Oct 2017 09:51:46… continue reading.
I'm adding a new feature to ZF's Problem-Details component and it's easiest to do this within the context of the application I'm developing. The component lives in vendor/zendframework/zend-problem-details and was installed using composer require so doesn't have its own git repository as the distribution zip file was used to install it. To change it to a git repository, we can use the –prefer-source option and specify a branch like this: $ composer require –prefer-source zendframework/zend-problem-details:dev-master… continue reading.
By default, OpenWhisk will handle the relevant responses for CORS. Specifically, it will respond to an OPTIONS request with these headers: Access-Control-Allow-Origin: * Access-Control-Allow-Methods: OPTIONS, GET, DELETE, POST, PUT, HEAD, PATCH Access-Control-Allow-Headers: Authorization, Content-Type If you need to change what is sent or you don't want to send these headers at all, then you need to do set the annotation web-custom-options to true and handle the OPTIONS header yourself. Note that if you don't set… continue reading.
Having successfully deployed a PHP application to Cloud Foundry, I needed a PostgreSQL database for persistent storage. I found Lorna Mitchell's Connecting PHP to MySQL on Bluemix helpful and this article expands on that information. I want to create a cloud-based PostgreSQL database and connect it to Laravel's Eloquent in a Cloud Foundry application. This is how to do it. Create the database instance As I'm using Bluemix for my Cloud Foundry hosting, I'm using… continue reading.
I recently had a requirement to deploy a Slim application somewhere. As I already have a Bluemix account, it seemed sensible to deploy it to their Application Runtimes service which is an installation of the Open Source Cloud Foundry project. This turned out to be quite easy, but there are a number of steps involved, so I'm documenting it here. Setup the CLI tools I'm a command line person, so did it all via the… continue reading.
I've been interested in Apache OpenWhisk for a little while now and recently submitted a new feature to add PHP support to the project. As OpenWhisk is a serverless environment, most users do not run their own copy and instead use a commercial provider with IBMs Bluemix available now along with Adobes I/O Runtime and RedHat coming soon. As a result, my contribution, isn't practically useful until it's in production with a provider. Fortunately, and… continue reading.
Using Zend-InputFilter is remarkably easy to use: use Zend\InputFilter\Factory as InputFilterFactory; // set up InputFilter $specification = [ 'my_field' => [ 'required' => false, 'filters' => [ ['name' => 'StringTrim'], ], ], ]; $factory = new InputFilterFactory(); $inputFilter = $factory->createInputFilter($specification); // use InputFilter on some data $data['my_field] = 'Some string'; $inputFilter->setData($data); if ($inputFilter->isValid()) { Return false; } return $inputFilter->getValues(); // my_field is now trimmed How do you add your filter to it though? This is… continue reading.
