Posted by Branjawn on June 17, 2010 at 7:49pm
So, here is what is special about a church directory, families. In a business directory you just have one entity and their listing. In a church directory you may have 5 or 6 people, each with their own unique account, needing to be displayed as one entry.
What you really need is a block with a family photo, then names of each person, then contact info. What to do...
Comments
2 content types. 'Person' and
2 content types. 'Person' and 'Family'. (Maybe you already have a 'profile' content type for people, whatever.) Node reference each person to a Family.
Another approach is to have a Taxonomy for families, with a term for each family.
For output, use Views and group by the taxonomy or node reference field.
Hope that helps steer you in a useful direction. Good luck.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
thanks
thanks Matt. I will try the node reference idea by creating a new node type of Family.
Not working
So, the problem I'm running into here is that I used the core profile module which only responds to 'User reference' which only references the username. So, when wanting to look for John Doe, if his username is CoolMonkey then I get no results when searching for John or Doe.
and thats why you never want
and thats why you never want to use core profile module. Although I'll bet there's a contrib that provides profile search capability.
But I suggest you get content profile module instead. Besides, do you really plan to have a user account for each kid in each family?
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
response
"Besides, do you really plan to have a user account for each kid in each family?"
Yes. I mean, I don't want to, I don't know of another way to do this.
... that is an invitation for you to tell me a better way!!!
p.s. I read there is a way to Export Profile into CSV; Import CSV into Content Profile... so I am going to research that this evening. I guess if I can get that to work, I can use Node reference.
p.s.s. still, can you help me conceptualize how to do this? My idea is that I need a "Family" node for each family.
Keep your profile data in
Keep your profile data in nodes, with or without content profile module. (The limitation with content profile module is that it enforces one-node-per-user, so that will be a challenge if you expect parents to have accounts and enter data for their children, for example. So you'll need to hack around that, or not use content profile -- you may not need it.)
So 'Individuals' are one node type. 'Families' are another. Yes, you have one family node for each family, and you node reference Individuals to a Family.
Maybe Family nodes are a content profile, but individuals are not. The details are up to you depending on the specifics of your needs.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
CiviCRM
Depending on your needs you may want to take a look at CiviCRM. Here is a video if your unfamiliar - http://sf2010.drupal.org/conference/sessions/case-studies-non-profits-ja.... It offers a similar concept with the ability to setup individuals, households and organizations. You can create a household and then add contacts to that household - http://wiki.civicrm.org/confluence/display/CRMDOC/Add+Contacts+to+a+Hous.... Even if you don't end up using CiviCRM it may give you some ideas how best to structure your site using other drupal modules.
CiviCRM
I have ended up going with CiviCRM for profiles, directory, and event registration. Oh, and mailings and online contributions! Loving Civi so far!
Good choice!
That always felt like the right answer to me. Lots of power, lots of options. Also the ability to include information for people who do not want to actually be a member of the site, regardless of whether it's because they're uncomfortable with the Web (or computers in general) or only tangentially attached (for example, not a member, but want to hear about events held at the church — concerts, meetings, fall festivals, whatever else your church might host or support).
(One of these days I'll find a church that will go along with my ideas for a Drupal-based site to enrich community interactions.)
Church Drupal Site
Cliff,
Me and a friend are moving both of our churches to a Drupal-based site to enric community interactions. (One is focused on students and building articles and resources whilst the other is focusing on an adult baptist church trying to more effectively connect the church with its mission partners)
So I'm interested, what are your ideas for that kind of site? I have some ideas but I'm certainly interested in whats in other people's heads.
I would make heavy use of groups and permissions
@yautja_cetanu, my idea for a Drupal-based site included these features:
A lot of that can be done through CCK, CiviCRM, and Ubercart. But getting even one member of the congregation to join me in sketching out this idea turned out to be too much to ask.
People did step forward to tell me that they think blogs are inappropriate for church websites, or to tell me why these features can't be built (they know nothing of Drupal), but no one stepped forward to help sort out what information we have, what kinds of communication we need, and the roles and activities that tie all of that content together.
Too bad. If we built it, this site could have been a great boost to our community.
Cool, Well there are 2 of us
Cool,
Well there are 2 of us working on our church website. I think I want to build quite a bit of what you're referring to anyway and package them into either modules or distribution/contributions to modules (Most of this can probably be done without any code, just needs a pretty theme!)
1) Definitely think that is a good idea. One church I was speaking to for example just wanted one thing. They wanted a method for church members to update their own contact details through a website. This, I'm sure, could easily be done with CiviCRM and Drupal but the difficult question is how to make people know that they are able to do it and how? If someone moves house they are probably not automatically going to know that they can click anywhere nor where to click. So I'm thinking some small dynamic banner somewhere with text saying very simple news items that only appears to members of the church who log in.
This would go some way to dealing with the problems you're talking about: There would be some other stuff:
- A Rota System (Definitely into designing!) to sort out various rota including choirs, bands and other stuff for different churches
- A only database of food in the pantry. Now I'm guessing this could be done with views and cck. However I'm wondering if something like that would be a very specific tool that many churches might not want (thinking a little ahead here). I'm wondering if a generic database creation module would be better, like a Microsoft Infopath for drupal? IT feels like food in pantry is a faily simple flat database apart from the fact it has reminders.
2) I really like discussions forums to deal with issues like this. I previously built our whole youth site around www.phpbb.com and find it far more intuitive then Organic Groups. I haven't played with the Organic groups module enough yet so maybe I don't understand it well enough. I feel that organic groups requires learning that we don't find elsewhere whereas people are used to forums. (Maybe I'm wrong? Maybe Facebook groups are where normal people get training for the concepts behind Organic Groups). I think its important that advanced social media features of a Church site don't require people to know the "Drupal Way" and get their training from standard concepts on popular sites like facebook.
3) Definitely like that. I haven't played with it much but as CiviCRM is made for Volunteer Organisations and I know many churches use it I'm sure there is stuff like this out of the box. I feel like the main issue with CiviCRM is that it can do so much that it needs to have loads of features and options turned off before you can let a Pastor of a church use it! (And I think CiviCRM gives you the options to do this)
4) On our church site we'll definitely have blogs. I'm really intrigued in how we can use blogs to promote the testimonies of individuals in the church to other members of the church. Something similar to the way Wordpress or Digg use tags to both categorise and recommend posts to people with various interests. But this is just an idea at the moment. The chances are the only success I can have with this in my church over the next year are the features you're talking about.
5) Yeah, I really like http://www.desiringgod.org 's resource library. It is complicated though (from a developer, not user point of view) and has potential SEO problems like multiple URLs pointing to the same page (As you can find resources by date or category and the breadcrumbs and URLs show how you got there). I think this could become its own module, unless I can find something similar because it would need categorisation of tags, nested tags (So Sermon Series), people (standard) but most important bible passage which will probably need to be specific meta data (So people can search for talks and resources between passages). So might need custom metadata in a standard drupal resource library modules (if one exists)
6) Well there is CiviEvents!
To your final points, I know what you mean! Currently I'm building the site for the Student part of our church. This has the advantage that all the people I'm aiming at will understand social computing but is also slightly less interesting because of that. I'm really interested in how technology can solve communication problems within the church that even people without a computer can benefit from (and harvesting use cases of that).
Before building your own distribution, check out the UUs
The Unitarian Universalists maintain a Drupal distribution that works well for churches of any stripe. In fact, after I had sketched out what I wanted to do and downloaded most of the modules, I found them and realized that they had just about all I needed — including some modules I had not yet thought of. It's called the Welcoming Websites Wizard.
What I like about organic groups is that it's easier for me to tie a group membership into a person's permissions, so I can give them a link to each of their groups from their view of the home page (when they are logged in). Maybe that can be done while maintaining the discussions with phpbb, but I found it easier to work with an all-Drupal site in this respect.
Your idea of starting with the youth is a great one. If you can win them over, they will lead the church to use the Web. Parents will eventually like that they can connect to the website to confirm their children's church activities — regardless of whether the question is what kind of clothes to wear to church today (is it the youth picnic, or is that next week?) or whether there really are church youth activities on all those nights that Johnny and Susie say that's what they're doing.
You're wondering how to get folks to update their information in the church website? This was where I planned to start getting folks involved. This was my plan:
The whole idea is to get the website in their face and make it the easy way for them to do what they already have had to do. Some members will always do things the old way and will never come around to using the website, but you'll get enough participation to get pointed in the right direction, and things will get better with each succeeding generation.
For things like the food pantry inventory, the inventory itself would probably have been a simple Excel spreadsheet, but I would use Drupal permissions and roles to determine who could see what. Anonymous users might see only a cursory report — for example, "Urgently need canned fish and meat; need other canned foods; have plenty of rice and dry beans." But at least some volunteers would be able to see the complete database, and only those who are responsible for tracking the inventory would be able to replace the copy of the online database with an updated version. At least that's where we would have started. If we found another, more powerful, more convenient way to maintain it, we would develop that new way.
And of course Ubercart would help with making it possible for people to use the website to not only donate money but also target their donations when that's their choice.
Good luck with your site! Even with only two, it's so much easier than having only one. But it is still a challenge to communicate to your congregation the possibilities and what is needed to make those possibilities happen.
'nother view
Our situation is a bit different... just in case someone wanders by based on the topic and doesn't want to get pulled into the CiviCRM chasm...
First, one rule is never have two databases for the same data. One is always wrong. The church office, in our case, uses a "church management system" (yet another CMS) called Servant Keeper. Don't ask me why, they did it while I had my back turned. Anyway, that's the One True DB, because that's what the church office uses. But, it does at least export CSV files.
So, the Table Wizard module is great for this. Export one CSV file of family-specific data. Export a second CSV file of people data. Both exports need to include the family ID number (16-digit integer) which is generated by Servant Keeper, but I assume something like it must exist for most church management systems. Import and build a relationship using the family ID. Rinse and repeat as needed -- Table Wizard will replace the table and keep the relationship as long as you import the same file name(s) each time. So updates are easy for the church office to do. Then a little work with Views and you have a church directory.
And, this leaves your user accounts separate from the church directory, which I'll argue is most likely a Good Thing.
Servant Keeper how-to?
younggeezer - Any way you could elaborate on how you used Table Wizard with Servant Keeper? We have the same setup.
Does the info go both ways? Can users update their info on the site, which you can then push back to Servant Keeper via Table Wizard? What did you do for profiles? Regular profiles with fields? Content Profile? Anything like a write-up/recipe would be greatly appreciated. Thanks!
Re: Servant Keeper how-to?
I kept this very simple, mostly for my own benefit but also to keep things easy for the church office manager, who is very familiar with Servant Keeper but quite tentative about messing with a website.
The info doesn't go both ways -- the One True DB is considered to be Servant Keeper, which is certainly the way the church office views the situation. Any changes are via "send a note to the church office" and they'll change the record in SK, when then gets shown on the website after the next table upload. No use of user profiles; no connection to user accounts at all, nor Content Profile, which frankly I think is an advantage.
Basically I just use Table Wizard to import two Servant Keeper reports as CSV files (but called .txt files -- do not attempt to use Excel in any way with the 16-digit integer Family_ID: it will not preserve the integer). The two SK reports we write are, e.g.:
families: Family_ID, family_name, address, city, state, zip, home_phone, primary_email
family_members: Family_ID, firstname, lastname, work_phone, cell_phone, email
Then you create a relationship (using Relationships tab in Table Wizard) between the two tables through the Family_ID values. This allows you then to build a couple of Views, one just listing families, then another listing a family's members and their information. You can use a letter argument and glossary mode to work out an alphabetical listing of families, assuming 'family_name' starts with the last name. Then link from the family to another view listing the family members.
This seems to work well for us, so far.
Awesome
Thanks for the quick and thorough reply. I'm going to have to give this a go. Any chance you'd export your Family and Family Members views for me to build from? I'm all for reusing someone else's wheel. ;)
I think I might try attaching a correction form to the family member view, too, for easier reporting.
update on church directory implementation
In case anyone is still interested...
Table Wizard appears to be semi-abandonware, and is marginally flaky. I've replaced its function with the CSV data import capability from the Feeds module, which is easier to use. The Servant Keeper CSV exports are the same as I previously outlined, but Feeds wants a unique ID for each record in case of replacements, so the member ID from Servant Keeper needs to be part of the member table.