I just showed you how to automate multiple Wordpress Mu Blogs, unfortunately I don’t have only one Wordpress Mu Install to manage but several ones and I don’t want to create a specific script for each one but a script for all of them (if you are not interested to follow this tutorial just download the script at the end ;)). In this lesson, we mostly deal with the Architecture of Multiple Application Configuration files for Scalability (be able to sustain the management of an increasing number of Wordpress Mu Sites).

For example I have these 2 domain names:
Reboltutorial.com
Rebcode.com

If I had to manage these 2 domains with the script we crafted here, we would need 2 configuration files for the two databases and so 2 scripts for each one will reference its own configuration:

;change the file-name accordingly to your choice
prefs-file: %reboltutorial.com.preferences.txt

and

;change the file-name accordingly to your choice
prefs-file: %rebcode.com.preferences.txt

It will become a nightmare to maintain (especially if one has many more than 2 wordpress mu installations) as I will have to edit the source of one script, copy and paste it to change the name of the configuration file and then upload each one on their own ftp server.

I may not avoid to upload a script to each ftp server but I can at least have a single source script to upload. Here’s the trick: if the script knows where it executes from, it could just infer the configuration file name by ITself. Indeed, if you execute the script on your local pc, Rebol has a variable which contains the path of the script which is

system/script/path

You must create a script to test it so copy and paste the snippet below in Rebol Console to create programmatically a script named test-path.r:

>> make-dir %test-path
== %test-path/
>> write %test-path/test-path.r {rebol []
{    print system/script/path
{    input
{    }

Now execute the script in Rebol Console:

>> do %test-path/test-path.r
/C/Rebolview/test-path/

It will print the above path for example.

But wait a minute, if the script is on a FTP Server will this variable be usefull ? Well the answer is … no because in truth Rebol cache it locally before executing it (that’s logical since your server doesn’t have the Rebol executable !) … we are stuck

So the only one who knows where the script is executing from is ourself. So we have to tell the script that we are executing it from ftp.server1.com or ftp.server2.com by passing them through the command line arguments.

How to pass such argument ? Type help do to get the answer:

>> help do
USAGE:
    DO value /args arg /next

DESCRIPTION:
     Evaluates a block, file, URL, function, word, or any other value.
     DO is a native value.

ARGUMENTS:
     value -- Normally a file name, URL, or block (Type: any)

REFINEMENTS:
     /args -- If value is a script, this will set its system/script/args
         arg -- Args passed to a script. Normally a string. (Type: any)
     /next -- Do next expression only.  Return block with result and new position.
>>

So upload this script (named test-path.r) to the FTP server

rebol []
probe system/script/args
input

and execute this instruction:

>> do/args http://reboltutorial.com/source/test-path "reboltutorial.com"
"reboltutorial.com"

That’s good system/script/args contains the string we pass in command-line. It’s now easy to rewrite the script under its generic form (I just show the generic part):

;don't forget to pass the domain namme with do/args in Rebol console
prefs-file: to-rebol-file rejoin [system/script/args ".preferences.txt"]

You can test or download the script from the url below

do/args http://reboltutorial.com/source/wordpressmu-newblog-generic.r "reboltutorial.com"

As an exercice, you could also do the same thing for the FTP upload script.

Recent Articles