confirm_form() shouldn't assume that it is the only one on the form to set the '#attributes' element. Please merge the array instead of assigning it.

I've updated my Laptop to Debian Lenny and now use Firefox 3 (or rather Iceweasle 3). When I see garland-based websites, they look broken. Is that an issue with garland or with FF3?

Gabor,

using D6.x (which prints all PHP E_ALL notices), some unwanted warnings are displayed:

* Fieldset without '#attributes' predefined. Its fixed by replacing the line 1515 on includes/form.inc
<?php
  return '<fieldset'. (!empty($element['#attributes']) ? drupal_attributes($element['#attributes']) : '') .'>'. ($element['#title'] ? '<legend>'. $element['#title'] .'</legend>' : '') . (isset($element['#description']) && $element['#description'] ? '<div class="description">'. $element['#description'] .'</div>' : '') . (!empty($element['#children']) ? $element['#children'] : '') . (isset($element['#value']) ? $element['#value'] : '') ."</fieldset>\n";
?>

* Taxonomy terms, when created/edited, call taxonomy_term_path() and was supposed to give an OBJECT $term, but sometimes its just the term ID.
Its fixed by replacing the line 100 on modules/taxonomy.module (well... it fixes the taxonomy_term_path() function instead fixing the calling)
<?php
  if (is_object($term)) {
    $vocabulary = taxonomy_vocabulary_load($term->vid);
    if ($vocabulary->module != 'taxonomy' && $path = module_invoke($vocabulary->module, 'term_path', $term)) {
      return $path;
    }
    return 'taxonomy/term/'. $term->tid;
  }
  return 'taxonomy/term/'. $term;
?>

Sorry for not providing the patch file.

regards,

massa

The documentation says that any extra arguments fed to drupal_get_form are passed on to the form constructor. After some testing and looking at the source, that appears to only happen in the multistage form case.

I just noticed some errors when using some local task menu items with extra load arguments defined. After some investigation, I found that these are generated independently of the parent menu items based on the items "load arguments" and the items defined path.

The attached patch adds a check to allow the menu items to inherit their parents arguments:

The error was generated by the following menu declarations:

<?php
  $items['projects/%project/job/%job'] = array(
    'title callback' => 'jm_page_title',
    'title arguments' => array(3),
    'load arguments' => array('%map', '%index'),
    'page callback' => 'jm_page_content',
    'page arguments' => array('job', 1, 3),
    'access arguments' => array('access job management system'),
    'type' => MENU_NORMAL_ITEM,
  );
  $items['projects/%project/job/%job/view'] = array(
    'title' => 'View job',
    'type' => MENU_DEFAULT_LOCAL_TASK,
//    this would prevent the error
//    'load arguments' => array('%map', '%index'),
    'weight' => -10,
  );

// and one of the load callbacks
function job_load($nid, $map, $index) {
  $project = $map[1];
  if ($node = node_load(array('nid' => $nid))) {
    if ($node->status && $node->type == 'job' && $project->nid = $node->field_project[0]['nid'] && node_access('view', $node)) {
      return $node;
    }
  }
  return FALSE;
}

?>

read more

This is the message I receive:

* user warning: Got a packet bigger than 'max_allowed_packet' bytes query: UPDATE cache_menu SET data = 'a:991:{s:8:\"redirect\";a:26:{s:13:\"page callback\";s:24:\"cck_redirection_frameset\";s:16:\"access arguments\";a:1:{i:0;s:14:\"access content\";}s:4:\"type\";i:4;s:6:\"module\";s:15:\"cck_redirection\";s:14:\"load_functions\";s:0:\"\";s:16:\"to_arg_functions\";s:0:\"\";s:5:\"title\";s:0:\"\";s:6:\"weight\";i:0;s:13:\"_number_parts\";i:1;s:6:\"_parts\";a:1:{i:0;s:8:\"redirect\";}s:4:\"_fit\";i:1;s:8:\"_visible\";b:1;s:4:\"_tab\";b:0;s:10:\"tab_parent\";s:0:\"\";s:8:\"tab_root\";s:8:\"redirect\";s:15:\"access callback\";s:11:\"user_access\";s:14:\"page arguments\";a:0:{}s:14:\"block callback\";s:0:\"\";s:15:\ in /drupal_location/includes/cache.inc on line 109.

Small bug in the core "node" module's node.module

Current code:
<?php
function _node_access_rebuild_batch_operation(&$context) {
....
  while ($row = db_fetch_array($result)) {
    $loaded_node = node_load($row['nid'], NULL, TRUE);
    // To preserve database integrity, only aquire grants if the node
    // loads successfully.
    if (!empty($loaded_node)) {
      node_access_acquire_grants($loaded_node);
    }
    $context['sandbox']['progress']++;
    $context['sandbox']['current_node'] = $loaded_node->nid;
  }
...
}
?>
The last line in this while loop should read: <?php
$context['sandbox']['current_node'] = $row['nid'];
?>

As if the loaded is empty, $loaded_node->nid will be empty too causing an infinite loop in the batch operation, as it takes an empty value for $context['sandbox']['current_node'] as meaning it has not yet started the rebuild and starts all over again.

So, I admit that using reserved words for column names was a big mistake, but it was a typo, and I didn't know I had made it.

The gist of the bug is that db_change_field() uses backticks (`) to escape the new column name, but not the old column name. Since the column name is escaped when it is first created in drupal_install_schema(), it will gladly create a column that is a reserved word, but you can't change it after that.

Since using reserved words is an error, I'd like to change that column in an update function. But I can't.

Note that this issue is present in HEAD as well as D6.

I noticed the bug in content profile: http://drupal.org/node/302873

As long as the template provided by the module is used, the file stated in the 'file' property is included and the preprocess function is called. Once the theme overrides the template, the file isn't included any more and so the preprocess function lieing in the file isn't invoked. I noticed that in the theme registry the 'file' property isn't set any more in this case.

There is something wrong with radio buttons on node edit form. When you refresh the page the default value changes to something else.

This effect can be seen only on some radio buttons on (built in or custom) node edit forms.
Other forms does not seems to be affected..

repro steps:
1. node/add/page see your input format: it is set to Filtered HTML
2. hit refresh in your browser
3. see input format: it is set to Full HTML

you can check "Comment settings", it is also changed after refresh..

tested with Firefox3.01

when a multilingual support is disabled for given node type, then a saved node should not have language set in {node} nor in {url_alias} table, it should be saved with language = NULL

the problem is that some links will not show the url alias but shows the internal link, because the url alias does not exists for the actual language.. so I have to change the language manually for these nodes..

I'm not sure what's causing this, but I wasn't expecting this error. I have caching turned on and I occasionally get this error:

warning: gzencode() expects parameter 3 to be long, string given in /home/brad/Workspaces/Sandbox/Drupal6/includes/common.inc on line 2494.

See the attached screenshot.

Hi @all,

I just found a strange bug regarding the update.php process of Drupal. To reproduce this bug perform the following steps:

- Use a fresh Drupal install
- Check Site building / Themes -> Garland is enabled (checkbox is ticked)
- Run update.php
- Check Site building / Themes -> Garland is still the default theme, but the "Enabled" checkbox is not ticked anymore

Of course, the theme is still used when it is the default theme, but if you have other themes enabled and users can choose from them, they will get only the default theme after update until you enable all other themes again.

Hope this can be fixed soon, as we are using quite a lot of themes and it is a pain in the ass to enable all of them again after running update.php :-)

Thanx in advance & cheers

hctom

In "includes/bootstrap.inc", function "ip_address":
Instead of
array_pop(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR']))
shouldn't it be
trim(array_pop(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])))
because when the XFF header contains multiple addresses they are separated by ", ".
Same for D7.

Fatal error: Call to undefined function: db_num_rows() in /home/pojack1/public_html/nyclightwave/includes/common.inc(1547) : eval()'d code on line 11

The upgrade aside from this worked.
my site, nyclightwave.com is running 6.

Another problem is that all of a sudden the admin pages don't show up anymore.
I went into mysql and changed the Administration theme to garland, but no go.
The watchdog, has this error,
wid uid type message severity link location referer hostname timestamp variables
123662 1 page not found themes/ability/js/jquery.pngfix.js 4 http://nyclightwave.com/themes/ability/js/jquery.p... http://nyclightwave.com/admin/user/rules x.x.x.x 1219886311 N;
Checking ftp, the file is there. I'm not sure what the problem is.

Antonio

• user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM dev_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /path/to/drupal-6.4/includes/menu.inc on line 315.
• user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM dev_menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /path/to/drupal-6.4/includes/menu.inc on line 315.

how to replicate:

1. instal site normally
2. remove all tables except users, roles and watchdog
3. start re-installing site by going to example.com/install.php
4. click "Install Drupal in English"
5. Ignore the following errors, they're normal with this kind of installation.
   • table already exists
   • duplicate entry for key
   • headers already sent
6. refresh page
7. Voila! Error!

During an installation, I accidentally mv'd default.settings.php. On the third stage of the installer, the default.settings.php file was not found. The error was not handled as expected, though.

To reproduce:

1. Remove or rename default.settings.php
2. Run the installer, completing the first two pages normally.

Expected:
Garland-like installer page giving an error message in a red box.

Got:
A white screen with the following:

Warning: fopen(./sites/default/default.settings.php) [function.fopen]: failed to open stream: No such file or directory in /Users/mbutcher/Code/DrupalCore/6/drupal/includes/install.inc on line 188

Warning: Cannot modify header information - headers already sent by (output started at /Users/mbutcher/Code/DrupalCore/6/drupal/includes/install.inc:188) in /Users/mbutcher/Code/DrupalCore/6/drupal/includes/install.inc on line 618

Warning: Cannot modify header information - headers already sent by (output started at /Users/mbutcher/Code/DrupalCore/6/drupal/includes/install.inc:188) in /Users/mbutcher/Code/DrupalCore/6/drupal/includes/install.inc on line 619

Environment:
CVS checkout of DRUPAL-6 branch (from Sept 11, 2008)
Mac OS 10.5
PHP 5.2.5
Apache 2.0.59
Firefox 3.0.1

I have a problem with menu_navigation_links function. It seems to me that active-trail class is not added.

tested with page.tp.php
<?php
$menu = menu_navigation_links('navigation', 2);
print theme('links', $menu, array('id' => 'mymenu'));
?>

type url: admin/content/types/add
the "Content types" menu item should have "active-trail" class added, but it has not..

the drupal.org search does not work on "page not found" and "access denied" pages

repro:
1. goto http://drupal.org/asd
2. search for "drupal"

I'm running into two problems with form elements added to by AHAH:

1. Elements with the #ahah property don't work unless Javascript settings are already on the page. So new elements with the #ahah property don't work.
2. A file upload element requires the form enctype attribute to be set to "multipart/form-data". Adding a new file upload element can set this attribute in the server's cached copy of the form, but it doesn't change the setting in the browser.

For my current project I hacked around the problem by adding AHAH settings for all possible form elements that might be added to the page and by adding the enctype attribute "multipart/form-data" even when the initial form contains no file elements. This seems like a bug in AHAH form processing.