Module development and code questions

Updated TinyMCE Module v4.6.0j (1.21.2.11j 2006/02/24 01:55:27)

Long time listener, first time caller... what I'm trying to say is, I've never contributed to a Drupal module before, and I'm not even sure if I'm doing this in the right place.

I've been trying to get the most updated version of TinyMCE installed and configured on my Drupal setup. Currently, I'm running CivicSpace 0.8.3, which I believe synchs with Drupal 4.6.5. As many of you know, the TinyMCE module 4.7.0 has been taken down from the modules area, and only 4.6.0 is available right now (but I hear is still available in the CVS). I guess TinyMCE 4.7.0 is meant to work with Drupal 4.7.0b, and since I won't be moving to Drupal 4.7.0 until CivicSpace certifies their distribution of it, I'm at 4.6.5, probably for a while.

TinyMCE 4.6.0 works fine with CivicSpace 0.8.3/4.6.5, but the documentation on the implementation of the included plugins is aimed at developers using TinyMCE within a custom installation, not with the Drupal module. Because it's not intended for those of us running Drupal, the context of the TinyMCE plugin instructions doesn't apply to how the plugin inits need to be syntaxed within our module.

So I played around with the TinyMCE 4.6.0 module for a while until I figured out the syntax, and I added in the plugins I was most interested in using. They have been added to the "Advanced" theme. Since it took me so long to figure out how to add all of this, I thought I'd provide everyone else with a copy of the tinymce.module that I modified, in case you want to use it until the next version is stabilized.

I am new to Drupal and I am developing my first module.. It all seems to work OK, other than I get a Login and Register Tab mixed with my module tabs.. I am using a CSS based template.

I have created the permissions and access control elements and they seem to work OK, however, I don't seem to be able to get rid of these unwanted tabs.

Any idea..?

While perusing the bug/feature issues for Privatemsg I realized that it might be time to rethink the way it's done, and perhaps make it more helpful and easier for developers to develop modules around it.

Originally, some ideas were proposed on this thread http://drupal.org/node/50213

RobertDouglass said that a brainstorming thread would be a good idea, and I agree.

Already we have talked about creating a function that modules and php snippets can use to send messages without a form... but there are other discussions to be had.

Should we take the opportunity to change the way messages are stored? Who can edit them? (right now both the sender and the recipient can edit the messages. While this can be useful in some cases it can be confusing in other cases, especially when messages need to behave more like intra-site email)

Also, the idea to store privatemsg as nodes came up in this issue: http://drupal.org/node/49349

Nodes are a bit complicated to store a simple message in, but it's worth looking at. I think that privatemsg maybe should be handled by the server as if it were email, using the same standards. This will probably make it a lot easier to interface with peoples inboxes if they wish. Also, I think doing a mailhandler sort of thing for custom email addresses would be nice too... if you email username@yourdomain.com it gets forwarded to the user as a privatemsg. I'm not sure how this would be possible.

I have been trying to install the e-commerce module, but without success. Iv'e ran the mysql script and placed the e-commerce directory in the module folder. Now when i login in and go to the module screen, i get a blank white screen. I've even tried taking out folders from the module like the contrib folder, but still just a blank white. Has anyone else run into this problem or have a suggestion? I'm using drupal 4.6 with php 5 on a linux machine. Thank you

Miles

I would like to create a custom module that include the following database field type:
* single-line textfield (OK)
* multi-line textfield
* checkbox
* list selection
* freeform list
* URL
* date

How can I modify the example module to include these fields?

Maybe we can create documentation for an advanced example node type!

Thanks, Darly

-------------------

The example module is documentated as follows:

Database definition:

CREATE TABLE node_example ( nid int(10) unsigned NOT NULL default '0', color varchar(255) NOT NULL default '', quantity int(10) unsigned NOT NULL default '0', PRIMARY KEY (nid) )

Implementation of hook_form().

Now it's time to describe the form for collecting the information specific to this node type. This hook requires us to return an array with a sub array containing information for each element in the form.

Code
function node_example_form(&$node) {
$form['title'] = array('#type' => 'textfield', '#title' => t('Title'),
'#size' => 60, '#maxlength' => 128, '#required' => TRUE,
'#default_value' => $node->title);
$form['body'] = array('#type' => 'textarea', '#title' => t('Body'),
'#default_value' => $node->body, '#required' => FALSE );

// Now we define the form elements specific to our node type.
$form['color'] = array('#type' => 'textfield', '#title' => t('Color'),

I've begun work on a replacement for profile.module, which I am tentatively calling profileplus.module

While I considered suggesting at least some of the changes I am making to profile.module itself, I'm concerned that they might add overhead while adding features that many users might not need. And yes, I'm also a little shy about making major changes to core modules, since this will be among my very first Drupal projects.

In a nutshell, I've noticed that a common need for site owners is to be able to add different field types to profile.module easily. Currently, you have to hack the hard-coded field types to do this.

What I wanted was a way to add drop-in extensions (a la Flexinode), that would add new field types to profiles easily.

While working on that project, I realized that it wouldn't be too hard to add a little more functionality - such as field types that don't refer to the built-in profile values field, and which are display-only. Sometimes, you want to have things display in a user's profile, but it doesn't necessarily need to be edited or stored as an actual user variable.

For instance, I wanted an easy way to add lists of "recent nodes by this user" so that they appear in profiles.

Well... I've got that working... but then I decided, it would really be better if some of this stuff appeared in a tabbed interface, so that every displayable profile field thing doesn't appear on the same page. The user/edit pages have a tabbed interface for different sections - I think that profile viewing ought to have the same thing, so that only the necessary information is shown at a time, instead of an enormous page (if you have lots of profile fields).