Widget for showing package and core updates on the dashboard

[wuuti]

It would be nice to have widget, which shows updates for installed packages and for the core, so that you can see quickly if an installation needs to be updated. Only updates valid for your installation should be shown (in opposite to the newsfeed widget, which is quite useless). Further enhancements (along with a new internal update feature):

• automatically send an email if there is an update for the core or a package.

[wuuti]

The following code gives you an array with packages that have updates available:

<?php
/* returns an array of packages which have updates available */

/* default limit is 10, not enough for our widget */
$scriptProperties = array("limit"=>99 );
$response = $modx->runProcessor('workspace/packages/getlist', $scriptProperties);
if ($response->isError()) {
    return null;
}

$res = json_decode($response->getResponse(),true);
$results = $res['results'];
$updates = array();

foreach ($res['results'] as $p) {
    $updateResponse = $modx->runProcessor('workspace/packages/update-remote', array('signature'=>$p['signature']));
    $updateObject = $updateResponse->getObject();
    if (!is_null($updateObject) && sizeof($updateObject)>0) {
       $updates[$p['signature']] = $updateObject;
    }

}

return $updates;

/* example return value:
/*
 * Array
(
    [getpage-1.2.3-pl] => Array
        (
            [0] => Array
                (
                    [id] => 5331082662cf24022e002475
                    [package] => 4d556c77b2b083396d000c1b
                    [version] => 1.2.4
                    [release] => pl
                    [signature] => getpage-1.2.4-pl
                    [location] => http://modx.com/extras/download/?id=5331082662cf24022e002477
                    [info] => http://modx.com/extras/download/?id=5331082662cf24022e002477::getpage-1.2.4-pl
                )

        )

)

 */

[wuuti]

Not tested yet: is caching used by the update-remote processor? Seems not. Where does the caching (auto_check_pkg_updates) take place...

[MrRoco]

<?php
/**
 * Version Control

    Still to do
    - Add lexicons 
    - Make selector visible with upgrade function In Progress
    - Remove download latest button 

 *
 * Copyright 2015 by Roel Zeilstra, Sterc internet & marketing <modx@sterc.nl>
 *
 * This file is part of Version Control.
 *
 * Version Control is free software; you can redistribute it and/or modify it under the
 * terms of the GNU General Public License as published by the Free Software
 * Foundation; either version 2 of the License, or (at your option) any later
 * version.
 *
 * Version Control is distributed in the hope that it will be useful, but WITHOUT ANY
 * WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
 * A PARTICULAR PURPOSE. See the GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along with
 * Version Control; if not, write to the Free Software Foundation, Inc., 59 Temple Place,
 * Suite 330, Boston, MA 02111-1307 USA
 *
 * @widget Version Control
 */
/**
 * Version control widget
 *
 *
 *
 * @author Roel zeilstra, Sterc internet & marketing <modx@sterc.nl>
 *
 * @widget Version Control
 *
 */

$currentVersion = '';
$select = '';
$latest = '';
$button = '';

$curr = 'v'.$modx->getOption('settings_version');

$url = "https://api.github.com/repos/modxcms/revolution/tags";

$ch = curl_init();
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1); 
curl_setopt($ch,CURLOPT_HEADER, false);
curl_setopt( $ch, CURLOPT_USERAGENT, "revolution" );
curl_setopt($ch,CURLOPT_CONNECTTIMEOUT,1);
$content = curl_exec($ch);

if(!curl_errno($ch)){
        $versionArr = json_decode($content);
} else {
        return 'Can not retrieve latest version';
}

curl_close($ch);

//print_r($versionArr);

$currentVersion = '<strong>Current version:</strong> MODX Revolution '.$curr.'<br/>';

if($versionArr[0]->name != $curr) {
    $versionsC = count($versionArr);

    $latest = '<strong>Latest version:</strong> MODX Revolution '.$versionArr[0]->name.'<br/><br/>';

    // $select = 'Select the version you want below<br/>';
    // $select.= '<select>';

    // for($i = 0; $i < count($versionArr); $i++){
    //     if($versionArr[$i]->name != $curr){
    //         $select.= '<option value="'.$versionArr[$i]->zipball_url.'">'.$versionArr[$i]->name.'</option>';
    //     } else {
    //         $i = count($versionArr);
    //     }
    // }
    // $select.='</select>';

    $button ='<a href="'.$versionArr[0]->zipball_url.'" type="button" id="ext-gen100" class=" x-btn-text">Download latest MODX from Git</a>';

    return $currentVersion.$latest.$button;
} else {
    return "Current version ".$curr;    
}

[wuuti]

Ok, mixed it together. Another edge case: if you already downloaded the update for a package, but forgot to install it, you won't be warned. Will fix that tomorrow and add some nice iconized style for the widget.

[wuuti]

Ok, here we go:

TODOs:

• package it up
• the Download-Button should download to server, not to local client (needs connector/processor)
• discuss about styling issues
• combine with push messaging system to not only show on dashboard

[bequadrat]

:+1: Looks really promising! Great job!

[christianseel]

Looks awesome! Just really small thought: it might better to have gray-ish icon backgrounds and make the icon green. That way it won't take too much attention if everything is ok.

[JensWolff]

Really nice :+1:

[wuuti]

Will do different styling ... already discussed that with @rtripault and removed the red background at the packages - because package updates are not that important in comparison to core updates. btw: currently it is hard to decide if a package update is necessary (because security fix inside) or not (only bug fixes or enhancements). Until there is some meta-field in the package manifest the only way may be to look if the previous version was marked as deprecated - but this seems to be a workaround. I would like to have a flag in package metadata stating "this is a security patch". This way we could enhance automatic updates of packages to something like "do them automatically for security patches, but ask me/inform me for all others..." What do you think?

[JensWolff]

Cool idea @inreti :+1:

[wuuti]

According to Romain's personal "lectures" :-) for me in setting it up the right way, I will give my best to implement this:

• create a processor which is responsible for checking the core updates (this would indeed be a core functionality IMHO and not bound to the widget package - but as the widget package is intended to be an intermediate update enhancement until anything gets into the core, it will be part of the package)
• create a processor which downloads the setup zipball
• create a connector triggered by the download button

Some other topics touching the "updater" we discussed during the CCC (enough to open up some more wishlist-issues!):

• implement a simple broadcast mechanism to inform about core updates on every manager page (and not only on the dashboard which may not be visited ever even by administrators). Therefore the update check has to be done on a regular base (it is currently done when the dashboard widget is run). I need some kind of scheduling mechanism for that - cron would be the tool of choice, but this is not possible in simple webspace environments. How to solve? Trigger the scheduler when a manager action is done (login not enough - you can keep being logged in for weeks depending on the session lifetime) and then check for updates only once a day? (configurable of course)... It would love to make it independent from manager: e.g. if the scheduled version check detects an update for your concrete instance, send out an email to all users having the permission "receive_system_messages" - this way your instances would inform you about their need to be updated.

We should have an advanced, configurable messaging system, which handles a lot more: warnings in the frontend (e.g. for unpublished views, see #69), information about updates, warnings about insecure setup or missing requirements, handling other channels like emailing to users ("maintenance window", "lock-down") or messaging to monitoring dashboard, probably a hooking mechanism to build custom channels (slack, sms, irq, whatever). By using "channels" there we will also be able to include (and maybe resurrect) the already existing user messaging system, which currently has a poor niche existence unnoticed and unused by almost every modx user.

If in the near future Romain's implementation of the update procedure comes out, it should not be that hard to mix that all together in order to get an enterprise-ready update and system maintenance subcore.

btw: I also would like to have something for the package manager like "Download and install all updates at once" as another intermediate step for (semi)automated updates. Does anyone know if package update can be done unattended (esp. if there are installation options)??? As I only consider updates of previously installed packages, setup options should have been set already...

uups... to much ideas popping up now. We should schedule the next CC (PCC, ACC?) in the next 3 months to keep on fulfilling our wishes!!!

[Mark-H]

Is there any code for this out there somewhere?

[sottwell]

After building Revo from github - not reporting as a bug, just saying. What would be nice would be if it determined it was a build and used a different color, maybe blue, and had a message something like "Custom build {version}.

[wuuti]

Congratulations Susan, you are the first bug reporter :-)

Sure, that is weird. I feared this would happen but couldn't figure out any circumstances how one could produce that. You did it with the github build... The fix is quite easy, I will build it into the upcoming 0.2.6b release next week!

Thanks for your report.

Jens