Module development and code questions

I'd like to suggest that module developers put a little bit more info into the README file so that users don't have to figure out how the module works and how to configure it. It might also be a good idea to put some contact information into the README file in case a user finds a bug or wants to add a new feature.

I say this after spending about a half hour trying to figure out how the refer module works and getting it set up properly. I probably could have saved the bulk of this time if the information had been in the README.

Instead of just putting the whole shebang in the revisions field, shouldn't we put instead a diff(1) with the node's last content?

Arguably, this would force admins to have standard RCS tools available (diff, patch), unless someone knows of a PHP implementation lying around.

It's really sick to see the same data copied over and over again in the revisions field when only a few typos are being corrected in a revisionned node..

I will start working on this project soon if no-one has started this task yet.

All - I've been going through an extremely painful 4.1.0 to 4.2.0 migration. Got through the initial "Upgrade to CVS" hurdles, to upgrade the core DB table structures to conform to the 4.2.0 changes. I've been slowly working through upgrading my modules as well. I've run into severe problems with module developers making wholesale changes to the table structure of their modules, for 4.2.0, from the 4.1.0 structure.

Personally, I believe this is a bit improper software development modeling going on. A minor point release change shouldn't be implementing so many major structural changes. However, I do understand the fast and loose MO of Open Source (I've supported, coded for, and used many dozens of different Open Source tools).

Major problems come from modules that provide an SQL structure for the 4.2.0 table formats. There are no update/upgrade SQL statements, to migrate a 4.1.0 to 4.2.0 table structure. This has caused me over 2 days of work, to manually compare the tables, determine which rows/fields in the tables are changed, new, deleted, etc. Observe the contents of the cells, then decide whether to jetison the data in deleted rows/fields, or move it to another new row/field, etc...

The core engine to Drupal, it's extensibility, and flexibility are a major critical reason why I run it. However, I consistently find that there are way too few structural rules defining how things should be handled in terms of usability, upgrading, structure in how modules should work, etc...

I know there is (finally!) a big usability push occuring to try and address some things, but my major woes and issues lie with back end developmental procedures and structure. Are there any movements I'm unaware of that would help address these major flaws?

If I hadn't already invested 100s of hours of effort into getting 4.1.0 running, tweaked, tuned, and burned in on my production sites, I'd jettison 4.2.0 and move to another platform, simply because I don't have many many hours to deal with a minor point release. I absolutely grant that there are dozens of great changes, enhancements, fixes, etc... To 4.2.0, but I believe little effort has been given to those folks who have running production sites, to help them with the migration.

Some simple examples:

• some 4.2.0 "compliant" modules still use functions that have been deleted from the core (eg la(), lm() - etc...)
• changes to core functions without documenting those changes clearly in a distributed README or INSTALL guide (eg the change of page_header() to drupal_page_header() - and the *footer() function as well)
• radical alterations to the underlying table structures, with no provisions for proper migration or documentation of changes

Please don't misread me...I think Drupal is awesome, and far ahead of a lot of other stuff out there. I consider myself a very savvy end-user/sysadmin. I'm not a good coder, I make no pretense about it, but I can hack code and fix stuff here and there. With that said, I find making Drupal go a major hurdle that requires extreme amounts of my time - especially the upgrade process. I had the same and more issues from 4.0 to 4.1.0 - but I didn't have production data, I was safely able to NUKE my existing DB and install base and start fresh. That's an absurd thing to have to do.

I only wish to try and open some dialog on making things better, please don't misread my statements as being negative.

v/r

I have a Drupal node module that combines the standard "node" DB table with additional information in a table that I've titled "persona". The module is named "persona".

I would like to automatically fill in the "Title" field in the Node table, but currently, there's no apparently way for me to automatically override the "Title" field that's created by default when you define the function "persona_form". I'm wondering if the following can be done without changing the actual Drupal core:

- Rename the "Title" label to something else
- Remove entirely the "Title" text field from appearing on the form
- Automatically insert the value "Title" field based on other parameters

Specifically, I want to be able to ensure that the "Title" is standardized among all nodes of type "Persona", and I want to ensure that this somehow reflects in the UI. I don't want users to type in a title, and then have the system automatically overwrite it behind the scenes.

If this can't be done, please let me know so I can submit a feature request for the system.

Thank you!

~~~~~~~

Miscellaneous background information: I have a Drupal node module that I am writing that are used to manage Persona Sheets for a story-based role-playing game. Persona sheets describe a character that each user has to play the game with. There's some information that I required, such as "Character Name", "Character Age", and so forth that didn't fit in well with the existing Node table, so I created a Persona table with a node ID to store the extra information. What I want the title to say is "P-sheet: $character_name" where $character_name is the character name entered by the user.

I'm considering implementing a module that captures more user information than the current user module. I need name and address in addition to user name. I have two questions.

1)Is someone already doing this?
2)Is there some way to extend the user module or would the user module be replaced by this new "super" user module?

Thanks,
Joe Cotellese
www.clearstatic.org

How can I simply deactivate the teaser function in the page.module. I tried, but then, Drupal doesn't show me any content.