Some ideas for simple updating.

[svasti]

Hi developpers,

I just updated the dokuwiki of our CMSImple_XH Wiki and was astonished, how easy it was... Just install the new version on top of the old one. It was not even a special update version, just the normal version!

Could we do the same? May be. Now, how to handle configuration files?
The source could come without configuration or language files. Once, the programm is intalled, an initializing routine could look for configuration and language files. If it doesn't find any, it would generate these files. If it finds some, it would make a backup of them and check, if some configuration values were changed. Taking the changed values into account it would generate new configuration files.

This way the update could be simplyfied or even automated (provided changes were made only in the config files of the core). Either by uploading a new version via ftp or even later like firefox does.

svasti

[cmb]

Just install the new version on top of the old one.

And what about the file and folder permissions? IMO that's still a big problem. Of course one can configure the FTP client to set full permissions for all files (0755 resp. 0777), but I don't recommend doing so.

A few days ago I've written a small PHP script that should be able to adjust the file and folder permissions for CMSimple_XH's core (not the plugins). It has to be configured (see comments at the top of the script) and is meant to be run from the client (local webserver or cgi; I have not tested the latter). Probably you have to configure you're firewall to let the script perform it's job.

Please note that the script is only a draft, and so should not be used on a real website -- you can test it on a CMSimple_XH installation in a subfolder (adjust $rootdir appropriately).

Code: Select all

<?php

/**
 * Chmodder
 *
 * Connects to an FTP server and changes file/folder permissions for a CMSimple_XH installation.
 */

/*
 * Important settings
 */
$host = 'ftp.example.com'; // the FTP host name without the protocoll (i.e. without ftp://)
$port = 21; // the FTP port number (21 is the default)
$username = 'u12345678'; // the FTP user name
$password = 'xyz'; // the FTP password
$rootdir = 'html/'; // the root directory of CMSimple_XH relative from the FTP root
$writePermsAnybody = true; // true => 0777/0666, false => 0755/0644


/*
 * The list of writable files and folders; * means all existing files in the folder.
 */
$writables = array('cmsimple/config.php',
                   'cmsimple/log.txt',
                   'cmsimple/languages/*',
                   'content',
                   'content/content.htm',
                   'content/pagedata.php',
                   'downloads',
                   'images',
                   'templates/cmsimplexh/stylesheet.css',
                   'templates/cmsimplexh/template.htm',
                   'userfiles');



/**
 * Whether $fn is a directory.
 *
 * Note: the current implementation is somewhat hacky,
 * as the check is done by trying to chdir() to $fn.
 * I'm not aware of a better alternative.
 *
 * @param   string $fn
 * @return  bool
 */
function isDir($fn)
{
    global $ftp;
    
    if (@ftp_chdir($ftp, $fn)) {
        ftp_chdir($ftp, '..');
        return true;
    } else {
        return false;
    }
    
}


/**
 * Changes the file/folder permission of the content of $dir. Recurses down through all sub-directories.
 *
 * @param   string $dir
 * @return  void
 */
function chmodDir($dir)
{
    global $ftp, $writables;
    
    set_time_limit(30);
    ftp_chdir($ftp, $dir);
    $pwd = ftp_pwd($ftp);
    $files = ftp_nlist($ftp, '.');
    foreach ($files as $file) {
        if (isDir($file)) {
            $perms = in_array("$pwd/$file", $writables) ? 0755 : 0555;
            if (!ftp_chmod($ftp, $perms, $file)) {
                echo "can't chmod $pwd/$file<br>\n";
            }
            chmodDir($file);
        } else {
            $perms = in_array("$pwd/$file", $writables)
                    || in_array("$pwd/*", $writables)
                ? 0644 : 0444;
            if (!ftp_chmod($ftp, $perms, $file)) {
                echo "can't chmod $pwd/$file<br>\n";
            }
        }
    }
    ftp_cdup($ftp);
}


/*
 * Connect to the FTP server and change file/folder permissions.
 */
array_walk($writables, create_function('&$x', '$x = "/' . $rootdir . '$x";'));
$ftp = ftp_connect($host, $port) or die ('Couldn\'t connect to server!');
ftp_login($ftp, $username, $password) or die ('Login failed!');
chmodDir($rootdir);
echo ':-)';
ftp_close($ftp);

?>

Christoph

[svasti]

And what about the file and folder permissions? IMO that's still a big problem. Of course one can configure the FTP client to set full permissions for all files (0755 resp. 0777), but I don't recommend doing so.

After die Update dokuwiki complained and wouldn't start because of 2 missing permissions. As these missing permissions were cleary stated, they were easy to set.

Say we have a running CMSimple_XH installation. If you install over it, the old permission are still valid. So there shouldn't be a problem for updates. Only if there are completely new files, the usual error notice would suffice.

I think the permissions are a (tiny) problem only at the first installation.

[maeg]

Hi

I think the permissions are a (tiny) problem only at the first installation.

Totally agree, and with the new "Info system check" it is easy to check the most importent permissions for all website owner.

[cmb]

Hi,

If you install over it, the old permission are still valid

Is that so? I don't have much experience with FTP client (actually just a bit with FileZilla), but I'm not sure, if that's the typical way how permissions are handled.

I think the permissions are a (tiny) problem only at the first installation.

Indeed the permissions are not a problem in the first place. The typical case might be that the FTP client grants write permission to all files and folders for the FTP user (i.e. 0644/0755). This will smoothly run the site on a typical (F)CGI installation, as all files and folders are writable by the HTTP user (i.e. any visitor of the site). If PHP runs as Apache module, the write permissions won't suffice, and the system check resp. the error messages will help to figure that out. But what about files and folders that shouldn't be writable? If PHP is running as (F)CGI, any file and folder might be writable, without CMSimple_XH giving any warning message (this is simply not checked), what might result in a weakened security.

Once, the programm is intalled, an initializing routine could look for configuration and language files. If it doesn't find any, it would generate these files. If it finds some, it would make a backup of them and check, if some configuration values were changed. Taking the changed values into account it would generate new configuration files.

Isn't that nearly the same as what's currently happening with the upgrade packages (e.g. 1.5(.x) -> 1.5.4)? I.e. the new config options are injected by defaultconfig.php and those that were already existing are overwritten by config.php. ISTM the only difference is that removed config options are (not) being removed from the config file on saving. But neither way would cater for changes in the configuration: e.g. an option switching from true/false to 1/0 or similar.

And the problems updating customized CSS files unfortunately still remain.

Christoph

[svasti]

Is that so? I don't have much experience with FTP client (actually just a bit with FileZilla), but I'm not sure, if that's the typical way how permissions are handled.

Yes, that's the typical way permission are handled.

I have encountered 2 kind of servers: both usually have similar permissions, i.e. for files 0644 and for folders 755, the difference being only in the owner of the files. On some servers CMSimple_XH can write to files with 0644 and on some it cannot. If it cannot I give permissions 0646 (adding public write permission, group permission won't change anything here). The usually does the trick.
If through upload via ftp files are overwritten, the permissions stay.

Now concerning an automated upgrade, I think it's not impossible, and it's on top of the wish list.
We should determine which files may be edited and which not. Thoses files which could be edited must get a special treatment, the rest should just be overwritten.

Editable files could alway have a default file, the language files may either need specific default files or a dialog for manually checking possible changes (may-be similar to your translater_XH). Then we need a routine to compare and generate editable files. This seems to me the biggest challenge, but not an impossible one.

Looking at the Joomla-test-installation on the Joomla site, I found they already have an automatic update setting in the back end.

[cmb]

Well, I've thought about that issue again. IMO we shouldn't strive for a fully automatic update (at least for the near future). On one hand this would be extremely hard to accomplish and on the other hand it's not absolutely necessary. Any CMSimple webmaster should be accustomed using an FTP client and a ZIP program. So downloading, unpacking and uploading a new version can be handled manually and shouldn't be too much hassle.

We should determine which files may be edited and which not.

I'd say: all files that can be modified in CMSimple_XH's back-end should be treated as being possibly modified by the user. Any other changes (e.g. to the program files, the editor's inits, core.css etc.) can't be reasonably catered for. Any user making such customizations should be aware of additional work in case he wants to update.

These files would be: content and pagedata, templates with the stylesheet, config and language files. For an update it's not necessary to upload content, pagedata and the template folder. What remains are the config and language files. These do already have default files, which handle new entries quite well.

This might be improved by an upgrade script, which is called once after uploading a new version. This script could trim down the proper config and language files (i.e. removing unnecessary entries) and even be adapted to make automatic modifications to existing entries (i.e. the password can be automatically "encrypted" when updating to XH 1.5.4 or a later version). And this script might note, what else should be done (e.g. removing the FCKeditor/ folder when upgrading to XH 1.5).

So I suggest to provide two different downloads for new versions: a full package for new installations, and an upgrade package including such an update script. Ideally the upgrade package will not work for revisions (e.g. 1.5(.x) -> 1.5.4), but for upgrading minor versions (e.g. 1.5(.x) -> 1.6). Even better (if possible): we should provide an upgrade package 1.2 -> 1.5.4. And we should consider, if it's possible to provide an upgrade package for the ANSI encoded versions as well (including CMSimple 3.x).

The user who wants to use these upgrade packages has to be aware, that existing plugins might not work with a newer version of CMSimple_XH. This has to be documented; active plugin developers might provide information with which version their plugins work; for plugins that are not maintained anymore somebody else has to check that out.

And well, this upgrade procedure works only for the CMSimple_XH base distribution. Additional plugins can't be catered for easily. There has to be agreement on conventions regarding the plugins offering required upgade information, and probaly it would be good, if the plugin developers would provide upgrade packages (without config and language files etc.) too.

Another very important thing is the update availability check. This could work totally independent from the proper update procedure, and might well be written as a plugin. It might be more important for users to be informed about updates, than to actually have some kind of semi-automatic update, particularly if severe bugs or even security vulnerabilities were found in any component (see e.g. the vulnerability found in Register; in the 10 days since it's known, the new version was only downloaded 10 times).