This document will detail how to test your custom script as well as give you some useful tips in debugging what (if anything) has gone wrong. If you need detailed instructions on adding your custom script, see Adding a Custom Script to ScriptWorx

If you run into a situation that is not listed here and you think it should be, please post it to the InterWorx forums and it will make its way into this document!

Once you’ve written your class and placed the archive and .php file in the proper place it’s time to see if it works!

1. Log in to the SiteWorx account where you wish to install the script.
2. Get to the ScriptWorx interface.
3. Click on the [ Install ] link next to your script.
4. Fill in the appropriate details.
5. Click the Install button.
6. If all went well your script will be installed. If not, see the debugging section for help in diagnosing and fixing the problems.

When something goes wrong with a script installation, the first place to look for information is the iworx.log file. iworx.log can be found at /home/interworx/var/log/iworx.log. A sample entry from the log file follows. The sample shows a failed installation and what type of thing you should be looking for in the log.

Nov 07 12:39:48 scriptworx.php [debug] scriptworx.php --install mydomain phplist
2.10.2 /home/mydomain/mydomain.com/html/mylist location=mylist,username=user,password=pass,email_address=me@mydomain.com,version=2.10.2,
Nov 07 12:39:50 mysql.php [info] script begin
Nov 07 12:39:50 mysql.php [debug] mysql.php --chgrp --gid 581 --database mydomain_phpl1
Nov 07 12:39:50 mysql.php [info] script end
Nov 07 12:39:51 scriptworx.php [debug] importing databases
Nov 07 12:39:54 scriptworx.php [info] ScriptWorx: Installing Config File failed.

The error messages in red are ones that you as developer have no control over and if received should be reported to the InterWorx development team.

• "ScriptWorx: Setting up the databases failed."
• "ScriptWorx: Adding installation to db tables failed."
• "ScriptWorx: Unable to create script dir structure."
• "ScriptWorx: Removing Temporary Install Dir failed."
• "ScriptWorx: Error generating manifest file"
• "Scriptworx: Error Chowning Files."

The error messages in green are ones that your subclass code directly influences. If you see one of these error messages in the log, you should investigate why the function is erroring out.

• "ScriptWorx: Failure unpacking the archive." --> Debug _unpack()
• "ScriptWorx: Preinstall failed." --> _preInstall()
• "ScriptWorx: Install DBs failed." --> Debug _installDBs()
• "ScriptWorx: Configuring the dbs failed." --> Debug _installDBConfig()
• "ScriptWorx: Installing Config File failed." --> Debug _installFileConfig()
• "ScriptWorx: Removing Temporary Install Files failed."--> Debug _removeInstallFiles()
• "ScriptWorx: Setting the final permissions failed." --> Debug _setPermissions()
• "ScriptWorx: post install failed." --> _postInstall()
• "ScriptWorx: Moving script to final location failed."--> Debug _moveToFinalLocation()

As with any php development, a decent way to debug what went wrong is to litter your code with print statements. ScriptWorx will dump output to the screen when a subclass function returns false. The easiest way to get output from your php code is to isolate the php function in question, add print statements, and return false from the function. Returning false will indicate to ScriptWorx that a particular step of the installation process failed and ScriptWorx will dump to the screen any output directed to stdout such as print statements. Below is an example where we we return false from a function to determine what values are.

  function _postInstall() {
 
    $temp_install_dir    = $this->_getInstallDir();
    $blog_dir_htaccess   = "$temp_install_dir/blogs/sample.htaccess";
    $admin_dir_htaccess  = "$temp_install_dir/blogs/admin/sample.htaccess";
    $mvto_admin_htaccess = "$temp_install_dir/blogs/admin/.htaccess";
 
    // We want to print out the values of the following variables to make sure they are what we are expecting.
    print( "$blog_dir_htaccess\n" );
    print( "$admin_dir_htaccess\n" );
    print( "$mvto_dir_htaccess\n" );
 
    $retval = IWorxFileSys::iworx_mv( $blog_dir_htaccess,
                                      "$temp_install_dir/blogs/.htaccess",
                                      true );
 
    $retval2 = IWorxFileSys::iworx_mv( $admin_dir_htaccess,
                                       $mvto_admin_htaccess,
                                       true );
 
   // See if the moves succeeded.  If they return 0, we're all set.
   print( "First Move: $retval\n" );
   print( "Second Move: $retval2\n" );
 
    if( $retval  != 0  ||
        $retval2 != 0 ) {
      $error =
        array( 'name' => '',
               'status' => false,
               'reason' => '##LG_SCRIPTWORX_DELETING_INSTALL_FILES_ERROR##');
      return( $error );
    }
 
    return( false );
    //return( true );
  }

Most likely, this means you have an error in your class file. You can find out the exact error one of two ways:

1. Open up /home/interworx/iworx.ini
2. Search for debug=
3. Set only that value to 1
4. Reload the ScriptWorx page.

or:

1. From the command line run php -l /path/to/your/script.php

This is usually a problem with permissions.

1. Verify that the script class file has the proper permissions and owner. (The class .php file should be grouped to iworx and owned by the iworx user)

This usually indicates that the configuration (values in the script’s config file or database tables) of the script is not correct.

1. Verify that all of the config files and database tables have valid and proper values.
2. Verify there are no syntax errors in the script config files.
3. Verify that the permissions are set properly on the script config files.

Most likely one of two things is happening.

1. ScriptWorx cannot connect to the database to import the db tables.
2. The .sql file being imported is invalid or not compatible with the version of MySQL on the server.

In case of #1, try to verify that you can connect to MySQL on 127.0.0.1 and localhost by doing the following (for the password enter the DSN grepped from the iworx.ini file):

[root@vpsdev3-fdr20-2 root]# grep "rootdsn" ~iworx/iworx.ini
rootdsn="mysql://iworx:jgCBF7QUKuoP@unix(/var/lib/mysql/mysql.sock)/mysql"

[root@vpsdev3-fdr20-2 root]# mysql -u iworx -h 127.0.0.1 -p
Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5182 to server version: 3.23.58

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>quit
Bye
[root@vpsdev3-fdr20-2 root]# mysql -u iworx -h localhost -p
Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5182 to server version: 3.23.58

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>quit
Bye

If you get the mysql> prompt, ScriptWorx can successfully connect to the database. If, when trying to connect you get an error like “Too many failed connections” you need to execute the following:

[root@vpsdev3-fdr20-2 root]# mysqladmin flush-hosts -h localhost -u iworx -p
Enter password:
[root@vpsdev3-fdr20-2 root]# mysqladmin flush-hosts -h 127.0.0.1 -u iworx -p
Enter password:

In case of #2, open up the .sql file you are trying to import it and try to narrow down what part of the file is causing the database import to fail. Many times it’s due to the sql having directives that are only recognized in a newer version of MySQL than what is present on the server.

Usually when this fails it’s because the path to the archive is wrong or the archive name is incorrect. It is often useful to print out and verify the values of three things:

• The command that is being run by IWorxExec::exec
• The directory where the archive is supposed to be unpacked to.
• The path to the archive.

Look in the _installDBConfig() function and make sure that there are no syntax errors in the sql used to modify the database tables. Often times it is helpful to isolate the sql statement and try to run the query on the database via phpMyAdmin or the MySQL command line interface. Also, you need to verify that the proper tables and fields are being accessed in the database.

Most of the problems in this function are one of two things.

1. The paths to the files you are trying to use/modify are not correct.
2. You’re using IWorxFileSys::iworx_lock_barf instead of IWorxFileSys::iworx_barf or vice versa.

Usually if there is a problem here it’s with the paths used in the IWorxFileSys::iworx_rm call(s). Verify that your paths are correct.

Usually if there is a problem here it’s with the paths used in the IWorxFileSys::iworx_chmod call(s). Verify that your paths are correct.

Usually if there is a problem here it’s with the paths used in the IWorxFileSys::iworx_mv call(s). Verify that your paths are correct.

Check /home/interworx/var/log/iworx.log to see where the error occurred in the installation process.

This usually happens when there is a php error in the script that caused early termination. For example, an undefined function being called (generateTempDir != _generateTempDir). Verify that you are calling all of the correct functions.

Verify that the _package_glob and _package_ver_regex in the constructor for the object match the name of the archive (this is case sensitive). The * in the two variables represents the version number of the script package. An example follows.

The archive name is the following: b2evolution-0.9.1b-2005-09-16.zip and it can be found at /home/interworx/lib/scriptworx/b2evolution/0.9.1b

The corresponding variables in the constructor should be as follows:

    $this->_name              = "b2evolution";
    $this->_package_glob      = "b2evolution-*-2005-09-16.zip";
    $this->_package_ver_regex = "b2evolution-(.*)-2005-09-16.zip";

Verify that the script is enabled in NodeWorx. The following procedure explains how to do this.

1. Click on the SiteWorx menu if it is not already expanded.
2. Click on the ♦    ScriptWorx item.
3. You should now be looking at the ScriptWorx controls in the main content area.
4. Locate the ScriptWorx Global Options section.
5. Select Enable or Disable from the drop-down labeled ScriptWorx.
6. Click the Save button.

Verify that the variable _package_ver_regex in the constructor for the object matches the name of the archive (this is case sensitive).

The archive name is the following: b2evolution-0.9.1b-2005-09-16.zip and it can be found at /home/interworx/lib/scriptworx/b2evolution/0.9.1b

The corresponding variables in the constructor should be as follows:

    $this->_name              = "b2evolution";
    $this->_package_ver_regex = "b2evolution-(.*)-2005-09-16.zip";