FUDforum: FUDforum Suggestions » Separating source and data

Home » FUDforum » FUDforum Suggestions » Separating source and data

Show: Today's Messages :: Polls :: Message Navigator

Separating source and data [message #40588]

Sun, 23 March 2008 04:17

Underhand

Messages: 5
Registered: June 2007

Karma: 0

Junior Member

We have been using FUDforum for quite some time on our site, and it has been pretty well suited for us.

Now, I'm trying to check our web area into version control, so that we can be a bit smarter about testing and rollout of new versions of software (including FUDforum) and changes to themes.

This is working quite well for the other applications which we use on our site, but FUDforum is proving to be a little hostile to this way of working.

The basic premise is that I want to version control anything which is installed by hand - source files, etc. I want to leave out of version control anything which the software is able to rebuild easily. In FUDforum's case, that means that the templates are version controlled, but the themes ideally would not be, as FUDforum is trivially able to rebuild these.

The problem that I am having is that FUDforum seems to be extremely reliant on such autogenerated data existing and being correct. I can't seem to find a way in which I can run the consistency checker script (which seems to rebuild everything in the cache directory) without there being at least *something* in idx.inc. If the theme files are absent, understandably things are even worse.

I haven't yet found a script which is able to regenerate everything which is autogenerated without some kind of autogenerated content already being present. Ideally this would take the form of a script which I can automatically invoke after an update.

Does such a script exist? Would it be difficult to create one?

I can't help feeling that it would be really nice if the directory structure itself were to be more cleanly separated between files which are part of FUDforum itself, and files which are autogenerated or in some way contain user data. Note that I'm only interested in version controlling the software and the templates - not the actual messages, or avatars, or anything else which the user uploads. In fact, my test site points at a different database and a different set of data files.

Or is there an obvious separation which I've missed?

Report message to a moderator

Re: Separating source and data [message #40597 is a reply to message #40588]

Sun, 23 March 2008 15:07

Ilia

Messages: 13241
Registered: January 2002

Karma: 0

Senior Member
Administrator
Core Developer

The scripts such as consistency can be ran via command line, which means you can run them by just doing require( path to file) from PHP. The only thing you'd need to do is modify the few top lines of the file to bypass authentication.

FUDforum Core Developer

Report message to a moderator

Re: Separating source and data [message #40981 is a reply to message #40597]

Sat, 03 May 2008 23:29

Underhand

Messages: 5
Registered: June 2007

Karma: 0

Junior Member

I actually needed to make a few changes for that to work.

Firstly, simply uncommenting the lines changes the behaviour when the script is run from the web site. Secondly, there's no way of choosing whether to run the consistency checks or optimise the database.

This code fragment in consist.php implements that.

        if (php_sapi_name() == "cli") {
                fud_use('adm_cli.inc', 1);
                cli_execute(1);
                if (($argc > 1) && ($argv[1] == "sqlopt")) {
                        cli_execute(0, array('opt'=>1));
                }
        }

In include/adm_cli.inc, I had to change

        fud_use('adm.inc');

        fud_use('adm.inc', 1);

and move it to after the code which sets _GET and _POST.

None of this works if there are no themes. Pretty much all of the scripts require at least the default theme to exist.

To allow the themes to rebuilt, I needed this in admthemes.php

        require('./GLOBALS.php');

        if (php_sapi_name() == "cli") {
                fud_use('adm_cli.inc', true);
                cli_execute(1, array('rebuild_all'=>1));
        }

and a separate script to rebuild the default theme:

<?php
        require('./GLOBALS.php');
        define('__dbtype__', 'mysql');
        fud_use('adm_cli.inc', true);
        cli_execute(1);
        fud_use('compiler.inc', true);
        compile_all();
?>

Running this script first then allows the other scripts to be run to create the temporary files, and to build the rest of the themes.

It would be really nice if this sort of functionality could be achieved without having to make changes to files, in the future. This would make upgrades less risky.

What are the chances of making some of this stuff script-friendly in a future release?

[Updated on: Sat, 03 May 2008 23:31]

Report message to a moderator