This PR does 2 things.

1. It renames the generic admin middleware to backpack.base.admin

2. It adds a guard, additional middleware (which can be customised), and config items

This means that if you set 'separate_admin_session' => true in the config, users and admins can have separate sessions, so they can be logged in as a different user on the frontend to the admin.

Merged this PR https://github.com/Laravel-Backpack/Base/pull/141 into a branch, so we can work on it a little bit more.

I've already implemented all of @lloy0076 's comments regarding spacing, docblocks, etc.

Made a few design improvements to make AdminLTE look less outdated (compared to other premium admin themes):

• bigger texts
• more space

Also:

• added Gravatar instead of placeholder image with letter;
• cleaned up sidebar so there are less elements;

This new design is introduced as an "overlay" (a new css file) I called "bold". Since these changes are very subjective, I expect other people to want to create their own overlays, and easily drop them in all projects to get their preferred look-and-feel.

What do you guys think? Better/worse than before?

Similar design to the 3.4 revamp, but using CoreUI instead of AdminLTE. I found this CoreUI was the only free Bootstrap 4 Admin Panel HTML Theme that was easy to work with, and provided a reasonable amount of building blocks (basically all of Bootstrap's plus a sidebar). And trust me, it took MONTHS to take this decision. In the process, I've tried the top 5 free admin panel themes, and even got to implement like 80% of the features for 2 of them (AdminLTE v3 and Tabler). But they each had stuff that annoyed me. I consider the HTML theme you're working with very very important in admin panels, so I decided to scrap weeks of work and start again. Fortunately CoreUI is a keeper, in my opinion.

However, I found its default design underwhelming, so I went ahead and layered my design preferences on top of CoreUI. The result is Backstrap, a free HTML template that I hope more people will use, even outside of Laravel.

Need guidance how best to actually implement this functionality.

usage

use \Backpack\Base\BaseServiceProvider as Backpack;

public function setUp()
{
    Backpack::enqueueAsset('css', 'blockui', '/css/blockui.css');

    Backpack::enqueueAsset('js', 'jquery-ui', '/js/jquery-ui.js', ['jquery']);
    Backpack::enqueueAsset('js', 'angular-sortable', '/js/ng-sortable.js', ['angular']);
    Backpack::enqueueAsset('js', 'angular', '/js/angular.js', ['jquery']);
    Backpack::enqueueAsset('js', 'blockui', '/js/blockui.js',['jquery']);
}

I've added the functionality needed for a project, which will also help developers who want to add non conflicting input types to their code, however I've implemented it as a Trait on the BaseServiceProvider - which I'm pretty sure is not the best way to do this, however I do not know how you're meant to do something like this in Laravel, so feedback on how to implement this feature correctly would be lovely :)

This allows for various theme options. While I suggest that we only support adminlte by default to avoid further update and such once we get a 'marketplace' type place setup themes should be included on there and could be downloaded etc. Takes less work from the core backpack team and spreads more to the community to help contribute, expand, etc. perhaps even get a category on themeforest and such.

Added two new helpers both return strings:

backpack_view($view, $package = 'backpack') { // }
backpack_theme($view, $package = 'backpack') { // }

• backpack_view(): This allows for us to get just the view, and we can define a package such as crud but defaults to backpack.
• backpack_theme(): Gets the theme to be used based on the new config option of backpack.base.theme (defaults to 'adminlte')

First Part of making bootstrap themable.

Themable option for backpack/base:

• Default Admin LTE
• Optional: CoreUI (theme colors ("skins") coming soon)

This PR should be backwards compatible, if no theme is set within the base it will default to the generic location of backpack of vendor/backpack/base.

note: currently working on a themable for Backpack/CRUD but would love some feedback on this to proceed.

Based off https://github.com/Laravel-Backpack/Base/issues/86 here is a starting point for an edit profile function.

This adds a template, route and controller for an "Edit Account" functionality, by default it comes with the stock laravel auth fields. can be seen under /admin/edit-profile

It can be extended from the users application folder and the view modified/validation changed etc.

Heres simple screenshot of it

and the change password functionality

If you change your User model to use another field that email to authenticate, you can't use BackPack. (In my case, I use Adldap2 to login with AD username) You need to update login.blade.php to allow username instead of email field.

separated head, main_header and scripts to new blades, added support for adminlte original login page style for auth blades

example of auth pages

Register Page

Login Page

Email Page

This adds the ability to add widgets from the controller. Widgets are content blocks that can look&work in any freaking way :-). Their syntax is similar to CRUD fields/columns/filters/etc, because at their core they're just blade views.

Widgets can be useful to add:

• charts
• notices
• extra content

Widget sections

The default layout has two widget sections where you can push cards:

• before_content
• after_content

For example, this is how you can add content in the Dashboard, before and after the main hero unit:

/**
     * Show the admin dashboard.
     *
     * @return \Illuminate\Http\Response
     */
    public function dashboard()
    {
        $this->data['title'] = trans('backpack::base.dashboard'); // set the page title
        $this->data['widgets']['before_content'] = [
            [
                'type' => 'card',
                'wrapperClass' => 'col-sm-6 col-md-4',
                'content' => [
                    'header' => 'Some card title',
                    'body' => 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis non mi nec orci euismod venenatis. Integer quis sapien et diam facilisis facilisis ultricies quis justo. Phasellus sem <b>turpis</b>, ornare quis aliquet ut, volutpat et lectus. Aliquam a egestas elit. <i>Nulla posuere</i>, sem et porttitor mollis, massa nibh sagittis nibh, id porttitor nibh turpis sed arcu.',
                ]
            ],
        ];
        $this->data['widgets']['after_content'] = [
            [
                'type' => 'card',
                'wrapperClass' => 'col-sm-6 col-md-4',
                'class' => 'card text-white bg-primary text-center',
                'content' => [
                    // 'header' => 'Another card title',
                    'body' => 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis non mi nec orci euismod venenatis. Integer quis sapien et diam facilisis facilisis ultricies quis justo. Phasellus sem <b>turpis</b>, ornare quis aliquet ut, volutpat et lectus. Aliquam a egestas elit.',
                ]
            ],
        ];

        return view('backpack::dashboard', $this->data);
    }

Result:

However, this is a pretty simple view. I expect all views to have the before_content and after_content widget sections, but more complex views could have more widget sections. For example:

• all CRUD views could have before_heading, after_heading;
• CRUD's List view could also have before_filters, after_filters, before_table, after_table;
• etc

Of course, you can also push widgets into those sections from the view. For example, your dashboard.blade.php could look like this:

@extends('backpack::layouts.top_left')

@php
$widgets['before_content'][] = [
        'type'        => 'jumbotron',
        'heading'     => trans('backpack::base.welcome'),
        'content'     => trans('backpack::base.use_sidebar'),
        'button_link' => backpack_url('logout'),
        'button_text' => @Laravel-Backpack/community-members backpack::base.logout'),
    ];
@endphp

@section('content')
@endsection

Arguably, this is an even better way of using widgets - since the presentation logic will be contained within the views, and the views alone.

How to create or overwrite a default widget

Similar to CRUD fields:

• you can add new widgets by creating a file inside resources/views/vendor/backpack/base/widgets;
• you can overwrite default widgets by creating a file inside resources/views/vendor/backpack/base/widgets;
• JS and CSS can be used in the blade file by pushing to the existing stacks (before_styles, after_styles, before_scripts, after_scripts);
• you can use widgets from a different directory or package, by mentioning a different viewNamespace, for example:

        $this->data['widgets']['after_content'] = [
            [
                'type' => 'card',
+               'viewNamespace' => 'package::widgets',
                'wrapperClass' => 'col-sm-6 col-md-4',
                'class' => 'card text-white bg-primary text-center',

                'content' => [
                    // 'header' => 'Another card title',
                    'body' => 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis non mi nec orci euismod venenatis. Integer quis sapien et diam facilisis facilisis ultricies quis justo. Phasellus sem <b>turpis</b>, ornare quis aliquet ut, volutpat et lectus. Aliquam a egestas elit.',
                ]
            ],
        ];

Widget types

In this first draft, there's only one widget, card. It outputs a simple Bootstrap card with a heading. You can change how it looks by manipulating class names - both widgets in the screenshot above are using the card widget.

Of course, more default widgets are needed for this feature to be useful. Hopefully, Backpack developers will be also create custom widgets, and share them with the community. Here's what I believe would be some useful widgets - let me know what you think.

MUST

• [x] small_number
• [ ] small_pie_chart
• [ ] small_line_chart
• [ ] small_bar_chart
• [x] card
• [x] alert

SHOULD

• [ ] line_chart
• [ ] bar_chart
• [ ] pie_chart
• [ ] doughnot_chart
• [ ] radar_chart
• [ ] polar_area_chart

COULD

• [ ] carousel
• [ ] accordion (aka collapse)
• [x] div (to group one or more widgets into a div)
• [x] jumbotron
• [ ] tabs
• [ ] progress_bar
• [ ] breadcrumb

WON'T

... idk ...

Feedback needed

Feedback anyone? Is widgets a good name? Previously I called it "cards" but it felt odd that "cards" was the name of the feature, but also one of the "cards". Confusing. Sounded to me like "widgets" is a better name, because it's more broad, but I never particularly liked this word - makes it sound generic.

Do you mind that it doesn't have a Facade, that you add the widgets by creating simple arrays that get passed to the view? Or does this just make it easy to understand how it works? If it were to have a Facade or helper, what would it be? Widget::section('before_content')->add($widgetDefinitionArray)?