[#18451] - Feature Request - Joomla Head
- Closed
- 30 Oct 2017
- Medium
- Build: 3.X
- # 18451
I am not sure if this is the Feature Request area, but I could not find any where else
When using:
<jdoc:include type="head" />
The minimum you get included with a fresh install is :
<script src="/media/jui/js/jquery.min.js?c147e56e085ff914b460b9cdddab4d30" type="text/javascript"></script>
<script src="/media/jui/js/jquery-noconflict.js?c147e56e085ff914b460b9cdddab4d30" type="text/javascript"></script>
<script src="/media/jui/js/jquery-migrate.min.js?c147e56e085ff914b460b9cdddab4d30" type="text/javascript"></script>
<script src="/media/system/js/caption.js?c147e56e085ff914b460b9cdddab4d30" type="text/javascript"></script>
<script type="text/javascript">jQuery(window).on('load', function() {new JCaption('img.caption');});</script>
In some cases I would like to have control over this, maybe in an admin panel of the core as the class that loads this is in the core
Many work with companies that are very strict about SEO (page speed) and where ever we can save size and loading of data would be great.
The idea that we can manage a bit more the front end library loading and create a lighter version of Joomla is something that has been talked about for a long time. I think by creating a light weight Joomla it would open up Joomla to a great API admin for applications (web and others) and mobile devices. We use it for managing native mobile content etc, but had to alter some of the core files that load stuff in the head (so now we have to stay at that version).
Thanks
joomla-cms-bot
- 
You can already do this if you want in your template which is the correct place to do this by unsetting and setting what goes in the head. For examples see this gist https://gist.github.com/proweb/4634662
I guess you're asking for this:
joomla-cms/administrator/templates/atum/index.php
Lines 62 to 66 in f34dac1
@brianteeman I understand the unset, I have used this method before, but I find it hacky, unclean.
@dgt41 had not seen that solution, I will take a look thanks
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18451.
The unset trick is essentially what would be happening under the hood if we had a core UI for managing this stuff. Because you have to remove the elements from the media arrays after they're set. Unless we're going to write an even more complex API where the document class' add methods are aware of a blacklist and don't even set the media to begin with.
I am going to close this. The solution is to use unset and a UI for this would cause more problems than it is worth and potentially cause issues with many extensions along the way that expect files to be loaded in a specific order. If you want to have fine control and have the knowledge and skill to work out what goes where and why and how to fix it if it breaks then unset is an acceptable solution
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-10-30 17:31:57 |
| Closed_By | ⇒ | brianteeman |
Your best bet for this type of control is to either write your own plugin or to use one of the existing plugins that help manage this.
Joomla core doesn't arbitrarily load any media on its own. All of the media loads dynamically come from the active extensions on a page and what they say to load (i.e. com_content loads the JCaption behavior usually, the core templates load jQuery and Bootstrap, and the helper methods for loading media also ensure their inherent dependencies are loaded).
So it'd be pretty impractical to try and add a UI that efficiently lets a user control what media can or cannot be loaded. A lot of this logic is heavily dependent on code variables that would be set with the request (the URI, active menu item, etc.). The plugins that are out there do a good job of helping manage this from a UI level, but to do it correctly would introduce a what I would personally consider too complex of a screen to be user friendly (there are a lot of scenarios that you have to account for to do this right and it's honestly a fair bit more complex than the existing UI config we have for modules and deciding when to render those).