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.

ianfoulds
View Replies:
mlocati replied on at Permalink Reply
mlocati
exchangecore replied on at Permalink Reply
exchangecore
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.
ianfoulds replied on at Permalink Reply
ianfoulds
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.
exchangecore replied on at Permalink Reply
exchangecore
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.
JohntheFish replied on at Permalink Reply
JohntheFish
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.
exchangecore replied on at Permalink Reply
exchangecore
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.
andrew replied on at Permalink Reply
andrew
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:

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));
zanedev replied on at Permalink Reply
zanedev
I tried putting this in app.php but I'm getting an error
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?
zanedev replied on at Permalink Reply
zanedev
Looks like it should be bootstrap/app.php not config/app.php
MrKDilkington replied on at Permalink Reply
MrKDilkington
@zanedev

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>
zanedev replied on at Permalink Reply
zanedev
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?

'select2'                  => array(
            array('javascript', 'js/select2.js', array('minify' => false, 'combine' => false)),
            array('javascript-localized', '/ccm/assets/localization/select2/js'),
            array('css', 'css/select2.css', array('minify' => false))
        ),
zanedev replied on at Permalink Reply
zanedev
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');
            }
        }