What's New

Website Rareloop Timber Documentation Twig Documentation
Search…
What's New
This release of Lumberjack is jam packed full of goodies. We have also added a whole lot more documentation, so grab a cuppa and make yourself comfy while we take you through all the changes.
What's new in v4.3
Features
Middleware Aliases on routes and controllers
You can now create Middleware Aliases that can be used anywhere that middleware can normally be used, both in the Router and through Controllers.
If, for example, an Alias had been registered for an AuthMiddleware with the key auth like so:
1
MiddlewareAliases::set('auth', function() {
2
    return new AuthMiddleware;
3
});
Copied!
You can now use this in your route definition like this:
1
Router::get(
2
    'route/uri', 
3
    '\App\Http\Controllers\[email protected]'
4
)->middleware('auth');
Copied!
Middleware
logger() helper
The logger helper can be used to write debug messages to your logs.
1
\Rareloop\Lumberjack\Helpers::logger('Product added to basket', ['id' => $product->id]);
2
​
3
// Global function
4
logger('Product added to basket', ['id' => $product->id]);
Copied!
If you need to access the logger class itself, to log different types of errors for example, you can use the logger function with no arguments. This will get you an instance of the PSR3 compliant logger that is bound to the container. By default Lumberjack uses Monolog\Logger.
1
\Rareloop\Lumberjack\Helpers::logger()->warning('Example warning');
2
​
3
// Global function
4
logger()->warning('Example warning');
Copied!
Also, the Logger instance is now also bound to the PSR-3 interface Psr\Log\LoggerInterface in the Container.
Helpers
Patches
The E_USER_NOTICE and E_USER_DEPRECATED errors are now whitelisted from the Exception Handler so that they aren’t fatal.
What's new in v4.2
Features
Query Builder
The Query Builder became macroable & also received one new useful method: first().
You can now add your own functionality to the query builder by using a macro. In this example we are adding a custom search method:
1
use Rareloop\Lumberjack\QueryBuilder;
2
​
3
// Add custom function
4
QueryBuilder::macro('search', function ($term) {
5
    $this->params['s'] = $term;
6
    
7
    return $this;
8
});
9
​
10
// Use the functionality
11
$query = new QueryBuilder();
12
$query->search('Elephant');
13
​
14
$posts = $query->first();
Copied!
Query Builder
Define middleware in controllers
You can now apply Middleware on a Controller class too, either for use with the Router or as a WordPress Controller. In order to do this your Controller must extend the App\Http\Controllers\Controller base class.
Middleware is added by calling the middleware() function in your Controller's __constructor().
1
use App\Http\Controllers\Controller;
2
​
3
class MyController extends Controller
4
{
5
    public function __construct()
6
    {
7
        // Add one at a time
8
        $this->middleware(new AddHeaderMiddleware('X-Key1', 'abc'));
9
        $this->middleware(new AuthMiddleware());
10
​
11
        // Add multiple with one method call
12
        $this->middleware([
13
            new AddHeaderMiddleware('X-Key1', 'abc',
14
            new AuthMiddleware(),
15
        ]);
16
    }
17
}
Copied!
Middleware
Config has()
Lumberjack's configuration class now lets you check whether a config file contains a given item:
1
if (Config::has('app.mySetting') {
2
    // ...
3
}
Copied!
Note that the has method only checks whether the config item exists, regardless of its value. 
If you set app.mySetting to an empty value such as false or null, has('app.mySetting') will return true.
Configuration
Documentation
We have also added/revisited some of the documentation. We recommend checking these out:
​View Models -  New documentation
​Middleware - New documentation
​Collections - New documentation
What's new in v4.1
Features
Extending Lumberjack with Macros
You can now extend core Lumberjack classes and add your own functionality without needing to rely on inheritance. Instead, you can add macros (custom functions) to the core classes themselves.
Here's an example macro, that adds a custom acf() method on Rareloop\Lumberjack\Post. 
1
use Rareloop\Lumberjack\Post;
2
​
3
// Add custom function
4
Post::macro('acf', function ($field) {
5
    return get_field($field, $this->id);
6
});
7
​
8
// Use the functionality
9
$post = new Post;
10
$value = $post->acf('custom_field_name');
Copied!
The following classes are 'macroable':
Rareloop\Lumberjack\Post
Rareloop\Router\Router
Rareloop\Router\RouteGroup
Rareloop\Router\Route
What's new in v4.0
General 
PHP Version
The first important thing to mention is that the minimum version of PHP has been bumped up to 7.1. So make sure your server can handle this version.
Standardising the Container
Lumberjack uses a dependency injection container under the hood, which allows you to decouple your class dependencies by having the container inject dependencies when needed.
In v3, it wasn't clear when you were resolving a singleton or a new instance of a class from the container. It could have lead to some unusual & unexpected issues, so we decided to make things much clearer with v4 and standardise the behaviour.
Now, when you bind a class name into the container like so:
1
$app->bind('key', MyClass::class);
2
​
3
// Or bind a concrete class to an interface
4
$app->bind(MyInterface::class, MyClass::class);
Copied!
The container will always resolve a new instance. What does that mean? In short, it means state is not kept between resolves, you will always get a new instance of the class. Here's a couple of examples to illustrate the point:
1
// Bind a class to the container
2
$app->bind('key', MyClass::class);
3
​
4
$value1 = $app->get('key');
5
$value2 = $app->get('key');
6
​
7
$value1 === $value2; // false
Copied!
Here we are resolving key from the container twice. Each time it is resolved, the container will create a new instance of the MyClass class. If we were to modify $value1 in any way, that change would not persist in $value2. For example:
1
// Bind a class to the container
2
$app->bind('key', MyClass::class);
3
​
4
$value1 = $app->get('key');
5
​
6
// Modify $key1
7
$value1->name = 'Adam';
8
​
9
// Get 'key' from the container again
10
$value2 = $app->get('key');
11
​
12
// Throws an exception as name is not defined on $value2
13
$value2->name;
Copied!
For the majority of the time, we feel like this is the better option. It means you are not accidentally coupling your application to the state of something in the container.
However, sometimes you do want that behaviour. When you do, you can simply use the singleton method to tell the container to resolve the same instance if there is one.
1
$app->singleton('key', MyClass::class);
2
​
3
// Or bind a concrete class to an interface
4
$app->singleton(MyInterface::class, MyClass::class);
Copied!
Now, when the container resolves the instance it will use the one that is already bound to the container. For example:
1
// Bind a singleton to the container
2
$app->singleton('key', MyClass::class);
3
​
4
$value1 = $app->get('key');
5
$value2 = $app->get('key');
6
​
7
$value1 === $value2; // true
Copied!
And when we modify the instance, its state will persist:
1
// Bind a class to the container
2
$app->singleton('key', MyClass::class);
3
​
4
$value1 = $app->get('key');
5
​
6
// Modify $value1
7
$value1->name = 'Adam';
8
​
9
// Get 'key' from the container again
10
$value2 = $app->get('key');
11
​
12
// 'name' is available because $value2 is the same object as $value1
13
$value2->name; // 'Adam'
Copied!
It is important to note that if you bind an object instance to the container, you will always get that instance back. For example:
1
$app->bind('key', new MyClass);
2
​
3
$value1 = $app->get('key');
4
$value1->name = 'Adam';
5
​
6
$value2 = $app->get('key');
7
​
8
// Both variables reference the same object
9
$value1 === $value2; // true
10
​
11
$value2->name; // 'Adam'
Copied!
Head over to the "Using the Container" docs to learn more:
Using the Container
Features
New helper functions
To make your development lives easier, there are now some additional helper functions available. These are:
redirect() - returns a RedirectResponse
back() - returns a RedirectResponse which automatically redirects back to the previous URL
report($exception) - tells the Exception Handler to report an exception. Useful if your theme needs to swallow an exception, but you still want to log the fact that it happened
request() - returns the current ServerRequest object
session() - can be used to interact with the session in various ways
Check out the Helpers documentation for more details:
Helpers
Query Builder
We've baked-in the rareloop/lumberjack-querybuilder package into the core. You now get an expressive, fluent and explicit way of querying data in WordPress out-of-the-box with Lumberjack. It can be used instead of WP_Query to query posts (of any type) and means you do not have to worry about "the loop".
Query Builder
Sessions
This is one of the bigger features added to v4. You can now manage sessions in a concise, expressive and headache-free way.
Let's dive straight into what sessions look like in Lumberjack. We'll be using the global helper function session() for these examples; make sure you have enabled them if you want to use it too.
1
// Get a value, with a default value
2
$value = session('key', 'default');
3
​
4
// Get all values
5
$values = session()->all();
6
​
7
// Store a value
8
session()->put('key', 'value');
9
​
10
// Check if the session has a value
11
session()->has('key');
12
​
13
// Flash a value for 1 request
14
session()->flash('key', 'value');
15
​
16
// Remove a value
17
session()->forget('key');
Copied!
Be sure to read the Sessions documentation for a more in-depth look:
Sessions
Interacting with the request
In v3, you could access the request by dependency injecting Zend\Diactoros\ServerRequest, like so:
1
use Zend\Diactoros\ServerRequest;
2
​
3
class ExampleController
4
{
5
    public function handle(ServerRequest $request)
6
    {
7
​
8
    } 
9
}
Copied!
Lumberjack now has its own ServerRequest class, making it much easier to work with the request. You can access it like so:
1
use Rareloop\Lumberjack\Http\ServerRequest;
2
​
3
class ExampleController
4
{
5
    public function handle(ServerRequest $request)
6
    {
7
​
8
    } 
9
}
Copied!
You can also use the request() helper to access the request from anywhere in your theme:
1
use Rareloop\Lumberjack\Helpers;
2
​
3
$request = Helpers::request();
4
​
5
// Or if you have global helpers enabled:
6
$request = request();
Copied!
Overview of some available methods
1
// Get the current path
2
$request->path(); // e.g. /path
3
​
4
// Get the current URL
5
$request->url(); // e.g. http://test.com/path
6
​
7
// Get the current URL, with query parameters etc
8
$request->fullUrl(); // e.g. http://test.com/path?name=adam
9
​
10
// Get query params
11
$request->query();
12
$name = $request->query('name', 'default');
13
​
14
// Get all input (from $_GET and $_POST)
15
$input = $request->input();
16
$name = $request->input('name', 'default');
17
​
18
// Check the request has a specific key
19
$request->has('name');
Copied!
You can read the HTTP Requests documentation for more information:
HTTP Requests
Documentation
We have also added/revisited some of the documentation. We recommend checking these out:
​Upgrade Guide - How to upgrade to v4 from v3
​HTTP Requests - New feature!
​Sessions - New feature!
​Using the Container - Revisited docs after the changes to the container's behaviour
​Helpers - Added more helpers
Introduction
Upgrade Guide
Last modified 2yr ago
Copy link
Contents