Testing Gallery/Gallery 2

There are several contrib modules for Drupal whose main purpose is to embed third party applications so they can be administered within Drupal. An example of this type is the Gallery module which embeds Gallery 2 into Drupal.

It can be very confusing for first-timers to use this type of contrib module because they somehow miss the fact that, in addition to the Drupal contrib module, they also need to download the third-party application from somewhere else and then install and configure it to work with Drupal. I managed to set up Gallery 2 in Drupal via the Gallery module and you can see the result of my test by clicking either the image on the right sidebar or the Gallery link on the left sidebar.

Not bad. However, I'm thinking what advantages are there to have all types of content within the control of a CMS? For one, many more types of content can be brought under the search and retrieval mechanisms of the CMS. What advantages are there to have some types taken cared of by external third-party applications and just linked to from Drupal? Storage and bandwidth perhaps especially if you use Flickr or YouTube to host your media files.

Quotes test

"The human mind does not work that way. It operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain. It has other characteristics, of course; trails that are not frequently followed are prone to fade, items are not fully permanent, memory is transitory. Yet the speed of action, the intricacy of trails, the detail of mental pictures, is awe-inspiring beyond all else in nature."

— Bush, Vannevar (1945, July). As we may think. The Atlantic Monthly. Available from The Atlantic Online at http://www.theatlantic.com/doc/194507/bush.

This site updated to Drupal 5.0

Woohoo! Done. My first update experience with Drupal (from 5 beta 2). So now, we should be on the just released Drupal 5.0 (and the latest stable version of CiviCRM 1.6). Lots of stuff to test, dearlings. But first, I need to catch up with lessons at Drupal-Dojo, the new learning group at groups.drupal.org, so I can be a better teacher here.

Synchronizing Drupal users and CiviCRM contacts

Ideally, we would like membership information to enter into a system from one entry point and follow a seamless sequential processing thereafter. But we know that ain't so, especially when you are trying to synchronize basically two applications here.

As have been noted elsewhere, CiviCRM has a way of automatically synchronizing Drupal user accounts with its contact profiles but not the other way around. For example, when users create accounts via Drupal's Create new account, the account created automatically becomes a CiviCRM contact which can be used in events/activities defined in CiviCRM. But when a user joins by filling out a CiviCRM membership sign-up/payment page (the Join Drupal5beta2-CiviCRM1.6 Sandbox link on the right sidebar brings a user to such a page), the info is stored in CiviCRM tables in the database but do not automatically translate into Drupal user accounts which would allow these members to participate in Drupal-based activities such as forums, blogs, etc.

A solution to the latter situation calls for an additional module plus manual intervention to integrate membership management in Drupal/CiviCRM as documented at http://wiki.civicrm.org/confluence/display/CRM/Creating+a+Drupal+user+fo.... The first situation (Drupal to CiviCRM) also has its own challenges as we have to integrate the profile info entered by the user with a CiviCRM membership dues page. I'm currently looking into this.

Syndicate content