Set-up and development notes
Contents
Set-up and development notes 1
Contents 2
Outline 3
Infrastructure 3
System framework 3
Standards 5
By functionality 5
moderation module 5
Deletion of content 6
Security 6
Use randomly generated unique tokens with forms to store into session variable and check on next
page before executing any action. 7
Creation of groups, management of users, publishing objects to groups, permissions 7
Create subscriber groups, nominate admins, invite users 7
Users can change subscriber groups 7
Devise and implement improvements to search facility 7
All LOs have a full audit trail 7
Collaboration (on Summary tab and Collaboration tab) 8
Resources player window 8
Audio Player 8
Video Player 9
Document Player 9
Web-link player 9
Image player 9
HTML Player 9
Conversion > Generate test script and test file bank for regression testing conversion process 9
Appendix B 9
Server and application set up guide 11
Application + Content 11
Application 11
Database 15
Web Conversion 15
Application 15
Testing 16
Outline
The collaboratory.org.uk system is a user content driven system designed to allow web access and
collaboration over varying styles of content.
The basic technologies on which the site relies are as follows:
* PHP 5.2 To perform all server side page generation and control content/permissions.
* MySQL 5 Storage of all meta data for the site, in addition to non-binary content
* For binary content (images, SWF files etc) and uploaded content, the filesystem of the host system
is used
* Flash and Actionscript 2 media players are written in Flash and Actionscript
* HTML the content of the system is displayed in the browser using HTML (Specifically: XHTML
1.0 Transitional)
* Javascript and Ajax The system makes use of Javascript in the front end to manage user interface
elements. There are also elements where Ajax requests are made to dynamically update a page. To
add a layer of obfuscation and security to this, the SAJA (http://saja.sourceforge.net/) framework is
used.
The system has been built up into a custom framework. There are three basic interfaces to the application
for client software
* Generation of whole pages the client browser accesses all full pages through one path in the
system
* AJAX methods in the instance where part of the page is updated, a separate interface is in place
to serve elements of a page
* Other files both static files (such as CSS, JS and user files) are delivered using standard path
requests that map directly to the location of the file on the web server. The location requested is
processed to determine whether the requesting user has the correct permission to access the object.
Infrastructure
Infrastructure considerations are outside of the scope of this document.
The system allows for functioning on a tiered server structure, where the MySQL database is running on a
separate tier to the application.
System framework
Structure
The structure of files within the site is split to allow focusing on either the model, view or controllers
independently of each other.
When a user accesses a page, the arguments in the request are used to initially determine the path through
the system. If there is an action associated with the request, an include is called to perform it. If the
request is to display information, a view file is included which then formats and displays data in the
correct way.
The directory structure is as follows:
classes/
Model
[ClassName].php
Classes to describe the basic objects of the system, includes
getters and setters linked straight to DB
[ClassName]Management.php
Allows the creating and management of [ClassName]
objects, along with any functionality based on multiple
objects
[ViewName]Helper.php
Custom methods processing view elements directly
includes/
Controllers in the site, make decisions about what to do with
data, and where to send the browser afterwards. These are
used for making updates to the site.
html/
View elements - contains php based templates ( there is no
custom engine) that render variables into the page
saja/
For AJAX requests. These rely heavily on 'Helpers' in the
classes to format output.
style/
Directory containing style sheets
images/
Static images served by the site
moderation/
Moderation module components
js/
Javascript libraries
converter/
Conversion functionality (not called directly by outside world)
[functionalityName]Ajax.php
For each main ajax based tool there is a separate class that
controls and delivers the correct response
conf.php
Contains deployment specific parameters to allow portability
of the complete system. Any deployment specific variables
will be defined here.
types.php
Contains definitions of the different global constants that the
system makes use of. These types are used as metadata in
the database, as well as serving to provide communication
standards between objects. When new types, levels or
other constants are added, they will be placed here to ensure
consistent access to the whole site. Please note, this doesnt
include class specific constants, which unless used to
communicate with the database, or other classes, should be
defined within the class itself.
index.php
The basic controller and page wrapper, deals with all static
page requests.
Appendix B details the purpose of each of the files in the classes/ directory.
Database definition
The database is defined by the provided SQL.
Alternative style definitions
A requirement surface to create a version of the site that was functionally identical, but followed a
different style. The project was not branched at this point, rather the code was changed to support a
separate style sheet running on top of the existing one. Some elements are driven in the configuration file
but generalising the style should be considered incomplete and requiring overall attention if the project is
forced this way. At the time of writing, an alt style uses CSS and some code changes driven by the
configuration file to force a different style on top of the existing one.
In index.php there is the inclusion of the custom CSS files, based on the configuration. Default group,
resource and project images are driven by code and pull images from a separate configuration driven
directory. Style sheets have been generalised to pull resources from a local profile, the first steps to having
a theme driven system. There is one main javascript alteration that uses a variable set in index.php to
convert colours using a colour map, ideally this would be replaced with style sheet definitions (fn:
new_scripts.js::fixColours).
Standards
Ajax popups
As previously mentioned the dynamically controlled page content is served using a framework called
SAJA. On the view side of things, there are two elements created to enable this:
* Includes/popups.php contains the html frame which is used to contain the popup. As the HTML is
not dynamically created, there can only be one instance per definition in this file. The popup is
shown by javascript (currently split between js/scripts.js and js/new_scripts.js) which simply
shows the content.
* Content is loaded into the body of the popup using the SAJA call. This means that the linking of
content must be generated in php, and hence is part of the standard view and helper setup. (ie
showing the resource popup would mean running Javascript to show window and exporting a saja
function to update the innerHTML
HTML structure
The view side of the site is split to allow the different widgets of functionality to be built up. This is
represented by the directory structure of this area. Commonly used side widgets are in column_boxes.
The different tabs of different areas of the side are included from the directories [area]_tabs. Html for the
AJAX based functionality is generated by helpers in the class directory. There is also allowance for some
specific processing of HTML in the AJAX classes themselves.
Security
File security
There is a blanket redirect to 404 pages if the directory/file requested is one that shouldnt be accessed
directly over the web. There is also a redirect for user files, which, based on the path requested, first
checks the permissions against the user session before delivering the file.
User sessions
When a user has logged in, they are given a session cookie which grants them access to the site. This
cookie is used to identify the user within the internal permissions structure. There is a system class
Auth.php which manages the relationship between session variables, permissions structure and finally
access to specific objects. There is a configurable timeout for sessions, after there is been that length of
inactivity, the user is redirected to the login page automatically.
Accessibility
The requirements for this are defined with the functional requirements. The latest guidelines allow the
reliance on Javascript based functionality when using the site, for this reason, no HTML only version of
AJAX elements has been provisioned.
By functionality
NB. This does not constitute a full list of functionality present.
moderation module
The moderation module is delivered through a separate set of views and controllers. It follows the same
structure to the rest of the site, and makes use of the classes to interact with the database.
Only users with the level "TYPE_USER_MODERATOR" are able to access the moderation module.
There is no method by which to add users of this type to the system.
Deletion of content
For each object type there is functionality to delete it. When deleting an object, the system will ensure that
no data is left redundant (ie references to the deleted object should be altered or deleted also).
Security
Where appropriate the following measures are taken to secure the site:
Validate input for preventing executing of arbitrary code
Never include, require, or otherwise open a file with a filename based on user input, without thoroughly
checking it first.
Dont use eval() with not validated input.
Turn register_globals to off and use superglobals to deal with input ($_GET, $_POST, $_COOKIE,
$_SESSION, etc).
Move all user input validation from the client side (javascript) to the server
Move all include files outside of the document root and make sure all include files have .php extension.
Use sessions to validate login and user access level on every page (including file downloads and
resources)
Protecting from SQL injection
Check if magic_quotes_gpc is enabled and if not escape all queries with addslashes() or
mysql_escape_string()
Or if using a framework use prepared statements
Secure error repoting:
Turn screen error reporting to off and enable logging of errors.
Use PHP Exceptions or at least trigger_error() instead of die () to use the PHP's error and exception
handling functionality and have control whether errors should be displayed or not
Cross site scripting attacks:
Encode html characters to protect from Cross Site Scripting (XSS) attacks (use bbcode tags in html editor
Remote File Inclusion Attacks
set allow_url_include and allow_url_fopen to off
or use mod_rewite to prevent RFI attacks
Session security (preventing stealing of sessions and session fixation attacks):
check for changed session id and regenerate the session
With PHP 5.2 + dont allow Javascript access to session cookies
Cross-site request forgery (CSRF)
Use randomly generated unique tokens with forms to store into session variable and check on next page
before executing any action.
Creation of groups, management of users, publishing objects to groups,
permissions
This requirement sees functionality added to the group and group management classes to serve the back
end requirements. The technical requirements for the permissions structure are detailed in the functional
specification.
Create subscriber groups, nominate admins, invite users
An organisation is a particular type of group. It is managed and controlled by the same functionality as a
normal group, except that it has the property of:
TYPE_GROUP_SUBSCRIBER for its level/type to ensure it can be identified in the system.
Users can change subscriber groups
The process in the back end to change a users subscriber group will be to:
1. update their organisation number
2. add them to the request list for the group
Since the system is specified not to allow a person to be directly associated with an organisation group
unless they are individually verified, there is no functionality to instantly swap a user from one group to
the next.
Devise and implement improvements to search facility
To achieve the complex searching, a set of functions build up a single query to make the relevant joins
across the different tables that are involved. These functions are compounded in general search functions
that are then accessible to the rest of the back end to query the database in this common way.
All LOs have a full audit trail
This data is stored in the log table. The following actions are kept here, and not deleted:
define("TYPE_LOG_LO", 1200);
define("TYPE_LOG_LO_CREATED", 1201);
define("TYPE_LOG_LO_MODIFIED", 1202);
define("TYPE_LOG_LO_DELETED", 1203);
define("TYPE_LOG_LO_PUBLISHED", 1204);
define("TYPE_LOG_LO_BOOKMARKED", 1205);
define("TYPE_LOG_LO_RATED", 1206);
define("TYPE_LOG_LO_COPIED", 1207);
define("TYPE_LOG_LO_ATTACHED", 1208);
define("TYPE_LOG_LO_TRANSFERED", 1209);
define("TYPE_LOG_LO_VISITED", 1210);
define("TYPE_LOG_LO_TAGGED", 1211);
define("TYPE_LOG_LO_UNPUBLISHED", 1212);
define("TYPE_LOG_LO_COMMENTED", 1213);
define("TYPE_LOG_LO_REPORTED", 1214);
define("TYPE_LOG_LO_REINSTATE", 1215);
define("TYPE_LOG_LO_DETTACHED", 1216);
For each of the log elements a string of serialised data is stored with any extra metadata for the action.
Collaboration (on Summary tab and Collaboration tab)
This data is parsed from the log table and details. The entries displayed are listed in the functional
specification. Complete in functional specification.
Resources player window
The resources player window is the wrapper for the display of any resource. It displays all the required
metadata and allows certain editing facilities (defined in functional specifications). The player window
interfaces with the back end system over the previously defined SAJA (AJAX) interface, and shouldnt
see the full page reload at any point.
The media player works in a popup window to display all different resources that have been uploaded to
the system.
Most uploaded files will be converted to a standardised format that can be shown in the player. The
original version that the user uploaded will also be available for download.
The player will always play the converted version if it can, otherwise reverting to attempting to embed the
original, and if this is unsuccessful, not showing anything.
Converted media falls into 3 categories:
* FLV video this will use a standard FLV player that we will decide on and procure when needed.
For now please use the one in the prototype.
* Mp3 audio this will use the same player as FLVs.
* Pdf documents embed the document in the same way as the prototype.
The player will attempt to play other documents in the player by attempting to embed it in a fixed window
into the page. The details of this have not been specified, please use the embed codes present in the
prototype for this scenario.
Images are displayed as they are (eg <img src= alt= />)
The player front end should only access a custom ResourcePlayer/ResourcePlayerManager classes in the
php backend. These should then act as an interface, making use of the classes already in place for getting
hold of files/information etc. This will mean that very little (if any) access to the database will be required
directly by the resource player classes.
The code for the front end should also sit separately from the rest of the code. All HTML/Javascript will
be in separate windows. This will mean that changing popups.php should have an include, which refers to
any code needed only for the resource player. See index.php 269-274 for use surrounding popups.
Audio Player
The audio player is a simple flash based mp3 player with the controls as defined in functional
requirements and design documents. There is no provision at this point for the player to manage streaming
media.
Video Player
The audio player is a simple flash based flv player with the controls as defined in functional requirements
and design documents. There is no provision at this point for the player to manage streaming media.
The video player doubles as an audio player and is built under a separate project media-player. When
changes are made to the media-player project, they must be manually merged into the system for the
changes to be visible in context.
Document Player
The document player loads a static swf file into a window area. The swf content has pages separated by
frames, which the player uses to skip forwards and backwards through the pages of content. The document
player is also being used to show jpg images using the same interface (except with the page controls
removed).
The document player is built under a separate project document-viewer. When changes are made to the
document-viewer project, they must be manually merged into the system for the changes to be visible in
context.
Web-link player
The details in the functional specification have been superseded here. There is currently in place a
conversion facility that allows the generation of an image to represent a web page. This being the case, the
method for displaying web-links is as their image (eg <img src= alt= />). The conversion process will
convert the image to a standardised format and size, the embedding of this image should include the size
variables and if the image isnt present the alt tag will be the string forming the http address.
Image player
Images are displayed in the document player. See above.
HTML Player
Pasting of arbitrary HTML into the create wizard will display the html in an iframe sitting within the
Resource player (such as youtube embed).
Conversion > Generate test script and test file bank for regression testing
conversion process
To enable back-testing large numbers of potential problem conversions, a script has been made to bulk
convert a set of files in a directory. This makes use of exactly the same conversion tools, but doesn't
output the files to the site, and shows them in a separate, basic utility for checking the conversion (using
the same player and embed code as the rest of the site).
Appendix B
Description of the class files.
classes/
³ Project.php
Contains the code associated with a project
³ ProjectManagement.php
For dealing with multiple activities and managing them
³ Auth.php
Controls user sessions and allows querying of permissions related to
an object and the user requesting
³ AutosaveManagement.php
Allows access to autosave data associated with a LO
³ Collection.php
Extends learning object, methods specific to a collection
³ CollectionManagement.php
³ ConverterUtils.php
Linking class between internal system and conversion utility
³ Cookie.php
Helper for dealing with cookies
³ File.php
A file in the system - allows the relation of LO to binary content
stored n filesystem
³ FileManagement.php
³ Flag.php
A report, associated with an object (can be group, LO, etc)
³ FlagManagement.php
³ Group.php
Class of object for a group
³ GroupManagement.php
³ GroupsViewHelper.php
Bespoke functions to aid the contruction of the interface
³ JoinGroupViewHelper.php
Bespoke functions to aid the contruction of the interface
³ JSON.php
Imported class for dealing with JSON content
³ LearningObject.php
Learning object, which could be a resource, project etc. Base class.
³
LearningObjectManagement.php
Base management for all learning objects\
³ LinkResource.php
Management class for linking resources to activities
³ LinkResourceViewHelper.php
Helper for creating link resource dialogue
³ Log.php
Log entry
³ LogManagement.php
Management of log entries
³ NoteManagement.php
obsolete
³
ObjectPermissionViewHelper.php
Helper for the permissions popup (when access is denied)
³ Paginator.php
Helper for dealing with pages of results.
³ PlayerViewHelper.php
Helper for creating resource player view
³ Resource.php
Resource, extends LearningObject, is a resource within the system
³ ResourceManagement.php
Management of resources
³ ResourcePlayer.php
Interface for controlling resources within the system while the user is
accessing resoruce player
³ ResourcePlayerCollection.php
When accessing collection
³ Search.php
Selection of search functions
³ Tag.php
A tag withing the system
³ TagManagement.php
Management of tags
³ TagsPopupHelper.php
Helper to contruct the tagging window
³ ThumbNailer.php
Helper functions for creating thumbnails in the file system
³ User.php
A user
³ UserManagement.php
Management of users
³ Validator.php
Check the contents of a sumbitted fields
³ ViewHelper.php
General helper to create sections of view
³ WizardHelper.php
View helpers for the create wizard.
Server and application set up guide
The application is designed to run on a Linux system, while the web conversion requires a Microsoft
based server environment. This section outlines the requirements placed on the environment as well as
building up a working copy of the site based on a bare bones environment. It is the case that this may not
form a one stop guide, and differing environments may require extra steps. It is also the case that changes
to third party applications may force a slightly different set up, or modifications to the source code. We
will look at these separately. In addition to this are some notes on any general infrastructure.
Application + Content
The application is split into two main constituent parts:
1. The application server a PHP based application formatting and delivering the pages and other
elements of the site.
2. The database server storage of non-binary (images, etc) data stored in a MySQL server
Application
When deploying the application, care should be taken to ensure that the files directory is writable to by the
Apache process owner. NB. It is not necessary that the php within the files directory are writable.
Core application configuration
The core application needs configuring in two places:
* conf.php there are explanations of the terms in the source provided core-app/www/conf.php
* core-app/www/converter/thumbalizr.php contains the settings required to link to the
Core
Mail settings we havent had the requirement for any mail auth settings or non smtp set ups. To change
the smtp host simply change the host variable.
$MAIL_TYPE="smtp";
$MAIL_CONFIG=array ('host' => 'localhost', 'auth' => false);
Session length in seconds
define("SESSION_TTL",3600);
admin mail
define("MODERATOR_EMAIL", "alex.dutton@opencc.co.uk");
Database settings for main database
define("DBHOST", "localhost");
define("DBUSER", "user");
define("DBPASSWORD", "pass");
define("DBNAME", "dbname");
Database settings for conversion queue database
define("CONV_DBHOST", "localhost");
define("CONV_DBUSER", "user");
define("CONV_DBPASSWORD", "pass");
define("CONV_DBNAME", "db2name");
Session name in cookies
define("SESSION_NAME", " collaboratory_logged ");
The root domain information
define("WWW_ROOT", "http://exmple.com/");
Relative root in the case that the system is running somewhere other than the root of the domain
define("RELATIVE_ROOT", "/");
define("CMS_WWW_ROOT", WWW_ROOT.'cms/');
Temporary directories for documents, media and url. Should be rw by apache process owner
define("DOC_FILE_TMP", '/tmp/conv');
define("MEDIA_FILE_TMP", '/tmp/conv');
define("CONV_URL_TMP","/tmp/url");
Location of the conversion log
define("CONV_LOGPATH", "/serverroot/www/converter/logs/worker.log");
Locations of binaries/conversion scripts :
define("FFMPEG", '/usr/bin/ffmpeg');
define("FLVTOOL", '/usr/bin/flvtool2');
define("DOCCONV", '/scripts/convert);
define("PDF2SWFCONV","/usr/local/bin/pdf2swf");
define("SWFBBOX", "/usr/bin/swfbbox");
The path to the PEAR directory *within the webroot*.
define("PEAR_PATH", "/serverroot/www/pear");
The IDs of the activities to appear on the home page
$CONF_MOST_POPULAR = array(241,256,313,327,328); //most popular activities, for homepage.
Custom skin definitions. Set ALT_STYLE to false and VIEW_PROFILE to root to use normal
style.
define("ALT_STYLE", true);
define("VIEW_PROFILE", "alt");
Changes beyond these settings in the conf.php file would probably require changes to the
application. (The conf.php file served as a place to define, and perform some absolute
fundamentals.)
Conversion
Config:
conf.php should be altered, with all the relevant paths and DB info added (should be self
explanitory/commented).
core-app/startup/* require the paths changing appropriately (converter/worker.php)
An include path is added at top of worker.php (as this is ran independantly of apache and webroot). This
will need updating to point at the webroot.
The conversion requires that the user running the script has a home directory as this is used by OO.
Currently, both Apache and the conversion facility are run under apache-custom, which has its own
home directory. The scripts required to start the conversion process are in core-app/startup/* (one for
each distinct site). These can be run at startup under the special apache user using the following command:
nohup su - apache-custom -c "/home/webroot/scripts/startup/collabconv.sh" >> /dev/null &
The script on its own only runs one job at a time, with a 1second delay between them. (Multiple threads
can be setup by running this multiple times. This will increase fequency of conversion, but obviously
impact on processor/memory in times of heavy load.)
Use
Once everything it setup, just run the function to add to queue. The worker should then pick up the job and
have a go at converting it.
When it is finished, the system can be updated, and the user can view the file.
Apache configuration
The server should run Apache v2. There has been no requirement so far to include any non-standard
modules beyond PHP.
However, due to the conversion facility, apache must run as a fully fledged user with a home directory.
A commented Apache virtual host configuration is located at core-app/vhost-apache-conf.txt. Here there
are a few basic functions served:
* Block access to areas that we dont want people to directly access
* Redirect file downloads through download.php to check permissions
* Redirect www.example.com to example.com
* Provide any other special access scenarios or filters
PHP configuration
The server runs PHP v5.1, with a number of extra extensions above the core configuration:
* Imagick 2.3
* Libxml 2.6
* Mbstring 3.7
* Curl
* Ffmpeg 0.6
* Mysql
* Soap
Email
The server should support outgoing email over SMTP. The system sets the from and return path from the
configuration settings. Care should be taken when setting this up to avoid spam filter problem.
Settings for incoming emails is beyond the scope of this document.
Server settings and connecting
It is important that the server allows outgoing connections to the IP of the web conversion software. In
addition to this there may be the requirement for the server to allow outgoing and incoming email
connections. There is currently no requirement for SSL connections to the server.
All domains and subdomains should both point to the IP of the server.
Other
The following applications should also be installed:
Python 2.4
Required to run document conversion.
Ffmpeg 0.5/ 0.6
* Converts audio and video to the standardised formats required by the site
* Now working with Ffmpeg 0.6.1
FFmpeg location: http://ffmpeg.org/ (normally available in repostory)
This should be installed to a location where the apache user is able to execute it.
Openoffice
* Converts many document formats to PDF to provide to the next step.
* Previously running as a python script that connects to Openoffice as a service, but recently
changed to use the unoconv package. This package was wrapped using source/core-app/convert to
ensure no code changes were needed.
Required packages:
* openoffice.org-base.x86_64 3.1.1
* openoffice.org-calc.x86_64 3.1.1
* openoffice.org-core.x86_64 3.1.1
* openoffice.org-draw.x86_64 3.1.1
* openoffice.org-headless.x86_64 3.1.1
* openoffice.org-impress.x86_64 3.1.1
* openoffice.org-math.x86_64 3.1.1
* openoffice.org-pyuno.x86_64 3.1.1
* openoffice.org-ure.x86_64 3.1.1
* openoffice.org-writer.x86_64 3.1.1
* unoconv.noarch 0.4
NB. Also tested with 32bit Openoffice packages
Openoffice location : http://download.openoffice.org/other.html#en-US (depending on distro, available in
repository)
Swftools v09.0
* converts PDF (from OO output) files to swf
* corrects bounding box problems
Swftools location: http://www.swftools.org/ - RHEL only has 0.8.1 in Repo which is insufficient (and
doesn't work on 64bit RHEL).
Please note that there are some significant differences between 0.8 and 0.9 that may require code changes
to the conversion module to ensure compatibility.
Actual applications used are:
* pdf2swf
* swfbbox
Flvtool2 v1
* Updates meta data on FLV files to ensure that their header is correct
Database
MySQL configuration
The database runs on MySQL version 5.0. No special configuration options have been specified.
There are two separate databases running behind the application, one for the main app and one for the
conversion queue. In setting up a new instance of the site, one can simply run the following database
scripts into the database of choice:
/core-DB/DB/conv_db.sql
/core-DB/DB/clean.sql
These files have not be altered at their core, but run chronologically through development, meaning that if
the live site is an older version, updates can be made by looking at the bottom of the script.
If migrating between systems, one should duplicate the databases to the new server. It may not be
necessary to move the conversion queue database, as this data has only limited use once a conversion is
completed.
Web Conversion
The web conversion server is a passive environment that delivers images based on a url provided to a
simple web service. Located in source folder under: webconvservic-app.
Application
Core application configuration
The config files for the webconversion is conf.php in the web root. The core settings here are:
define("CONV_URL_TMP","C:\\temp"); - the temporary directory to store files while processing
define("CONV_LOGPATH", "C:\\work\\www\\converter\\logs\\worker.log"); - the location of the log.
Please ensure that the path and file already exist before starting the server.
define("URLCONV", 'C:\\webshotcmd.exe'); - the location of the website screenshot binary application
Apache
The webserver runs a standard Apache 2 installation. It also requires the Apache2-PHP5 module installed.
No special set up measures have been taken.
PHP
PHP 5.1 is installed on this system, though it should run on PHP >5.1. No special modules are required.
Other
Websitescreenshot
This is a standalone executable available here:
http://www.websitescreenshots.com/
It should be placed on the filesystem in a place where the PHP application can access it.
The binary is available in the source folder under core-app.
Testing
There are test scripts available for checking conversion functionality. These scripts use the real conversion
functionality, and allow the building up of different sample documents that can be tested against any
changes to the server or code.
These scripts should not be publically accessible.
Web conversion:
www/testing/testscript.php
* Change the $url at the top of the file to the url of the web conversion app with the url to convert
included
* Testing individual sites can be done by accessing the conversion app directly from the browser (or
a simple script to iterate through many requests)
File conversion (including audio/video/doc)
www/testing/conversion/convertall.php
* Attempts to conver all files in the testing/conversion/files directory,
* Creates output in testing/conversion/output directory to render them in a way that replicates the
actual site. Accessing the index.html file will provide links and a simple breakdown.
* the actual output files go to testing/conversion/converted.
README.doc Page 5 of 16
Download Latest Version
2011-08-17_Collaboratory_v1_0.zip (12.3 MB)
