[Purpose of v0.11] Removal of widgets configuration

[marktopper]

Widgets might be removed as a configuration and become a stackable object.

Currently the widgets can changed using the configuration file like:

'widgets' => [
    [
        'name'  => 'Post',
        'icon'  => 'voyager-news',
        'model' => TCG\Voyager\Models\Post::class,
        'url'   => 'admin/posts',
        'image' => '/images/widget-backgrounds/03.png',
    ],
],

Instead it will however be turned into a stacked object with the following options.

Create widget

$widget = new Widget('widget-identifier', 'icon')
    ->backgroundColor('blue')
    ->backgroundImage('/images/widget-backgrounds/03.png')
    ->title('Title of widget')
    ->text('additional text')
    ->button('Text', 'Link');

Add widget to stack

Voyager::addWidget($widget);

Get widgets

Voyager::widgets();

Overwrite widgets

Voyager::setWidgets($widgets);

[marktopper]

Calling in @bestmomo and @Frondor for their opinion on this.

[Frondor]

Yes, I gave my opinion before accepting that PR. I didn't like that way.

Also, I've changed my mind regarding to what I replied there. I still believe each widget should have its view/template, so we have default widgets (the ones pre-installed with voyager), and user-registered ones. So if an user wants to register a Collection of widgets named 'charts' and he/she has a charts (or whatever name) BREAD, if he/she overrides the view for it, something like Voyager::getWidgets('charts') would return a collection of widgets named charts. And each one previously configured with a custom view.

We can also add default views for default widget types like templates (L5.4 components), so there's no need to create a view for each new registered widget.

But to be honest, I have no idea how the "method" to register those widgets would work :D I'll just kindly ask to TRY and not to query DB for each widget and/or widget collections. What about JSON files? or even config files are fine, but decouple the widget specific logic (to either widget's view, or widget's controllers -preferably-)

[Webpicasso]

What's about to integrate something like this? https://github.com/arrilot/laravel-widgets

Or is it already planed to integrate it in this way?

[Frondor]

@Webpicasso I'm not fan of this kind of packages but I really like the idea behind that one. It even uses widget groups, like I mentioned before as "collections" so... I like it

[marktopper]

@Frondor, really good idea to make each widget have it's own view, or have different views and handlers. Any ideas how the usage of this should look in the codebase?

[Frondor]

@marktopper to be honest, I really like arrilot/laravel-widgets usage. Because it has implemented cache functionality and widget groups which can be used by BREAD types. So we can use either that package, or a new fork if needed. If this is the case, we may need to create our own methods, facade or even Blade directive to use our own namespace to /widgets instead of Arrilot\Widgets.

php artisan make:widget ActiveUsersChart

@widget('ActiveUsersChart', ['take' => 10, 'show_button' => true])

{{ Widget::group('users_header')->display() }} (I'd like a foreach tho)

[marktopper]

Well I am open for the usage of that package, but with some customization. We could store the widgets for the dashboard on the Voyager instance somewhere.

Add widget

// Add `ActiveUsersChart` class widget to the `charts` group.
// Then they can be added from a service provider
Widget::add(ActiveUsersChart::class, 'charts', $parameters);

Display widgets

{{ Widget::group('users_header')->display() }}

[Webpicasso]

I think a widget class as in Arrilot\Widgets implemented would be also helpful to have the possibility to collect more complex data for the widget (it's like a controller).

[Frondor]

Can be... But probably will be needed to implement some plugin/extension structure for the whole package, so we can start developing this kind of "sub-packages", and decouple some of the already built-in features like database tool for example...

[marktopper]

@Frondor: Any ideas how the plugin structure for the package would work?

Then I could properly make a pull request or a fork for it.

[Frondor]

@marktopper I don't know if its a good practice, but seems handy how pyrocms handles addons aka packages or modules. They are simply packages on a custom folder. Personally, I like the way how the backend UI for each package is configured. They use an API for creating inputs from the migration file (minute 5:00). That allows you have each input type as a module/package (own repo maybe?), which is way more easy to maintain than the current messed up views.

Maybe we can have a repo for each feature (database & menu builder tools, custom posts bread, themes, etc...) and field types.

[marktopper]

@Frondor: The plugin system for Voyager (Hooks) does store all plugins in a /hooks folder.

https://github.com/larapack/voyager-hooks

There is a UI interface for this, but still in alpha.

Available packages: https://larapack.io

[Frondor]

Alright then. We can still consider the structure for field types. I'll take a look to the hooks later

[marktopper]

Created in #769

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have further questions please ask in our Slack group.