The first step to get the project started required getting a pair of machines installed and configured to properly support php and mySQL. Since the system will run in an interpreted language with a multi-platform backend, it should run on any machine that can support those programs. I will develop and test on two machines, one running a common Linux distribution, and one with Windows XP installed. These two platforms, properly configured, should be a solid basis for development and testing.
Windows XP comes with the ability to install Internet Information Server (IIS) right from the installation CD, or at anytime later if you choose. IIS installs and configures itself quite easily. IIS’s setup is very much like any other wizard driven setup. The default webroot of “C:/Inetpub/wwwroot” should be suitable for php and mySQL. Next, I installed mySQL server 4.1. It’s important to note that mySQL should be installed in a directory structure containing no spaces, and preferably close to the root of the drive. This is because PHP doesn’t respond well when it encounters spaces in folder names, as it sticks to a Unix style directory naming convention. After mySQL has been installed and configured PHP can be installed and configured to work with IIS and mySQL. This process is outlined in a file called “install.txt” that can be found in the root of the php folder. The manual installation process is a bit time consuming but offers the most flexibility and control. It basically involved making sure key binary files where in the “WINDOWS/system” directory as well as making necessary adjustments to the “php.ini” file. After I had followed the instructions in the install doc, IIS, php and mySQL were effectively configured and ready to go.
Any current Linux distribution is a good candidate for configuring and compiling both php and mySQL. These include, but are not limited to: Fedora, Red Hat, Mandrake, Debian and Slackware among others. Early on I decided to find a webhost offering sufficient Linux shell access instead of installing and configuring Linux myself. Using a shell account for development and testing on Linux provides some advantages. First, I don’t have to go trough the process of installation and configuration of Linux, php, and mySQL myself – a suitable host would have all of these conditions met. Secondly, having only limited administrative access to the system means I’ll have to keep the code I write as simple and straight forward as possible because I won’t be able to make any administrative configuration changes to the php and mySQL setup provided by the hosting service. This is also an advantage because it will ensure the project meets my original intent of it having ‘drop-in’ capability since it will be developed and tested on a machine that I have little administrative access to. The code I write will need to be compatible across the board, independent of software versions and configuration.
Being an avid proponent of the open source movement, Sourceforge.net was my first choice for hosting. Sourceforge.net is the world’s biggest open source software development site, hosting a monstrous 102,818 projects with 1,103,578 active users. Sourceforge is a community-oriented site where developers from across the globe can communicate and work on projects of all flavors and kind. It is the development and testing grounds for many popular open source projects including the Gimp, TightVNC and phpMyAdmin just to name a few. Sourceforge.net provides free hosting for qualified projects, as well as paid hosting for large scale projects. To qualify for hosting, the project administrator needs to submit a document outlining what the project is, its intended audience, its target platforms, and how the project is different from other similar projects. Two days after I registered and submitted my information I was given a webspace and Linux shell account with php and mySQL. The url for my project is http://simpleportal.sourceforge.net. In addition to free webspace and shell access, Sourceforge.net also provides developers with a plethora of tools to aid them in all steps of the development process. Projects are given a free CVS server for keeping project source current and organized. Sourceforge.net provides a file release system that allows developers to provide their work to the public, both in binary and source form. A system called DocMaganger is mechanism for releasing documentation about your project to the public. Sourceforge.net provides an outstanding service to the open source community and is a model for what open source developers and administrators should strive to follow.
Once I had access to both Windows and Linux platforms, I began planning the portal. Although there are many open source portal/CMS solutions available few successfully accomplish what I, in my role as a webmaster, see as useful. The motivation behind this project is not to reinvent the wheel . rather to reconfigure it. As a result, I decided to look at several open source portal/CMS systems and critique their installation and use. I decided to install and test two solutions: XOOPS v2.0 and PHP-Nuke v7.7.
The installation and configuration process for XOOPS was quite straightforward and simple to understand. By simply pointing Firefox to /xoops/install/ the installation began by prompting me for database and administration settings. The XOOPS install process did a good job of providing informative feedback if a requirement wasn.t met making the task run smoothly. Installing PHP-Nuke left much room for improvement. First of all, PHP-Nuke did not provide a browser-driven installation. Installation required manual editing of a configuration file to add database and administrative settings. It also required the manual creation and editing of the pertinent database and tables. The manual installation process isn.t necessarily difficult, but if it.s done incorrectly the user is given no helpful feedback about the discrepancies that need to be fixed in order for the system to function. This could make for a difficult day of work for those who aren.t very comfortable with their web environment. As a result, both systems were relatively easy to install and configure although PHP-Nuke could use a friendlier browser driven installation process.
Next, I used the two systems to administer a simple website. The administrative pages for both XOOPS and PHP-Nuke offer a plethora of options and configuration settings. At first glance the administrative interfaces seemed cluttered and unfocused. I was quite unsure where to start and was disappointed by the documentation available by both systems. After some time I had a basic understanding of how to operate these systems. The main problem I had with the administration of the two systems stemmed from the fact that these systems are not geared toward an actual webmaster using it. These systems are meant to be administered by a person who has little to no experience with actual website administration. Very little knowledge of actual server and site administration is required, rather through knowledge of the given system is key in successfully making it work.
Both PHP-Nuke and XOOPS are very useful under the right circumstances. They offer a plethora of options and are both in a mature stage of development. Their drawbacks are situational in nature. As a webmaster with a working knowledge of my web environment, I do not require all of the features and user interface options that these systems have. I plan on providing a simple solution written for use by a webmaster who has working knowledge of his website and computing environment. It will have a browser driven installation interface, be well documented, and provide a framework for a developer or administrator who wishes to implement further features.
