An Idea: Additional Admin Menu for Additional extensions!

I've got an idea and will look into implementing it when I get the first chance, for an additional Menu in the Admin Area named Extensions. This menu will provide a dynamically generated list of additional controllers and extensions to OpenCart.

The advantage would be that extenstion developers such as myself, could release new extensions that require no changing of the admin menus. This means that one extension wont cancel out the admin menu links for another.

The proposed solution would involve the writing of either an XML or PHP file  in addition to the other files for the extension that can load the extension into the admin menu..

This method would be a big step forward for making opencart alot easier to install extensions into without the need to know some level of PHP in order to make the admin menu link to all installed extensions.

Workflow:

Extenstion XML or PHP Extension Descriptor File Admin Link(s) to aditional Extension Extensions Menu in Admin Area Controller to read all XML/PHP files in folder "addons" (or something along them lines)

Thoughts are appreciated,

-Dave

Hey no fair you beat me to it.

I wondered why some menus aren't loaded from the database. When people include a new contrib, they could add a line of sql to add a new menu that would use a group to place itself in the appropriate menu category, and then point to the correct page that uses their controller.

LOL.. well how about we do it rather than dream of it then??

an additional DB table would be viable too 

-Dave

I agree. This needs to be done asap.

Let me run some ideas by you all, let me know if you see anything wrong with the design that I may have overlooked:

1. Take the default admin menu and shove that into a db table. All the values that are in that menu.php file would be queried from the db, but dynamically. ("select * from menu_table"). The main levels would likely be static tho: (Admin, Catalog, Extensions, Customers, Reports, maybe an "Extras" for misc stuff)

The Table structure could be like this:
http://www.unbannable.com/menudb.jpg[/img]

2. The menu.php then would parse that data for the javascript to read. I believe it should be transparent to the actual javascript stuff, since all of this would be happening on the server-side.

3. The database entries would have the href to the controller file that it uses, so new contribs would include sql to point the new menu to the proper controller.

4. Any new menus would be in effect as soon as they were inserted, let the order of the menu be automatic. Doesn't really matter what order they are in, just that they are under the correct menu.

One thought, not sure how sub-sub menus would be done, so maybe pull the "Configuration" menu out of the "Admin" menu and make it be its own category.

Any thoughts?

Thinking more about it, the main levels should be in their own table and crossreferenced at their main id. Then you could have dynamic main levels as well, could also do language based stuff in there.

http://www.unbannable.com/menudb_mainmenu.jpg[/img]

I tend to agree with the cross-referenced tables.. It will be so much beeeter from all aspects of writing modules.. one downside with the sql method will likely mean we need to add a controller to install the extensions

This could prove a good thing though in that you can also easily remove them later on as well as install extra payment gateways and the likes via the same installation controller. It'd be a simple Upload form in admin where you can upload a zip file containing the directory structure and an install.php that can insert necessary tables etc..

-Dave

the zip package idea would be ideal, but for starters there could just be a simple "sql file upload" controller that lets you browse to the .sql file and hit go and it executes the query. Similar to the backup/restore controller.

I'm going to work on finishing up my search_history_log contribution (saves searches to database) and then after that I will start working on porting it all over to sql code.

I think the first step is to just get the default menu using the database. Then we can work on adding the import sql code and stuff.

Ok. Here is my sample sql file

I changed it slightly to avoid using nested sub menus.

- Pulled Localisation into its own parent menu
- Pulled the configuration and user stuff into the root Admin menu.

Take a look and see if it makes sense or if you think there is another way to do it.

I went a little deeper with the menu files and realized something pretty obvious... there is absolutely no reason for this menu to be javascript based. This menu could be done 50x easier and more manageable using simple css. There are a billion examples out there.

Plus if you have javascript disabled on your browser, you don't even see the admin menu. There is no point in that.

I'd say first we need to find a perfectly accessible and crossplatform compatible css drop down, and we can simply redesign the menu completely and get rid of the unnecessary javascript

A menu should be html based and css will design it to be more menu-like. This way its always available.

Is there a reason you ever switced to the javascript menu in the first place? What was there before?

Following all this with great interest and it all seems to make sense.  How much backward compatibility would there likely be for existing 3rd part extensions/modules.  Would two versions of these need to be maintained - i.e one for folk using a well-established/modded store to install using the traditional method and one for a 'virgin' store that used the proposed installation/menuing method?

Great to see creativity at work and things unfolding 

Chris

Qphoria wrote: Ok. Here is my sample sql file

I changed it slightly to avoid using nested sub menus.

- Pulled Localisation into its own parent menu
- Pulled the configuration and user stuff into the root Admin menu.

Take a look and see if it makes sense or if you think there is another way to do it.

http://www.unbannable.com/menu_sql_1.zip

Since there is a need to support sub-menus, too, we might as well consider a more generic database design which would support any number of levels in a nested menu structure, and which obeys the table naming conventions of OpenCart:

Table 'menu':

menu_id title icon href
............
............



Table 'menu_to_menu':

parent_menu_idchild_menu_id
......
......

Hey, whatever works. 

Ok. I'm done with the first beta of the database-based admin menu.

• Javascript menu has been removed.
• It is a simple css menu design, and can be skinned however you want it. I added a menu.css to keep it all separate.
• This menu design "WILL" support nested menu levels, however, for the first pass, I opted to just make it all one level. I pulled the Localisation stuff into its own top menu, and the user/usergroup stuff into the regular Admin menu. It works fine for now
• Database supports language id for multiple languages via the database.
• Keep in mind this is just some default css, I haven't designed it to look like the old menu, but will before release.
• Path structure changes:
  -- moved the images out of the javascript/jscookmenu folder and into the template/default/image/menu folder.
  -- Added a menu.css file to the template/default/css folder.
• Files modified:
  -- admin/template/default/module/menu.tpl
  -- admin/extension/module/menu.php

You can demo it here: http://unbannable.com/opencart/admin/index.php
user: demo
pass: demo

No longer will there need to be a extension/menu.php or menu.tpl or language/menu.php file changes. And no more trying to edit that massive menu file and not break other menus. Now to add a new menu you simply add a sql insert statement and it's there. I am using the table example I showed above, with the addition of a language id column.

Let me know what you think or what else should maybe be added.

I know we will need to add an "Install sql file" module to make sql patching easy. I'd like to get some developer input on this too for official release with either 0.8 or 1.0. This is something that really needs to be done officially to set the standard.

No comments? IMO, This is like one of the biggest limiters of OpenCart at the moment. The sooner we can get this into the Official 0.8 or 1.0, the smoother the contrib process will be.

I'd say this plus the override feature would be the main goal to get into OpenCart to start getting it really moving forward with proper contributions. The sooner we can make things easier for the store owners, the more people will want to use & contribute to OpenCart.

These 2 items will get rid of manual edit contribs and add fully modular "drop-in" contribs that won't break other people's contribs.

Hopefully when Daniel is done with all the 0.8 coding, he can come back and peruse the forums a bit more.

JNeuhoff wrote: Since there is a need to support sub-menus, too, we might as well consider a more generic database design which would support any number of levels in a nested menu structure, and which obeys the table naming conventions of OpenCart:

Table 'menu':

menu_id title icon href
............
............



Table 'menu_to_menu':

parent_menu_idchild_menu_id
......
......

I'm giving this method a shot, tho I knew before I started that I was not really sure how I was going to loop through the data to create my menu.

I'm a bit stuck on both the loop as well as how to display it.

- I could pull each menu item, and do a query for each item in the menu_to_menu table and match all child_menu_ids that match my parent_id. But that would be a lot of db queries

- I could pull all the data  back into an array. But the same fundamental as the above would apply, but I'd just be looping through the array looking for matches multiple times.

** Neither of the above really give me any levels tho, so I'm not sure how I would display the data even after I got it all in order.

- I could pull all the menus with and for the full range of parent ids from menu_to_menu, set each to a level, but I'm still not sure how I'd add more to a level and display it.

- I could possibly build a level path from the menu-to-menu table, and explode the "_" for each level, but I think that might be overkill.


Any one got any tips?

I've attached the sql file to show the structure.

Well I realize the one major ingredient in doing multiple nested levels is having some sort of "path". So I was trying to think of Admin menus like categories. But there is a fundamental problem.

Categories are inserted manually from the Admin area by the admin himself. During insertion, the path is created based on its current path plus the new category id (actually insert_id).

But since the Admin Menu will be sql created by someone else, they won't know if you've made any changes to your menu structure, which means your paths might not line up the same. So while they could hardcode the path based on the assumed location of the default menu, it might not work if your path has been changed.

So the Tree class API won't work without a path value. I am trying to figure out a way to create a path on the fly, but I'm stuck. It seems it would be some ridiculously repetitive loop to go through all the menus, get their parent id, then go through them again to see if their parent id has a parent id, and loop over and over all the way up. But I'm not sure if its feasible to do that.

Another thought would be to do a db query per level, but we still don't know the level without having some path

So anyone got any ideas?

One idea could be to have a structured php "admin menu importer" controller that would take the sql and apply the path check on it like the category controller does. But I was trying to keep it simpler and have just the sql import add the menu.

Well I found one possible menu class that might work. But in all the examples I've seen, there are multiple db queries. I guess that is just the reality of it. I will try to make something using that.

I'm giving this method a shot, tho I knew before I started that I was not really sure how I was going to loop through the data to create my menu.

I'm a bit stuck on both the loop as well as how to display it.

The best way to go about things is to read the whole menu_to_menu table in one go and then recursively iterate through it in an attempt to build a nested UL + LIs structure. Once we have nested ULs we can use CSS magic to display it. I did something similar with OpenCart categories, see http://www.vcsproducts.com.au , no need for client-side Javascripts. If you like I could e-mail you my code I used for generating nested categories, and you could adopt it for the nested menus.

Oh I'm anti-jscript for menus anyway.
Sure I'll take a look.
PM'd you my email

Qphoria wrote: Oh I'm anti-jscript for menus anyway.
Sure I'll take a look.
PM'd you my email

Just sent you an e-mail with some sample code.