dmitry.g.ivanov

@themsaid Thank you.

@themsaid Thank you for your response!

Now I understand it.

We can use Redis with predis/predis or with PhpRedis (which is "PHP Redis extension", it is the same).

I was confused by one of the projects where both were used in tests, so I thought that predis/predis required redis.so (and I supposed that PhpRedis is yet another extension), which is not true.

@themsaid What is the best practice for "requiring" predis/predis?

I mean, I don't need it on local environment, I need it only on production.

But Composer doesn't have something like require-prod...

So, I can "composer require" it and have loaded on every environment (which is not too bad but doesn't feel very clean...)

Or I can "composer require" it on production, but in that case, I would have unclear "git status" on production, which is worse for my eyes.

(As far as I know, there is no possibility to install the package without modifying the composer.json/composer.lock files.)

@gorby Yes, I use Redis on Forge too.

But I want to understand how does it work.

In order to use Redis locally, I have to install redis PHP extension.

But I can't see it installed on Forge. So, I wonder how does it work then?

@ejdelmonico Yes, I know it.

But your answer doesn't answer my question)

@kfirba , hi!

Can you please check https://laracasts.com/discuss/channels/forge/laravel-forge-redis ?

Thank you!

How does Laravel Forge use Redis?

I've found redis-server and redis-tools installed via apt:

apt list --installed
...
redis-server/bionic,now 5:5.0.2-3chl1~bionic1 amd64 [installed]
redis-tools/bionic,now 5:5.0.2-3chl1~bionic1 amd64 [installed,automatic]

But I can't find redis php extension installed, neither in php -m, nor in php -i.

However, I've checked - it works somehow.

Also, does anyone know - Laravel Forge pre-install PHPRedis by default or not?

Hey, guys!

I want to introduce my new package for the Weather Forecast in PHP: https://github.com/dmitry-ivanov/dark-sky-api

It is a stand-alone PHP package, with Laravel support implemented.

Check the readme file for the basic usage examples and more detailed explanations in my recent article: https://medium.com/@dmitry.g.ivanov/weather-forecast-in-php-95bca6b0ed18

Hope it would be useful for you!

Hey, guys!

I've created the package for getting the weather forecast (and past weather conditions) using the Dark Sky API.

The syntax is very simple:

use DarkSky;

$forecast = (new DarkSky($latitude, $longitude))->forecast();

You can get the forecast, or do the "time machine" requests for multiple dates:

$weather = (new DarkSky($latitude, $longitude))->timeMachine(['1986-05-11', '1987-05-11', '1988-05-11']);

Multiple requests are executed concurrently for you, so you don't have to bother with that. Also, the response body is automatically gzipped for you for better performance.

You can change the language, the units system and other parameters on the fly, or in your config file.

Please, check the readme file for more information:

https://github.com/dmitry-ivanov/laravel-dark-sky

Hope it would be useful for someone!

@kfirba Hey! I'm using the same solution, but PHPStorm Doesn't understand that syntax and showing "expression expected" error for such syntax.

Do you know how to learn IDE that it's okay? Thanks!

@gbrits I'm using the same solution, however my IDE (PHPStorm) doesn't like that syntax, it shows an error - expression expected.

I have Laravel plugin, Blade and Vue - all enabled.

Does anyone know how to learn PHPStorm that it's okay?

Thank you for your kind words, @Loach, @m7vm7v !

Hi, guys!

I've just finished new package - for grabbing Wikipedia (or another MediaWiki) page.

Base usage is very simple:

use Wikipedia;

echo (new Wikipedia)->page('Donald Trump');

It grabs a page with the images, galleries, audio and video files and returns HTML in the specified format. It can be plain HTML, Bulma or Bootstrap (3 and 4).

Also, an information about grabbed page can be retrieved. Such as id, title, page status, etc.

Please, see readme for more info: https://github.com/dmitry-ivanov/laravel-wikipedia-grabber

Hope it would be useful for someone!

Hi, guys!

Laravel 5.4 released, and testing api changed, so 5.3 tests are no longer supported without backwards compatibility package: https://github.com/laravel/browser-kit-testing

So, after migrating my project to 5.4, I've started to remove browser-kit-testing dependency, and migrated my tests to Dusk. I've done with a few tests and saw that a speed is a really slow compared to BrowserKit. So, I've changed my plan and I've tried to fix my tests according to the new 5.4 api, but there are not all assertions implemented in 5.4. Even such simple things as "assertSeeLink" are absent.

So, I have a situation when my simple project tests are running ~8 sec with BrowserKit can't be migrated to 5.4 http testing api, and probably can be migrated to Dusk - but with such a slow speed, which makes it not interesting for me.

From the other hand, I don't want to have that "backwards compatibility" dependency, and I understand that the same question would be relevant for the new 5.4 projects. Any thoughts?

Thanks and have a great day!

Hi there!

I've created a package, where I'm collecting Laravel-specific testing helpers and asserts. For example, methods for environment emulation, methods to run console commands directly through the object, different types of assertions - assertCollectionsEqual, seeInDatabaseMany, seeInSchedule, etc.

New helpers and assertions are welcomed! https://github.com/dmitry-ivanov/laravel-testing-tools

Hope it would be useful for someone.

Hi there!

Sometimes it's needed to check all of your database queries.

You can achieve this in a different ways:

• listen db queries via DB class;
• add separate method in your AppServiceProvider;
• use one of the extensions or packages, for example, Laravel DebugBar;
• etc;

It's pretty simple task, really. But, that copy-paste process, or using of the heavy packages is boring. I've created very simple package just for db profiling: https://packagist.org/packages/illuminated/db-profiler https://github.com/dmitry-ivanov/laravel-db-profiler

It enabled only for local environment. It supports http and console applications both. Use vvv request param, or -vvv option to turn it on. Please, check readme for more details.

Hope it would be useful for someone! Thanks and have a great day!

Hi!

Let's pretend you have a package. And you want some class from your package would be available in a simple way, through class alias (as facade). The common solution is just to add an alias to config/app.php in aliases array:

    'aliases' => [

       // ...
        'FooBar' => My\SuperPackage\FooBar::class,

    ],

Now you can use FooBar like this:

FooBar::doSomething();

But, the bad thing that people using your package have to add those aliases by themselves.

The good thing is that can be done automatically in your service provider:

use Illuminate\Foundation\AliasLoader;
use My\SuperPackage\FooBar;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function register()
    {
        $this->app->booting(function() {
            $loader = AliasLoader::getInstance();
            $loader->alias('FooBar', FooBar::class);
        });
    }
}

Hope it would be useful for someone! Thanks and have a great day!

Odessa, Ukraine

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

In your package's service provider, you can use:

use Illuminate\Console\Scheduling\Schedule;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function boot()
    {
        $this->app->booted(function () {
            $schedule = app(Schedule::class);
            $schedule->command('foo:bar')->everyMinute();
        });
    }
}

Hi, everyone! Hi, @JeffreyWay!

Thanks for your work, videos are really awesome! As a proposition - it would be great to have some SEO series here, at Laracasts.

After creating a project (and we do have series here at Laracasts, which are covering that process fully, from the moment of buying a domain to a production), so after creating a project - everyone would have that question. What a hack is SEO, and what should I do now? What are at least "must have" basic steps at this direction, and what should I do in future?

Hope that other people would vote for that request too. Thanks and have a great day!

Actually, as it was expected there is no correct answer on this question. All depends on situation. Sometimes it useful to have a constant, and there are definitely some benefits of that. But sometimes, it is not needed and simple string literal is okay.

Maybe the count of usages and the scope of usages are the criteria to make the choice.

Anyway, you have to find your golden mean which is suitable for you and your projects.

@jimmck Ah, got it! Sorry, but I don't actually understand why would you ever need such custom composer script?

Helper function provides an ability to call artisan command in background from code (from another process).

For example, your foo command needs to call your bar command, but actually doesn't care about the results of bar execution and doesn't need to wait till bar is finished. So, you call bar in background, and foo is ready to go on immediately.

In the case of command line call - you just open terminal, run command. Want some more - just open another terminal and call another one. I don't understand what would be a difference between simple call from command line and "call in background" from command line? You have to be in some process to make "call in background" have sense.

@jimmck Sure, it is available through composer. Just run in your project:

composer require illuminated/helper-functions

And all of existing helper functions (including call_in_background()), and the new ones - would be available in your project.

Please, see readme for more information: https://github.com/dmitry-ivanov/laravel-helper-functions

Hi there!

If you need to call artisan command from code, you can use Laravel Artisan facade class: https://laravel.com/docs/5.2/artisan#calling-commands-via-code

But what about background calls?

I've made a simple helper function for that.

call_in_background() Calls artisan console command in background, with optional before and after sub-commands:

call_in_background('foo');

// "php artisan foo" would be called in background

call_in_background('foo:bar baz', 'sleep 0.3');

// "sleep 0.3 && php artisan foo:bar baz" would be called in background

If you'd like to use it, this helper is available in my package with other helper functions: https://github.com/dmitry-ivanov/laravel-helper-functions https://packagist.org/packages/illuminated/helper-functions

Hope it would be useful for someone. Thanks and have a great day!

Hi there!

Just wanted to write few words about a package I've just released: https://github.com/dmitry-ivanov/laravel-console-logger https://packagist.org/packages/illuminated/console-logger

Often I'm working with a projects, which have a lot of scheduled commands (cron jobs). These crons can be very simple - just make some trivial operations with database, generate some report, etc... But also, they can be really complex - some interaction with external services, getting data from them, pushing data to them, etc.

So, it's very useful for me to have some kind or text logs (separate logs for each command) and, which is even more important, - some kind of monitoring tool, which would notify me if something went wrong.

This is exactly what illuminated/console-logger package do.

After installing package through composer, all you have to do is use additional trait in your command class and specify notification recipients. Package is fully customizable and has a lot of cool features, such as: logs separated by commands and dates, auto-rotation (only latest 30 files are stored), global error handler (it would catch ALL types of possible errors - even PHP notices for you), email notifications with optional deduplication if needed, ability to save notifications to database, set of useful info added to your logs, context support with nice dumps, etc....

I've tried to describe all of these features really good in readme, there are a lot of examples, and even notification screenshot example. So, please, check it for more information. Feel free to ask me if you would have some questions about the package.

Hope it would be useful for someone. Thanks!

Yep, a lot of trash today)

Hi there!

As we all know, there are some mechanisms in Laravel, which help you to prevent schedule tasks overlapping: https://laravel.com/docs/5.2/scheduling#preventing-task-overlaps

You can just use withoutOverlapping method, and this will protect you from running more than one instance of your schedule command at the same time.

But what if someone call your protected schedule command from console manually? withoutOverlapping method wouldn't help in such situation. It handles just scheduled executions of the command.

So, I've found that it is a problem for one of my projects, and I've created a small package, which will prevent Laravel console commands overlapping, no matter from where it was called. Few times manually, from schedule + manually, etc. No matter - it just protects your command from overlapping.

Here are the links, already available through composer via packagist: https://github.com/dmitry-ivanov/laravel-console-mutex https://packagist.org/packages/illuminated/console-mutex

See readme please, but generally speaking, all you have to do is use Illuminated\Console\WithoutOverlapping trait in your console command class:

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminated\Console\WithoutOverlapping;

class Foo extends Command
{
    use WithoutOverlapping;

    // ...
}

And now your command is protected against overlapping:

➜ php artisan foo:bar baz
Command is running now!

Also, there are several strategies for preventing overlapping:

• file (default)
• mysql
• redis
• memcached

See readme for more information.

Hope it would be useful for someone!

@tfevens, as @martinbean said - probably you get an error because you didn't specify full class name (with namespace included).

According to my User class example, which is in the first post of the topic, that works fine in views:

@if (\App\User::ROLE_ADMIN == 'admin')
    Ridiculous check works! :)
@endif

But let's try to return to the main theme of the topic :) Are string literals in code always bad? We're NOT talking about integers, just strings please)

PS: Actually, I'm still using them, always) But just want to hear more opinions from other developers.

I've just added timestamps to my package migration filenames by myself. So, my package migrations look like:

./database/migrations/2016_05_11_000001_migration1.php
./database/migrations/2016_05_11_000002_migration2.php
./database/migrations/2016_05_11_000003_migration3.php
...

Here is the code of your package service provider:

<?php

namespace Foo\Bar;

class ServiceProvider extends \Illuminate\Support\ServiceProvider
{
    public function register()
    {
        $this->mergeConfig();
    }

    public function boot()
    {
        $this->publishConfig();
        $this->publishMigrations();
    }

    private function mergeConfig()
    {
        $path = $this->getConfigPath();
        $this->mergeConfigFrom($path, 'bar');
    }

    private function publishConfig()
    {
        $path = $this->getConfigPath();
        $this->publishes([$path => config_path('bar.php')], 'config');
    }

    private function publishMigrations()
    {
        $path = $this->getMigrationsPath();
        $this->publishes([$path => database_path('migrations')], 'migrations');
    }

    private function getConfigPath()
    {
        return __DIR__ . '/../config/bar.php';
    }

    private function getMigrationsPath()
    {
        return __DIR__ . '/../database/migrations/';
    }
}

Then, in a project, which is using your package (after composer require foo/bar is done, of course) - add in config/app.php:

'providers' => [
    // ...
    Foo\Bar\ServiceProvider::class,
],

And now you can publish your config and migrations:

php artisan vendor:publish --provider="Foo\Bar\ServiceProvider"

Hi there!

A lot of developers (including me) - are using consts for almost each primitive (int, string) in the code. When it comes to integers (so called "magic numbers") - it perfectly makes sense, but I have some doubts according strings. I understand that consts are more IDE-friendly, they are protecting me from typos, it's easy to find, to change... But how often actually do we need to find, or change them? How often do we create const with the name which exactly match it's value? Does it makes sense?

For example:

class User extends Authenticatable
{
    // ...
    const ROLE_ADMIN = 'admin';
    const ROLE_MODERATOR = 'moderator';
    const ROLE_USER = 'user';
    // ...
}

class AdminsController extends Controller
{
    public function __construct()
    {
        $this->middleware('role:' . User::ROLE_ADMIN);
        // vs
        $this->middleware('role:admin');
    }
}

Without consts code can be more simple, clear and readable. Do we need that strict practice? I've searched through Laravel code - and it has only 19 declared class consts. Taylor is mostly using string literals in Laravel.

I understand that this is the question of preference, and probably there is no just one correct answer - all depends of situation. But can we at least say that using string literals instead of consts overuse is NOT a bad practice? Are there any "best practices"? It would be very interesting to hear @JeffreyWay here, if possible.

Thanks and have a great day!

Thanks for your replies!

So, my final solution is using simple TaskRequest for validation only, and separate TaskPolicy for authorization:

class TasksController extends Controller
{
    // ...
    public function edit(Task $task)
    {
        $this->authorize($task);
        return view('tasks.edit');
    }

    public function update(TaskRequest $request, Task $task)
    {
        $this->authorize($task);
        $task->update($request->all());
        return Redirect::route('tasks.index');
    }

    public function destroy(TaskRequest $request, Task $task)
    {
        $this->authorize($task);
        $task->delete();
        return Redirect::route('tasks.index');
    }
    // ...
}

class TaskRequest extends Request
{
    public function authorize()
    {
        return true;
    }

    public function rules()
    {
        return [
            'name' => 'required|min:10',
            'description' => 'required',
        ];
    }
}

class TaskPolicy
{
    use HandlesAuthorization;

    public function edit(User $user, Task $task)
    {
        return $user->owns($task);
    }

    public function update(User $user, Task $task)
    {
        return $user->owns($task);
    }

    public function destroy(User $user, Task $task)
    {
        return $user->owns($task);
    }
}

Which is also gives a beautiful authorization checks syntax for the views:

@can('edit', $task)
    <a href="{{ route('tasks.edit', [$task->id]) }}">Edit</a>
@endcan
@can('destroy', $task)
    {!! Form::open(['route' => ['tasks.destroy', $task->id], 'method' => 'delete']) !!}
        <button type="submit">Delete</button>
    {!! Form::close() !!}
@endcan

PS: You can find more info about this solution (acl) in laravel documentation: https://laravel.com/docs/5.2/authorization#policies Or here, at Laracasts (ACL, last four lessons): https://laracasts.com/series/whats-new-in-laravel-5-1

Hi there!

I have typical simple resource controller - TasksController. Each Task is owned by a User. I want to protect Tasks from being updated or deleted NOT by their owner User. Also, there are some simple validations for tasks form.

So, here is my solution:

class TasksController extends Controller
{
    // ...
    public function store(TaskRequest $request)
    {
        $task = Auth::user()->tasks()->create($request->all());
        return Redirect::route('tasks.index');
    }

    public function update(TaskRequest $request, Task $task)
    {
        $task->update($request->all());
        return Redirect::route('tasks.index');
    }

    public function destroy(TaskRequest $request, Task $task)
    {
        $task->delete();
        return Redirect::route('tasks.index');
    }
    // ...
}

And my TaskRequest class:

class TaskRequest extends Request
{
    public function authorize()
    {
        if (empty($this->task)) {
            return true;
        }

        $user = Auth::user();
        return $this->task->isOwnedBy($user);
    }

    public function rules()
    {
        if (request()->isMethod('DELETE')) {
            return [];
        }

        return [
            'name' => 'required|min:10',
            'description' => 'required',
        ];
    }
}

So, performing authorize checks by a common injected TaskRequest object, but I'm not sure is that a best solution? I don't really like unused variable TaskRequest $request in TasksController@destroy. And I don't really like that mix of logic in my TaskRequest class.

Any ideas? Thanks and have a great day!