Skip to main content
Start of main content.

kim.pepper

Kim Pepper
Kim Pepper headshot
Co-Founder & Tech Director

Location

Sydney

Drupal.org

kim.pepper

Twitter

kimb0oo

Kim is the co-founder and Technical Director of PreviousNext.

My blog posts

Dynamic Routes in Drupal 8 with a RouteSubscriber

Previously I have demonstrated how to create a new route controller in Using Drupal 8's new route controllers then how to restrict access to it in Controlling Access to Drupal 8 Routes with Access Checks. But that's not where the fun ends!

What about when we need to create a route dynamically. For example, if we need to create routes for content types that we don't know will exist in advance?  In Drupal 7, we created dynamic routes with a foreach loop in hook_menu(). In Drupal 8, we can do all this and more with a RouteSubscriber.

by kim.pepper /

Controlling Access to Drupal 8 Routes with Access Checks

In the previous post, I looked at how to put together a basic route controller in Drupal 8, and restrict access by specifying permissions. But there are my situations where basic permissions aren't enough.

In Drupal 7 we had procedural access callbacks. In Drupal 8 we now have AccessCheck services.

This post takes you through how to use the new AccessCheck interface to provide a custom access checker for your routes.

by kim.pepper /

Using Drupal 8's new route controllers

As part of the Web Services and Context Core Initiative, traditional procedural page callbacks were converted to shiny new Object Oriented route controllers. 

In this post, we cover the basics of creating a route controller, and how to pass in dependencies using dependency injection.

In following posts, we'll look at how to convert Drupal 7 custom access callbacks, to the new AccessCheckInterface, as well as dynamic routes.

by kim.pepper /

Automated Drupal Testing with Github Pull Requests

We are passionate about code quality. We want to make sure our code is well tested and confirms to standards at all times. If there is a bug, we want to know as soon as possible, so we can fix it and keep our code stable, well tested and bug free, even in early development versions.

Typical workflows use a git topic branch for development of each feature, and require code to be merged into a development branch before automated tests are run. The problem with this approach is it tests code after it has been reviewed and merged.

Using Jenkins for automated testing of Github pull requests, we can get one step closer to code quality nirvana.

by kim.pepper /