Have a question not answered on one of the links below? Post a comment to this page and we’ll see if we can’t answer your question.
Choose from one of the links below, or click here to view a summary of all FAQ pages.
Are you having trouble creating an account† or logging into our web site? The most common problem is entering an incorrect user name. On our server, we ask that you use your real name, no handles, aliases or abbreviations. So you should enter both your first and last name, with a space in-between. The system will reject entries which don’t follow this convention; this is the most common problem people encounter when signing up for an account. Once you are signed up, you must enter your information exactly as before, including the same capitalization and number of spaces.
So if the system is telling you that the account name you chose is invalid, make sure you are using your first and last name (with a single space in-between). You may use middle initials and suffixes too, if you like, but remember you will have to enter them exactly the same way when logging into your account. Also, be careful not to slip in an extra space.
So what do you do if you forgot exactly how you entered your name and now you can’t log in? Request a new password. You can use the eMail address you signed yourself up with to identify yourself on the “request new password” page. [Note: Currently this feature is not working as a result of a bug introduced in a recent security update to Drupal core. In the interim, until the Drupal development team issues an update, you may request a new password by contacting SWNI staff.]
If you have a problem with your account name as you entered it when you signed up originally, you may change it under your account settings.
You may customize a number of settings related to your account. These include page layout and other user interface (UI) elements of web pages, your subscriptions and notifications settings, and more.
To get to your account settings, look for a “My account” link under your name (right). When you click on that, you’ll see a number of tabs (below). Clicking on each of the tabs give you access to various settings or information. The “Edit” tab, for example, controls a number of UI elements.
If you haven’t read the primer, please start there.
If you want to create a multi-page section, such as Neighborhood or Committee site, or just want to create multiple pages linked together in some sort of hierarchy, the Book format is probably what you want to use.
If you want to announce a meeting or special event, or place something on the calendar, you should use the event type (see Calendar events).
To create web pages on this site (or merely add comments to an existing page), you need to register for an account. Once registered and logged into the system, you should see your account name on every web page, in a block along the left-hand edge. One of the items inside that block will be “New web page.” Under that you will see a menu of content types you can create (click on the “New web page” menu item to see brief descriptions of each type and their intended purpose). The types you see will depend on the privileges associated with your account. For most users, a story or event are the types of content you will want to create. Other types serve more specialized purposes and are generally only needed by site administrators.
Once you select a content type, you’ll see a page with a number of fields germane to that content type. Fill in all appropriate fields and leave blank any which don’t apply. If a field doesn’t make sense to you, go with the default value. The “Path Alias” field is generally best left blank as the system will automatically insert an appropriate value. Required fields – those which cannot be left blank – are marked with a red asterisk.
If your page pertains to a particular neighborhood association or two, then select them from the menu. If your story applies to many neighborhoods or all neighborhoods, then don’t select any (as this will be counterproductive). The neighborhood selection scroll box looks like the image to the right.
Chose as many categories from the Topics menu as reasonably apply to your page, but again don’t select too many. Limit your choices to those which best describe your page. The topics selection scroll box looks like the image on the left.
You may use a limited set of HTML tags in your text. This page demonstrates the effects of most of them. They are useful to create italics, do bolding, create headlines, create an outline, etc. Alternatively, the “Switch to rich text editor” option may be used for this purpose without the need to know how to use these HTML tags. It is compatible with most major browsers, including Safari, Firefox, Opera, Chrome, and IE. The rich text editor inserts various HTML tags to achieve desired styling effects.
Once you have entered your text, hit the “Preview” button to see what your page will look like. If you have more than a small amount of text, you’ll see two versions of your page. The first is a “teaser,” a truncated version which will display on pages showing teasers from a number of pages (i.e. syndication), and the second is the full version of your text. You can control where the teaser breaks by moving your cursor to the point you want to break the text, and clicking on the “Break at cursor” button. While you can control the default break location, you should be careful not to include too much text in the teaser. Also, it is possible to decouple the teaser from the content of your page by deselecting the “Show summary in full view” checkbox.
Depending upon your privileges, you may be able to attach files for downloading or graphics to display in the page. Because this is a privilege which can be easily abused by InterNet outlaws, you have to apply for this privilege.
You may change your text and hit the “Preview” button as often as you like before submitting your page for publication. Once you are ready to publish, just hit the “Save” button. Even after publication, as the author of the page, you may still go back and edit it to make changes to the page.
Please Note: You need elevated privileges to upload files (including graphics) to our system. This is a security measure to protect the site against malicious attack by unknown parties. If you would like these privileges, please contact the webmaster with a short request, including your intended uses of this site.
Here’s how to insert images into your web pages. First, either edit an existing page, or create a new web page (see “A Primer on Creating Web Pages” if you don’t know how to do this.) Next you must upload your image files using the attachments dialog box (see image upper-right).
Click “Choose File” to select a file to upload. [Note: this button may be labled “Browse” or something similar, depending on your browser.] Then click “Attach” to mark the file for uploading. (It won’t actually be uploaded until you submit the page for publication.) Repeat this two-step process if you wish to upload more than one file or image. The image below shows the dialog with some files attached.
Notice the “List” checkbox? That’s to display a list of downloadable files in an attachments box at the end of your page. It would look something like this:
You probably don’t want your image files to be listed like that on the page, so uncheck those checkboxes for your image files. You will want leave them checked only for files you explicitly wish to make available for download (e.g. a PDF file). Please see the Attaching Files for Download FAQ page for details.
If you mark for upload a file which you later decide you’d really rather omit, check the “Delete” checkbox. The file will be removed when you “save” the page.
Once you have uploaded your image files, you still need to display them. Ultimately, this is done with the HTML image tag (<img src…>). There are two different methods to insert the tag:
Unless your images are small, around 20K or less, you should ensure they aren’t displayed in the teaser (i.e. the “Preview” or “Summary” section). This is can slow down the home page. It also causes problems for users with slow InterNet connections.
Factors which might inflate file sizes include image resolution and file format. For the web, 72 DPI (dots per inch) is sufficient resolution. And the JPEG format generally produces the smallest file sizes, especially for photographs. One often has an option to reduce the file size when saving JPEG images, albeit at some loss of quality. However the quality loss isn’t always noticeable. GIF is intended for line art and may produce smaller sizes in that application. Since JPEG patent issues have gone away, there’s no longer a compelling reason to use the PNG format.
Also – and this is very important – it's generally a bad idea to use width & height parameters in the image tag (<img src…>) to resize a graphic, especially if the change is significant. A rookie mistake is to upload a large sized image, reduce its size via the image tag, and think that that reduces the image on the server. It doesn’t. While that displays the image at the desired size, the reduction is done on the fly in the browser, and that creates a whole host of problems, from placing more demands on the web server, as well as the web surfer’s client machine, and it consumes precious bandwidth. An analogy would be to load all the contents of your refrigerator into ice chests, lug those heavy chests to the park, only to eat a couple sandwiches. You wouldn’t do that. You'd just make the sandwiches at home, and take along only what is needed.
Oversized images can easily be 50 or more times larger than necessary. That wastes space on the server, causes the server to work harder to deliver the image to the client (user), chokes bandwidth for both the server and client, and slows things down significantly for the client. Not only does it take longer to download the image, the browser must spend time and resources to reduce the image size to what it should have been in the first place. If the user has a slow internet connection, is low on memory, has a slow CPU, or is using a mobile device like a phone or tablet, this can really slow things down considerably.
In virtually all situations, the width & height parameters in the image tag should reflect the actual size of the image itself; they shouldn’t be used to resize images. If the image needs resizing, this should be done before uploading to the server. It is better to omit these parameters from the image tag if you don’t fully understand their purpose (which is basically to help the browser to render the page more quickly, not resize the images on the fly).
There may be some situations where you might want to make a larger size or higher resolution image available. Generally, any time the file size would be 200K or larger, it’s probably best to provide a small thumbnail image, with a link to the larger image (like you see here on the right). That way the user can see the larger image by clicking on the thumbnail. To do that, you’d upload two images, a small thumbnail and a larger full size one. You’d put the thumbnail in your <img src…> tag. Typically, you’d encase that inside a <a href…> tag, linking to the full size image.
One often omitted item is text in the “alt” parameter of the <img src…> tag. It's important to include text which describes the image. This is useful for the blind, who can’t view the image, but who may be using text-to-voice software to hear a description of the graphic. Omitting a description is the equivalent of letting a door slam shut in the face of the blind. Most people wouldn't intentionally do that. The text is useful in other situations too, such as when the browser doesn’t automatically render the image, or as a placeholder while the browser is loading the image. The thumbnail here has this description in the alt parameter: “Photo of a burgundy tinged sunflower against a blue sky.”
Please note: If you don’t know HTML, you’ll probably want to use the Rich Text editor for inserting images into your web pages rather than doing it the HTML way. The Rich Text editor provides a GUI interface which hides the HTML code from you. Start the editor, and click on the graphic icon. The controls are relatively straightforward. The rest of this discussion is explains how to do things the HTML way. If you are going to use the Rich Text editor, you may wish to skip this page.
To insert the image into your text, you use an HTML image tag, as shown here on the right. If you are not familiar with HTML, the image tag, in its simplest form, looks like this: <img src="path to file">, where “path to file” is replaced with a path to your uploaded file.
The image tag supports additional (optional) elements, some of which control how the image is displayed. For example if you embed the image tag inside a block of text, inserting align="right" will cause the image to appear on the right side of the page, with text wrapping around the image to the left. Embedding hspace="10" vspace="5" will add 10 pixels of whitespace horizontally around the image, and 5 pixels of whitespace vertically, which is visually more appealing than text which runs right up to the image. Although optional, it is always good to include the alt element. It adds text describing the graphic, which users with disabilities will appreciate. The format looks like this: alt="Text describing graphic".
The path to the file consists of “/CMS-Uploads/” plus the filename. You may use spaces in the filename provided the filename is quoted. HTML specifications actually require that the filename be quoted. Because many browsers are forgiving if it isn’t quoted, some people fall into the bad habit of omitting them.
So for a file named “img tag example.png” the path should be: <img src="/CMS-Uploads/img tag example.png">. Of course you can add more elements; a more sophisticated image tag example is: <img src="/CMS-Uploads/img tag example.png" alt="An example of the image tag in use" align="right" width="521" height="345" hspace="10" vspace="5">.
To attach files (e.g. PDF’s, graphics, etc.) to your web pages, you must upload them to our system. To do that you need a user account and elevated privileges. The elevated privileges requirement is a security measure to protect the site against malicious attack by unknown parties. If you would like these privileges, please contact the webmaster with a short request, including your intended uses of this site. Please Note: Adding images to your web pages differs somewhat from merely attaching files for download, so there is a separate FAQ on inserting images into your web pages.
To attach a file for downloading (assuming you already have elevated privileges), these are the steps to follow:
To make a file available for download, you can attach it to an existing page (by editing the page), or create a new web page (see “A Primer on Creating Web Pages” if you don’t know how to do this.) Next you must upload (i.e. attach) your file(s) using the attachments dialog box (see image on the right).
Click “Choose File” to select a file to upload. [Note: this button may be labled “Browse” or something similar, depending on your browser.] Then click “Attach” to mark the file for uploading. (It won’t actually be uploaded until you submit the page for publication.) Repeat this two-step process if you wish to upload more than one file or image. The image below shows the dialog with some files attached. In this example all the files happen to be image files, but they could be a mix of any filetype(s); the procedure is the same.
Notice the “List” checkbox? That’s to display a list of downloadable files in an attachments box at the end of your page, which would look something like this:
For most files (except image files), this is probably what you want. You might want to mention the link in the attachments box in the text of your page. In many cases, this may be all you want/need. If so, then you are done. In some cases, however, you may wish to add a link inline in your text, or may not want the file to show up in the attachments box. You control whether the file shows up in the attachments box simply by selecting or deselecting the “List” checkbox. And you can add an inline link to the file independently of whether or not it is shown in the attachments box.
Note: If you mark for upload a file which you later decide you’d really rather omit, check the “Delete” checkbox. The file won’t be removed from the list, however the file will not be uploaded when you go to publish the page. (If you are editing a page in which a file has already been uploaded, the file will be deleted from the server once you publish the page.)
To add an inline link for attached files, you can use the Rich Text editor, or do things the HTML way with this tag: <a href="path to file">link text</a>, where “path to file” is replaced with a path to your attached file, and “link text” is the text of your link.†
The path to the file usually consists of “/CMS-Uploads/” plus the filename. You may use spaces in the filename provided the filename is quoted. HTML specifications actually require that the filename be quoted. Because many browsers are forgiving if it isn’t quoted, some people fall into the bad habit of omitting them.
For example, with a file named “August Newsletter.pdf” the path should be:
<a href="/CMS-Uploads/August Newsletter.pdf">
The closing link tag would look like this:
To add a link to another web page, use the HTML “A” element. This element has an opening tag (<a>), content, and a closing tag(</a>), like this:
<a href="URI">link text</a>
The content is everything in-between the opening and closing tags, in this case the words “link text.” The content becomes your link. (If your content included an <img> element, a graphic would become be part of your link.)
The href attribute specifies the target, or URI (Uniform Resource Indicator), of your link. Although many browsers are forgiving, the URI should always be enclosed in straight quotes! This is especially important if the URI contains characters like spaces.
You can specify two types of URI’s: relative and absolute. The difference between relative and absolute URI’s is that absolute URI’s can point anywhere on the web, whereas relative URI’s can only point to the same server. While you can use an absolute URI to reference a page on the same server, there are several reasons why this is generally bad practice.
On the SWNI server, using an absolute URI to point to a resource on the SWNI server is something which can cost you a lot of work later, if we make certain onfiguration changes to the server (which is likely). So you should be in the habit of using relative links to reference pages (or uploaded files) on the SWNI website. Doing so is simple. All you have to do is omit “http://swni.org” from the absolute URI.
Note: If you are not familiar with the term “URI,” you can think of it as a “URL.” A URL is actually a specific kind of URI (as is a “URN”). URL is generally a deprecated term.
Our CMS system (Drupal) supports a type of content known as “books.” Books are really just a way to relate pages with one another in a hierarchically cascading chapter/section arrangement. This structure is extremely useful for creating a series of related pages on a given topic. It is an excellent way to organize a committee or neighborhood association website. The “Library” tab (at the top of any page) will show all the books on our site. Our FAQ is one of those books, and the page you are now viewing is a page in it.
Books are a way to relate pages with one another in a hierarchically cascading chapter/section arrangement. This structure is extremely useful for creating a series of related pages on a given topic. In a book, each page may have children (i.e. “child pages.”) Each child may itself have children. So to create a chapter or section, merely make a page (the chapter), then attach child-pages to it (pages in the chapter).
Pages, chapters and sections of the book may be easily moved around. They may be moved to other areas of the book, or to another book entirely, or made into a new book in and of itself. When a page is moved, all its children (and any of their descendants) come along for the ride.
When a book page is displayed, links to its children (if any) are automatically listed at the bottom of the page (as well as links to “previous” and “next” pages, and a link to move up one level in the book hierarchy). When a page, section or chapter is moved, those lists are updated automatically, without the need to edit the parent page(s). The “printer-friendly version” link at the bottom of a book page allows you to view multiple pages of the book at once.
Another advantage to the book structure is the book navigation block (on the upper-left of a book page), which looks something like the image here on the right. It displays the name of the book in the title, and presents links to its chapters, and the hierarchy down to your current page (plus siblings and children). Pages without any children are denoted with a bullet in front of them; pages with children (e.g. sections/chapters) are preceded by a triangle (or arrowhead).
To learn how to create and manipulate book pages, read the other pages of this section (by following the right pointing link below, or use the menu links for FAQs on the upper right). Additional information about books may also be found in the Drupal handbook on books.
Creating a book starts by creating a “Book page,” then adding additional pages to it. In order to create book pages, you generally need to ask for “book” privileges. Only then will you see some of the book creation options, such as the “Outline” tab, or “Book page” type. With proper permissions, different people may work collaboratively on a book.
The best practice is to use the “Book page” type when creating new pages in a book. The easiest way to do this is to use the “add child page” link. You’ll find one at the bottom of every book page. Clicking on it creates a new “Book page,” with the current page automatically selected as its parent.
Non-book pages (i.e. already existing pages in the system) may be added to a book. So non-book pages you posted previously, which you hadn’t intended to be part of a book, for example, may easily be added without the need to recreate the page as a “Book page” type. Because these pages lack the “Parent” and “Weight” parameters (necessary for positioning the page within a book) in their creation/edit dialogs, those parameters are made available under an “Outline” tab for the page (you will see the “Outline” tab alongside the “View” and “Edit” tabs if you are the page’s author and have book privileges).
Note: The “Outline” tab is a bit of a kludge to retrofit the book structure onto non-book page types, something Drupal did not originally support. You will not see it on a “Book page” because you can choose a parent when you create (or edit) it. Since other page types lack this option on their creation/edit pages, they require the “Outline” tab to retrofit that functionality. This is a subtle difference between a “Book page” and a “Page” type.
Strictly speaking, new books are only created when a page is assigned “<top level>” as its parent value. Only system administrators can do that. However a book may be effectively started at any level by anyone with book privileges, and later moved by an admin to become a truly standalone book. Technically, such books begin their lives as chapters, and are later promoted to book status. The Community Webmasters group on our site provides a place where you can create a book prototype which is generally out-of-sight of the public (and search engines), until you are ready to take the book live. All that needs to occur is for the top page of your book prototype to be moved elsewhere. Because all the links are relative, your whole book – and all its descendants – can therefore be moved by one simple page edit. You can use this approach with whole books, chapters, sections, or single pages.
Books are a way to relate pages with one another in a hierarchically cascading chapter/section arrangement. Strictly speaking, our CMS doesn’t support chapters or sections. There are only book pages, and links to ancestor pages. But we can easily create data structures which resemble chapters or sections, so it is very useful for us to use these metaphors.
In a book, each page may have children (i.e. “child pages.”) Each child may itself have children. So to create a chapter or section, merely make a page (the chapter), then attach child-pages to it (pages in the chapter).
Chapters/sections are merely pages with children. As such, it is possible to put a great deal of text into a chapter page. Be careful about this as too much text may obscure the chapter contents. Chapter and section pages should be very succinct, generally no more than a short paragraph. Put the bulk of your content in the pages of the chapter or section.
One approach to books is to limit, as far as possible, each page to a single topic, then organize related pages into chapters or sections. Be forewarned that you can easily carry this too far, creating a complex and difficult to navigate hierarchy. Striking the perfect balance between the total number of pages and amount of text on a page is more art than science. Fortunately, you can edit and rearrange.
With well chosen titles and divisions of content, it is possible to create an extremely accessible layout for your content.
To add an event to this web site’s calendar, all you need to do is create content of type “event,” filling in all the fields appropriate to your event, and leaving blank any which don’t apply. If you don’t know how to create web pages on our system, read the FAQ page on Creating Web Pages.
Be sure to choose one or more appropriate topics for your event. If it is a committee meeting, for example, you’ll want to select “meeting” and the committee (e.g. Transportation, Board, Trails, Public Safety, etc.) If a topic for your committee does not exist, ask the webmaster to add it.
Please note that there are separate fields for agenda and description. The description field will show up in the event summary, so it is best if it is relatively succinct. The agenda field is optional, if you don’t have a formal agenda to post, or if you want to add the agenda later. If you don’t have your agenda finalized, you could post a preliminary agenda and mark it as such, or you could simply put in “TBD” or leave the field empty. You can always edit your event page later by hitting the “edit” tab at the top.
If you fill in a street address and city information in the location fields, the system will automatically create a Google Maps link for you. Brief instructions for each field appear just below the field’s entry box.
In general, if an optional field is left blank, it will be omitted from the event’s web page; even the title for the field will not appear on the page. For example, you would normally leave the “cost” field empty for committee meetings, and the word “cost” would not appear on the page. On the other hand, if you entered “free” into the “cost” field, a line would appear on the page which looked something like: “cost: free.” In some circumstances, this might be what you want. But for many events, such as a committee or neighborhood meeting, it is probably unnecessary.
Leave the “repeat” field unchanged, unless you wish to set up a recurring/repeating event.
Note: If the “End” date & time is the same as the “Start,” only the “Start” date & time will be displayed.
Did this page answer all your questions? If not, please post a comment.
Note: We have made some changes to our system, and this information may be out-of-date. Please report any errors you might find by adding a comment below.
It is possible to create repeating events, which are extremely useful for monthly meetings. Modeled largely on the iCal RRULE standard, it is possible to define events which repeat at regular intervals (e.g. the 2nd Thursday of each month, etc.) Most SWNI committee and neighborhood association meetings can therefore take advantage of the repeat feature.
Repeating events may be perpetual, end on a certain date, or repeat for a specified number of occurrences. Exceptions to the pattern may also be defined.
To define a repeating event, it is usually best to create an event template using the date and time of the next event. Fill in all appropriate fields which are unlikely to change from one event to the next. For example the agenda for meetings usually changes from one meeting to the next, so you’ll want to leave that field empty (even if you already know the agenda for your next meeting). Once you have the template in place, it’s just a matter of editing each individual event later on with date-specific information, such as agenda; recurring information, like meeting location, is already filled in for you from the original template and requires no further entry.
Set the date and time for your next event. If the “repeat” field is collapsed (which is usually the case), you’ll need to click on it to see its options, which are: “Repeat type,” “End Settings,” “Advanced” and “Exceptions.” Set all which are appropriate, leave unchanged any which don’t apply or which you don’t understand.
Repeat type is the interval at which this event is to repeat. Options include: Daily, weekly, monthly and yearly. While these are straightforward, what is not immediately obvious is how this may be combined with the “Interval” setting under the “Advanced” section. Setting up a monthly event with an interval of 3 defines a quarterly event. Likewise a weekly event with an interval of 2 defines an event which recurs every other week.
End Settings determines when to end the recurring event schedule. You may choose to end it either on a specific date, or after a certain number of events (but not both). To define a perpetually recurring event, leave this field unchanged/undefined (i.e. the default settings).
Interval acts like a multiplier expanding the schedule. So a weekly schedule becomes biweekly (i.e. every other week) with an interval of “2.”
Days can be used to specify a day of the week, a day of the month, etc. It has many options, so scroll through it to determine if one(s) are right for you. This field has an option to select, for example, an event which recurs the 2nd Thursday of each month.
Months can be used to specify irregular patterns. Usually you’ll leave this field unchanged/blank. With it, you could specify a pattern of events, for example, which occurs during only a few months in the year. For regularly recurring monthly events, you would normally leave this field blank (and set the “Repeat type” to “monthly.”)
Exceptions can be used to exclude certain days, months, etc. Exception dates exclude the creation of an event which is otherwise within the repeat sequence.
Generally speaking, multiple selections within the same parameter use an OR comparison for determining the pattern (e.g. Monday OR Tuesday OR Wednesday). Choosing multiple parameters uses an AND comparison between the parameters (e.g. on Monday AND in March). So, setting the days parameter to Monday, Wednesday – and the month parameter to July, August – would result in this comparison logic: Occurs on (Monday OR Wednesday) AND (July OR August.)
For a your typical monthly meeting, set “Repeat type” to “monthly”, “End Settings” at their default values (i.e. unset), “Interval” set to “1”, “Days” to the appropriate value (e.g. 2nd Thursday), leave “Months” and “Exceptions” unset.
Once a repeating event is defined and posted (i.e. submitted), you’ll eventually want to edit each individual event it spawns to provide date-specific information, such as the agenda, a room change, or whatever. Under the section titled Apply edit(s) to: you’ll be given three options: “This occurance only,” “This occurance and all future occurances,” or “All occurances.” In most cases, you’ll want the default of “This occurance only” as that leaves your default template unchanged. If you ever need to edit your default template, you would choose the “This occurance and all future occurances” option.
A help information page for the repeat module may be found here.
Did this page answer all your questions? If not, please post a comment.
We have installed the Webform module for creating various one-off forms such as contact forms, surveys, order forms, reservations, CRM requests, and more. Since this can be a technically challenging module to use, advanced user permissions are required to create Webforms.
If you have the proper permissions, you will see a “Webform” type under the “New web page” menu. Start off by giving the webform a title, description, confirmation message, set up eMail settings and the like. After you “save” the Webform, you can go back to edit it. Under the “Edit” tab, you will see a “Form components” sub-tab; this is how you build your form. There are several component types available: fieldset, pagebreaks, grid, textarea, textfield, select (checkboxes, pulldown lists), email addresses and more.
There are some screencasts available (a video is worth a thousand words):
Additional info may be found in the Drupal Webform documentation.
As a security measure, in order to embed YouTube videos – or content from other providers – you’ll need elevated user privileges. To determine if you have sufficient privileges, click on “Input format” (which is located under the “Body” field’s text input box). If you see “YouTube” listed, as in the example below, then you have the privileges necessary to embed YouTube videos. This input format enables the <object> <param> and <embed> HTML tags, which are necessary to embed videos from YouTube, and many other content providers. If you fail to select the YouTube input filter, these tags will be filtered out, and videos won’t appear on the page. Even if you are using a video provider other than YouTube, you must still select the “YouTube” filter.
To embed a YouTube video, go to the YouTube site and select the video you’re interested in embedding. Next, click on the <Embed> button, then select the options you want to select (e.g. frame border, size, etc.) After making your selections, copy the code snip-it, and paste it into the body field where you’d like your video to appear. The procedure should be similar for other video content providers.
For example, the code snip-it below was obtained from YouTube (the Object tag was manually tweaked to align the video to the right side of the page, and to add ten pixels of whitespace around the vertical & horizontal borders)…
<object width="660" height="405" align="right" vspace="10" hspace="10"> <param name="movie" value= "http://www.youtube.com/v/z0cWxoK9ElY&hl=en_US&fs=1&rel=0&color1=0x5d1719&color2=0xcd311b&border=1"> </param> <param name="allowFullScreen" value="true"> </param> <param name="allowscriptaccess" value=“always"> </param> <embed src= "http://www.youtube.com/v/z0cWxoK9ElY&hl=en_US&fs=1&rel=0&color1=0x5d1719&color2=0xcd311b&border=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="660" height="405"> </embed> </object>
…produces the video on the right:
You may want to add <br clear="all"> to the bottom of your body field on any page with embedded video; this ensures that your video doesn’t trounce on the footer Drupal automatically appends to each page.
Note: You may embed videos from providers other than YouTube, provided they don’t require HTML tags other than those provided in the YouTube Input filter. If they do, their videos may not display properly. The name “YouTube” was chosen as the Input filter name simply because it is a popular video content provider (and because it is known to work with YouTube). That name choice in no way restricts which video content providers may be used.
We don’t allow uploading videos directly to the SWNI server because we don’t have sufficient bandwidth and other resources to serve video directly from our server.
If you wish to make a page available only to members of a certain group, but unavailable to all others, select the group(s) to which you wish to grant access, and uncheck the “Public” checkbox, in the Groups area (when creating or editing a page):
In this example, only members of the Community Webmasters Group will be able to see this page.
You may wish to have the system automatically notify you when something new is posted to a group. This may not be the default, so you may need to enable this feature for each group you wish to track; you can always turn it off if you don’t like it. When enabled, the system will notify you when content is added or changed in a group.
To enable this feature, select the “Groups” sub-tab, under the “Notifications” tab in your account settings, and check the appropriate checkboxes (and other options) for each group you wish to track (you must be a member of the group):
Then click on “Submit” or “Save.”
To create minutes for meetings, choose the “Minutes” content type under the “New web page” menu. Then complete the appropriate fields. Most fields are optional (except for those marked with an asterisk: *). You should complete optional fields if you have relevant content for them, otherwise leave them blank. When done, it is a good idea to Preview your work before Saving.
Did this page answer all your questions? If not, please post a comment.
Calendar of Events, Officers/Contacts, Meeting Minutes, SWNI map, Neighborhood Map, Bylaws, Photo Gallery.
After you create your new page, you will need to move it to the correct location:
You can only edit pages that you have created.
Highly Recommended: Before you upload pictures to the SWNI site, use a program – such as Picasa (Windows) or Preview (Mac OS X) – to compress photos to under 70 KB. This will allow them to load faster when someone clicks on your web page (especially those using a dial-up connection). And they still look good. Once you’ve done that, you’re ready to upload the pictures…
The previous method will provide a link which a visitor must click to see the picture. That’s probably not what you want. Instead of links, it looks better if you display the actual photos, so the user does not need to open each file. Example: see the Marshall Park photo gallery
For example, a PDF file of Bylaws (note: PDF files are recommended. RTF files are not allowed.)
For example, a link to a PDF file of Bylaws .
This is useful if you have several pages underneath one page, and you want to change the order they appear.
You can only delete pages that you have created.
On the SWNI site, visit the FAQ for Creating an Account, Logging in, Creating Web Pages, and more!
Users may change subscription options via the web, including:
These topics are covered in the Mailman List Member Manual on the Mailman site.
RSS (Really Simple Syndication), XML and Atom feeds – known generically as web feeds – are useful for keeping abreast of web sites which update often. When you subscribe to a web feed, you see an abbreviated list of articles, much like a table of contents for a magazine. Web feeds contain a title, a “teaser” showing a little of its content, and a link to view the whole article. This is a convenient and time-saving way of scanning new content on a web site. You can quickly find those pages of interest without wasting time loading the “stinkers.”
Here’s a sample feed from our site:
It order to get the most out of a web feed, you’ll want to use a web browser with built-in web feed support. You can also use a stand-alone feed reader, but built-in browser support is more convenient. The Safari browser (pictured above and inset below/right) has the best built-in web feed support of any browser, and is available for both Mac and Windows. It tracks feeds and displays a count of the articles you haven’t read yet. It can also aggregate feeds, meaning that it can merge the contents of multiple feeds, sorted by the criterion you select, and seamlessly display all articles as though it were a single web feed. By adjusting the “Article Length” slider, you control how much (or little) of the teaser you see. A “Search” area is provided to filter articles based on keywords inside the feeds. And feeds may be filtered by their age as well.
When you place web feeds in your toolbar, Safari automatically looks for and displays a count of the new articles available. If you place web feeds inside a toolbar folder, the “new” count is actually an aggregate of all the web feeds inside. You may choose to view an individual web feed, or display them as an aggregated collective (see inset).
Firefox is another browser which supports web feeds (via plug-ins), although not as smoothly and seamlessly as Safari’s interface. Sage is perhaps the best of the Firefox web feed reader plug-ins. However by the time you read this, there may be a new kid on the block. Check out Sage first, then if you feel like experimenting, try out some of the other plug-ins.
Once you start using web feeds, you’ll wonder how you ever got along without them.
The Wikipedia has a detailed write-up about RSS feeds.
If your Neighborhood Association or committee would like to create a home page on the SWNI server, please do the following:
Have questions? Add a comment to this page.
We have installed the open-source Mailman mailing list software on our server. This enables us to quickly and easily create community mailing lists for a variety of purposes and audiences. Sending eMail to list subscribers is simple, and automation handles the drudgery of maintaining subscriber lists. Your lists will each have their own home page (as will each subscriber), so folks will be able to locate and self-subscribe to your list. You need not know subscribers’ eMail addresses, worry about bounced eMails, etc.
In general, the way mailing lists work is you send an eMail to the list address, and it automatically rebroadcasts it to the list subscribers. The list does not disclose the eMail addresses of subscribers when sending out messages (except that of the message sender).
With Mailman, users can manage their subscription via a web interface (or through eMail, if they prefer). This includes changing eMail addresses, various list options, or unsubscribing. Please see Mailing List Guide for Users or the Mailman documentation for details.
Use this form to create a mailing list. Initial list owner will receive an eMail notification and instructions. List owners may add additional list owners and/or moderators.
Only server administrators can create or delete a mail list. The person assigned as list owner, however, then has complete control over list configuration and management.
List owner’s may assign additional list owner’s or re-assign list ownership, and they may also assign moderators (who may approve posts, but may not change list configuration settings.)
To request that a list be created for you, send the following information: Name of list (no spaces), and list owner’s eMail address.
Once a list is created, the system will send the list owner an eMail. The owner can then configure the list as desired. For most situations, the defaults will suffice. However list owner’s should review and, if necessary, tweak the list configuration settings to suit their particular needs/application. Please see “Configuration” for the most important settings list owner’s should consider/review.
Once your mailing list is set up, you should review the list settings. Mailman has a wealth of configuration options; many are esoteric. Fortunately, relatively few need to be considered by list owners since most have reasonable defaults and may be safely ignored. Only the first three listed below in the General Options section are essential. All other parameters mentioned herein (a small subset of all available) are optional, but do control how your list operates, so are worthy of your consideration. Exploring options not mentioned below is primarily an exercise for the adventurous.
On the admin pages, each option has a brief description, and a link to what is usually a more detailed description of that option. Please note that when you modify options listed on the admin pages, no changes are made until you hit the “Submit Your Changes” button. The general rule of thumb is: If you don’t understand what an option does, leave it alone. The list owner welcome eMail includes a link to the main list administration page, and the password you need to access it. There are around two dozen configuration pages, but you need concern yourself with only a few:
You should be sure to supply values for three settings: “A terse phrase identifying this list” (which appears next to the list name on the “list of mailing lists” page, as well as in the header of the list’s subscription page and elsewhere), “An introductory description” (which appears on the list’s subscription page), and “List-specific text prepended to new-subscriber welcome message” (which in most cases should be the same as – or very similar to – the introductory description; this text is included in the welcome message eMail and is particularly valuable to people you might conscript to your list). Adding some text to “Text sent to people leaving the list” is a nice touch; it will be included in the confirmation eMail to users who are unsubscribing from your list.
You may change the capitalization of your listname with the “public name of the list” setting. Sometimes the default value of “subject-line prefix” is longer than you might want, or not very pretty. Whatever is in this field is prepended to the subject of each outgoing eMail from your list; this makes eMail from your list standout and easily identifiable to your readers.
By default, each new list is publicly advertised when people request a list of all SWNI mailing lists. If for some reason you do not want your list publicly advertised, you need to make a trip to the Privacy options screen.
Moderation is implemented on a per-user basis. By default, as a SPAM prevention measure, moderation is turned on for all new subscribers. Effectively, nobody may post to the list without moderator approval. Trusted subscribers may be granted posting privileges by clearing their moderation bit. This may be done when approving a post, or under the Membership Management area (where multiple users’ settings may be changed en masse). General list moderation policy is controlled in Sender filters (a sub-section of Privacy options).
If you have a low-volume list with less than an average of three eMails a month, you should tweak these settings. In particular, the “number of days after which a member's bounce information is discarded” setting will probably need to be extended, otherwise the list will never drop users whose eMail addresses are no longer valid. This value should set to around 330% of the number of days, on average, you anticipate between eMails. It is better to err on the large size, if you are uncertain what your average might be. Unless you like to tinker, leave the other settings at their defaults.
If you have a low volume list, it may make sense to change the “How often should a new archive volume be started” to “Quarterly” or even “Yearly.”
Note: Archives are set to “private” by default, which means only list subscribers may view them. Making your archives publicly available usually exposes the eMail address of posters to SPAM harvesters; it is therefore not recommended.
Normally, any list subscriber may post to the list. This is great for facilitating dialog, but sometimes excessive chatter causes people to unsubscribe. One way to reduce list attrition is to create an announce-only list. Such lists may be tightly controlled, limiting the list volume, thus mitigating attrition. Sometimes it is useful to have a pair of lists, one for community dialog, and another for announcements only. Presumably the subscriber base for the former would be a subset of the latter.
If you wish to create an announce-only list, in the Sender filters (a sub-section of Privacy options), change the “Action to take when a moderated member posts to the list” setting to “Reject” (the default is to hold for moderator approval); adding some text to include with the rejection notice is usually helpful (there are two boxes for this; one for list members, and another non-list members). With these changes in place, only those subscribers whose moderation bit is unchecked may post to the list. Typically, this would be only one or just a few users (otherwise it ceases to be an announce-only list).
You may also want to make these changes in the General section: Set “Hide the sender of a message, replacing it with the list address” and “Should any existing Reply-To: header found in the original message be stripped?” to “Yes.” Doing so will strip personal eMail return addresses and make all mail appear to come from the list itself. If you do this, it is safe to make your list archives publicly available (under Archiving Options) as SPAM harvesters will not be able to pick up any eMail addresses except for the list address (which will automatically reject the mail sent to it).† But if anyone replies to the list, those eMails will bounce. To avoid this, you need to set “Where are replies to list messages directed?” to “Explicit address,” and “Explicit Reply-To: header” to “firstname.lastname@example.org” (where listname is the name of your list).
Once you are familiar with its operation and have your settings tweaked, you will probably want to advertise your list’s subscription page on your web site. (The URI for the subscription page was in your list-owner welcome eMail.)
You very likely have a list of eMail addresses you can use to seed your new mail list. The Membership List section has a Mass Subscription sub-section. You can use it to either invite people to join (which requires them to take an action to subscribe), or simply conscript them. It is best to start by adding your own eMail address, alternately using the “Invite” and “Subscribe” options, to understand how they each operate. This will help you to understand what is most appropriate for your users. (You may have to unsubscribe yourself between passes, if you have only one eMail address to play with.) You might choose to subscribe certain users, but merely extend invites to others (e.g. eMail addresses you suspect might bounce, or people who may only have minimal interest in your list). If you are migrating from Yahoo Groups or another provider, you probably want to simply subscribe those users en masse.
Unless you are running a moderated or announce-only list, shortly after a mass subscription is a good time to turn off everyone’s moderation bit (this presumes that the people you mass subscribe are unlikely to SPAM your list). Potentially, this will save you lots of moderation work. You can do this easily and quickly in the “Additional Member Tasks” section on the “Membership List” page. By default, new subscribers will be moderated, so anyone subscribing to SPAM your list will be unsuccessful, and those who demonstrate good intentions can be cleared of moderation on their first post.
Finally, don’t forget to turn on message archiving, if you turned it off for testing purposes.
We also offer have a FAQ page for list subscribers.
Post a comment on this page.
Post your questions about Mailman list management here.
We have installed the Mailman mailing list open-source software on our server. With it, you can quickly and easily send eMail to list subscribers. Mailman supports a variety of features:
For more details, please see the Mailman documentation.
A “sub-domain” is similar to a domain name, and has most of the same advantages. Technically speaking, it is that part of a URI between the “http://” and the domain name. For example, in the URI “http://www.swni.org/,” the sub-domain is “www.” Often, however, the term “sub-domain” may be used to refer to a URI (i.e. the sub-domain plus a domain name, e.g. www.swni.org).
Historically, the purpose of the sub-domain was to route to a particular machine on a network. Today, it’s more flexible; it can route to anywhere on the InterNet. So while a sub-domain remains constant, it’s target may be changed at any time (essentially, it’s an alias). This is ideal for printed media, as the sub-domain always remains valid. Website hosts may change after publication; anyone entering the published URI of the sub-domain will be taken to your current website host, not an old one which was operational at the time of publication. A sub-domain therefore offers the same advantage of a domain name, but without the expense and administration hassles. The cost, however, is that “swni.org” appears in your URI.
SWNI implements its sub-domains by URI forwarding, which means a sub-domain will send the browser to another page. That page may be on the SWNI server, or any other page on the InterNet. For example, http://ep.swni.org/ (the sub-domain) forwards to http://swni.org/emergency (the target), SWNI’s Emergency Preparedness section. A drawback to this approach is that this sometimes confuses people, and they may bookmark the URI of the target rather than the sub-domain. The two are not the same, even if they currently display the same page. The target is locked into a specific host. Only the sub-domain is perpetual (and host-independent).
SWNI makes sub-domains available to all its member neighborhood associations. This allows Neighborhood Associations to publish an unchanging URI for their websites without the expense of renting a domain name. They have an unchanging URI, and the freedom to change servers or IHP (InterNet Hosting Provider) at any time. Sites don’t need to be hosted on the SWNI server. But you do need to let us know when your host server changes, so we can update your sub-domain’s target!
Here is a list of the SWNI Neighborhood Association sub-domains:
Please note that it is possible to change your sub-domain, if you don’t like what has been assigned.
We are often asked if we can host standard HTML pages which are uploaded via FTP (File Transfer Protocol). The short answer is no. If you choose to host on the SWNI server, you must use our Content Management System (CMS).
Our CMS allows you to create, update & delete web pages using only a web browser. With it you can upload images to display on your web pages, or make files available for download. It automatically supports BBS-like commenting on selected pages, and much more.
Our server is not configured like an InterNet Hosting Provider’s (IHP). There simply is no way into the system except through the web interface. This is by design as it minimizes server administration and reduces our overall security risk.
Specifically, we do not offer FTP service because it is an insecure protocol (i.e. sends passwords in the clear without encryption). This is a huge security risk. While there are secure alternatives, such as SFTP and SSH, we have chosen not to support them. Doing so would significantly increase the server administrator’s workload. We simply don’t have the staff nor resources to support that. And our CMS makes those services unnecessary.
You agree not to post any commercial, abusive, obscene, vulgar, libelous, slanderous, hateful, threatening, sexually-oriented or any other material that may violate any applicable laws or community standards.
By using our site, you agree to be bound by these conditions.
As a user of this site you agree to any information you enter being stored in a database. While personal information will generally not be disclosed to any third party without your consent, SWNI (including its staff, administrators, moderators, and/or webmaster) cannot be held responsible for any hacking attempt that may lead to such data being compromised. SWNI generally strives to collect the minimum information necessary to comply with applicable law or provide the service requested. SWNI does not sell, rent or otherwise distribute visitor's information, including electronic mail addresses, to any outside company or organization, unless legally required to do so under Oregon Public Records Law. Certain information, however, may be used internally, or otherwise made available to SWNI organizations or volunteers.
By using our site, you agree to be bound by these conditions.
By using this web site, you agree to adhere to our Posting Guidelines, and understand that posts are not pre-screened, so you may encounter objectionable material. Posters are expected to be familiar with the guidelines and to self-regulate.
You acknowledge that all posts made to this site express the views and opinions of the individual author and not necessarily those of SWNI, the administrators, moderators, nor webmasters (except for posts by these people) and hence they shall not be held liable. You also grant SWNI the non-exclusive right to publish what you post.
SWNI does not, however, guarantee you the right to publish on this site. SWNI† reserves the right to remove any post at any time for any reason, to remove, edit, move or close any topic at any time for any reason, or to limit (or even ban) system access to any individual. While SWNI† may remove and/or edit any material deemed non-conforming to the Posting Guidelines, SWNI, the staff, administrators, moderators, and/or webmasters are under no obligation to do so and shall not be held liable for failure to do so.
By using our site, you agree to be bound by these conditions. You also agree to use your real name when registering.
† Applies to SWNI or its staff, administrators, moderators, and/or webmasters.