Dec

12

(2006)

Custom Fields in Drupal Event Signups

Filed under: Uncategorized. Tags: , , . | 12 Comments 

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 FieldsTLC 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.

Jun

6

(2006)

Drupal Module Sets for Various Website Profiles

Filed under: Uncategorized. Tags: , . | Leave a Comment 

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).

Jun

6

(2006)

Drupal Modules by Profile

Filed under: Uncategorized. Tags: , , . | 4 Comments 


Module
Simple Site
Community Site
TLC Projects
wedge Drupal Core Modules
[ ]
[ ]
[ ]
* aggregator
[ ]
[x]
[ ]
* archive
[ ]
[x]
[ ]
* block
[x]
[x]
[x]
* blog
[x]
[x]
[x]
* blogapi
[x]
[x]
[x]
* book
[x]
[x]
[x]
* comment
[x]
[x]
[x]
* contact
[x]
[x]
[x]
* drupal
[ ]
[ ]
[ ]
* filter
[x]
[x]
[x]
* forum
[ ]
[x]
[ ]
* help
[x]
[x]
[x]
* legacy
[ ]
[ ]
[ ]
* locale
[ ]
[ ]
[ ]
* menu
[x]
[x]
[x]
* node
[x]
[x]
[x]
* page
[x]
[x]
[x]
* path
[x]
[x]
[x]
* ping
[ ]
[ ]
[ ]
* poll
[x]
[x]
[x]
* profile
[x]
[x]
[x]
* search
[x]
[x]
[x]
* statistics
[x]
[x]
[x]
* story
[ ]
[ ]
[ ]
* system
[x]
[x]
[x]
* taxonomy
[x]
[x]
[x]
* throttle
[ ]
[ ]
[ ]
* tracker
[ ]
[x]
[ ]
* upload
[x]
[x]
[x]
* user
[x]
[x]
[x]
* watchdog
[x]
[x]
[x]
wedge Third Party Modules
[ ]
[ ]
[ ]
* audio
[ ]
[x]
[ ]
wedge content (CCK)
[ ]
[ ]
[x]
* date
[ ]
[ ]
[x]
* nodereference
[ ]
[ ]
[x]
* number
[ ]
[ ]
[x]
* optionwidgets
[ ]
[ ]
[x]
* text
[ ]
[ ]
[x]
* userreference
[ ]
[ ]
[x]
* weburl
[ ]
[ ]
[x]
wedge event
[x]
[x]
[x]
* event_all_day
[ ]
[ ]
[ ]
* basicevent
[ ]
[ ]
[ ]
* signup
[ ]
[x]
[x]
* front_page
[x]
[x]
[x]
* image
[x]
[x]
[x]
* img_assist
[x]
[x]
[x]
* ldap_integration
[ ]
[ ]
[ ]
* logintoboggan
[x]
[x]
[x]
* notify
[ ]
[ ]
[x]
wedge organic groups (OG)
[ ]
[x]
[x]
* 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
[x]
[x]
[x]
* robotstxt
[x]
[x]
[x]
* simple access
[ ]
[ ]
[x]
* survey
[x]
[x]
[x]
* tagadelic
[ ]
[ ]
[x]
* taxonomy_theme
[ ]
[ ]
[x]
* tinyMCE
[x]
[x]
[x]
* urlFilter
[x]
[x]
[x]
wedge views
[ ]
[ ]
[x]
* viewsUI
[ ]
[ ]
[x]
* video
[ ]
[ ]
[ ]
* workspace
[ ]
[ ]
[x]

May

29

(2006)

Battle of the Drupal Rich Text Editors

Filed under: Uncategorized. Tags: , , . | 4 Comments 

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.

  1. FCKEditor
  2. HTMLArea
  3. TinyMCE

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.

May

22

(2006)

Colophon

Filed under: Uncategorized. Tags: , , . | 6 Comments 

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.

    $modulelist = module_list( FALSE, TRUE, TRUE, NULL);

    echo '

      ‘;
      foreach ($modulelist as $amodule) {
      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.’

    • ‘;
    }
    }
    */
    ?>

Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 Canada License.