[#13073] - Create a JMenuItem object to represent menu items in the JMenu API
- Fixed in Code Base
- 6 Dec 2016
- Medium
- Build: staging
- # 13073
- Diff
- mbabker:JMenuItem
- Success continuous-integration/drone the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success JTracker/HumanTestResults Human Test Results: 2 Successful 0 Failed. Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #13054
Summary of Changes
Menu items as loaded by JMenuSite (as this is the only JMenu class actually loading anything) will now be loaded into this new JMenuItem object instead of a plain PHP object. The object's properties are based on the query used by JMenuSite instead of a direct mapping to the #__menu database table as this is actually what is used in runtime.
All of the class properties are public (emulating the existing behavior) except for the parameters. This is a protected field and through a magic getter and setter still allow read/write access to this field. This is required to allow the menu item parameters to be "lazy loaded" into a Registry instance only when the parameters are actually needed. Thus, the auto-conversion of all parameters in JMenu::load() is removed.
The magic getter and setter, and extending from JObject, are deprecated and should be removed with 4.0. These measures are in place now to retain B/C with the existing plain PHP objects that are currently used by the API. The parameters field has a dedicated getter and setter method which should be used instead and we should discourage adding additional undocumented properties to this object going forward.
Testing Instructions
When the site's menu tree is loaded into JMenu, the data should continue to be loaded correctly but instead of being mapped to a stdClass object, each item in the $_items array should now be a JMenuItem object. The params field should stay in the form of a JSON string until the menu item's parameters are explicitly read, at which time it will be converted to a Registry object.
Documentation Changes Required
N/A
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries |
Please don't hijack threads like this.
(Database is on SSD, and duplicating menu items via PHP code to go up to 6000 menu items)
load() (on a JMenuSite object)
-- Before patch: 2.710 seconds, With 600 parameters for 6000 menu items
-- Before patch: 0.498 seconds, With <100 parameters for 6000 menu items
-- After patch: 0.045 seconds
Speedup 10x - 60x
Also since languageFilter system plugin onAfterInitialise does:
$router = $this->app->getRouter();
- which eventually loads all menu items (and their parameters)
onAfterInitialise times
Before patch: 2,704 seconds, with 600 parameters per item for 6000 items
Before patch: 0.625 seconds, with<100 parameters per item for 6000 items
After patch: 0.181 seconds
Please note that if you display all 6000 menu items in large menu in your page
or if you display a page with all menus
- then all parameters will be forced to be loaded, and you will get no benefits
I have tested this item
Tested using PHP 7.0.13
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13073.
I have tested this item
p.s.
@ggppdk can you share your script for create tons of menu items?
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13073.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/13073.
| Milestone |
Added: |
||
rdeutz
- | Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-12-06 22:30:58 |
| Closed_By | ⇒ | rdeutz |
This change should benefit all AJAX requests too,
since ... getMenu() called as a result of some code inside onAfterInitialize event,
will no longer cause a slow down on website with many menu items
Thanks Michael!.
A side note to this large menu performance and so I hijack this for an idea about modules too.
As now when you have many site languages and for example you have one and several modules that render info data from a component you have a site design with same module in the same positions with the same content data but with different language heading/text/title/description before/after etc then you have to set up new modules for each of these languages that are exactly the same?
Let me know if I have missed something that you can do different to that problem instead of creating a copy of every module of your page, write a new module title to every languages you have on your Joomla site.
So what it means is that if you have 7 languages you have to create 7 different modules just for changing the title to map to each language instead of just have one module that can do exactly the same but with different language title text.
What I would like to have is o n e module that is in the same position with the same data input but where you can have language settings of Titles for a ”master module” like:
Title (fr-FR): French title of module
Title (es-ES): Spanish title of module
Title (it-IT): Italian title of module
Etc
Wouldn’t that be better and maybe also for performance bcs the module can be cached but the extra title text can be dynamically updated for each language?
Advanced module mgr doesn’t have this feature. Maybe some modules can have this option(s) for being a master module with these settings?