D'Arcy Norman dot net » modules

Custom Fields in Drupal Event Signups

dnorman — Wed, 31 Dec 1969 17:00:00 +0000

We’re using the Event module to list our workshops at the Teaching & Learning Centre, and the Signup module to let people register to attend workshops (or other events). It’s working really quite well, but we needed to add some extra fields to the registration form so we could track Faculties, Status, etc…

“Sure,” I said, “Drupal’s open source, so we should be able to add any fields we want. Worst case scenario? We’d have to fork Signup.module and maintain our own version with our custom fields in it.”

I then proceeded to drag my feet, not looking forward to having to maintain a module for something as simple as adding some custom fields. Maybe I could use the FormsAPI and insert the fields through some custom code?

So, I poked through the signup.module source code to see what would be involved. I’d braced for some rather convoluted and involved hackery. I blocked my schedule for the day so I’d have time to dedicate to the task.

Then, I saw that the module developers had already done the work for me. They implemented the signup form’s fields as a themable method, letting me override it on a per-theme basis. Without having to touch the code for the module itself. Brilliant. Absofrakking brilliant. So, I added this code to our theme’s template.php file (the theme is called “uofc_thisisnow”):

function uofc_thisisnow_signup_user_form() {
	$form['signup_form_data']['#tree'] = TRUE;
	$form['signup_form_data']['Name'] = array(
		'#type' => 'textfield',
		'#title' => t('Name'),
		'#size' => 40,
		'#maxlength' => 64
	);
	$form['signup_form_data']['Phone'] = array(
		'#type' => 'textfield',
		'#title' => t('Phone'),
		'#size' => 40,
		'#maxlength' => 64
	);
	$form['signup_form_data']['Faculty'] = array(
		'#type' => 'textfield',
		'#title' => t('Faculty or Department'),
		'#size' => 40,
		'#maxlength' => 64
	);
	$form['signup_form_data']['Status'] = array(
		'#type' => 'select',
		'#title' => t('Status'),
		'#default_value' => t('Faculty Member'),
		'#options' => array(
			'faculty' => t('Faculty Member'),
			'staff' => t('Staff'),
			'student' => t('Student'),
			'other' => t('Other')
		)
	);
  return $form;
}

That results in a signup form that looks like this:

TLC Workshop Signup with Custom Fields

The beauty of this, since it exposes the full FormsAPI, we can add select menus, radio boxes, default values, etc… Without having to touch the code of the Signup module itself. Very cool stuff.

Drupal Module Sets for Various Website Profiles

dnorman — Wed, 31 Dec 1969 17:00:00 +0000

I've been helping to assemble some lists of modules that would be enabled by default for three "typical" website profiles that we've come up with at the TLC.

"Simple site" – a regular "static" department-ish website that is really just using Drupal as an easy way to share editing duties without requiring a geek.

"Community site" – akin to weblogs.ucalgary.ca – which may (or may not) be a superset of "simple site"

"TLC projects" – a project site supported by the Teaching & Learning Centre. May be a "simple site" or may be more complex than that. Might involve some unpretty hackery to provide things like "private" content, etc… This profile will require a bit more babysitting/handholding/documenting, and may not be for the faint of heart. That being said, we're basically using this profile for the next version of the TLC department website … (coming this summer(?) to a browser near you)

The list of default modules for each profile is online , generated by the most excellent OmniOutliner Pro 3. Each site profile is just a starting point, and may be customized from there (which is why some modules are listed, but not enabled by default for any profile).�

Drupal Modules by Profile

dnorman — Wed, 31 Dec 1969 17:00:00 +0000

Module	Simple Site	Community Site	TLC Projects
Drupal Core Modules
aggregator
archive
block
blog
blogapi
book
comment
contact
drupal
filter
forum
help
legacy
locale
menu
node
page
path
ping
poll
profile
search
statistics
story
system
taxonomy
throttle
tracker
upload
user
watchdog
Third Party Modules
audio
content (CCK)
date
nodereference
number
optionwidgets
text
userreference
weburl
event
event_all_day
basicevent
signup
front_page
image
img_assist
ldap_integration
logintoboggan
notify
organic groups (OG)
og2list
og_basic
og_block
og_book
og_civicrm
og_forum
og_gmap
og_mandatory_group
og_menu
og_moderate
og_promote
og_store
og_views
pathauto
robotstxt
simple access
survey
tagadelic
taxonomy_theme
tinyMCE
urlFilter
views
viewsUI
video
workspace

Battle of the Drupal Rich Text Editors

dnorman — Wed, 31 Dec 1969 17:00:00 +0000

This post was triggered by my need to use a few websites that are stuck in Drupal 4.6, and as such they have HTMLArea installed.

For Drupal, there are 3 options to choose from when shopping for a rich text editor to be used in content editing textareas.

Of the three, only TinyMCE has an official 4.7 compatible release.

The first two produce absolutely horrid markup. TinyMCE used to be as spectacularly invalid/nonsemantic as the others, but it’s received a LOT of love recently and its markup is actually pretty decent now.

HTMLArea produces brutal markup. Silly divs inserted for no apparent reason. Really crazy markup that I have to go in and clean up by hand if I want to make sure the code is tight and correct. That defeats the purpose of a rich text editor.

FCKEditor isn’t bad – when weblogs.ucalgary.ca was still on Drupal 4.6, that’s what it used. The markup wasn’t hideous, but it wasn’t great either. It was slightly quirky to use, but it worked (mostly).

Then, weblogs.ucalgary.ca was moved to our shared Drupal hosting environment, which runs Drupal 4.7 – FCKEditor wasn’t happy, so I dropped in the CVS build of TinyMCE.module. And the markup was much cleaner. And it integrated with Image.module. And a bunch of other nice stuff like providing a full screen editing mode.

None of them, however, cleanly “disable” themselves so I can get to raw code. Several “meta” pages on the sites have PHP code embedded, which is completely obliterated by the rich text editors. Even clicking the “disable rich text editing” link below the textarea isn’t enough because the source text has already been nuked by the javascripts used by the editor. So, I still have to make a round trip to “My Account”, edit it, and disable rich text editing for my account until those pages are edited. I’ve currently left it off by default, and call it into action by hitting the “enable rich text editing” link beneath the textarea. That makes it safe to edit any content in a site without worrying about clobbering stuff that isn’t grokked by the editor, while keeping the fancy schmancy WYSIWYG stuff just a single click away.

Colophon

dnorman — Wed, 31 Dec 1969 17:00:00 +0000

Modules enabled on this copy of Drupal:

The colophon is a list of Drupal modules used to run this site. It’s generated by calling the module_list() method, and iterating over the output, so it’s a live reflection of what’s running right now.

echo '

‘.$amodule.’

‘;
}
echo ‘

‘

/**
// Get current list of modules
$files = system_listing(’\.module$’, ‘modules’, ‘name’, 0);

// Extract current files from database.
system_get_files_database($files, ‘module’);

ksort($files);

foreach ($files as $filename => $file) {
if ($file -> status) {
drupal_get_filename(’module’, $file->name, $file->filename);
drupal_load(’module’, $file->name);

$file->description = module_invoke($file->name, ‘help’, ‘admin/modules#description’);

echo ‘

‘.$file->name.’: ‘.$file->description.’

‘;
}
}
*/
?>