We assume that you have some working experience with Apache, MySQL and PHP. The installation of these required packages is beyond the scope of this document.
MySQL - http://mysql.com/
(development with version 3.22.32)
PHP4 - http://php.net/
(development with version 4.0.0)
Apache - http://apache.org/
(development with version 1.3.14)
Apache supports both IP- and name-based virtual hosts (vhosts). While running more than one engine (by using vhosts) can be very useful for development and testing purpose, it might even be more interesting for hosting companies. Therefore, we tried to support vhosts in the best possible way in order to make life of any administrator easier. We do so by making it possible to run an unlimited amount of vhosts on the same physical source tree, though by using different configuration files. Moreover, you can setup multiple configuration files in your includes-directory.
[drop@localhost drop]$ ls -l includes/*.conf -rw-rw-r-- 1 drop drop includes/www.yourdomain1.com.conf -rw-rw-r-- 1 drop drop includes/www.yourdomain2.com.conf
The only thing left to be done is to setup the corresponding vhosts in your Apache configuration file. Note that the DocumentRoot points to the same source tree twice:
NameVirtualHost 127.0.0.1
<VirtualHost 127.0.0.1>
DocumentRoot /home/www/drop
ServerName www.yourdomain1.com
</VirtualHost>
<VirtualHost 127.0.0.1>
DocumentRoot /home/www/drop
ServerName www.yourdomain2.com
</VirtualHost>
When developing drop.org it became clear that we wanted to have a system which is as modular as possible. A modular design will provide flexibility, adaptability, and continuity which in turn allows people to customize the site to their needs and likings.
A drop module is simply a file containing a set of routines written in PHP. When used, the module code executes entirely within the context of the site. Hence it can use all the functions and access all variables and structures of the main egine. In fact, a module is not any different from any other PHP file: it is more of a notion that automatically leads to good design principles and a good development model. Modularity better suits the open-source development model, because otherwise you can't easily have people working in parallel without risk of interference.
The idea is to be able to run random code at given places in the engine. This random code should then be able to do whatever needed to enhance the functionality. The places where code can be executed are called "hooks" and are defined by a fixed interface.
Even though we aim towards modularity, a basic rule is to avoid defined interfaces. We are exceptionally careful when it comes down to adding interfaces because once you give an interface to developers they will start coding to it and once somebody starts coding to it you are stuck with it.
In places where hooks are made available, the engine calls each module's exported functions. This is done by iterating through the ./modules directory where all modules must reside. If your module is named foo (i.e. ./modules/foo.module) and if there was a hook called bar, the engine will call foo_bar() if this was exported by your module.
Each module has to declare a associative array named $module that serves as the list of hooks that a module wants to export or carry out. Each entry in the array contains the name of a hook and an export function.
In our above example, $module would look like:
$module = array("bar" => "foo_bar");
| Hook name | Hook description |
|---|---|
page |
If a module requires it's own page it should provide a function named module_page. The page can then be publicly accessed via http://www.yourdomain.com/module.php?mod=module which will cause the engine to invoke module_page in order to generate the module's page. |
cron |
Modules that require to schedule some commands to be executed on regular intervals can implement the cron interface: the engine will then call module_cron at the appropriate intervals defined by the administrator. This interface is particulary handy to implement timers or to automate certain tasks like for instance database maintainance, recalculation of settings or parameters, automatic mailings and so on. |
admin |
If a module requires a spot in the administrator section it should implement module_admin. The engine will automatically add a link to the administration menus and will call module_admin when this link is followed. In order to make virtually any module maintainer's life easier, you don't have to worry about access rights or permissions for that matter. The engine will only allow priveleged users to call exported admin functions. |
The site can be almost entirely configured through a web interface by using droplets. Simply put, droplets are small bit of PHP code which will get plugged into the engine or modules powering the site. Droplets are typically used to link modules with the mainstream engine or to customize various aspects of the engine itself.
If you know how to script in PHP, droplets are pretty simple to create. Don't get your panties in a knot if you are not confident with PHP: simply use the standard droplets (i.e. those available by default) as they are just fine or ask an expert dropletber to help you creating custom droplets that fit your need.
Each droplet consists of a key of maximum 255 characters and an associated block of PHP code which can be as long as you want it to be. You can use any piece of PHP code to make up a droplet. A droplet's code is stored in the database and the engine or a particular module will use the key to find the associated piece of PHP code which will then be dynamically embedded in the engine or the module just-in-time for execution.
There are however some factors to keep in mind when using and creating droplets: droplets can be extremly useful and flexible, yet be dangerous and insecure if not properly used. If you are not confident with PHP, SQL or even with the site engine for that matter, avoid experimenting with droplets because you can - and you probably will - corrupt your database or even break your site!
Remember that the code within each droplet must be valid PHP code, including things like terminating statements with a semicolon so the parser won't die. Therefore, it is highly recommended to test your droplets seperatly using a simple test script on top of a test database before migrating to your production environment running your real database.
Note that you can use any global variables, such as configuration parameters within the scope of a droplet and keep in mind that variables that have been given values in a droplet will retain these values in the engine or module afterwards.
You may as well use the return statement to return a value back to the engine.
A basic example:
Given the droplet with key sumbit_information, used in submit.php to retrieve and display submission guidelines at the top of the story submission page. A simple code block for this droplet could look like this:
return "Welcome visitor, ... sumbission guidelines go here ...";
If we are however dealing with a registered user, we can customize the message by using:
if ($user) {
return "Welcome $user->userid, ... submission guidelines go here ...";
}
else {
return "Welcome visitor, ... sumbission guidelines go here ...";
}
For more in depth example, we recommand you to check any of the available modules and to go from there.
As said above, you can virtually use any piece of PHP code in a droplet: you can declare and use functions, consult the SQL database, access configuration settings and so on.
Cron (wich stands for chronograph) is a periodic command scheduler: it executes commands at intervals specified in seconds. It can be used to control the execution of daily, weekly and monthly jobs (or anything with a period of n seconds). Automating tasks is one of the best ways to keep a system running smoothly, and if most of your administration does not require your direct involvement, cron is an ideal solution.
Note that cron does not guarantee that the commands will be executed at the specified interval. However, the engine will make sure that the commands are run at the specified intervals as closely as possible.
When http://www.yourdomain.com/cron.php is accessed, cron will run: it queries the database for the jobs cron controls, and their periods in seconds. If a certain task wasn't executed in the last n seconds, where n is the period of that job, it will be executed. It then records the date in the database so it can know when to run it again. When all the executed commands terminate, cron is done.
Cron is handy to run daily, weekly and monthly tasks that take care of various "housekeeping chores" such as database maintainance, recalculating settings, periodic mailings, scheduled backups and so on.
The recommanded way to setup drop.org's cron job is to setup a real UNIX crontab that frequently visits http://www.yourdomain.com/cron.php: the more you visit the cron.php, the more accurate cron can and will be. If your hosting company does not allow you to use crontab, you can always ask someone else to setup a crontab for you. Afterall, virtually any host machine with access to the internet can run the crontab for you.
For the crontab, use a browser like lynx or wget but make sure the process terminates: either use /usr/bin/lynx -source http://www.yourdomain.com/cron.php or /usr/bin/wgeti -O /dev/null http://www.yourdomain.com/cron.php. Take a look at the example scripts in the scripts-directory and make sure to adjust them to your needs.
A good crontab-line to run the cron-script once every hour would be:
00 * * * * /home/www/drop/scripts/cron-lynx