Let’s learn how to work with custom Laravel helpers. This will allow us to create our own globally accessible functions, just like the built in helpers that Laravel provides.
To demonstrate, we’ll create a helper called say_hello that will return the string ”Hello”.
To get started, create a file where you’ll store your helpers - I suggest app/helpers.php
.
Within this file, define your helper functions:
<?php
function say_hello() {
return 'Hello';
}
To make this function available throughout our application, we need to load our helpers file them via Composer. Open your Composer config file (/composer.json
) and find the autoload section:
"autoload": {
"psr-4": {
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
}
},
By default, you should see some autoload settings using PSR-4, which is what you’d edit if you were trying to autoload PHP classes. In this case, we’re working with simple functions so the autoload setting we’ll use is called files and that’s where we’ll specify the path to our new helpers file (app/helpers.php
):
"autoload": {
"psr-4": {
"App\\": "app/",
"Database\\Factories\\": "database/factories/",
"Database\\Seeders\\": "database/seeders/"
},
"files": [
"app/helpers.php"
]
},
Next, we need Composer to recognize these changes. If you’re using Laravel Sail, you can do that via the command:
$ sail composer dump-autoload
If you’re not using Sail, you would just omit the sail
part of that command:
$ composer dump-autoload
Test it
You should now to able to invoke your custom say_hello helper function throughout your application. For example, within a route (/web.php
):
Route::get('/test', function() {
return say_hello();
})
Or within a controller method:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class WelcomeController extends Controller
{
public function index()
{
return say_hello();
}
}
Or directly in a view:
{{ say_hello() }}
Name collisions
One word of caution when creating custom helpers is you always want to pick unique helper names, so as to not conflict with any built in helpers, or even helpers added by external packages you may be using.
For example, let’s say we had called our helper config
- this would conflict with Laravel’s built-in config helper. When we ran our application, this would produce a fatal PHP error:
One way to avoid name collisions like this is to prefix each of your custom helpers with some unique identifier. For example, let’s say your application was called foo - you could prefix all the helpers with foo_
, e.g. foo_say_hello
, foo_config
, etc.
A nice benefit of this is whenever you saw this helper being used, you could quickly identify it as a custom helper that you could edit if needed.