Concept #2
Comments
… it was in front-end. Removed unnecessary admin specific layout added earlier as it is so far same as original edit.php, may be added back when needed. Remove page specific meta data fields from backend component type menu items. For now disable/unsupport association for backend menu items. Disallow change of client id for existing menu items, unexpected conflicts may occur if allowed so better be safe. Ref to #2
…isting Joomla backend menu. These are to be used for testing during upgrading menu module. language keys are not yet translated. Translation will be done as we are ready with most new or modified language keys application wide. Backend menu items does not require all those parameters as that with front-end menu items. Therefore segregated entire menu item xml for backend/frontend. Ref #2
…. Other options will be the menu-type and will cause us to load from database. Ref #2
* bootstrap option * valid html &-> & * Fix no-user button * for no-user the value was null
…nu item edit form, for item that belongs to large menu) (joomla#11628) * Remove unused left join in getOptions for menuparent form element * Replaced unneeded group by with distinct * fix joomla#11628 for postgresql (#2) in postgresql don't work as it is now , it give an **SQL ERROR** for the `ORDER BY` clause field used `a.lft` must be in the select list of fields when the `SELECT` use `DISTINCT()`
… (joomla#12291) * Cleanups, fixes and a bit of optimizations for site/components batch #2 - com_contact Note: This is a single commit bundling all types of changes, since PR joomla#12261 which had detailed commits, was rejected as a whole * oops ;)
…z. 'main' and 'menu' Allow explicit filtering by protected menu type choices in menu items list view. Not limited to #__menutypes table entries only. Unfiltered list still excludes those menu items. (B/C ok) Menu items created during installation of a component are now saved as published. When unpublished we won't load it in customised menu's component menu container. They will still be loaded irrespective of state as previously when preset is in use. (B/C ok) Home page can now be set one per client instead of one overall. Menu module only loads item from 'main' and 'menu' type menu items when requested for component menu items. This filter is now required because we are now going to have other custom menu types for backend which should not be included. Ref #2
… separator type menu items created due to exclusion of certain menu items based on various conditions. Populate menu items loaded from db into the AdminCssMenu object for final rendering. Load new installed components menu items dynamically under the specified menu item with “components container” flag. Any unpublished menu items from the protected menutypes (viz. “main” and “menu”) will be skipped. When loading from system preset menu items, these components menu items are all included regardless of their published state. (B/C ok). Ref #2
|
@brianteeman I have done with the major implementation part. There may be some unnoticed bits and pieces left over. I'd like you to have a review on the work done so that we can move forward and prepare it for a PR. The overall database change is: ALTER TABLE `#__menu_types` ADD `client_id` INT NOT NULL AFTER `description`; |
|
Great - I will review it this weekend On 11 November 2016 at 10:03, Izhar Aazmi notifications@github.com wrote:
Brian Teeman |
|
Thanks! 😄 |
|
I downloaded your branch admin-menu-manager and installed it with the learn joomla sample data
|
|
When I go directly to a menu i get
|
|
Sorry, that is not yet ready to install. You'd need to add that column Or you can just skip joomla install process and import the 2 SQL files On 13 Nov 2016 4:37 p.m., "Brian Teeman" notifications@github.com wrote:
|
|
Ran the manual query
Which two? |
|
I have a "different" admin menu now |
|
The 2 SQL files are directly under the root of the Joomla in my branch. Go to menu module (admin) edit page. You'll see a new dropdown to choose One is said system preset that resides in /preset folder in mod_menu. On 13 Nov 2016 6:28 p.m., "Brian Teeman" notifications@github.com wrote:
|
|
found them now - thanks On 13 November 2016 at 13:06, Izhar Aazmi notifications@github.com wrote:
Brian Teeman |
|
|
I didn't get what you mean by 1 & 3.
2 - Sure.
3 - To my understanding, yes we can move components various sub menus at
random places. If this is what you meant.
|
|
Well for now no 3PD component would have that till this feature is rolled For native components I've added those manifests already. I'll write the detailed doc in the PR as much as I can. So do you suggest any more changes/fixes (other than resetting the preset |
|
If you have done the manifests for core components then great. I didn't see On 13 Nov 2016 8:26 p.m., "Izhar Aazmi" notifications@github.com wrote:
|
|
Yes, certainly the front-end and backend options must not mix up or
interfere. I took care of that mostly. Any missing bits however needs tests.
And all those menu items in the replica are created using the menu manager
itself, that utilizes those manifests. The com_menus links, com _categories
links are the examples.
Good night :-)
|
|
I can see now that you are using the seperator - its the alias that was confusing me thinking about it though I think creating xml for the admin isnt the best way forward as this means that all 3pd will need to add it. Instead you could just read the values from the extensions database. Everything is already there so no need to create anything extra - this will ensure that ALL existing extensions do not need to be updated |
|
@brianteeman I got referred here from the backend template thread, just wanted to say I am in favor of this concept. Customizable admin features are a top request from our users and it opens the door for many other concepts as well. I'll take a look at this in more detail as soon as I have a chance. |
|
Still needs a bit of work before it's ready I think but its something I've
wanted to see for a long time - I've tried to code it myself but failed
hence we are here.
|
|
I know, but it's helpful for me to know there is support for the concept. We can find people to code it if the support is there. This is a concept that I've had in mind for a very long time and I've got a lot of ideas as well. I'm still catching up from JWC, but this one of the main interface changes I want to start working on as soon as possible. |
|
Getting the code done has been the hardest part. I've been talking about it
for years and several developers have said they will work on it but I had
is the first to actually do anything and so far he has done a lot which is
great
Izhar has done a lot of work already and I am sure he will be able to get
it ready for sharing and then it can be improved upon from a ui / ux
perspective.
|
|
It is complicated, far beyond my skills personally, but I honestly believe if we can implement this type of solution it will help us solve a number of other interface and workflow challenges. There is lot we could do with this. |
|
Thats why I have been pushing for it for about 3 years ;) On 16 November 2016 at 22:42, Cliff notifications@github.com wrote:
Brian Teeman |
|
I've been pushing this all year myself, and I think now is the right time to get into it since we're getting into everything. It's pretty clear that our users want customization options for themselves and for their clients. Some people don't want to change anything back there because it's what they know, but customization could also include making it look the exact same way it does now if you wanted to. If it ties into the template system and ACL it could offer a lot of control across many different scenarios. It's all about providing flexible options and this opens the door to many possibilities in my opinion. I am 100% in favor of this approach. It is very technical and has many other implications we need to consider, but there is a lot upside. I'm all for finding solutions to make this work. |
Not seen anything, anywhere where was it ? One feature that Izhar (I hope I am getting your name correct) hasnt coded (yet) is the ability to reset the menu to the installed setup. I think this could be quite important for users who mess it all up. Definitely you should read all the comments on the original issue joomla#5492 There were a lot of good comments as well as a complete answer to those people who had blocked this in the past |
|
I've never been able to get it past the discussion phase, and I can't code it myself so none of it is out there. That's why I was happy to find this thread. I've got a ton of notes and sketches, we'll put our ideas together from here and see what we can do to move it forward. |
… their install manifest for admin menu manager menu link types. This provides ability to create links for then without requiring them to add layout manifests. Hence, full B/C solution. Ref #2
…state, dropping implicit inclusion of joomla#10657 improvement. Ref #2
… their install manifest for admin menu manager menu link types. This provides ability to create links for then without requiring them to add layout manifests. Hence, full B/C solution. Ref #2
|
@brianteeman 😄 Yeah, you got my name absolutely correct... Izhar Aazmi (Izharul Haque Aazmi)
I skipped it intentionally. To be able to reset to "default" setup is the same thing as using a "preset". Why code something dynamic to write something static. Hence I switched to offer a "preset" choice in the module manager's Choose Menu dropdown. I had the idea to offer multiple presets too, but I skipped that as well, at least for now. I hope I did right, did I?
Yes, I read that all. And before sending a PR, I'll definitely also cross reference my implementation with that. However, I request you to bear with little differences in approach. 🤗 Please! |
|
Name - glad I got it right. I know how annoying it is when people get names Patience - I am just excited we are finally making progress with this idea. On 17 November 2016 at 10:23, Izhar Aazmi notifications@github.com wrote:
Brian Teeman |
|
@brianteeman Can you please help me adding database changes in this patch. I am afraid that I may miss a place or more. |
|
Not 100% sure I understand your problem
|
|
I've never created a PR that introduces a DB change. I need to add the
change into the code but not sure how and where.
|
|
Two places
(Sent from my phone so I might have the paths wrong) |
|
I see the install sql in: 3 db types each: Is that all? Filenames for update sql are beginning with version number and then a date. What version number should I use to prefix today's date? |
|
yes thats correct On 19 November 2016 at 11:07, Izhar Aazmi notifications@github.com wrote:
Brian Teeman |
* Some improvements in tests #2: - fix callable name mismatches - removed closing tags (also one that's in other PR, to not clash) - removed loop that does nothing * Revert removal of empty loop, as $i is decremented in the while statement
|
Closing as joomla#13036 was merged. Thanks @brianteeman. |
* Added client id column to menu_type table. Allow creating and editing of "menutype" records with client_id = 1 Add client_id filters in menu and menu items list views Sync menu type filter and client_id filter allowing only menu type in the URL query parameter (B/C) Both Lists now also filtered by client id. Client id selection updates the menu type list options to show choices only for that client id TBD: Reserved menu types: main & menu * In modal list view we currently hide client_id filter and show only site menu types, will be updated once we have more clear vision. Menu type assignment to backend mod_menu config from both menu manager and module manager. Though that is not functional within the module itself. * Add/edit menu item redirect with clientId from list filter. Load menu item form based on active client id Menu type dropdown choices limited to active client id value Show menu-item-type choices (modal) trigger with client id parameter in the url Switch edit layout based on client id * Menu item type loading from component metadata xml or mvc not identifies backend and frontend application separately. Not yet able to load menu item type from backend so returns empty list. Front-end is still intact and unaffected. * Edit menu item and create menu item set to follow client id and menu type value consistenty. When creating menu item alias, the referenced menu must also belong to same client id. Client id field removed from form, this should be auto-calculated from the menu type when saving. * Adding layout metadata xml in backend to reference menu item types as it was in front-end. Removed unnecessary admin specific layout added earlier as it is so far same as original edit.php, may be added back when needed. Remove page specific meta data fields from backend component type menu items. For now disable/unsupport association for backend menu items. Disallow change of client id for existing menu items, unexpected conflicts may occur if allowed so better be safe. Ref to #2 * Created each backend menu items using menu manager as a replica of existing Joomla backend menu. These are to be used for testing during upgrading menu module. language keys are not yet translated. Translation will be done as we are ready with most new or modified language keys application wide. Backend menu items does not require all those parameters as that with front-end menu items. Therefore segregated entire menu item xml for backend/frontend. Ref #2 * [a11y] Protostar back to top (joomla#12446) * [a11y] Protostar - back to top link * Oops Andre was right * add anchor for non-js enabled browsers * Restructure mod_menu to load preset menu items as an option (default). Other options will be the menu-type and will cause us to load from database. Ref #2 * Disallow editing and set to home of protected menu type menu items viz. 'main' and 'menu' Allow explicit filtering by protected menu type choices in menu items list view. Not limited to #__menutypes table entries only. Unfiltered list still excludes those menu items. (B/C ok) Menu items created during installation of a component are now saved as published. When unpublished we won't load it in customised menu's component menu container. They will still be loaded irrespective of state as previously when preset is in use. (B/C ok) Home page can now be set one per client instead of one overall. Menu module only loads item from 'main' and 'menu' type menu items when requested for component menu items. This filter is now required because we are now going to have other custom menu types for backend which should not be included. Ref #2 * Load menu items from databases in correct hierarchy. Remove any extra separator type menu items created due to exclusion of certain menu items based on various conditions. Populate menu items loaded from db into the AdminCssMenu object for final rendering. Load new installed components menu items dynamically under the specified menu item with “components container” flag. Any unpublished menu items from the protected menutypes (viz. “main” and “menu”) will be skipped. When loading from system preset menu items, these components menu items are all included regardless of their published state. (B/C ok). Ref #2 * View manifests for menu item type and related language key updates. ref #2 * Minor mistake fix. * Translate menu item titles in list view. Ref #2 * Reset the preset menu structure to be same as the current J37 branch state, dropping implicit inclusion of joomla#10657 improvement. Ref #2 * Allow the existing components to leverage the menu/submenu entries in their install manifest for admin menu manager menu link types. This provides ability to create links for then without requiring them to add layout manifests. Hence, full B/C solution. Ref #2 * Minor fix * Remove temporary dev phase files * Preparing for PR, database and install script updates. Ref #2 * Minor fix * Codestyle fix * CS fix * Don’t sort menu items * Sort lang keys Allow ‘component’ as first level alias in admin menu items Fix lang key Remove ‘home’ setting from admin menu items * apply in hathor * menu item alias check for site only * Post merge fixes. * Fixes as suggested by @infograf768 1. Group menu types by client id in lists and default admin menu 2. Hide association tab for admin menu items. 3. Hide client id filter for association mapping modal. * Add recovery mode for menu where the selected admin menu does not contain link to module manager and/or menu manager. * minor bug fix * Remove assoc column for admin menu items. Make recovery mode message more straight forward. Change radio to toggle buttons.
* Add a fieldset in the component config to support disabling the debug users and groups view. The defaullt is to on * Add code to read the params from the config.xml If not set then it defaults to ON Change the IF statement use to turn on the display of the debug link to use the param instead of the JDEBUG * Add code to read the params from the config.xml If not set then it defaults to ON * Change the IF statement use to turn on the display of the debug link to use the param instead of the JDEBUG * fix the params IF statement * Fix the params fallback * Add language strings * Add missing Cancel button from toolbar (replaces PR14384) Add missing Options button from toolbar * Simplify param check * Simplify param check #2 * change the strings from debug to advanced * fix toolbar permissions check * Update config.xml * Update default.php * Update default.php
* Type safe string comparison of strings in plugins - second iteration - some more string comparisons - some bool - some int * Fixed two bugs introduced in previous commit (one involving multiple comparisons) * Missed a comparison. Thanks @shur! * Reversed type safe comparison, as it turns out, that the type of the value is not guaranteed. * Reversed type safe comparison (#2), as it turns out, that the type of the value is not guaranteed. * Reverted this one to not clash with @laoneo's refactoring efforts
The Joomla admin menus are one of the few things in Joomla that you cannot truly customise. The location of the menu items is as a result of arbitrary decisions made many years ago.
Why have all the components under one menu?
Wouldn't you like to perhaps separate the utilities from the content creation components.
Why is content a top level menu item?
It is just a component. I am sure the logic was that it was a component that is used so often that it deserves its own place. But what if you don't use com_content and use com_seblod - or you even have a photo gallery as your main content creating component.
Wouldn't it be great if you could build and customise the admin menu however you want? I am sure many people have had this thought as well but have you ever looked at the code that generates the menus in the Joomla admin? If you have then I am pretty sure that you will have run away scared.
I am proposing that we switch the entire admin menu system to be database driven and customisable via an admin menu component. Thecomponent will allow people to move menu items, create and remove top level menus etc.
Backwards compatibility
By default without any modifications the site should look exactly the same.
The big BC issue to address is where do the menu links for NEW components that a user installs get created. The problem is that the user could have removed the "components" top level menu. I would suggest that just as we have to flag a top level menu item as default homepage in the frontend we would have to flag a top level menu item in the admin as well for the default location that new component menu items are created.
Multilanguage issues
Unlike the frontend I would suggest that the admin menu manager can only manage ONE menu and not one per language. Instead of user created menu titles as in the front end we can continue to use the strings from the language files. This will ensure that a site with multiple admin languages installed will only need to manage one menu and that everything will be in the same place in all languages.
Database issues
Currently the jos_extensions table contains all extensions so we would just need to update that table to contain the id for the menu link
[copy pasted from https://github.com/joomla/issues/5492]
The text was updated successfully, but these errors were encountered: