Pictures can be too big, or too little, or vertical instead of horizontal. Words can be misspelled. Worse yet, we might step into a pickle with a wrongly-turned phrase.
Here is the place to look for methods and standards that will govern how to get things loaded, and posted, on this site.
Just create -- or edit -- any article/page/node that should have a "permanent" URL: near the authoring information is the item "URL Path settings". Expand that entry, and follow the instructions. It's easy to test, of course. In fact, you will see the change take immediate effect on the title bar when you save the changes and the page reloads.
For example, to cause the node for Clackamas County, initially known as "node/18", to be referenced as " http://www.oregonrepublicanparty.org/clackamas", we simply put "clackamas" in that URL path settings field for node 18, and saved the page.
You can think of the "clean URL" as an external, public alias, or shortcut, to the node you have created. The URL path setting is not case sensitive, so a visitor entering "hTtP://wWw.OrEgOnRePuBlIcAnPaRtY.oRg/ClAcKaMaS" would still find the page.
As with any page or article or other node that you create, you will still be assigned a unique node number for the item, even if you do specify a unique URL path setting. For example, the Clackamas county page can still be accessed by its original node number, "http://www.oregonrepublicanparty.org/node/18".
Now, not all pages need to be referenced with an external alias using the URL path settings field. It will never be a problem to have pages referenced that way, but Google can still find a page that's referenced by a node number. At one extreme are internal events, like meetings, that certainly are better accessed through the calendar rather than an external alias like "December-Central-Committee-Meeting". At the other extreme are items that are frequently accessed as stand-alone pages, like the events calendar ("calendar"), the blog ("blog"), and the donation page ("donate"). Between those extremes, you'll have to decide whether an external name is useful.
If you do enter a URL path setting, DO NOT USE spaces, or any other non-alphanumeric characters, except perhaps hyphen or underscore. If removing spaces makes the title confusing, substitute a hyphen for the space for readability. For example, "help-us-win" instead of "Help Us WIN!", or "stop-job-killing-taxes-rally-in-pdx" instead of "Stop the £¤&@%* Job Killing Taxes Rally".
Specify an alternative URL by which the node can be accessed. For example, type "about" when writing an about page. Use a relative path and don't add a trailing slash or the URL alias won't work.
Specific Standards
COUNTIES: simply use the name of the county and don't include the word "county". "Hood River" becomes "HoodRiver", of course.
ELECTIONS INFO: preface info with which election and what year, such as "Primary2010". Add a back-slash, then the specific type of info, such as "/Candidates". Thus the new alternative URL for "node/352" is: www.oregonrepublicanparty.org/Primary2010/Candidates
Others?
If you have a question in mind, creating a new poll is very simple. Formating is automatic, appears uniformally in Arial with consistant size and color.
There are some challenges - sometimes it recognizes reader's IP address, and wont let more than one person from that IP vote.
Comment if you have additional challanges or tips to share!
Also, please share ideas on how to apply this module to make it more interesting and useful.
The content area of normal pages is 695px wide, and of course variable length. The right sidebar button width is 260px, and the internal content area varies a little, but max should be about 240px if on white block background, or 260px if transparent (like the quotes and social networking displays).
On pages with no right sidebar, the content area is 955px wide.
The left sidebar is available but not populated at the present.
Images that are off-size can reduce effectiveness of our site, so here are the actual image window sizes for the dynamic areas on the front page:
Dynamic Display Block main image panel: 447px wide by 300px high
"Pager" images (the row below the main dynamic image panel): 70px wide by 50px high
Feature Blocks 1 & 2: 75px wide by 170px high
When an image is way to big, it takes noticably more time to load it. One image we had recently was so large that it took a couple of seconds to fully display... in the PAGER image area. Use Paint.Net, and edit the image. Crop and resize it to fit the actual image space.
If the image is too small, try to find a better one to use instead. A 16x16 image might work fine for an icon, but it's not an ideal image on the big screen.
It's just no fun to lose things when you are working, especially when it's a content section somebody else put up, and you are tasked to edit it. So, before you change things, back it up! Also, since there might just be concealed formatting in the window, as well as links and things, it's important to keep a complete copy, not just a copy of the text you see.
To save the contents of a body text block you are about to edit, for backup purposes:
Now, edit away, knowing you can always put things back the way you found them before you started editing.
If you decide you must start over before you actually save any of your edits, the easiest way is simply to close the page without saving, and reopen it: the current saved copy will reappear. If you have saved the edits you have made, however, you'll need to restore the previous version, and that's why you backed it up.
To restore the edit contents you just clobbered:
Some nodes, and most blocks, contain special formatting elements, in the form of embedded HTML or scripts. If you are going to edit a node, take care not to blitz somebody else's hard work by not paying attention to the details that don't show in text.
The edit window that appears for the body of the block is a formatting editor, but it doesn't always protect you from making a mess. This is why backing up the SOURCE contents of the block is so important. As a last resort, the original writer of the block should have kept the original source, so don't ever hesitate to ask.
After you have backed up the contents, take a look at the block in the default (non-SOURCE) mode. If it looks pretty much just like the block looks when displayed to an ordinary visitor to the site, it's probably mostly text, and can be easily edited. If not, however, you may be staring at some serious concealed HTML construction, and you should tread carefully.
Select the SOURCE button in the block edit controls, and look at the contents. If you can easily discern the location and structure of the text area you want to edit, go for it (since, of course, you have backed up the data, right?). If not, perhaps you need to ask someone with more HTML experience for a little help. On this team, that should not be a problem.