2.1. Roles and responsibilities

As a site owner, your role is to create and maintain your web pages, to help others who are contributing pages to your site, and to take responsibility for the content, appearance, and usability of the site. You also have a responsibility to UCC to present your site to the world in an appropriate manner and to keep it up to date. The description in section 5, ‘Netiquette’ explains in more detail how you can achieve this.

⇛ The Computer Centre provides the networking infrastructure, connectivity to the Internet, and backups; and the Electronic Publishing Unit looks after the running of the web server, including support for technical queries. Training courses in web page creation are available from the Computer Training Centre, but the Computer Centre does not have the resources to design or write your pages for you: you have to do this yourself.

Please check with the Webmaster  before you start work on a new site or new developments, especially if you are using an external designer, so that appropriate arrangements can be made for any special requirements.

Web site owners are reminded that the disk space and email facilities are provided for the relevant department/project/society and may not be used for other file storage or personal email. All work on UCC computers is subject to the Acceptable Use Policy.

2.2. Using an external designer

You may want to hire an external designer to help with the layout and even the day-to-day production of your site, but you still need to plan what each page is going to say, and how they all link together. If you do decide to use an external designer (or even an internal one: there are many students who do web sites), please be aware of the following:

• A reputable web designer will do a professional job, which includes designing the pages to work properly as well as to look good. To do this effectively the designer needs to read this document, especially the information in section 6, ‘Technical details of the UCC main web server’ and section 7, ‘Requirements for site authors and designers’.

• Having someone else do your pages for you can be efficient and effective, but if they go away without passing on the relevant access details and software to you or a successor, you may be left high and dry, unable even to change your own pages.

  It is essential that you are told where the master copy of your web site is stored (locally, on a machine in your office) and how to edit it and upload changes, even if your designer normally does this for you.

• You and the designer must contact the Webmaster before work starts, so that the relevant software facilities and features can be made available.

• Please avoid designers who have no track record of web work, or who have little experience in university sites, or who are accustomed to producing only printed material, as they are unlikely to have the relevant skills.

• We cannot give separate accounts to external designers. As site owner you are responsible for what goes in your web pages. If you need to give the account name and password to an external designer to upload material, you must exercise due caution with regard to security, and you must have a written undertaking from the designer that they will exercise the same caution, and not divulge the password any further.

The web is first and foremost an information system, and the information in your web site (your text) is more important than the appearance (style) that you may give it from time to time. The design is very important as a means of making the information comprehensible and easy to find, but it is not more important than the information itself. Be careful to pick a designer who understands how to balance these requirements: some designers still think the web is made of paper, or believe that flashy layouts with blinking lights and animations are a substitute for hard facts (see some examples of poor design!).

2.3. Intranets

Intranets are just parts of a web service which are restricted to departmental or on-campus use: they cannot be accessed from outside the organisation except by special arrangement. They can also be protected by username/password entry or by IP address if further security is needed, for example to restrict access to named individuals or groups such as committee members.

The UCC server can provide Intranet services both with and without username/password or IP security. The usernames and their associated passwords can be allocated either on an individual basis or on a group basis. See section 4.10, ‘Restricting access’ for details.

Pages on the old Intranet server will eventually be moved into the new system, using the CMS. No new Intranets will be created on the old server.

2.4. Secure serving

The main UCC web server does not currently support encrypted data transfer (https/SSL), such as is used by companies for passing secret information or by e-commerce sites for transferring credit card details. Secure serving is in use elsewhere within UCC: if you think you may need this service please contact the Webmaster. Discussions are ongoing with the Finance Office about enabling web-based credit-card or other payment systems but there is no facility available at the moment.

2.5. A brief UCC web history

The service began unofficially in 1991 when the Computer Centre started Ireland's first World Wide Web server (the 9th in the world) for use with the then CURIA project (now the CELT project). At that time it was already accessible to anyone on the Internet, but in UCC this was limited to users of the old Bureau VAX service, and a few other (Unix) computers with Internet connections.

In 1994, an ad hoc committee under the chair of Prof Máire Mulcahy requested the Computer Centre to start a formal pilot scheme. The takeup increased rapidly during 1995–99 as more and more users were connected to the Internet, and the pilot rapidly developed into a standard service.

Currently, all staff and postgraduates are entitled to direct access to the Internet from within their own departments. Undergraduates have access from public terminal rooms, the Library, the Internet café, and wireless hotspots around the campuses. Some departments also provide student labs of their own with external access. The Computer Centre is constantly trying to increase the provision of computing facilities for students and staff, but on a campus of this nature, physical space is limited.

2.6. Applying for an account

Any College department, faculty, office, project, unit, or student club or society wishing to become an information provider and run their own web pages can be allocated an account on the main web server which they can use to announce and advertise themselves, publicise events, provide information to members and non-members, and conduct their network-based activities.

To apply for an account, send email to the Webmaster.

2.7. Taking over a abandoned site

If the former owner of your department, faculty, office, project, unit, or student club or society has gone away or moved on to other things without passing on the details of the site and how to maintain it, you can apply to take it over.

To do this, send email to the Webmaster specifying the site name, and we will then contact you to verify that you are in a position to succeed to them as the new site owner.

See the warning on the warning panel ‘Security’ before you email the Webmaster..

2.8. Changing your password

Passwords expire every 90 days by default.

You should change your password from time to time before that deadline in order to help ensure it does not get guessed by crackers, security snoop programs, spyware, colleagues, enemies, etc. You do this by logging into the server with SSH (SSH is required as it is encrypted so your password cannot be sniffed). See the documentation for how to use SSH and where to get it.

The command to change password is  passwd . This asks you for your existing password again, then your new password, and then a repeat of your new password to make sure you spelled it right (see the example below).

1. Log in with SSH

   Either type  ssh username@www.ucc.ie  or run your SSH program and type www.ucc.ie in the box for the name of the system to connect to.

   If this is your first time connecting from the computer you are using, it may ask you to accept the security key of the machine (answer Yes or click OK).

2. The system will then ask for your web site password. Type it in and press Enter

   In  ssh , passwords do not display at all, not even as dots or asterisks.

   If you typed the password correctly you will be logged in. If not, you get another try.

   If it rejects a password you know to be correct, then the password has expired too long ago to be changed: contact the Electronic Publishing Unit to have a new password set.

3. If your password has very recently expired, you will be logged in one last time and asked immediately to change your password. If this is the case, go to step 4 in this procedure below

   To change the password manually, at the system prompt ($) type  passwd

4. Type your current password when asked.

5. Type a new password when asked.

6. Retype the new password when asked. It must be identical to the one you just typed. This is to make sure you typed it correctly.

7. If all went well, it will say that ‘all tokens have been updated’. If not, you must start again from step 3 in this procedure above.

8. Log out by typing  exit

   Please don't forget to log out. Failing to do so means you are leaving your account open for the next person at your computer to abuse.

Terminal Commands

_=X

	$ ssh ontology@www.ucc.ie
The authenticity of host 'www (143.239.1.60)' can't be established. 
RSA key fingerprint is fc:10:cc:1e:54:53:f3:03:46:58:6c:0f:32:e3:5f:79.
Are you sure you want to continue (yes/no)? yes
Warning: Permanently added 'www' (RSA) to the list of known hosts.
ontology@www.ucc.ie's password:       
Last login: Mon Jul 21 10:21:35 from tantamount.ucc.ie
This system is restricted to authorised users only.
If you are not authorised, you are committing an offence by logging in here.
[ontology@nina ontology]$ passwd
Changing password for ontology
(current) UNIX password:	      
New password:       
Retype new password:       
passwd: all authentication tokens updated successfully.
[ontology@nina ontology]$ exit
Connection to www.ucc.ie closed.
$

You should change your password at irregular but frequent intervals. Do not under any circumstances tell other people your password or give them hints about how you make up new passwords. Do not use personal names, pets' names, dictionary words, or any term related to your site subject, as these are too easily guessable. Include at least one capital letter, one digit, and one punctuation mark.

3.1. Basic principles

If you are preparing text for use on the web, it must be in HTML format. Wordprocessor files are neither meaningful or useful, as they are only intended for printing. If you are only able to use a wordprocessor, it is possible to use the ‘Save As...HTML’ function, but beware of the poor quality pages this produces. See section 3.2, ‘Creating and editing HTML’ for details of more suitable software.

There is an online tutorial in three parts called ‘How to write HTML files’ which you can use to get started with HTML.

Creating web pages requires a slightly different approach to the conventional one of wordprocessing, spreadsheet, desktop publishing, or database with which you are probably familiar. The major difference is that HTML works by letting you label the parts of your document according to their meaning or function, rather than their appearance on any one occasion. Appearances are

Thus in HTML a paragraph is labelled as p; a top-level heading as h1; and an unordered (ie bulleted) list as ul and the list-items within it as li. The basic formatting is left up to the user's browser, which has built-in knowledge of how to format HTML paragraphs and headings (and all the other elements like lists and images).

Here's a simple example of how it works: the first illustration is a web page being edited in SeaMonkey Composer; the second is a copy of what it actually creates, internally, for reference; and the third is how it might look in a browser:

HTML code for the web page

	<html><head><title>UCC Ontology and Semantics Home Page</title></head><body><h1>Department of Ontology and Semantics</h1><p>Welcome to the Department of Ontology and Semantics. We provide
	      courses in the following subjects:</p><ul><li>History of Ontology and Semantics</li><li>Language Design</li><li>Document Engineering and Structure</li></ul><p>For more information please phone +353 21 490 9999 or
	      email <a href="mailto:ontology@ucc.ie">ontology@ucc.ie</a>.</p></body></html>
      

The web page in a browser window

UCC Ontology and Semantics Home Page — NEbrowser

File   Edit   View   Go   Bookmarks   Tools   Help

http://www.ucc.ie/academic/ontology/

Department of Ontology and Semantics Welcome to the Department of Ontology and Semantics. We provide courses in the following subjects: History of Ontology and Semantics Language Design Document Engineering and Structure For more information please phone +353 21 490 9999 or email ontology@ucc.ie.

⇛ You can add recommendations about formatting (fonts and sizes and colours and positions) in a CSS stylesheet, but remember they are only recommendations, because a) users can change the appearance of your pages in the ‘Preferences’ or ‘Options’ menu of their browser and set it to ignore your styles and use their own instead; and b) there are many browsers which do not (or cannot) implement all the possible variations of formatting.

For simple files, therefore, all you have to do is to use HTML to mark in your files what are the headings, what are the paragraphs, what are the lists and their individual items, your points of emphasis, your illustrations, the links to further files (hypertext), and so on — and let your readers' browsers do the rest for you. This is extremely simple to do, and will get you effective and efficient web pages, but they will look rather boring.

⇛ When you (or your designer) want more sophisticated features for layout and formatting, you can create a CSS stylesheet which specifies how each type of element should appear. You need to make sure that it is not going to obscure your message or make it harder to understand. Here's an example of the same page as before, now using a stylesheet:

body { font-family:Helvetica,sans-serif; }
h1   { font-family:Charter,Times,serif; 
       color:red; }
p    { text-indent:12pt; }
ul   { font-style:italic; }
a    { font-family:Courier,monospace; }

HTML code for the web page

	<html><head><title>UCC Ontology and Semantics Home Page</title></head><body><h1>Department of Ontology and Semantics</h1><p>Welcome to the Department of
	      Ontology and Semantics. We provide courses in the following
	      subjects:</p><ul><li><i>History of Ontology and Semantics</i></li><li><i>Language Design</i></li><li><i>Document Engineering and Structure</i></li></ul><p>For more information please
	      phone +353 21 490 9999 or email <a href="mailto:ontology@ucc.ie">ontology@ucc.ie</a>.</p></body></html>
      

The web page in a browser window

UCC Ontology and Semantics Home Page — NEbrowser

File   Edit   View   Go   Bookmarks   Tools   Help

http://www.ucc.ie/academic/ontology/

Department of Ontology and Semantics Welcome to the Department of Ontology and Semantics. We provide courses in the following subjects: History of Ontology and Semantics Language Design Document Engineering and Structure For more information please phone +353 21 490 9999 or email ontology@ucc.ie.

Most web page creation software (editors) can use these techniques to make your pages look very attractive, but try not be tempted to do this at the expense of the information. Read the List of Web Page Do's and Don't's so that you avoid making pages which fail.

body { font-family:Garamond,Georgia,Times,serif; }

⇛ The important thing is to create your text wisely and thoughtfully, so that it means something to the reader, then format it attractively so it presents the right image. Making it look flashy for the sake of cuteness or novelty, or leaving it plain and unpolished will soon make your pages tedious and boring, and people will avoid them.

To help users who want to search for your documents, be sure to include the relevant metadata (information about information) in the header, using the meta element (see the 16th item ‘Metadata’ in the list in §7).

3.2. Creating and editing HTML

It is possible to use any plaintext editor to create HTML files, because HTML files are all plain text, but it's a lot easier to use one of the many synchronous typographical editors (or even some wordprocessors or DTP systems) which support HTML properly.

This is a short summary of some of the software we have investigated and found useful for developing web sites. It's not an exhaustive list (that's probably impossible, given the number of packages), and you will find many other such lists elsewhere on the Internet if you search for terms such as "html editor" or "web development software". In many cases, it really depends on what you want to do: the new user wanting a simple project site of 2-3 pages probably doesn't need the same kind of software as the professional developer doing a whole 300,000-page site for an entire university.

Bear in mind that you do need to know some HTML to use the editors listed here. Not a lot, but no matter how much the manufacturer or vendor tells you you don't, they're wrong. HTML is very simple (some would say simplistic) and it only takes about 20 minutes to get the hang of it. Have a look at the online tutorial ‘How to write HTML files’ which you can use to get started with.

Products marked below with an asterisk (*) can be got from the Computer Centre either under site licence or at reduced cost. Other products are free and can be downloaded.

3.3. Publishing your site

When you request a web account, the EPU will create a username on the UCC main web server (www.ucc.ie) and assign you a password. In the account will be a subdirectory called web, which is where you put your files. (If you are creating an Intranet, this subdirectory is called intranet instead.) You will also be told the URI (web address) where your users can find your new site.

The account is a standard Unix shell, so you can either:

• prepare your files on your own computer and transfer them into the web subdirectory of your web account using any standard sftp program or the built-in sftp feature in your HTML editor (look for  Publish  or  Upload  in the toolbar or menus);

  or

• (experienced Unix users only) log into the account using ssh and create or edit your files in situ using Emacs and psgml-mode (mail Webmaster to get the setup file if you want to use Emacs this way).

The correct settings for your SFTP program are:

If your SFTP program won't let you store web as the initial remote directory (some don't, because web is actually just a shortcut [alias or soft link] to your web URI), you'll have to remember to change to that directory manually each time you log in to upload files. Or use a better SFTP program.

Any files you put in your web or intranet directory immediately become a part of the UCC web via the URI assigned to you. Those pages in a web directory become part of the World Wide Web and are accessible globally; those in an intranet directory are restricted to use by your nominated users.

Figure 1. Publishing a page in SeaMonkey

 

Notice that you must supply the filename to publish to and the name of the subdirectory where your web file is to go.

⇛ Once your first file (index.html) is in your web folder, inform the Webmaster and the link will be created from the relevant UCC pages so that people can click on it.

⇛ You can create subdirectories as much as you like within your web directory if you want to use a more complex information structure, but please ask the Webmaster if you want to make large files available (over 5Mb), as they may need to be put on a different disk for reasons of space. Please do not just upload multi-megabyte files without asking first: you may be depriving others of the web service.

3.4. Removing or replacing a site

If you are renaming, replacing, deleting, or moving your site, you need to ensure that the old URIs (web addresses) either continue working for a little while, or get redirected to the new address, or display a message for the user explaining what has happened.

Renaming a site

If you are changing the URI but essentially keeping the same pages with the same subdirectories and filenames, please inform the Webmaster so that the old address can be redirected to the new one.

Replacing a site

If you are replacing a site so that it uses the same URI for the home page, but just changes the names of some subdirectories and files, please email the Webmaster with a list showing the old directory/filenames and the equivalent new ones. This must be a two-column list in a plain text file (not a wordprocessor or spreadsheet file), eg

/academic/ontology/courses.html  /ontology/modules.html
/academic/ontology/stafflist.html  /ontology/staff.html
(etc)

Deleting a site

If you are deleting a site entirely, please let the Webmaster know, so that any requests can be redirected. For safety, never delete the subdirectories and files to start with: instead move them all into a subdirectory called old as described in section 4.7.2, ‘Hiding old pages’. Directories with this name will never be indexed by the search engine, but allow you to keep the files on the system in case you need to go back and copy material out of them for use elsewhere.

Moving a site

If you are moving the entire site (new URI, new structure, new directory names, new filenames, etc), and especially if you are switching to the Content Management System, you should move all existing material into a subdirectory called old, exactly as described in the 3rd item in this list, ‘Deleting a site’ above, in order to avoid it being indexed for searching.

In general, make sure to ask the Webmaster to redirect your old site address to the new one, to avoid breaking links for users who have bookmarked or linked your old site.

4.1. Email addresses and lists

4.2. Counters and web usage reports

You can have page counters (like this: ) to display how many hits your pages have had. Contact the Webmaster to set this up, and see the documentation for how to implement them and change their appearance. There is no limit on the number of counters you can use.

Be aware that counters are a two-edged sword: unless used on all pages, they only count hits to a single page at a time, and could be interpreted as betraying how few hits you have had, if your page is not popular! See section 4.3, ‘Web site usage (log files)’.

You can only use UCC-hosted counters on your site: the use of externally-hosted counters is forbidden.

4.3. Web site usage (log files)

To see who is visiting your pages and how many hits you have had, you can request a report. Log into your account with SSH and type the command  /usr/local/bin/webusage , then log out again, eg:

Terminal Commands

_=X

$ ssh ontology@www.ucc.ie
ontology@www's password:       
Last login: Mon Jul 21 10:21:35 from tantamount.ucc.ie
This system is restricted to authorised users only.
If you are not authorised, you are committing an offence
by logging in here.
[ontology@nina ontology]$ webusage
Submitting log analysis request for ontology 
  (Dept of Ontology and Semantics)
for URIs beginning /academic/ontology...
(any errors will be logged in /home/ontology/webusage.err)
Job submitted.
You can view the report in your browser at
http://www.ucc.ie/~ontology/webusage.html
in about 15 minutes, longer on a slow day.
[ontology@nina ontology]$ exit
$

The logs for the past month will be analysed and a report placed in your site's ‘personal’ folder, which is always your username prefixed by a tilde. For example, if the (mythical) Dept of Ontology had a username ontology, then their web log report would be accessible at http://www.ucc.ie/~ontology/webusage.html

A web interface to this routine will be available at a later stage.

4.4. LAMPS (MySQL/PHP)

LAMPS is the most common web development model, and stands for five of the most useful building-blocks for web sites:

Linux

Linux is the operating system used on the UCC web server.

Apache

Apache is the web server software (HTTPD) which responds to users' browser requests by sending them your pages.

MySQL

This is a popular implementation of the SQL database interface.

PHP

PHP is a HTML (hypertext) preprocessor which lets a developer add programmable functionality to web pages.

SHTML

Sometimes referred to as SSI, SHTML allows simple server-side file and command inclusions in HTML pages.

All these are supported in UCC. PHP and SHTML are not restricted (except by space: PHP systems tend to be profligate in their use of disk space and files, so please act with consideration for others, otherwise we will have to impose quotas).

Access to MySQL requires authorisation: mail the Webmaster if you need a web database. We will provide the database name, username, and password. The host is always localhost: incoming access to the database from other systems is not open, nor is outgoing access to other databases. Databases developed on another system can be transferred by dumping the data and structure to a .sql file, uploading it to your UCC web account, and rebuilding it into MySQL there.

Please do not use PHP/MySQL where it is not appropriate:

• Using them for static pages is a form of information abuse and just makes your site slower.

• Keep dynamic facilities like these for dynamically-constructed pages, where the information changes every time the page is retrieved.

• Do not use them just to paste banners or menus on otherwise static pages: we have a content management system for doing that.

If you run PHP, either homebrew or from elsewhere (eg gallery scripts, guestbooks, etc), you must constantly monitor and update them to avoid security holes, which are a well-known vector for bots, DoS attacks, and script or database injection attacks. Failure to observe this will result in your site being deleted.

4.5. Scripts

The Computer Centre provides a centralised script (CGI) directory for shared utilities such as the Mail Form script.

There are no facilities for individual users to run their own CGI scripts, as this is a security and performance risk and we cannot prejudice a production server. If you have a script you need to run, contact the Webmaster to discuss it. If it is a general-purpose utility that would benefit a number of users, and if it is either Open Source software or otherwise verifiable, it may be possible to run it centrally, but we cannot run every script we see, and we cannot duplicate services.

4.6. Short URIs, Virtual Domains, and hosting

All UCC web sites must be hosted on a computer run by UCC. The use of external hosting for UCC web sites is not permitted.

In order to ensure that UCC sites are all served with a .ucc.ie name, we can provide you with a subdomain name for your site, ending in .ucc.ie: we do not provide facilities for hosting other .ie, .com, .org, etc addresses because these do not identify the site as belonging to UCC.

When your web account is created, you get a directory called web in which you can put your pages. This is your homepage directory, and it is accessible to the world at a web address in the relevant place within the site structure. As this can make the URI rather long, it is possible to create a shortcut (alias) at the top of the tree.

The shortcut can be anything you want so long as no-one else has it, and it bears some sensible resemblance to your site name. Contact the Webmaster. All sites are given URIs at the ‘top of the tree’: if you need another directory to be given a short URI, ask the Webmaster. Please note that only directories can be given this treatment, not individual files. If you have an individual file needing a short URI, create a directory for it, and put the file in that directory, and rename the file to index.html, then ask for a short URI to that directory. Please also do not create internal absolute links except via your physical directory, or via short links created for you. The obsolete /ucc/ subdirectory is still being misused for this: it is only there to stop links from outside breaking, and should never be used for URIs.

It is also possible to create a Virtual Domain, which looks like a web server address of your own, eg http://ontology.ucc.ie. This can also be done if you create a new directory in your site, perhaps for a new project or topic. It has to be a directory, not a single file, and the name you pick cannot be one that is already in use (eg for your department email, or by someone else). Contact the Webmaster if you want this facility too.

Four-part domains (eg www.ontology.ucc.ie) are not permitted unless a site is physically located across several machines within the subdomain (for example news.ontology.ucc.ie, ftp.ontology.ucc.ie, phd.ontology.ucc.ie, www.ontology.ucc.ie) where it is needed to distinguish between them. In the case of a single machine the extra www just confuses users and must never be used.

4.7. Searching

The main web site uses the Swish-E search engine. This indexes the whole site between 5am and 6am each day. In addition to the whole index, separate indexes are maintained for each site, and for the site groups:

• Academic sites

• Administrative sites

• Service departments

• Research units and projects

• Student clubs and societies

• Miscellaneous subsites (Appointments, Calendar, Modules, Statutes)

The interface for users is at http://www.ucc.ie/cgi-bin/Search which is linked from the search box on the home page.

Work is continuing to bring back the subsite-specific search interface so that you can provide a search to your own pages wthout having to go through the old ‘advanced’ page.

4.8. Mail-in forms

If you want to create a form for users to fill in, and have the data emailed to you, email the Webmaster with four things:

1. the full, exact URI of your form;

2. the email address you want the data to appear to come from;

3. the email address[es] you want the form data sent to;

4. the URI of the page you want users sent to afterwards;

Then set the <form> element in your web page to:

Terminal Commands

_=X

<form method="post" action="/cgi-bin/uncgi/webform">
      

The data can be mailed to your nominated address in one of three formats:

Plain text (.txt)

name="value" pairs, one per line.

Comma-separated values (.csv)

a file attachment suitable for loading into a spreadsheet like OpenOffice or Excel.

XML (.xml)

A well-formed XML file with root element type named form and element content named after your form fields.

Please note the following:

• Your form page must be well-formed HTML or XHTML. This is essential: it will not work if your page uses the kind of broken pretend-HTML generated by some webpage editors;

• All your form fields must have a name, and those names must be valid SGML or XML Names (ie ASCII characters A-Z, a-z, 0-9, dot, hyphen, or underscore only, no spaces, no other punctuation, or non-ASCII characters). Field names must be unique within the form (except for multiple radio-button and check-box names, which must be identical for each group of options).

Please do not publicise the URI of your form page until the Webmaster has registered it, otherwise any data entered will be lost.

Please note that if you register a form and email address, you must tell the Webmaster if you change the URI (move the form), because the script cannot guess this for you. This also applies if you later provide a short-cut URI using a higher-level directory or a Redirect.

⇛ The webform script recognises several optional hidden fields for which you can set the value attribute:

webform_accumulate

Name of a file into which the data will be accumulated so you can download it for later processing. You must contact the Webmaster before using this field, to agree a suitable name and location for the file.

webform_datadest *

Email address of the recipient (probably you). Form data is sent to this address as an attachment in the format specified by webform_dataformat below.

webform_dataformat

Format for sending the data. Current values accepted are csv (the default: comma-separate values, suitable for a spreadsheet), xml (an XML file), and txt (a plaintext file of name="value" pairs).

webform_display

If set to a non-null value, this causes the acknowledgment page to display the form data in a table for the user to read or print, like mailform used to. If you use this, set webform_nextpage_delay to a suitable value in seconds (eg 60) to allow time for the user to have a look and click on Print if they want to.

webform_email_response

Name of the form field containing the email address to which an acknowledgment should be sent (not the email address itself but the name of the form field containing it). Form data is not sent to this address.

webform_formuri

URI of the page that this form is supposed to be at. Used when the form may be copied and hosted elsewhere, or when it may be sent as an email attachment (and thus have no URI of its own). Can also be used to allow the form to be filled in behind a firewall, or by broken software that obscures the URI.

webform_nextpage *

URI of the page to take the user to after the form has been submitted.

webform_nextpage_delay

Time-delay in seconds to wait between submitting the form and going to the URI specified in webform_nextpage. This can be any positive integer: 10 or 15 is usually enough to allow users to read the submission acknowledgement. Set it to zero for the minimum delay.

webform_owner

Email address of the person responsible for maintaining the form. Form mailer errors get sent to this address for handling.

webform_reformat

Enables the script to reformat the data as a typographically-formatted PDF document using a named XSLT script. Currently this option is restricted. If you think you need it, contact the Webmaster.

webform_sender *

Email address that the data will appear to come from, when sent to webform_datadest. The default is webmaster@ucc.ie.

webform_spam

Used to control forms spam (where spammers flood your form with the URIs of their financial scams, medication sites, porn sites, etc). By default (if you omit this field) the form data is allowed to contain one URI without causing rejection. If you set it to reject, then no URIs will be allowed at all. If you set it to any other value, data containing URIs will be allowed without restriction (not recommended).

* Values for webform_datadest, webform_nextpage, and webform_sender will override any equivalent settings previously provided in the configuration file (the database maintained by the EPU).

4.9. Bulletin-boards

Bulletin-boards or notice-boards are a facility where your users can leave messages for others or exchange information in a discussion without the need to use email or a mailing list. There is a bulletin-board service run by the Student Union on http://forum.ucc.ie. Any student site owner (club, society…) can have a discussion site on this system: contact the Student Union for details.

4.10. Restricting access

You can password-protect any of your subdirectories, or make them accessible only to groups of users based on IP address or domain name.

The responsibility for creating and maintaining the list of username/password pairs rests with you, the site owner. These lists are not in any way related to the site account login usernames and passwords.

1. Create the [sub]directory within your site that you wish to protect. You can do this using your normal SFTP program or by logging in with SSH and using the normal  mkdir  command. See details of using SSH in How to use SSH.

   Remember you must not have any spaces in directory names: they break some browsers.

2. Use a plaintext editor to create a file in this new subdirectory called .htaccess, containing the lines:

   Terminal Commands

   _=X

   Options       All
   AuthType      Basic
   AuthName      "Some title for the subsite"
   AuthUserFile  /home/?????/myusers
   	  

   replacing ????? with your account login name and substituting some meaningful text for the quoted AuthName value. You can use a different filename instead of myusers if you want. Now pick one of the following and add the relevant lines to the end of this file:

   • If you want to force all users to enter a username/password

     Terminal Commands

     _=X

     require valid-user
     	      

   • To allow access from within UCC without a password, but ask external users for a username/password:

     Terminal Commands

     _=X

     deny from all
     allow from .ucc.ie
     allow from 143.239.
     require valid-user
     satisfy any
     	      

   • To allow access from within UCC only, no username/password needed at all (skip step 3 in this procedure below; skip step 4 in this procedure below):

     Terminal Commands

     _=X

     deny from all
     allow from .ucc.ie
     allow from 143.239.
     satisfy any
     	      

   • To allow access from within UCC only and ask for a username/password as well:

     Terminal Commands

     _=X

     deny from all
     allow from .ucc.ie
     allow from 143.239.
     require valid-user
     	      

     You can create this .htaccess file on your local system and upload it using SFTP in the normal way. If you are using Microsoft Windows you must check that the filename really is .htaccess and not .htaccess.txt (Windows may interfere with your filename).

3. Create a file called myusers (or whatever filename you specified in the AuthFileName directive above) in your login directory (not in your web directory!). Your login directory is the directory you would be put into by default when you log in with SSH or SFTP. This will normally be /home/username (where username is your username that you log in with), so if your username is archi then your login directory is /home/archi.

   The username/password pairs which you put in this file (see step 4 in this procedure below below for how to) are nothing whatever to do with your own account username and password (the one you use to log in to manage your site). They are entirely separate and only apply to users of the subdirectory you are protecting. You make them up, and you can have any numberof them, from one pair for all your visitors, to a separate pair for each visitor.

   If you create more than one password-protected directory, you should use a separate password file for each one, unless you explicitly need users of one protected directory to be able to get at other protected directories with the same username/password.

4. Use the genpass program to add users to the password file once you have created it. Log in with SSH and type the command /usr/local/bin/genpass.pl followed by

   1. the username and password to add, separated by a space

   2. a redirect-append (two greater-than signs) to the password file

   For example:

   Terminal Commands

   _=X

   /usr/local/bin/genpass.pl  jean  khxsu687  >>/home/archi/myusers
   	  

   You can log in and use this program to add to your password files at any time. This program will be replaced by a web interface at some stage in the future. Ignore any bogus error messages about ‘unquoted strings’ or ‘possible typos’ (or just add 2>/dev/null to the end of the command).

5. Allow the web server access to your account so it can read the usernames file. Login with SSH and type: chmod go+rx ~/

6. Remember to log out after using SSH (see How to use SSH).

4.11. Non-HTML document types

HTML allows you to create links to anything anywhere on the web, but you need to take care that the files you link to are usable by your readers.

All UCC pages must be in HTML unless there is some very seriously compelling reason for them to be in another format. Non-HTML (non-text) documents cannot reliably be indexed in the normal way, and will therefore not be findable using the search engine. They are also slower to load than other formats, and will cause some users problems because they need additional software.

Links to Microsoft file-format documents (Word, Powerpoint, Excel, etc) will function just like any other link, but you must warn the reader that they are not normal HTML pages, and that they must have the relevant software installed to see the file.

files are acceptable if you have to present a fully-formatted document on the web, but make sure any graphics are kept at low resolution to keep the file size small (see the 19th item ‘File size’ in the list in §7). Adobe's own Acrobat PDF reader is available for all common systems (Windows, Linux, Macintosh) and can be downloaded free from Adobe's web site. There are smaller, faster alternatives as well, like xpdf and gsview.

Links to Microsoft format documents require the user to have an installed copy of Word, Excel, or Powerpoint, or a compatible office system (eg OpenOffice). Be aware that not all users use Microsoft systems, so they may need to download and install this additional software before they can read your document. Before publishing pages with links to non-HTML document types you must check with your target audience first to make sure they are all equipped with the relevant software.

5.1. General approach

• Information on the web server is publicly identifiable with UCC. The content, tone, and accuracy of the information must therefore be appropriate, as well as its appearance: the world outside will judge us on what they see and read. In particular the spelling and grammar on a university site are expected to be correct. To check the Flesch Index for your files (a measure of readability) download and install Bullfighter.

• Writing for a hypertext environment (the web) is not the same as writing for paper publication. Official but unnatural phrases and formulations which are appropriate to a formal paper document are out of place on the web, both because they don't ‘read’ well in an interactive environment and because they do not allow the document to be indexed effectively for searching (users won't know the special words to look for). Use plain English or Irish (or whatever language is appropriate) and avoid officialese.

• Please keep your information accurate and up to date. Information which is found to be misleading or outdated may have to be removed without notice or the site taken offline in order to protect UCC. This applies especially to the use of the title and meta header elements (see section 4.7.1, ‘Making yourself findable’ and the penultimate paragraph in section 3.1 ‘Basic principles’ ).

• Illegal, offensive, damaging, or otherwise actionable material is forbidden by the UCC Acceptable Use Policy.

• Web site owners must take full responsibility for the creation, editing, and deletion of their own information. The Computer Centre provides the web service and can help with training and advice, but does not have the resources to write your pages for you.

• You should take steps to provide for the continuity of your information: the web server is a long-term UCC resource, so if you get someone else to do your pages for you, make sure that if they leave or are absent, you have the ability to take over, or find someone else who can.

• Please do not hog all the disk space by downloading gigabytes of unnecessary files, or storing your thesis or music files online. This is an abuse of UCC's facilities (and in the case of downloaded music files, it may be illegal and leave you open to prosecution).

• The running of an X Window client is not permitted on the web server.

• You should not create information in a format that cannot be reused in the long term. You can get away with invalid or non-conformant HTML for short-term, ephemeral, trivial, or temporary information, but it is not permitted for pages which are intended for permanent or long-term use because they may need to be converted to another format in the future: remember this is UCC's information, not yours. The next section contains specific advice about what to avoid.

5.2. File formats

• Files in private, proprietary, platform-specific, or manufacturer-specific formats are strongly discouraged because not everyone can view them (the software needed to read them is not available on all computers, and may become obsolete, making your files unusable).

  An exception to this is the use of some proprietary formats for which software is freely available on all common platforms, so you can be reasonably certain that all readers will be able to see your files—for example in an Intranet where the readership and its technology are known or controlled; or in a special-interest or topic group where the readership is self-selected; or where you know that a suitable browser is available for all platforms (such as Adobe's PDF file format).

• The use of wordprocessor files is discouraged for the same reasons as above.

• The use of auto-converted files from wordprocessor origins is deprecated, because of the very low quality of most conversions when viewed in a browser. The exceptions to this are files in an Intranet where you can control the readers' technology; and files with a very short lifetime.

• Also deprecated are the use of gimmick markup in HTML, and the use of HTML which does not follow one of the public HTML standards. Always check your pages with a validator like the one at http://validator.w3.org/ to see if it makes the grade.

The Webmaster can advise on suitable public file formats for most applications. There are some further technical requirements in section 7, ‘Requirements for site authors and designers’.