After turning it on, you will see this button in the upper right hand corner of your screen. 

After clicking on the "Tour This Page" tab, items on the specific page that you are on will be highlighted and a brief description will be given for each. Some items will be descriptive enough for you to understand, others will have links to a more in depth help file.

When creating events, you can define the event's capacity.  The capacity is the number of people that will be allowed to register for the event before registration will be closed.  Once an event is filled to capacity, a wait list option will automatically be displayed to the user.  When a user signs up to be on the waiting list, he will provide his name and email address.

The Event Wait List option is very simple and was designed to remain simple.  Often administrators expect that people on the waiting list will automatically be added to the event roster if a position comes available.  They will not.  Wait list members are to be used at the administrator's discretion however the administrator deems best.

Why didn't we make it more "automated"?

We considered several options for automating waiting lists, but ran into roadblocks for each of the following reasons:

• Some registrations are complicated and ask for quite a bit of information.  It did not seem appropriate to ask for all of this information up front if the user is unlikely to get an actual registration.  What happens if the registration requires payment?  Do we then collect the payment information from the user?
• What do we do in the case that a user signed up for the wait list, potentially several days or even weeks ago, but is no longer interested in attending?
• If instead we determined we would notify members of the wait list when a spot became available, how would we do this?  Should we notify the first member on the list and give them some amount of time to respond before we moved on to the next member?  What if there were two spots available, then what?

For all these reasons (and others we have certainly not dreamed up yet) we determined that it would be best to leave the control with you, the administrator.  You can decide who to contact if a spot becomes available.  You can determine how often and when.  The wait list is simply a list of people who have indicated their interest in the event.  It is up to you what you do with that information.

The purpose of a ministry is to create a "site within a site." A hub for news, events, calendars, and content separate from the site as a whole. When used in the church context, a ministry should be follow these rules:

1. Ministries should be the digital representation of an actual, active ministry (Men's Ministry, Women's Ministry, High School Ministry), and not a page for a church event that occurs sporadically.
2. They should not have subministries that are events that occur under that ministry (like Men's Bible Study or Women's Retreat). This is the purpose of using the Events feature within the Ministry Administration. An event page becomes outdated information the second after it occurs. Using the events feature will pull this information off your site automatically when it expires.
3. They should not have subministries that are really just pages of information or lists of links. Create news items in Ministry Administration for ministry updates. Post Resources (pdfs, Word Documents, links, etc.) in the ministry's Content Administration and post it on the ministry homepage.
4. A ministry should not be host to just information (like About Us or Weekend Services). This is the purpose of Pages (created in Content Administration) and, to less important, more time-sensitive information, News (created in News Administration). 

Many make the mistake of creating too many ministries and too many subministries. Take the strategy of "less is more." Fill up a few, necessary ministry pages with tons of information instead of creating a bunch of ministry pages no one visits because you don't update them.

Pasting Text From Word

When you stylize text (organize into paragraphs and lists, make boldface, italicize, underline, change font, and text size) in word processors like Microsoft Word, the program adds tags around the text to display as you command it to. Unfortunately, web-based programs use a different command languages in its tags (HTML).

When you paste text from these word processors into the Editor of your page, news item, or blog entry, these language will conflict with each other and will not display as you intend (often, you will not see this until the item is published).

Below is a look at what the tagging from Word looks like:

Pasting from Another Outside Source (Website, Other Program)

Copying text from other websites and other programs can also bring with command tags that conflict with those you add in the Editor. When copying and pasting from other sites and programs, follow the steps below to ensure that text behaves as you intend.

Here's a look at the HTML tagging brought in by another website:

Removing Conflicting Command Tags

1. Don't paste text from outside sources into your Editor.

2. After pasting your text, use the Format Sweeper in your toolbar to remove all other command language.

3. Paste your outside text into the "Paste Plain Text" box.

How to Paste Plain Text

This is the easiest way to remove all the nasty outside tags that could conflict with your HTML commands. Just follow these steps:

1. Copy your text from Word or another outside source.

2. In the new/edited Web page, right click in the body of the Editor.

3. Select “Paste as Plain Text.”

4. Paste you text in the box and click OK.

5. Stylize your text (add italics, boldface, new paragraphs, lists, etc.)

Following this routine when pasting from other sources will keep your text behaving as you command. Here is how your command tagging should look. (See how clean in comparison to the other examples?):