Deprecated - Drupal core

Hi, I maintain the Drupal-based website www.wikinerds.org and I have a "Thanks" block where I write:

Wikinerds Portal is powered by Drupal 4.5.2.

.

The problem is: Everytime I upgrade Drupal I need to remember to change this text.

I tried to find the Drupal Version PHP variable in the 4.5.2 source code but I was unsuccessful. I also asked on the IRC channel. Where is this variable and what is its name?

I want to replace the above text by

Just making a sub domain drupal installation on my site specifically for e-commerce and noticed 4.5.2. Read this in the changelog - http://drupal.org/CHANGELOG.txt :

- multi-site configuration:
* made it possible to run multiple sites from a single code base.

... ? but release news says 'no new features'. I'm confused.

It's cool either way, but I guess since I was just about to create another drupal installation I figured I'd ask. Thanks for the update everybody!

I have used Plone CMS where each object (docunemt, folder etc.) can have symbolic name that is used in URLs instead of numeric ID as in Drupal.
Such urls are SE friendly.

Is it possible to make such thing in Drupal ?

I'm going to make every node and taxonomy term has symbolic name that user can enter.
If such name is not specified, it should be automatically generated based on node title.

Can you suggest how to do it easy?

Running PHP 5 I got a type casting error because the xmlrpc.inc uses the resource handle to create and array key. Bad idea.

the bug

Has anyone put the API documentation in an offline format?

I am getting a cheap laptop to do my reading and writing on and won't have an nternet connection. So want to have the docs on hand along with some other items.

I did a search and found nothing. Does anyone have any idea about how large the documentation files are in terms of megabytes?

History: (see: http://drupal.org/node/14120 and the discussion that followed for the full history)

A while back Steven Dondley (aka nysus) proposed some changes to the book.module so that it would create individual blocks for individual books. It was agreed that the suggested functionality was desirable, but not the solution provided.

The preferred solution would have been to have the book.module use the menu system to create the individual blocks for the individual books.

I wrote some code to test the idea using the MENU_CUSTOM_MENU and MENU_CUSTOM_ITEM menu types as a proof of concept. It worked. However, I didn't think it would be desirable for the book.module to be creating menus of this type, because these menus are not (by any definition) custom. I had suggested that some new menu types be added to menu.inc - something along the lines of MENU_BOOK_MENU and MENU_BOOK_ITEM. This idea was not well received because it was felt that it would open the door to all module developers to ask for their own menu type. Still, it seemed that a more generic menu type that any module could use might be acceptable.

Proposal: (see patch for full details)

As an alternative I would now suggest that two new menu type flags be created, along with two new menu types.

define('MENU_MODIFIED_BY_MODULE', 0x0400);
define('MENU_CREATED_BY_MODULE', 0x0800);
/*
*....
*/
define('MENU_MODULE_MENU', MENU_IS_ROOT | MENU_VISIBLE_IN_TREE | MENU_CREATED_BY_MODULE);
define('MENU_MODULE_ITEM', MENU_VISIBLE_IN_TREE | MENU_VISIBLE_IN_BREADCRUMB | MENU_CREATED_BY_MODULE);

note there are also two other minor changes in the file to handle the inclusion of these menu types in the $_Menu array for display

In the case of the book.module, I wrote some code that would essentially replace the verbose block creation in the module by instead building menus (stored in the menu table) that maintained the book hierarchies using these new menu types. The result was the book.module automatically updated the menu system to display changes in the book hierarchy. And since the block module already has a mechanism for showing 'custom' menus as blocks, each book (and its associated menu) automatically had their own block created as well. (This is a separate patch and discussion, but I bring it up to show why the change might be desirable in the menu.inc file - and indeed necessary for me to submit the book.module patch).

The second proposal would be to add a 'module' field to the menu table. In the case of the book.module, prior to inserting the updated book hierarchy into the menu table, I delete the existing hierarchy. If separate modules are going to add/edit/delete their own menus in the menu table, it isn't enough to know that they are of type MENU_MODULE_MENU, but you would also need to know which module created them so that each module could only change its own menus and not ALL module menus. Essentially I am proposing the same thing that already exists in the block table.

The proposed changes would in no way affect how drupal works, it would just allow added flexibility for modules to create their own menus using the menu system.

I would appreciate any feedback and am happy to entertain questions regarding this proposal. I will submit an official feature request along with the patch if feedback is positive, (along with patches to the book module, database and update.inc).

Thanks
andre