Science Collaboration Framework

In the Agaric annual brainstorm, it occurred to me that the Advanced Help module could also be used for site-specific documentation— both for users and developers.

Documentation is not something you want to trust to the vagaries of the often unstable content of a site in development, but at the same time you would rather have configuration and use information embedded in the site than in a separate document of which everyone needs to keep track.

This is how one would embed it in a node.tpl.php, but this should all be done in a pre-process function instead.

In a vi text editor as reached from the command line shell with vi filename.txt or an excellent GUI such as MacVim, enter:

:%s/\r/\r/g

and your file will be beautiful, even if only parts of it were messed up with ^M non-working line breaks.

Thanks to the comment at this post.

Resolution

The entire theme disappearing issue has an identified culprit.

(It was sort of cute– devel still printed the query log, but that's all we got for each page.)

First I commented out scf.module's implementation of hook_theme(), but visiting the admin/build/modules and admin/build/themes pages didn't bring it back.

Then I commented out the implementation of hook_theme_registry_alter(), and that brought the site back (and with it, the ability to see the warning messages).

First, the guilty function, that appears to only work with the scf stub theme:

A simple way of fetching documents from pubmed, as actually used, for testing purposes anyway:

<?php
  $efetch_url = 'http://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=' . $pmid . '&retmode=xml';

// @debug
//  $efetch_load = simplexml_load_file($efetch_url);
// drupal_set_message('<pre>'.var_export($efetch_load,TRUE).'</pre>');
?>

Reference:

There is a module to provide an Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) interface to the Bibliography module.

http://drupal.org/project/oai2
http://www.openarchives.org/pmh

Even some quality modules by very good developers are still using db_query("DROP TABLE {example_table}"); rather than the schema just defined and properly used by the update.

But sure enough, the hook_uninstall API documentation example shows the use of schema:

<?php
function example_uninstall() {
  drupal_uninstall_schema('example');
  variable_del('example_var');
}
?>

Resolution

In the process of adding modules Agaric finds useful to Drupal development to a special git repository I did a bit of bash command line scripting that was fun for me:

After a bunch of wget's like:
wget http://ftp.drupal.org/files/projects/schema-6.x-1.3.tar.gz

I ran:

for a in `ls -1 *.tar.gz`; do tar -zxvf $a; done
for a in `ls -1 *.tar.gz`; do rm $a; done

Struggling with taxonomy import.

After stripping everything out, the conclusion is that taxonomy_save_term, by itself, without even the hooks to add extra data, is simply too slow, with a minimum of three database calls per term. (data, hierarchy, vocabulary)

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1048576 bytes) in /RCS/agaric/agaric-sites/scf/includes/bootstrap.inc on line 836

134,217,728

Increased to 256MB. It ran forever, then returned this:

If you want to use Drupal sessions and the logged in user object from a straight PHP script not at Drupal root but somewhere in subdirectories in a site, you will probably need to do something like I endend up doing in profiles/scf/switch.php to impersonate the Drupal site root directory.

In fact, I think the partial installation profile idea might need something like this.

(Skip down to resolution.)

Some test output code used to figure out what the domains and sessions were doing: