Requirements Checker

The System Checker is a component to check needed system requirements.
It should be runnable as:

• Integrated in update and install process (with wizard)
• standalone to check system integrity (above wizard standalone)
• Reusable in case of errors to list not met requirements

The items to check can be separated in the following categories:

• system validations
• config validations
• frontend config validations

The System Checker should be automatically invoked on errors (PHP, additionally JS as soon as JS-Serverside-Errorlogging is implemented) to identify errors based on system changes.

Models_RequirementCheck

This class provides an Interface to all tests in the application, that means it loops over the test definition directories and gets all tests out of the definition files.

Models_RequirementCheck_DefinitionAbstract

Provides default methods to operate with the contained tests. Also provide default test methods like outlined above: isFile isWriteable etc. Implement this methods as needed. This Methods should be public, since they are used from inside the Closures defined as test method.

Models_RequirementCheck_Definition

A concrete definition instance defines each test as instance of a Models_RequirementsCheck_Test. Since the test logic is implemented as Closure, the Test class is used as struct and don't contain logic.
For complex tests, one can extend the test class and use the extended one.

Models_RequirementsCheck_JsTest

Since JS Tests are run in frontend, we define the texts here, and instead a method, we provide the method name of the test which should be called. The JS tests themselves are defined in a dedicated JS Class (here RequirementsChecker_Tests).
→ Settings / Parameters must be available in the running application and in the test environment. That would be possible by designing the JS methods with optional parameters: Test Method called with parameter, use this value, without use value from Editor.data.foo.bar.

RequirementsController

Name and Location of this controller is not fix yet. The Controller uses Models_RequirementsCheck and returns the test results as JSON to the Wizard.

ResultPanel

The result panel consumes the result json and visualizes the test results. It is integrated in the update wizard.

Test Result JSON

[{
	success: true, // → boolean if test was successful or test failed
	title: “This is a super test.”,
	description: “More Information for the user about this test”,
	successText: “OK”,
	successText: “Failed, please do bla bla bla”
},{
	title: “This is a JS test.”,
	description: “More Information for the user about this test”,
	successText: “OK”,
	successText: “Failed, please do bla bla bla”,
	test: “methodNameOfTest”, // → method should be designed, that parameters are optional on using the test in running application
	parameters: [“http://testurl/”] //→ parameters extracted directly from config
}]

Pre / Post installation checks

A division into pre and post installation checks are necessary. Assume a system with installed version 1.0. Admin is not installing update 1.1 immediately, but he updates to 1.3, which includes 1.1 and 1.2.
We assume further that all checks are running as first step in update process. If we had introduced a new config in 1.2, tested by the checker, the update to 1.3 will fail, because the “older” requirement is not met, since it is not installed either.
With splitting the tests into pre and post installation tests we can move this kind of tests to post installation. For admin this means two check screens:

• the first one with information like: you have no mysql db installed.
• the second one after installation with information like: “the directory foobar is not writeable” or something.

Already defined validations

Currently known validations are listed below. There are definitly more than these, which have to be met. The listed ones are only the once we immediately remember. We should have a look through all install*.txt files to get all requirements!

System validations

• php-version installed
• webserver-version installed
• system locale must be a utf8 based locale (see TRANSLATE-155)
• webserver can send email
• mysql-version installed
• mysql strict mode has to be off in my.ini
• mysql max_allowed_packet should be about 8M better 16M because of LEK_skeletonfiles
• mysql must be callable by shell exec for dbupdater
• All external needed PHP libraries
• Possibility to run php scripts without timeout (see TRANSLATE-143)
• TRANSLATE-143 max execution time and memory limit, upload limits
• Shell Exec in general (actually term tagger)
• Shell exec specific: mysqldump
• check software base (needes system components).
• TermTagger: java runtime is executable, and 1024 MB memory are allocatable
• enable the possiblity of an installation without termTagger
• get_magic_quotes_gpc() === false
• finfo class is available
• app.ini is writeable for installation only
• under Windows check all extensions, which has to be activated in the php.ini (not needed, since we have no updater under windows), thats right. Indeed this depends on our way how we want to distribute the application under windows. If we generate and provide a XAMPP package, I want to be able to run a install or check script after updating it manually.
• A check of install.txt and install-changes.txt for other validations is still to be done and will reveal a bunch of more needed validations

Config Validations

• runtimeOptions.fileSystemEncoding = utf-8 (Ask user if this setting is correct, try to find out setting of the operating setting and compare with it.)
• is_file && readable check: runtimeOptions.imageTag.fontFilePath = APPLICATION_PATH 'arial.ttf'
• is_file && readable check: runtimeOptions.termTagger.dir = APPLICATION_PATH 'modules/editor/ThirdParty/XliffTermTagger'
• is_dir && readable includePaths.editorbasics = APPLICATION_PATH "/modules/editor/"
• is_dir && writeable import taskData Verzeichnis
• runtimeOptions.dir.taskData

Client Config Validations

• runtimeOptions.extJs.basepath.407 = "http://icorrect.localdev/public/js/ext/"
• runtimeOptions.loginUrl = ''
• runtimeOptions.extJs.cssFile = "/resources/css/ext-all.css" ;alternativ: ext-all.css durch ext-all-gray.css ersetzen
• ;runtimeOptions.headerOptions.pathToHeaderFile = modules/editor/header.html; die Pfadangabe ist relativ zum globalen Public Verzeichnis.
• ;runtimeOptions.publicAdditions.css.0 = 'overwrites/KUNDE/modules/editor/css/main.css' ;Das Verzeichnis KUNDE muss entsprechend angelegt werden
• BEO Specific:
  • 2012-11-30: Die URLs /public/beodatatest/testupdateallcompanydata/ und /public/beodata/?wsdl=show dürfen nur innerhalb des beo-LANs erreichbar sein.
  • "data/editorImportedTasks/TASK-GUID/export.zip" must be accessible by browser

It would be useful to check this things in the browser by an ajax request, instead on the server side. So configured URLs and paths can be also checked.
Since we have a modular application structure, this validations should also be modular, to be reusable in other applications basing on ZfExtended. For example: there are things to check in the main app.ini which are facing towards ZfExtended not only translate5.