Up-to-date jQuery
Permalink
Can I propose a policy relating to the update of core scripts from third parties from 5.7 onwards.
This proposal is based on the fact that updates to core libraries, mainly jQuery, are very rarely reflected in releases of Concrete5. For example release 5.6 still uses a version of jQuery that is 2 years old.
The issue here is that developers building new sites typically want to include some of the latest gadgets to improve features, ease of use and styling to name a few. In a vast majority of cases these will rely on versions of jQuery that of significantly newer than in the current C5 release.
I realise that this will have an impact on developers upgrading their sites, however I feel it is generally easier to update the small amount of code on a site that desperately needs to move forward to a new release of C5 than it is trying to fix problems that cause serious headaches trying to shoehorn in new gadgets requiring say jQuery 1.9+ and finding lots of problems in ccm_app for example.
This is not a problem that is unique to C5. I have tried many CMS systems over the years and they all fail with essentially the same problem. You generally cannot use up to date third party gadgets because the core files in use by the CMS or usually very outdated.
We are already heading in that direction with 5.7. The version of jQuery in the current build is still 1.9. Why? You have an opportunity here to get the core updated to work with the very latest version, once done keep it up to date at significant milestones. If nothing major is released then consider doing it every 6 months to keep pace.
Fresh new sites using fresh new ideas and technologies is the life blood of web application development. Don't stifle it all with old tired code that is out of date before you release it.
Many thanks.
This proposal is based on the fact that updates to core libraries, mainly jQuery, are very rarely reflected in releases of Concrete5. For example release 5.6 still uses a version of jQuery that is 2 years old.
The issue here is that developers building new sites typically want to include some of the latest gadgets to improve features, ease of use and styling to name a few. In a vast majority of cases these will rely on versions of jQuery that of significantly newer than in the current C5 release.
I realise that this will have an impact on developers upgrading their sites, however I feel it is generally easier to update the small amount of code on a site that desperately needs to move forward to a new release of C5 than it is trying to fix problems that cause serious headaches trying to shoehorn in new gadgets requiring say jQuery 1.9+ and finding lots of problems in ccm_app for example.
This is not a problem that is unique to C5. I have tried many CMS systems over the years and they all fail with essentially the same problem. You generally cannot use up to date third party gadgets because the core files in use by the CMS or usually very outdated.
We are already heading in that direction with 5.7. The version of jQuery in the current build is still 1.9. Why? You have an opportunity here to get the core updated to work with the very latest version, once done keep it up to date at significant milestones. If nothing major is released then consider doing it every 6 months to keep pace.
Fresh new sites using fresh new ideas and technologies is the life blood of web application development. Don't stifle it all with old tired code that is out of date before you release it.
Many thanks.
Additionally there is an issue report up to get the latest and greatest of bootstrap in.
https://github.com/concrete5/concrete5-5.7.0/issues/30...
I think that you'll find that a lot is being done to get everything up to speed in 5.7.
https://github.com/concrete5/concrete5-5.7.0/issues/30...
I think that you'll find that a lot is being done to get everything up to speed in 5.7.
Thanks to mlocati and exchangecore, both of these posts are extremely good news.
However my main point has still to be taken on board.
We need to have a positive drive, an ambition, to keep these core files up to date. Having 2 year old versions of jQuery and Bootstrap, as in the current production release, simply does not cut it in a rapidly changing technology market.
Having the latest available version included in the next release is great but this needs to be matched with a real desire to keep this process running and the libraries continually up to date. If you don't do this then the same old problem will start to creep in several months from now when new versions of the main libraries have been around for a few months and C5 hasn't kept up.
It would be great to include a clause as part of a mission statement for C5 declaring that 'We will endeavour to keep all core libraries, such as jQuery and Bootsrap, as up date as possible with all releases of Concrete5' or similar. Putting it in writing as a defined goal for the project would mean a lot to the community.
However my main point has still to be taken on board.
We need to have a positive drive, an ambition, to keep these core files up to date. Having 2 year old versions of jQuery and Bootstrap, as in the current production release, simply does not cut it in a rapidly changing technology market.
Having the latest available version included in the next release is great but this needs to be matched with a real desire to keep this process running and the libraries continually up to date. If you don't do this then the same old problem will start to creep in several months from now when new versions of the main libraries have been around for a few months and C5 hasn't kept up.
It would be great to include a clause as part of a mission statement for C5 declaring that 'We will endeavour to keep all core libraries, such as jQuery and Bootsrap, as up date as possible with all releases of Concrete5' or similar. Putting it in writing as a defined goal for the project would mean a lot to the community.
I hear where you're coming from, but it's not always attainable.
Take the move from bootstrap 2 to bootstrap 3 for example. If people were dependent upon bootstrap 2, you probably just broke their entire site by forcing something on them. While shiny bells and whistles are great things to have, it's really hard to justify making breaking changes to the core, especially when most things can be overridden on a site by site basis if someone wants to have their site use the latest version of package abc.
I'm going to make a bold generalization and say that a majority of the user community aren't developers, so when you are giving them the option to upgrade their site via a user interface, and then they do so and it breaks their website because they're using a theme that isn't compatible with the new version of plugin xyz, it causes a lot more harm than good. One of the main concepts behind concrete5 is that it is supposed to be user friendly, so it's a delicate balance that the core team gets final say on and we developers live with or work around.
That said, I do think that if updates can be made without causing breaking changes it would be good to strive to keep these up to date.
Just my $0.02 here.
Take the move from bootstrap 2 to bootstrap 3 for example. If people were dependent upon bootstrap 2, you probably just broke their entire site by forcing something on them. While shiny bells and whistles are great things to have, it's really hard to justify making breaking changes to the core, especially when most things can be overridden on a site by site basis if someone wants to have their site use the latest version of package abc.
I'm going to make a bold generalization and say that a majority of the user community aren't developers, so when you are giving them the option to upgrade their site via a user interface, and then they do so and it breaks their website because they're using a theme that isn't compatible with the new version of plugin xyz, it causes a lot more harm than good. One of the main concepts behind concrete5 is that it is supposed to be user friendly, so it's a delicate balance that the core team gets final say on and we developers live with or work around.
That said, I do think that if updates can be made without causing breaking changes it would be good to strive to keep these up to date.
Just my $0.02 here.
My preference would be for loading assets such as jQuery and Bootstrap to have override mechanisms, just like everything else in c5. That way, those wanting to check out an update to an asset could do so in a controlled way that would show up on an environment report and could be easily disabled.
I'm not entirely sure but maybe with the new configuration overrides Korvin was working on in combination with the asset managers this might be possible? Maybe someone from the core team could weigh in on this one? I'm not overly familiar with how the new asset managers work, but it looks like you simply register the script, then it gets put in at the appropriate location some time later, this to me seems promising that I could override a previously registered script by it's "handle" later on in the call stack, but maybe that's wishful thinking.
The assets system already in 5.7 will allow you to do this. Just re-point the jQuery pointer to a new path. In your application/config/app.php, you add:
or:
use \Concrete\Core\Asset\AssetList; AssetList::getInstance() ->getAsset('javascript', 'jquery') ->setAssetURL('/path/to/new/jquery.js');
or:
use \Concrete\Core\Asset\AssetList; use \Concrete\Core\Asset\Asset; $al = AssetList::getInstance(); $al->register( 'javascript', 'jquery', 'path/to/new/jquery.js', array('version' => '2.0', 'position' => Asset::ASSET_POSITION_HEADER, 'minify' => false, 'combine' => false));
I tried putting this in app.php but I'm getting an error
Also this file seems to return an array not sure if this is the place anymore to do this?
PHP Fatal error: Class 'Concrete\Core\Asset\AssetList' not found
Also this file seems to return an array not sure if this is the place anymore to do this?
Looks like it should be bootstrap/app.php not config/app.php
@zanedev
Here is what I found trying this on my local install.
- adding the code to app.php
application\bootstrap\app.php
Approach 1:
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/application/js/jquery-2.2.0.min.js"></script>
Approach 2: does not work
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/concrete/application/js/jquery-2.2.0.min.js"></script>
Approach 2: works
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/application/js/jquery-2.2.0.min.js"></script>
Here is what I found trying this on my local install.
- adding the code to app.php
application\bootstrap\app.php
Approach 1:
use \Concrete\Core\Asset\AssetList; AssetList::getInstance() ->getAsset('javascript', 'jquery') ->setAssetURL('/application/js/jquery-2.2.0.min.js');
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/application/js/jquery-2.2.0.min.js"></script>
Approach 2: does not work
use \Concrete\Core\Asset\AssetList; use \Concrete\Core\Asset\Asset; $al = AssetList::getInstance(); $al->register( 'javascript', 'jquery', 'application/js/jquery-2.2.0.min.js', array('version' => '2.2.0', 'position' => Asset::ASSET_POSITION_HEADER, 'minify' => false, 'combine' => false) );
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/concrete/application/js/jquery-2.2.0.min.js"></script>
Approach 2: works
use \Concrete\Core\Asset\AssetList; use \Concrete\Core\Asset\Asset; $al = AssetList::getInstance(); $al->register( 'javascript', 'jquery', 'js/jquery-2.2.0.min.js', array('version' => '2.2.0', 'position' => Asset::ASSET_POSITION_HEADER, 'minify' => false, 'combine' => false) );
- jquery-2.2.0.min.js location
application\js\jquery-2.2.0.min.js
- output
<script type="text/javascript" src="/application/js/jquery-2.2.0.min.js"></script>
Thanks for the tips! So what about when I want to replace or override an entire asset group with css as well like the select2 asset group?
I ended up with this code for replacing the asset group. A bit hackey to check the class but couldn't find another way to check the asset type they all had the same handle. Also the path to localized javascript asset is being parsed differently than the standard css and javascript asset objects.
$al = \Concrete\Core\Asset\AssetList::getInstance(); $select2AssetPointers = $al->getAssetGroup('select2')->getAssetPointers(); foreach($select2AssetPointers as $select2AssetPointer) { $asset = $select2AssetPointer->getAsset(); if(get_class($asset) == 'Concrete\Core\Asset\JavascriptAsset') { $asset->setAssetURL(REL_DIR_APPLICATION . '/js/vendor/select2/js/select2.full.min.js'); } if(get_class($asset) == 'Concrete\Core\Asset\CssAsset') { $asset->setAssetURL(REL_DIR_APPLICATION . '/js/vendor/select2/css/select2.min.css'); } if(get_class($asset) == 'Concrete\Core\Asset\JavascriptLocalizedAsset') { $asset->setAssetURL('application/js/vendor/select2/js/i18n/en.js'); } }
Seehttps://github.com/concrete5/concrete5-5.7.0/blob/master/web/concret...