Problem

This code (which is not called automatically but is a helper function for our hook_form_alter implementation) adds the suffix but does not change the forms size. Somehow these widget settings must get added later.

We thought feeds would just import back news feed items after deletion, thus the need for feed moderation, but when testing it looks like it actually keeps track of deleted feed items somewhere.

Don't see any special table for this to be stored in, though.

Hmmm.. it doesn't delete anything from the feedapi_node_item table using hook-nodeapi on node delete, but it is deleting deleted feed item nodes' urls from this table nonetheless.

Resolution

Search from 404 page does not work
http://drupal.org/node/292565

Oh wow, it's finally been fixed!!! As of yesterday!

Commit to Drupal 6 core announced in comment #67 of the above issue thread.

No need to see if the Blocks 404 module fixes it (but the module is cool too)
http://drupal.org/project/blocks404

<?php
// $Id$

/**
 * @file
 * The Author field module.
 */

Fatal error: Cannot use string offset as an array in /home/ben/code/pdonline/drupal/includes/form.inc on line 976
Call Stack
# Time Memory Function Location
1 0.0019 64260 {main}( ) ../index.php:0
2 2.7990 23389320 menu_execute_active_handler( ) ../index.php:18
3 2.8490 23579028 call_user_func_array ( ) ../menu.inc:348
4 2.8490 23579192 node_add( ) ../menu.inc:0
5 2.8490 23580296 drupal_get_form( ) ../node.pages.inc:58
6 3.3649 29258140 drupal_process_form( ) ../form.inc:119

The nodes are, in fact, being saved. They are in the Drupal database node table with a user ID of zero.

Very very oddly, however, instead of displaying $node->uid = 0 nodes as authored by "Anonymous" (or "Visitor" or whatever you changed your anonymous user string to), Drupal returns "Page not found."

Weirdness.

Anyhow, the cause in this case is the way information is getting passed to biblio_node_save.

Discovered a race condition type bug in Drupal... if you register another account while the superuser account screen has not been submitted yet, and you use the same username and password for both screens,
things break when you submit the final page of the site setup process, and you can't login as the superuser.

Only as the other user you made.

Which has no powers.

This can be fixed by changing uid 1 from its placeholder values to the username and e-mail address you want, and changing the status from disabled (0) to enabled (1).

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

A view with "all taxonomy"

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: