Update: the same solution seems to still apply to dotProject 2.1.2; the post instructions have been modified for dP 2.1.2.

Update 2: fsmullin suggested a method to fix a similar error in index_table.php, the files_count_max cannot be found error when you click the FILES tab/menu item. His suggestion is now incorporated into the post.

Update 3: this post is still relevant for dotProject 2.1.3.

In one of my recent posts about project management software I stated the desire to extensively test dotProject 2.0.4. However, many shared hosting providers appear incompatible with dotProject: the right to CREATE TEMPORARY TABLES in MySQL is not granted, but is needed by dotProject.

Here’s sample error (2.0.4):

query failed(CREATE TEMPORARY TABLE tasks_sum SELECT task_project, COUNT(distinct task_id) AS total_tasks,
SUM(task_duration * task_percent_complete * IF(task_duration_type = 24, 8.0, task_duration_type))/
SUM(task_duration * IF(task_duration_type = 24, 8.0, task_duration_type)) AS project_percent_complete FROM `tasks` GROUP BY task_project)

For 2.1.2, sample error would be:

Table ‘tasks_total’ doesn’t exist

I tried looking for solutions, and here’s what I found…
Read the rest of this entry »

As described in my previous post, there are some rather simple mechanisms to enable visitor’s browser to cache content, and avoid unnecessary load on your servers. In this post I’ll take a look at some parts of the practical implementation of the caching mechanism on the server, using PHP.
Read the rest of this entry »

In this post: some caching-related HTTP request and response headers discussed.

Modern websites are “dynamic” by nature – content you get depends on a number of variables and conditions. The simplest example – being a “guest” or a “registered” user of some forum; in both cases you get content generated by the same script/program, but it differs because of your “registered” state.

Another example – web-photogallery. By design, it is wise to always keep the original photo (the largest and presumably of the highest quality). When gallery visitor’s browser requests any smaller version of the photo – we can dynamically resize (often downsize) the original and feed the resulting photo to the browser. This scheme works OK until your gallery gets more and more visitors – CPU load climbs up and increases wait time when accessing your gallery. Evidently, caching is needed.
Read the rest of this entry »

Post last updated: April 18, 2010.

Now there is a Drupal 6.x module available. It is in no way related to the migrate script(s) below.

The newest script version migrates from PHP-Nuke 6.5 to Drupal 5.x.
Download the latest version of the migration script.

In 2002 I set up a PHPNuke-6.0 – based portal. Eventually it died due to the lack of time investments and support from collaborators. Now, when time came to revive the project, I made a search and decided to use Drupal as a base CMS for the portal.
In order to migrate userbase from an old portal to the new Drupal-powered one, and following the topic at drupal.org, I found a script and its modification.
I used it to migrate only users, and made some cosmetic changes:

• added options for custom phpnuke table prefixes
• default user name is now = uname (login), not ‘temp_name’, as before
• I replaced hard-coded links to ‘migrate.php’ with links to $_SERVER['PHP_SELF'], so that if you rename the script you don’t have any problems with that
• now forum topics should not be promoted to the main page (changed 1 to 0 as hinted by Alexis)

Finally, I would like to thank both Karthik Kumar for the original script and Alexis Bellido for the 6.0_to_4.7 modification.
Read the rest of this entry »

Sometimes, writing automatic HTML forms processors, you need to post several values with the same name of the form field, e.g.:
collection_gene = str_chrom_name
collection_gene = gene_stable_id

This is against the RFC on form fields design and submitting, but this approach is used – for example, by Ensembl. I spent some time to figure out how to make HTTP_Client and HTTP_Request submit multiple ‘name-value’ pairs instead of one (the latest defined, which overrides the previous). The solution is extremely simple:
Read the rest of this entry »

If you fetch large amounts of data (e.g. over 2MB per request) using HTTP_Client (or HTTP_request), you may get “out of memory” fatal errors, especially if:

1. memory_limit is set to default 8M, and
2. you process multiple pages using single non-reset instance of HTTP_Client object.

This problem can manifest itself by producing fatal error after a couple of cycles of successful page retrieval – but always, if run with the same parameters, after some constant or only slightly variable number of cycles.

In my case the problem was that HTTP_Request (a dependancy of HTTP_Client) was holding in memory all the previously fetched pages of the current session (the ‘history’ feature). To force HTTP_Request to hold only the most recent page, you need to ‘disable’ history after creating the HTTP_Client or HTTP_Request object instance:

Hope this helps you.

If you happen to write PHP script, which uses either HTTP_Client or its dependancy HTTP_Request from PEAR, and the script is supposed to work through the HTTP proxy – here are the sample settings you need:

If your proxy does not need authorization – just drop the proxy_user and proxy_pass parameters.