Posts Tagged ‘PHP’

Upgrading from Slim 3 to Slim 4

Friday, September 18th, 2020 | Programming

Slim is one of my favourite PHP microframeworks and many websites are built on Slim 3. I have recently moved to Slim 4 and thought I would document the upgrade process for anyone else looking to make the leap.

Dependencies

Slim 3 came with its own dependency injection container. This is no longer the case. Therefore, we need to bring one in, such as php-di that Slim supports out-of-the-box. We will also need a PSR-7 library and the Slim HTTP helpers.

"slim/slim": "4.*",
"slim/psr7": "1.*",
"slim/http": "1.*",
"php-di/php-di": "^6.1",

Creating the app

In Slim 3, we created the app and then accessed the container.

$app = new \Slim\App([
    'settings' => []
]);

$container = $app->getContainer();

In Slim 4, we create the container then attached it to the app.

$container = new \DI\Container();
\Slim\Factory\AppFactory::setContainer($container);
$app = \Slim\Factory\AppFactory::create();

You can still access the container in the old way and inject dependencies into it, but you need to manually pass it into the app as above.

Accessing dependencies

Now we are using our PSR-11 DI of choice, we need to change how we access our dependencies. Previously, wee could use the Slim shorthand.

$db = $this->ci->db;

Now we need to use the PSR-11 standard.

$db = $this->ci->get('db');

Exception handling

Previously, we could set error handling using the dependency injection container.

$container['notFoundHandler'] = function ($container) {
    return function ($request, $response) use ($container) {
        $controller = new \App\Controller\ExceptionController($container);
        return $controller->notFound($request, $response);
    };
};

In Slim 4, we need to use the bundled middleware.

$errorMiddleware = $app->addErrorMiddleware(true, true, true);

$errorMiddleware->setErrorHandler(
    Slim\Exception\HttpNotFoundException::class,
    function (Psr\Http\Message\ServerRequestInterface $request) use ($container) {
        $controller = new App\Controller\ExceptionController($container);
        return $controller->notFound($request);
    });

This also means changing the exception controller, too, if you use one. In Slim 3, we would still get a response object passed in.

    public function notFound(Request $request, Response $response)
    {
        return $this->render($response, 'not-found.html');
    }

With Slim 4, we need to create our own.

    public function notFound(Request $request)
    {
        $response = new \Slim\Psr7\Response;
        return $this->render($response, 'not-found.html');
    }

That should take care of most of the changes. If you run into anything else, let me know, and I’ll update this article.

Slim Framework course

Saturday, July 25th, 2020 | News

Learn Slim microframework with my new course. You will build your first six projects including a searchable music catalogue, e-commerce project listings and member login and authentication system. Watch the course trailer below or preview the course.

Doctrine ORM course

Monday, June 8th, 2020 | News, Programming

My new course on Doctrine ORM is now available. If you are a PHP developer, adding Doctrine to your CV is a much=sought-after skill to have, being used by Symfony and thousands of other projects.

Here’s the trailer:

Slim PHP 3.12.3

Friday, December 6th, 2019 | Programming

If you’re using the Slim framework in PHP, there is a breaking change between 3.12.2 and 3.12.3. You’ll need to change where you are inheriting your class from.

- use Interop\Container\ContainerInterface;
+ use Psr\Container\ContainerInterface;

Rauma 4.0 released

Monday, February 4th, 2019 | Programming

I’m pleased to announce the release of the next major version of Rauma, 4.0.

Rauma is a full-stack PHP framework that gives you database, templating, session, authentication and many other functions out of the box. It’s the framework behind many of Worfolk Online’s websites.

Not much as changed in the 4.0 release, but it gets a major version bump because it’s a breaking change. Here’s what you need to know:

Authentication has been overhauled. The auth service now includes an isLoggedIn function to be a bit more verbose than checking for data. More importantly, you can now extend the base Authorisation class and create your own. This allows you to cache more data, connect to other services and implement persistent logins.

We’ve also deprecated the user description field, in favour of the new attributes feature that was added in version 3.6.

Two other things to be aware of:

There are now a set of proxy objects for things like JsonResponse so that you don’t have to import them from a different namespace.

This bumps the PHP version requirement from 5.6 to 7.1. This allows us to bring in a load of cool new stuff, including a far more up-to-date version of PHPUnit.

It’s available now on GitHub and Packagist.

Photo credit: Brett Donovan.

Heroku for PHP course

Wednesday, March 14th, 2018 | News, Programming

I’m pleased to announce the launch of my new course, Heroku for PHP. I love Heroku as a hosting platform, and there were no Udemy courses on how to use it with PHP. So, I’ve filled the gap. For a very reasonable $29.99.

You can check it out here, and that link will save you an additional $10, too.

How to serve .well-known on Heroku

Saturday, April 22nd, 2017 | Programming

If you want to use Apple Pay on your website, you need to serve a file from inside the .well-known directory. This is a nightmare.

For a start, you can’t create a directory called .well-known on Mac. So you have to find another solution. mod_rewrite to the rescue perhaps? You may be able to get this working, but I couldn’t. I just got a 403 permission denied on Heroku.

client denied by server configuration: /app/public/.well-known

So I decided to try Alias instead.

This was easy to configure on my localhost. I created a directory without the period and then used Alias to map it.

Alias "/.well-known" "/Users/me/Projects/ProjectName/well-known"

To configure it in Heroku, I created a custom Apache configuration file.

Alias "/.well-known" "${HEROKU_APP_DIR}/well-known"

And then configured my Procfile to load this.

web: vendor/bin/heroku-php-apache2 -C heroku-apache.conf public/

So far, so good. Except this didn’t work either because I had not given the directory permission in the Apache config. So I expanded my custom config file.

<Directory "${HEROKU_APP_DIR}/well-known">
    Options FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

This got it working. However, it took my homepage offline. It seems that when you include a custom Apache configuration file, it knocks out the standard DirectoryIndex that Heroku has. Or, there is something else really obviously wrong that I am missing. That’s entirely possible, but I haven’t spotted it yet.

And I did manage to fix it by adding in a new DirectoryIndex to my .htaccess file.

DirectoryIndex index.php

Finally, you have Heroku serving the directory correctly.

How to install Composer inside WordPress

Sunday, March 26th, 2017 | Programming

WordPress has an ancient and ugly codebase. When you are writing plugins, you often want to make your code less horrible and use Composer to bring in dependencies as normal. How do these things fit together?

The first thing I tried was to create plugin-specific dependencies list. Inside the plugin directory, I created a composer.json> file, then ran the install and uploaded it.

This approach works fines when you only use a dependency once and no other plugin uses the same dependency. However, when I wanted to re-use a library in another plugin I had a problem. If I included it twice it would crash.

Installing Composer globally

The solution I came to was to do a global install of Composer. I created a composer.json file in the root and listed all of the dependencies I needed for my plugins in there.

Then, in each plugin, I checked for the file and included it.

if (file_exists(sprintf('%s/vendor/autoload.php', ABSPATH))) {
    require_once sprintf('%s/vendor/autoload.php', ABSPATH);
    add_filter('the_content', 'simple_related_posts', 30);
} else {
    add_action('admin_notices', function() {
        echo '<div class="notice notice-warning is-dismissible"><p><em>Simple Related Posts</em> plugin requires <strong>Composer</strong>.</p></div>';
    });
}

Drawbacks to this approach

This means plugins are no longer self-contained. You have to install the plugin and add the dependencies to your central composer.json file. That is messy.

With the code above, it does not check if the _correct_ dependencies are there. This is something you could add in. However, given the problem above, it seems like it would require so much manual management anyway that I would know what was going on.

Optimise for performance

If you are using Composer on production, do not forget to optimise the autoloader before uploading your files.

composer dumpautoload -o

Conclusion

Personally, I would rather lose plugins being entirely self-contained and benefit from Composer libraries. This approach works well for me because they are purpose-written plugins for my blog.

However, this approach would not work well if you were publishing your plugins as most WordPress users would not know what was going on.

How to run Webpack Dev Server with PHP

Monday, March 20th, 2017 | Programming

You are making an awesome new JavaScript-based app in React. However, it needs to live inside an existing framework, such as Symfony for PHP. You want the hot-reloading function that you get with Webpack Dev Server, but you also need the content to be served from your LAMP stack because it creates the HTML wrapper page.

What do you do?

The answer is to run two servers: both Webpack Dev Server and your existing Stack. Here is how…

Configuring Webpack

Start by installing Webpack Dev Server as usual.

npm install --save-dev webpack-dev-server

Create a script entry in package.json to run it:

"scripts": {
    "start": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js"
}

We also need to make one change to our webpack.config.js file. We need to tell the output to point back at the Webpack Dev Server. Otherwise, it will point at your LAMP stack.

output: {
    publicPath: 'http://localhost:8080/scripts/'
}

Super. Next, let’s configure the LAMP stack.

Configuring your existing server

This step is easy. All we need to do is to point the JavaScript at the Webpack Dev Server.

Let’s say you have this at the moment:

<script src="/scripts/app.js"></script>

Change it to:

<script src="http://localhost:8080/scripts/app.js"></script>

Remember that when you are building for production, you will want to take the changes out. The easiest way to do this is to have a dev webpack.config.js file, and a production one, and have your build tool use the correct one depending on the context.

How we built Rena Men

Monday, October 3rd, 2016 | Programming, Tech

rena-men-september

Recently I launched a new website, Rena Men. It is deployed onto the Heroku platform and does quite a bit of cool stuff, so I thought I would document what I have done here.

Code

It is implemented in PHP, using the Rauma framework. Rauma is a project I developed for Learn Finnish and subsequently open-sourced.

Rena Men is built in several modules. There is a website, a content management system (CMS) and an image server. Because they use common functionality like the entity classes, there is also a shared library which is brought in as a Composer dependency.

The website itself is fairly straight forward. Beyond the PHP, there is only the CSS, pre-processed with SASS, and a tiny amount of JavaScript loaded in with require. The CMS is a bit more complicated, using Babel to transpile the ES6 JavaScript, and styled up with Bootstrap.

Deployment

Each module is deployed onto the Heroku platform. This makes it really easy to do as I can roll out an update just using git push. The code itself is stored in a series of private repos on BitBucket, and the Heroku build process fetches them from there.

In the case of the CMS, it also uses the Node build pack to run a Bower install. Third-party additions such as Bootstrap are pulled in on-the-fly just like we do with Composer dependencies. Heroku does not have SSH key integration for Bitbucket (it does for Github) so I’m using a ready-only account with Basic HTTP auth access.

The database is provided by one of the Heroku app add-ons. The storage is provided by Amazon S3. Heroku is built in AWS, so that fits nicely. We store originals in the file system and then crop them on-demand using the image server.

Delivery

Because cropping images is expensive, the image server originally had a local file cache where it would store each crop. However, as Heroku has an ephemeral file system, you cannot write to it, so I had to turn that off in production.

Instead, we’re using the AWS CloudFront CDN. This was super easy to implement. I just created the settings in AWS, pointed CDN subdomain at AWS and it started working. Like other web proxies, it caches your content based on the headers you send it.