Voyager: [Discussion] Separation of Voyager Menu Builder and Database into Components

[maiorano84]

I think this project has a ton of potential, and it's been exciting to see how much traction this has gained over the past few weeks.

I think it would be nice to start separating out pieces of functionality that users may choose to include with a fresh installation of Voyager, or ignore for barebones solutions.

There are a few parts to this that I think we should consider, and if enough people agree, I (and of course other interested developers) can start branches that addresses each piece:

1. The Core Elements - I feel that the primary parts to Voyager should include only User Management (Users and Roles, Codenamed "Crew"). The rest can be moved into a more modular system for accepting Dashboard Widgets ("Decks") and Modules ("Rigs").
2. Decks - I love how clean the Dashboard looks, but it would also be nice to allow registration of custom Dashboard Widgets as well. I propose adding a registerDeck method to the Voyager facade that accepts the appropriate Contract (Interface) as a dependency, handle the appropriate business logic, and render the appropriate partial view if applicable.
3. Rigs - Plugins/Modules/Extensions have helped just about every developer flesh out their Admin Panel or CMS in order to bolt on pieces of functionality they might need to meet client expectations. I would think that rather than assume that developers would simply want to register BREAD-based database records, there might be more robust solutions that should include custom views and functionality. Similar to Decks, I propose adding a registerRig method to the Voyager facade that accepts the appropriate Contract as a dependency, handle the appropriate business logic, and render the appropriate view if applicable.

With all of that in mind, I think that the Menu Builder, Database, Media Manager, and (possibly?) Settings features can be separated out as Rigs that users may choose to include or exclude as needed.

Posts, Pages, and Categories should also be moved to a Scaffolding feature that may be skipped during the installation process.

With all of this in mind, I feel like this will help add more flexibility to the project, specifically for users who may want more of a drop-in Admin solution rather than having to start from scratch.

With all of that said, I'm thinking that this is starting to move towards a CMS solution rather than simply an Admin panel, so if that deviates too far from the intent of the project or if this is too ambitious, I'm sure we can pare back some of the extra "stuff" and focus on getting a stable v1.0.0 off the ground.

Thoughts?

[marktopper]

I really support this idea.

[marktopper]

However I see one problem.

Currently the admin page uses the menu builder for it's own menu.
So we need to make that work without the menu builder but still be customizable.

[maiorano84]

@marktopper Absolutely correct. Part of the separation of the Menu Builder would also include an existence check (ie: Menu::has('admin')), and I'm thinking that down the road it can leverage a Driver system to allow menus to be defined either at the Database level (current), Configuration level (personally preferred), or even as simple Blade partials.

Conversely, we may be able to look into this package as a third-party dependency, though we probably want to avoid being tied down to too many dependencies apart from Laravel and Doctrine.

[marktopper]

@maiorano84, in my eyes, I do not really see why the admin panel is using a menu builder for it's own menu.

So I prefer to see this separated, and then the menu builder could be created at as a component for front-end in mind and not the admin panel in mind.

[fletch3555]

@marktopper, I agree about the Voyager menu. I'm going to take a shot at breaking that menu out and "hard-coding" it instead.

[marktopper]

@fletch3555, the thing is that it must still be extendable, so that people can change the menu. Since enabling a so called _"rig"_ like the menu builder, should add the Menu builder to the admin menu.

How would the best approach for this be? Any ideas?

[marktopper]

Maybe it should be hardcoded like @fletch3555 was talking about, but have some checks whether or not to show a certain item, like the menu builder.

[fletch3555]

I'm thinking of having the static menu ('Dashboard', 'Posts', 'Pages', 'Users', etc.), which each of the entries only showing up if it's valid (route exists, model or DB table exists, etc.. not sure on this yet). With a "Custom" dropdown (like 'Tools') only shown if a special menu exists (such as '_admin').

How's that sound to you @marktopper? I think that meets the criteria we've discussed.

[marktopper]

Sounds like a good approach @fletch3555, since currently I do not see the use for adding/removing items from the admin menu.

[tnylea]

@maiorano84 I absolutely love this idea.

I agree 100%. I don't want Voyager to become a CMS, instead I want it to be an admin. I think your suggestions would help in moving that forward.

1. The Core Elements - I love this idea of having core elements and I absolutely love the codename "Crew" for the user management.

2. Decks - Awesome. I think this would add a lot of value

3. Rigs - I like the idea of having extensions/modules/plugins; however, we'll want to be careful that this doesn't turn into a wordpress kind of plugin solution. Just because there are so many crappy WP plugins out there and many of them cause havoc on the site including load time and bad queries.

I think you are spot on with the direction I'm hoping Voyager goes.

Let's start adding these functionalities :)

@marktopper is currently merging pull requests and other issues.
@fletch3555 will be doing the same as well.

Looking forward to seeing this package become the ultimate Laravel Admin package.

Thanks for everything guys.

[Frondor]

IMHO, Voyager doesn't need the table creation feature, I'm not sure about it without migrations and relationships... The logic on this should rely only on modules or packages. I like this idea, and I like the of "extensions" more (Although I'm good with common packages, and some Voyager's facade to register things).
Also, I would like to make "dashboards for our clients" as well.. So they are able to administrate the website we make for them, from voyager itself, by setting permissions for each functionality. Let's say, a "manager" role which doesn't have access to menu items (and its component) if not specified by an administrator.
Registering widgets is also a great feature, I'm actually doing it on my own admin panel.
Also, one thing I don't like about how Voyager handles the Menus, is the database handling. In my opinion, we should't have been querying the database to get our menus on each page, but register them instead just like we would register widgets. And "make them" on boot, and/or blade templates with its own syntax.

[akazorg]

Interesting discussion in here, I thing the all idea is great, Decks, Rigs/Extensions, and menus should be hard-coded (@fletch3555 any progress on this?), maybe we should keep in mind about User Roles and the Menu? I'm sure you're thinking on that, but I didn't read about it.

Regarding the CMS topic, Voyager already includes Pages, Blog and Categories, @tnylea I understand you want to keep this an admin, I also love the approach of Voyager, but I'm sure that many people will use it for a CMS. Anyway, IMHO it is working already.

Keep up good work, I'll keep contributing with PRs [[ ]]

[tnylea]

I am going to close this issue for now in order to organize tasks to be completed for version 1.0 release. Please feel free to re-open, but we are now using hooks which are going to be included in version 1.0 to support the RIGS implementation.

Thanks.

[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.