Creating a Scorpio development environment

Posted by Dave Redfern (Writer), Tutorials on 19 Nov 2008 @ 21:32

Introduction and Getting Started

Creating a usable development environment can be half the battle, especially if you are not familiar with configuring packages like Apache and MySQL. This tutorial, while aimed at Linux desktops running Fedora / RedHat / CentOS, offers a set of instructions on how to get up and running with Scorpio. There are additional notes for Windows users at the end of the article and a set of notes for Debian users highlighting some of the differences between Debian and Redhat based distributions.

Please note: this is NOT a guide for configuring a production server and so ignores critical issues such as security and permissions etc. The basic assumption is that you are running a desktop and want to be able to try out or build using Scorpio.

If you have access to a virtual machine, it is strongly recommended to try out in one of these first as they are essentially disposable and it will avoid any potential stability issues. I recommend VMWare Workstation or VMWare Player and an appropriate appliance.

Getting Started

You will need the following available before starting with this tutorial:

Finally for development work either a text editor (vi, emacs, nano etc) or a GUI application or IDE. My preferred application is Zend Studio (currently at version 6.1 which is built on Eclipse). This is a commercial application for Windows, Linux and MacOSX. Alternatives include Eclipse with the PDT tools installed or NetBeans 6.5 PHP Edition. Which ever you use, you should be comfortable using it.

This guide uses absolute paths to remove any ambiguity when issuing commands; the exception is when importing SQL files into MySQL.

Finally; the guide assumes that Apache etc are not installed and will need to be installed. If you prefer to compile from source with custom paths and configs, then this guide is probably not for you.

With that said, lets begin...

Installing Apache, MySQL and PHP

The first thing we need to do is install the web-server, database and PHP itself. These are not standard packages - unless you installed them during the OS installation. So long as you have a working network connection and access to the internet they can be easily installed.

Please see the appendixes for some variations in particular for CentOS / RedHat 5 and Debian. Windows users should probably look at using WAMP Server instead of the separate applications - but that is up to you.

Login to your VM or Desktop and open a console window (or just use the command line and no GUI - the GUI gives better resolution so I find it better). Become root, either via using su or if you have sudo, prefix virtually everything with sudo that follows.

su -

We will now install in one go everything that we need:

The \ are there for line wraps. This may take some time, but will install Apache, MySQL, PHP, SubVersion and phpMyAdmin along with a number of PHP extensions. You may be asked to confirm installation or to install a security certificate. Answer 'y' or 'yes' where necessary.

That should complete without error though you may see additional screens informing you of other steps you need to take (e.g. MySQL setting a root password). That will be dealt with shortly.

Once the installation is done one of the steps I prefer to take is to disable the selinux system. selinux is an enhanced security system that is very useful, but it has some extremely difficult syntax and can cause weird issues. Therefore I prefer to ensure it is disabled. You can do this by editing the selinux config file and changing the parameters to disabled (it is commented):

nano /etc/selinux/config 

If you prefer to leave it enabled, you will later have to update the security contexts on the web accessible folders for Apache. If you do disable selinux, be sure to restart your system or VM before continuing any further.

Creating a user and getting the framework

Now we have the applications we need we can begin the proper work of setting up the environment. The first part of this is creating a new user that some of the scorpio components will run under (e.g. daemons or CLI scripts). This is not essential so if you don't want to do this step, you can ignore it.

groupadd -r scorpio
useradd -r -s /sbin/nologin -g scorpio -l -M scorpio

Installing the framework

We will now get the latest development snapshot of the framework directly from SubVersion and store it in a folder called "sites" within "home". First we need to create the folder structure:

mkdir -p /home/sites/scorpio

Change to the newly created folder:

cd /home/sites/scorpio

And finally we can export from SVN:

svn export https://scorpiofwork.svn.sourceforge.net/svnroot/scorpiofwork/scorpio/trunk ./

Notice that we are EXPORTing from SVN and not doing a checkout. This copy will be detached from the repository because we want to be able to add to it later. Performing an export also means that it can added to a local version control system.

If you created a scorpio user previously, now is the time to update the ownership:

chown -R scorpio.scorpio /home/sites/scorpio

And the general permissions:

chmod -R 775 /home/sites/scorpio 

Finally, both logs and temp need to be world writable as these will contain any (funnily enough) any log files or temporary files generated by the framework.

chmod 777 /home/sites/scorpio/logs /home/sites/scorpio/temp

With that done, we can create a couple of default sites and configure those as well. As this is just a dev environment you can call them pretty much anything you like. This tutorial is going to use .local and the base sites will be site.local and admin.site.local. Change to the websites folder:

cd /home/sites/scorpio/websites

And create two new folders for our sites:

mkdir site.local admin.site.local

To make life a little easier for us, copy the controllerMap.xml file from the base to site.local. The controllerMap.xml files define the controllers that are available to the sites. Without one, the site cannot function and will fail. Each site must have a controllerMap.xml file - it cannot be inherited from other sites.

cp base/controllerMap.xml site.local/

Along with the controllerMap.xml file, a site must have a config.xml file that defines the basic settings for it. Again, sites must have their own config.xml file. We will create two basic config files for each site, first the site.local file:

nano site.local/config.xml

I use nano for text editing on the command line, this is an alternative to pico and I like it because it is simple to use. If you prefer vi or emacs or some other editor, then use that instead. Either way, the config.xml file will need the following XML code:

<config>
    <section name="site" override="1">
        <option name="parent" value="base" override="1" />
        <option name="active" value="1" override="1" />
    </section>
</config>

In nano, now press the Ctrl key (lower left hand side of the keyboard) and O (that's the o owww key and NOT zero) to writeout the changes, then Ctrl+X to exit.

Note: the baseAdminSite was removed from Scorpio version 0.3 and above.

On a production box you should set a .htaccess rule to prevent public access to any configuration files.

Configuring Apache

We will now turn our attention to the Apache server. We need to create a vhosts.conf entry so that the websites folder and our sites can be accessed. This is a very basic setup and does not look at any advanced Apache configuration directives.

First we need to create the vhosts.conf file, or update an existing one:

nano /etc/httpd/conf.d/vhosts.conf

The following should be entered as the basic configuration:

# default virtual host
NameVirtualHost *:80
<VirtualHost *:80>
    DocumentRoot /var/www/html
</VirtualHost>

# scorpio site definitions
<Directory "/home/sites/scorpio/websites/base">
    Options +MultiViews +FollowSymLinks +ExecCGI
    AllowOverride All
</Directory>
<VirtualHost *:80>
    DocumentRoot /home/sites/scorpio/websites/base
    ServerName site.local 
    ServerAlias *.site.local
</VirtualHost>

Save the changes (Ctrl+O, Ctrl+X) and first test the config file to make sure there are no errors in it:

service httpd configtest

Finally, either start, restart or perform a graceful restart of the apache service:

service httpd graceful

A graceful restart will restart the server without taking it offline.

Configuring MySQL

With Apache now largely taken care of, we can look at setting up MySQL. By default on Fedora systems it comes with no root password and only a very basic configuration file. Before actually creating any databases though, it is usually best to first set a root password, but even before that it is much better to change a couple of settings in the my.cnf file. The settings to play with are the collation and character set and to remove the old_passwords directive. Why?

Well, MySQL is developed (mostly) by a set of Swedish developers which in turn has lead to some, shall we say, dubious choices in the default configuration. This is typified by the choice of latin_swedish_ci as the default collation and Swedish as the default character set. Not particularly useful. Why they have not changed this to UTF-8 is anybodies guess - though I am sure there is a long discussion on the pros and cons. Either way; we should (actually need to) use UTF-8.

Why remove old_passwords? Because there is little to no point in using them.

So, we need to edit the main my.cnf file:

nano /etc/my.cnf

Remove the line about old_passwords and then within the mysqld section and the following two lines:

default-character-set=utf8
default-collation = utf8_general_ci

Note: for MySQL 5.2+ the above directives have been removed. Instead you should use the following to set UTF-8 as the default:

character-set-server=utf8
collation-server=utf8_general_ci

Save the changes and exit nano. Now restart mysqld:

service mysqld restart

MySQL should restart without issue. With that done we can create a password for the root account and start setting up the various scorpio databases.

To create a mysql password where one has not been set before simply issue:

mysqladmin -u root password

And specify the password you want to use.

Change directory to the scorpio SQL data folder,:

cd /home/sites/scorpio/data/sql

Connect to mysql as root:

mysql -u root -p

And create a new user. As this is a development machine I am not being too careful with permissions. In a full deployment you would need to be restrictive. Either way, there must be at least one user that has ALTER and CREATE privileges as these are needed by the dbUpdate utility.

grant all on *.* to 'scorpio'@'localhost' identified by 'PASSWORD';

Next we need to create the three basic databases for the scorpio system which are: logging, system and wurfl. Logging can be skipped, however you will not be able to use the database system log writer if you do. The command can be issued on one line or individually:

create database scorpio_logging; create database scorpio_system; create database scorpio_wurfl;

Now it is time to setup the various tables. Scorpio comes bundle with a set of SQL scripts for MySQL for these components. All the initialisation files are located in the /data/sql folder and are named COMPONENTInit.sql.

First we will start with logging. Please note that you need the full path to the SQL files, or you must cd to the /data/sql folder first before continuing.

cd /data/sql
use scorpio_logging;
\. loggingInit.sql;

\. is a short-cut for importing SQL files. For all of these commands you must ensure there is a trailing ; (semi-colon) to tell the client to execute the SQL statement. You should see a result showing the number of queries executed and if there were any errors.

Next we will add the system tables. This is slightly more involved as there are additional update SQL files that need to be applied - but only after the Init.sql file has been loaded. They MUST be executed in order of Init, then update_X where X is a number from 1 to n+1.

use scorpio_system;
\. systemInit.sql;
\. system_update_1.sql;
\. system_update_2.sql;

Finally we can add the wurfl tables for the wurfl layer.

use scorpio_wurfl;
\. wurflInit.sql

With that done, we can exit the mysql client.

exit

That is MySQL sorted. If you wish to add any other specific configuration directives feel free.

The final step to take is to ensure that MySQL and Apache will start up with the OS. This is handled via the chkconfig command:

chkconfig --level 2345 mysqld on
chkconfig --level 2345 httpd on

With that all done, we can return to the Scorpio folder and finish the configuration there.

Creating the base Scorpio config file

Scorpio requires a central config file. This is a requirement for the system to function and will always be checked during the initialisation process. Fortunately, Scorpio comes bundled with a sample config file to make it easier to create this initial file.

We will now copy this file and update it with the database settings we created earlier and adjust the logging level.

First change to the data/config folder:

cd /home/sites/scorpio/data/config

Note: in earlier version the master config file was located in /libraries. This has been deprecated in favour of the /data/config folder. For backwards support, the libraries folder will still be checked last.

Now copy the sample file to create the config.xml file:

cp sample.config.xml config.xml

We need to edit the sample to set our database user and password, so do that now. Note the additional -w parameter on nano. This preserves any word wrap which would otherwise be applied by nano - potentially breaking the file.

nano -w config.xml

The sample config.xml file comes with a variety of settings already laid out. You can change the author, copyright and version if you like - these relate to YOUR application NOT to Scorpio. The parameters that have to be updated are the database user details and password. You should change the value component to whatever user you created. If this was "scorpio" then enter that. Do this for each user.

Why are there three users? Well Scorpio is intended to be used on the CLI as well as a web-app and to help differentiate running processes a separate database username will be used by each type of application. This then allows the web process to run on a minimum amount of permissions while leaving a CLI script with greater access.

daemon processes are long running background processes that can have custom permissions if needed.

You may want to change the logLevel at this point as the sample config file of "64" is a full debug output. The various logLevels are held in the systemLogLevel class file under libraries/system/log/level.class.php.

An example of a modified config file is below, this includes additional override parameters on the database details:

<config>
        <section name="app" override="">
                <option name="author" value="Your name" override="" />
                <option name="copyright" value="your copyright" override="" />
                <option name="version" value="your version 0.1" override="" />
        </section>
        <section name="database" override="1">
                <option name="dsn" value="%TYPE%://%USER%:%PASSWORD%@%HOST%/%DATABASE%" override="1" />
                <option name="userWeb" value="scorpio" override="1" />
                <option name="userScript" value="scorpio" override="1" />
                <option name="userDaemon" value="scorpio" override="1" />
                <option name="userPassword" value="DB_PASS_YOU_CREATED_EARLIER" override="1" />
                <option name="system" value="scorpio_system" override="1" />
                <option name="wurfl" value="scorpio_wurfl" override="1" />
                <option name="logging" value="scorpio_logging" override="1" />
        </section>
        <section name="system" override="1">
                <option name="logType" value="systemLogWriterFile" override="1" />
                <option name="logLevel" value="16" override="1" />
                <option name="isProduction" value="0" override="1" />
        </section>
</config>

When you are happy, save the changes and exit nano (Ctrl+O, Ctrl+X).

Finally we can check on the CLI to see if the config is OK. The easiest way to accomplish this is by running the dbUpdate.php script in the tools folder. This will test not only that the files are OK, but also the main config file and the database connection.

Change to the tools folder:

cd /home/sites/scorpio/tools

And then run the script without any parameters. If all works as it should, you should see the help information for the script.

php dbUpdate.php

To check that the database settings are correct, run the command again but check the update status. This will query the database:

php dbUpdate.php --status

This should run without error and display a table showing no updates are needed. You may need to resize the terminal to have the output display in a sensible manner. If you are directly on the command line, then the output will overflow the screen (it is formatted for ~120 characters).

Accessing the website

If you have got this far - well done. It's been a fair amount of work, but hopefully it will all pay off!

The final step is to connect to our web site to make sure that the web side is configured properly. As we are using site.local and admin.site.local which are not valid domain names, we need to create hosts entries so that the OS knows where to route the requests. Fortunately this is very easy:

nano /etc/hosts

Add the following line:

127.0.0.1	site.local

Now save the changes (Ctrl+O Ctrl+X) and open your web browser.

If all has worked as it should you should see a test page from the framework when you visit http://site.local/ If not, or you have errors about permissions, you will need to ensure that the temp and logs folders are chmod'd to 777 and that Apache can write to the folders. If you did not disable selinux, then you will need to update the security context so that Apache can read the path /home/sites/scorpio and can write to temp and logs and additionally the config files in websites.

If you get PHP errors about 'mvcSession' could not be found, you have an error in your config.xml file under /websites/site.local. You are either missing the config file, or you have not specified the parent folder - which should be 'base'.

You can run some simple tests against this default page by adding any text you like after /home on the address bar e.g. http://site.local/home/some/additional/text. This will be displayed to you.

And that's it! Scorpio is up and running. You can now get on and build new components play with what is there (try adding a folder called 'views' to /websites/site.local, a sub folder called 'home' and a file named home.html.tpl and put any HTML you like in there and refresh http://site.local/.

Adding a pre-built component

With the basics up and running you can get on with building your own databases, tables and objects etc. Just be sure to add the database mapping to the config.xml file. Alternatively if you want an idea of what you can do with Scorpio, you can follow these steps to download and setup the Scorpio Article System.

This is a component built using the various tools within Scorpio and designed to use the existing Admin framework.

First step: backup the existing files. Either tar the whole folder or create a ZIP file or just create a copy - just in case.

Change directory to the root scorpio folder:

cd /home/sites/scorpio

And now export the latest version of the article system from SVN. As this is packaged in the same format as the main framework, we can export it directly over the top of the existing files. None of the existing files should be overwritten by this action (unless you created an article set of classes). Note that you need to use --force on the SVN command to have it export into the existing folder.

svn export https://scorpiofwork.svn.sourceforge.net/svnroot/scorpiofwork/components/scorpio.article.plugin/trunk ./ --force

With the files downloaded, we need to update the main config.xml file with a new database reference: "articles". This needs to be added in the database section:

nano -w /home/sites/scorpio/libraries/config.xml

And the code is:

Save the changes and exit nano (Ctrl+O Ctrl+X).

Now we need to setup the database and initialise it. So change to the data/sql folder:

cd /home/sites/scorpio/data/sql

And login to MySQL with a user with CREATE privileges (e.g. root):

mysql -u root -p

Create a new database using the name specified in the config file and switch to it:

create database scorpio_articles;
use scorpio_articles;

Now we can import the initialisation file to setup the basic components of the article system:

\. articlesInit.sql;

And that's it for MySQL via the client.

exit

Before continuing any further, we have to make sure there are no database updates to be applied. Change to the tools folder and then run the dbUpdate.php script and check the status of the databases.

cd /home/sites/scorpio/tools
php dbUpdate.php --status

It should report that scorpio_articles requires updating. First we perform a trial run to ensure that the dbUpdate component has been downloaded correctly:

php dbUpdate.php --update

And then we run and commit the updates:

php dbUpdate.php --update --commit

A check of the status again should show no errors and the last update status of "Success".

php dbUpdate.php --status

With that now complete we can setup the article website and admin area.

Setting up the article sites

We will need to create a couple of sites to run the article system from. For this example, I am going to use article.local and admin.article.local. You can use whatever you like, just be sure to substitute the values where necessary.

Change to the websites folder:

cd /home/sites/scorpio/websites

And create two new folders: article.local and admin.article.local:

mkdir article.local admin.article.local

Copy the controllerMap.xml file from the baseArticleSite to article.local. This will give us our controllers.

cp baseArticleSite/controllerMap.xml article.local/

Now we must create the config file:

nano article.local/config.xml

Which needs the following content:

Save the changes and exit nano (Ctrl+O Ctrl+X).

Now we do the same for the admin site:

cp baseArticleAdminSite/controllerMap.xml admin.article.local/
nano admin.article.local/config.xml

With that done, we can update our apache vhosts file with the new sites information:

nano /etc/httpd/conf.d/vhosts.conf

Save the changes, exit nano and do a configtest and graceful restart of apache if the config is OK.

service httpd configtest
service httpd graceful

Now we need to update the hosts file so that we can access the sites from our local machine. Add the following line to the hosts file and save the changes.

nano /etc/hosts
127.0.0.1	article.local	admin.article.local

The final step is to update the site config in the admin system. Browse to admin.SITE.local and go to the Sites applet under Site Editor. You will need to create entries for article.local and admin.article.local taking care to specify the correct parent site (baseArticleSite and baseArticleAdminSite respectively). Save the new records. If you have not done so already, add site.local and admin.site.local as well.

With that done, go to the Plugin Manager applet and select "New". You need to locate the config.xml file in the scorpio/classes/article folder. This config.xml file contains the details for configuring the controller information in the admin system. Ensure that the default sites are set accordingly: Admin Site should be admin.article.local and the customer site should be article.local.

Check that the active flag is set to yes and save the changes.

You can now logout from that admin system and browse to admin.article.local. You can login using whatever user accounts you set up on admin.site.local however those accounts may not have permissions so for now you should probably use the root account.

Once logged in you should be able to see under "Plugins" that the article system is now listed. If you browse to other sections you should see that quite large chunks of the main admin system have been disabled - including Site Editor and User Management. This is all down to the controllerMap.xml file. You can enable controllers using the Controller Map Builder in the main site admin (admin.site.local).

In another browser window browse to article.local. You should see the article systems default view. Unless you added articles, there will be no categories or content. You can add it as you like.

How come you can login using other details?

Scorpio uses a hierarchy of overrides from config files to actual sites. You can override specific templates or entire controllers and models on a per-site basis. This allows you to create a single application and readily retheme it by creating a new set of views. Checkout Madagasgar.com and this site (scorpio.madagasgar.com). All that is different are the view files and the theme. The application itself is exactly the same - though controllers could be overridden or re-engineered or specific functionality added quite easily and without affecting any other site.

This overriding though extends to the databases. By default a single "system" database is used for all sites. You can configure users with site specific access or general access; or if you really need a specific system database create a new entry for the site in question and override the database config for the system database. That way you can run specific sites on a specific database without worrying about permissions or traffic or conflicts.

Need to update other article databases via the dbUpdate script? No problem! Simply point the dbUpdate script to use the config file for the site in question and the updates will be applied to that database.

Variations in setting up a system

This tutorial is based on using Fedora 7+ but was actually tested using CentOS 5.2. CentOS (and therefore Redhat Enterprise 5+) require some additional work as Redhat decided to use PHP 5.1.6 as their stable PHP. Unfortunately this is too old for Scorpio which requires at least 5.2.0.

CentOS 5 and Redhat Enterprise 5

Fortunately it is possible to add in some additional repositories and to install a more recent PHP 5 without too much trouble. So for CentOS 5+ and Redhat 5+ follow these additional steps:

Install Apache, MySQL and SubVersion like normal:

yum install httpd mod_ssl mysql mysql-server subversion

And then download the following RPM files which will install additional repositories.

wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release5-2.noarch.rpm
wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-2.noarch.rpm
wget http://rpms.famillecollet.com/el5.i386/remi-release-5-4.el5.remi.noarch.rpm

Now install the rpm files by issuing:

rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Now install PHP5 and the remaining packages by using:

yum --enablerepo=remi install php php-cli php-common php-pdo php-pdo-mysql php-mcrypt \
php-soap php-xmlrpc php-mbstring php-mysql php-gd php-bcmath php-pecl-apc \
php-pecl-imagick phpMyAdmin php-xml

This should install PHP 5.2.6 (at the time of writing). Test by calling php -i on the CLI and checking the version reported. If all is good, you can then following the rest of the guide.

Debian based systems

Debian based systems use APT for package management. For the most part the package names are the same (or very similar) so you can substitute:

 apt-get install 

In place of 'yum'. If you are using Ubuntu 8.10 (confirmed to work) you can use tab completion of package names to help make it a little easier. So long as you have PHP 5.2.6 that is all that really matters.

The other thing to bare in mind with Debian systems is that they do not put config files in the same places as Fedora / Redhat and (up until Ubuntu 8.10) they do not use "service" for manipulating running processes.

For Debian systems you can find the Apache files in the following locations:

vhosts.conf in Debian contains the main vhosts settings and NOT specific site configurations. Instead sites-available entries contain just the virtual host sections and need to be symlinked to /etc/apache2/sites-enabled/ to enable them (kinda crazy but it does make some amount of sense).

MySQL config is similarly located in: /etc/mysqld/

PHP config files are again relocated to: /etc/php/ and are split down further into apache and cli and the various extensions.

The hosts file is un-affected.

One more note: if you find you are getting database connection errors because PHP cannot locate the "MySQL socket", add to the config.xml file in /libraries an option for host and set this to 127.0.0.1 which will override the socket connection. This usually happens if you change either the MySQL config or the PHP config. Best option is to not change and just use the Debian defaults.

There may be other differences, but these are the ones I have noted (and can remember).

One last thing...

Don't forget to update your firewall settings to allow connections on ports 80 and 443 (if using SSL). On Fedora you can do these by running system-config-firewall-tui which is a command line interface to iptables.

Alternatively, if you know your iptables inside out, or have an aversion to using a GUI for this; add the config manually. The config that was used for this tutorial was the following:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

The iptables config file can be located under /etc/sysconfig/iptables.

Setting up on Windows

So you want to play with Windows instead of Linux?

Well, the easiest way is to download and install WAMPServer. This will give you MySQL, Apache and PHP in a nice convenient package and a handy tool that sits in the notification area allowing easy access to the config files and extensions in PHP.

Under this environment it is usually much easier to download Scorpio and deploy it in the WAMP www folder (usually: C:\wamp\www) which saves a lot of path issues. You will need to create a vhosts file and add ensure that requests are routed to the Scorpio /websites/base folder. You can use Tortoise SVN to do the exports.

Database updates / setup can be done using phpMyAdmin which is bundled with WAMP (under linux this can be used for creating databases and users but command line is often just easier as you are there already). Again, you will need to create the various users and ensure they have sufficient permissions.

Finally; the CLI scripts can be run under Windows as there are patch files specifically for this. You will need to add the PHP CLI executable to your environment PATH first otherwise you will not be able to use "php scriptName.php". Do this by going to Start -> Control Panel and then depending on your "view" (I always revert to Classic View) select System. Go to the Advanced tab and select "Environment Variables". Finally locate in the lower panel the line that says "Path" - note that is "path" NOT ClassPath which is something different. Once Path is highlighted, select edit and then append to the existing line (DO NOT REMOVE ANYTHING just add to the end):

;c:\wamp\bin\php\php5.2.6

Note the leading semi-colon - that is required if there is not a semi-colon at the end of the existing entries (which there shouldn't be).

With that done, click OK, OK and OK a third time. You can now open a command prompt by going to Start -> Run (Windows key + R) and typing in: cmd. If you then enter php -i you should get the PHP version information.

Other points to note:

As windows is case-insensitive MySQL can do "funny" things so you need to make a choice whether to use entirely lower-case database / table names or to preserve the case. Bare this in mind if you intend to deploy to a linux system which IS case-sensitive. My preference is to enable case-sensitivity (via the my.cnf file) - though I know a lot of people disagree with this. Which ever you choose to do - be consistent!

If you do opt to lowercase everything within MySQL, the generator script will output some strange results as part of the process relies on CamelCasedTableNames. This will be addressed in a future release.

Alternatively you can run a Linux VM under windows - which is what I like to do as Windows is not particularly good for developing PHP / MySQL sites when deploying to a Linux server (in my humble opinion!).

< Return to article