Nate Lewis


FWS::V2 - Framework Sites version 2


Version 1.13091122


    use FWS::V2;
    my $fws = FWS::V2->new( DBName        => 'myDB',
                            DBUser        => 'theUser',
                            DBPassword    => 'superSecret',
                            DBHost        => 'localhost',
                            DBType        => 'MySQL');


FWS::V2 is the utility counterpart to the web based content management development platform provided at The web based version of this module is derived from this source with additional web specific features and packaging. The web based version enables the FWS to function on most any modern hosting environment, be upgraded in real time via the web based FWS administration, and control shared plugins between all of your installations even on different servers.

Using this version is ideal for accessing any plugin feature, or data stored within a FWS installation from a standalone script. Examples of this would be scripts to do site maintenance, imports, exports, mass data updates, data mining, 3rd party data synchronization, web services, APIs... and more!

The syntax and usage of the FWS::V2 is identical to the web based element and plugin development available within the FWS web based administration. Code from either is interchangeable between both distributions of FWS::V2 and the web based distribution of FWS available from


Wait a second... why does FWS V2 seem to have its own home grown methods that are already in popular well established packages????

One of the main goals of FWS is to have a bundled, autonomous version of the FWS that can be picked up and sat on almost any major ISP or Linux hosting environment without any care for what is present on the server. Packages the FWS does use have been carefully picked and validated to be supported on most all major ISPs. For more information on this bundled web optimized version visit



Construct a FWS version 2 object. Like the highly compatible web optimized distribution this will initiate access to all the FWS methods to access data, file, session, formatting and network methods. You can pass a variety of different parameters which could be required depending on what methods you are using and the context of your usage. MySQL and SQLite are supported with FWS 2, but MySQL should always be used if it is available. On medium or high traffic sites and sites with any significance of a data footprint, you will see quite a bit of latency with SQLite.

Example of using FWS with MySQL:

    # Create FWS with MySQL connectivity
    use FWS::V2;
    my $fws = FWS::V2->new(       DBName          => "theDBName",
                                  DBUser          => "myUser",
                                  DBPassword      => "myPass");

Example of using FWS with SQLite:

    # create FWS with SQLite connectivity
    use FWS::V2;
    my $fws = FWS::V2->new(      DBType          => "SQLite",
                                 DBName          => "/home/user/your.db");

Any variable passed or derived can be accessed with the following syntax:

    print $fws->{'someParameter'}."\n";

With common uses of FWS, you should never need to change any of these settings. If for some reason, although it is NOT recommended you can set any of these variables with the following syntax:

    $fws->{'someParameter'} = 'new settings';

Required Parameters

  • DBName (MySQL and SQLite Required)

    For MySQL this is the DB Name. For SQLite this is the DB file path and file name. MySQL example: user_fws SQLite example: /home/user/secureFiles/user_fws.db

  • DBUser (MySQL Required)

    Required for MySQL and is the database user that has full grant access to the database.

  • DBPassword (MySQL Required)

    The DBUser's password.

  • DBHost (MySQL Required if your database is not on localhost)

    The DBHost will default to 'localhost' if not specified, but can be what ever is configured for the database environment.

  • DBType (SQLite Required)

    The DBType will default to 'MySQL' if not specified, but needs to be added if you are connecting to SQLite.

Non-Required Parameters

Non-required parameters for FWS installations can be added, but depending on the scope of your task they usually are not needed unless your testing code, or interacting with web elements that display rendered content from a stand alone script.

  • adminPassword

    For new installations this is the admin password until the first super admin account is created. After an admin account is created this password is disabled.

  • adminURL

    The url defined to get to the typical /admin log in screen. Default: 'admin'

  • affiliateExpMax

    The number of seconds an affiliate code will stay active after it has been received. Default: 295200

  • cookieDomainName

    The domain to use for cookies. Almost always it would be: '' For more complex scenario with host names you would want to make this more specific.

  • domain

    Full domain name with http prefix. Example:

  • encryptionKey

    The encryption key to be used if encryptionType is set to 'blowfish'.

  • encryptionType

    If set this will set what encryption method to use on sensitive data. The only supported type is 'blowfish'.

  • filePath

    Full path name of common files. Example: /home/user/www/files

  • fileSecurePath

    Full path name of non web accessible files. Example: /home/user/secureFiles

  • fileWebPath

    Web path for the same place filePath points to. Example: /files

  • googleAppsKeyFile

    For google apps support for standard login modules this is required

  • hideEditModeHeaders

    Turn off all blue bar column headers for a site. (Suppress the adding of elements to pages on a UI standpoint)

  • loadJQueryInHead

    Load jquery in the head instead of lazy loading.

  • scriptTextSize

    If your element scripts are larger than 'text' and get truncated you might want to set this to 'mediumtext'

  • secureDomain

    Secure domain name with https prefix. For non-secure sites that do not have an SSL cert you can use the http:// prefix to disable SSL. Example:

  • sendmailBin

    The location of the sendmail bin. Default: /usr/sbin/sendmail

  • sendMethod

    The method used to process queue requests internal or custom. Default: sendmail

  • sessionCookieName

    If there could be conflict with the cookie name, you can change the name of the cookie from its default of fws_session to something else.

  • FWSLogLevel

    Set how verbose logging is for FWS is. Logging will be appended: $fws->{'fileSecurePath'}.'/FWS.log' 0 - off , 1 (default)- Display errors

  • FWSKey

    This is the domain key from your account. This is used to share content from different installs using as your distribution hub. This is only used if your a FWS plugin developer or a developer has given you this key to install a plugin they created.

  • FWSPluginServer

    The server used to plublish and intall plugins. Defaults to

  • FWSServer

    The server used to download the FWS Core updates. Defaults to

  • SQLLogLevel

    Set how verbose logging is for SQL statements ran. Logging will be appended: $fws->{fileSecurePath}.'/SQL.log' 0 - off (default), 1 - updates/deletes/inserts only, 2 - everything (This file will grow fast if set to 2)


Accessable after setFormValues() is called

  • formValue()

    All passed variables. The value is not set, it will return as blank.

  • formArray()

    An array of form values passed.

Accessable after setSiteFiendly() is called

  • {siteId}

    The site id of the site currently being rendered. Version 1 of FWS refered to this as the SID. This will be set via setSiteValues('yourSiteId') if setSiteFriendly is not being used.

  • formValue('p')

    The current page friendly or if not available the page guid.

Accessable after setSession() is called

  • {affiliateId}

    Is set by passing a value to 'a' as a form value. Can be accessed via $fws->{affiliateId}

  • {affiliateExp}

    The time in epoch that the affiliate code will expire for the current session.

  • formValue('session')

    The current session ID.

Accessable after setSiteValues() is called

  • {email}

    The default email address for the site being rendered. This is set via 'Site Settings' in the administration.

  • {fileFWSPath}

    The file location of FWS packaged distribution files. This is normaly not used except internally as the files in this directory could change with an upgrade.

  • {homeGUID}

    The guid of the home page. The formValue 'p' will be set to this if no 'p' value is passed.

  • {siteGUID}

    The guid of the site currently being rendered.

  • {siteName}

    The site name of the site currently being rendered.

  • {queryHead}

    The query head used for links that will maintain session and have a unique random cache key. Example return: ?fws_noCache=asdqwe&session=abc....123&s=site& It is important not to use this in a web rendering that will become static though caching. If the session= is cached on a static page it will cause a user who clicks the cached link to be logged out. queryHead is only to ment to be used in situations when you are passing from one domain to another and wish to maintain the same session ID.

Accessable after processLogin() is called

  • {adminLoginId}

    The current user id for the admin user logged in. Extra warning: This should never be set externally!

  • {userLoginId}

    The current user id for the site user logged in. Extra warning: This should never be set externally!



To use the web based rendering you can use this module, or the current web optimized version that is available from When using this module as opposed to the web based version you still need to run the FWS core upgrade to receive the admin modules to your local installation. Any time running an FWS core upgrade you of course not have your core updated, only the admin elements and supporting JavaScript and files..

Simple Web Rendering Sequence

    # Load FWS
    use FWS::V2;
    $fws = new ( 
        #....  FWS Settings ...
    # add any plugins we have installed
    # Get the form values
    # Connect to the DB
    # Page descisions and friendly url conversions
    # Run any init scripts if needed
    # Set session and or get session vars
    # Set site values based on any information we have collected, created or changed
    # Do login procedures
    # Run Internal Admin Actions
    # Display the content we just created

For a more robust version of this sequence use the file creation for manual installation located on



Any plugin that is actived via the plugin list in developer menu will attempt to be loaded.

    # register all plugins applied to this instance


Apply a plugin to an installation without using the GUI, to force an always on state for the plugin. If server wide plugins are being added for this instance they will be under the FWS::V2 Namespace, if not they can be added just as the plugin name.

    # register plugins that are available server wide 
    # register some plugin added via the FWS 2.1 Plugin manager

Additionally if you want to check if a plugin is active inside of element or scripts you can use the following conditional:

    # check to see if ECommerce is loaded and active
    if ($fws->{plugins}->{ECommerce} eq '1') {     print "ECommerce is installed!\n" }
    else {                                         print "No ECommerce for you!\n" }


Nate Lewis, <nlewis at>


Please report any bugs or feature requests to bug-fws-v2 at, or through the web interface at I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.


You can find documentation for this module with the perldoc command.

    perldoc FWS::V2

You can also look for information at:


Copyright 2013 Nate Lewis.

This program is free software; you can redistribute it and/or modify it under the terms of either: the GNU General Public License as published by the Free Software Foundation; or the Artistic License.

See for more information.