ToC1. Before you jump in with both feet tied together

This document describes what to do if you want to start or take over a web site for your faculty, department, office, project, club, or society. It contains documentation for new site owners as well as for those who have done the job before. Other documentation is available on the IT Services web site, especially the AUP.

⇛ Most departments, projects, and societies already have a presence on the World Wide Web (or on a departmental Intranet), and you understandably want to have your own pages there as quickly as possible.

⇛ Using the Content Management System

All new sites (and sites being updated) MUST now use the SiteManager content management system (CMS). The creation of home-brew, hand-made, and privately-designed web pages for UCC colleges, departments, offices, units, and centres is no longer permitted.

Research project pages and student club/society pages may create non-CMS sites but this is discouraged unless there is strong evidence of competent technical support within the project or club/society.

IT Services does not have the resources to help maintain home-brew, hand-made, and privately-designed web sites and reserves the right to replace unmaintained sites with a page in the content management system.

This document is intended to bring you up to date with what's needed. Most of it is very straightforward but there are some things you MUST already know about before you think about taking on this responsibility

Up to start of section1.1. What you need to know before you start

If you do not have this experience, but have just been told by your Head of Department/Section/Office, Project Director, or Club/Society to ‘go and do the web pages’ please show them this document, in particular section 1.2, ‘People in charge’ and section 1.4, ‘Students creating web sites’.

Up to start of section1.2. People in charge

This section is addressed to Vice-Presidents, Deans of Faculties and Heads of Colleges; Professors and Heads of Departments and Schools; Chairs of College Committees; Heads and Managers of Sections and Offices; PIs responsible for Research Units, Centres, and Projects; Managers of Programmes; Officers of Student Clubs and Societies—in effect all the people responsible for the people who do web sites.

⇛ A certain level of skill and knowledge in computing and the Internet is required before a user can proficiently set up and maintain web pages. IT Services runs ½-day courses in the use of the Content Management System we use (CMS: currently SiteManager), and users are required to take this course before being given access to a content-managed web site. We no longer run training courses in the manual techniques of stand-alone or home-brew web page creation.

People MUST not be given the task of writing or running a web site unless they have sufficient skills to do so, or are imminently about to acquire them.

⇛ For continuity, it is also essential that a deputy or assistant web person is available with the relevant authorisation and level of access so that the site can be updated in the absence of whoever normally does it. Skills in the CMS are widely available, but if you have a stand-alone, home-brew, or external site, other help may not be available.

Details of the Content Management System are in section 1.3, ‘Content Management System’. This has been available to all departments since 2006, and existing site owners are required to migrate their sites to it.

Up to start of subsection1.2.1. Contacts

When a web account is created, we make note of the email address of the site owner, so that we have someone to contact if there are difficulties or changes. If the person in charge of your web site leaves or changes, you MUST let us know the email address of the new person. We can only intervene in site maintenance in an emergency, as we have no resources to undertake design and development.

⇛ If their mailbox overflows, or becomes non-existent or otherwise inaccessible, your web site will be disabled until you provide a working email address. Failure to provide a working contact address will result in your web site being deleted. If you cease to be responsible for a site, or hand over to someone else, you MUST give them this document, because all this applies to them as well.

Up to start of subsection1.2.2. Designers

If you are going to hire a third party (eg a student or designer) to create a site, they MUST read this document in full unless they are going to use the content management system.

Please make sure they see it before they start work, not afterwards. You MUST NOT divulge your web account username and password to them to upload your new site until you are satisfied they have read and understood this document, including section 2.2, ‘Using an external designer’ and section 7, ‘Requirements for site authors and designers’, and that you also have someone within UCC who knows and understands how the site works and how to manage it after your designers have gone.

Up to start of subsection1.2.3. Student help

If you are using a student to help with the site, please make sure both you and they read this document and abide by the rules in section 1.4, ‘Students creating web sites’. Making a student project out of ‘doing the web site’ is a popular and often productive choice, but please remember a) to provide for continuity so that you are not left unsupported when they leave; and b) to ensure they are sufficiently responsible to undertake the project.

Up to start of subsection1.2.4. Responsibility

Please bear in mind that the information you put on your web site is not your information: it's UCC's information, and you are only the custodian of it pro tem. Please try to make things easy to follow for those who succeed you.

Up to start of section1.3. Content Management System

From the beginning in 1991 UCC did not enforce any particular layout or design on departmental, unit, office, project, or club/society pages, and there was no central facility for templating or managing web sites beyond what was provided by site-owners' own HTML editors.

In 2004 UCC installed the SiteManager Content Management System (CMS) from TerminalFour Ltd to help implement the redesign of the web site by Pentagram Ltd for the Office of Marketing and Communication. The new site was installed (starting with the top levels) at the end of 2004 and is now in general use for almost all sites.

SiteManager is available to all colleges, faculties, departments, units, centres, projects, clubs, and societies. There is a free ½–day familiarisation course for new site owners: please contact the Training Centre for details of the next one available.

A central CMS has a lot of benefits for people who run web sites:

A number of departments have in the past used other CMSs for their sites. These will be phased out as sites migrate to SiteManager. The use of private content management systems is not permitted except as noted in the warning panel ‘Using the Content Management System’.

The Office of Marketing and Communication now requires that all new and redesigned sites ( as specified in the warning panel ‘Using the Content Management System’) conform to the new site design, and the CMS is the easiest way of achieving this. This means you probably won't even need an external designer, since most of the page design has already been done for you. You may, however, wish to use a document engineer to do the implementation if you unable to learn how to use the CMS yourself.

Where there are exceptional circumstances, a new or redesigned site may be permitted to use a variant page layout, but the UCC banner (including the crest, the coloured identification rule, and the institutional and page title) MUST be retained. Application for the use of a variant page layout MUST be made to the Director of Marketing and Communication.

Up to start of section1.4. Students creating web sites

If you are a student doing a UCC web site, whether it is for a student club or society, or for a College department, section, or project, please note that it is a requirement that you register your phone number, contact address and the account name and password with the person responsible for your work, and that you notify them whenever you change phone or address, especially when you go home or away in the vacations. Failure to do this will result in the site being removed.

You MUST inform the Webmaster of your UCC email address if you are responsible for maintaining any UCC web site, including student club or society sites, so that we can contact you if anything goes wrong. The Webmaster will also need evidence that you are sufficiently skilled to create and manage a web site—you will be sharing a server with hundreds of other sites, and we cannot afford the risk that they may be damaged or made inaccessible because of technical problems in yours. This is particularly true if your site involves Javascript, PHP, JSP, or MySQL, all of which have security and other defects. The site and any code you have written (HTML, Javascript, XML, XSLT, PHP, JSP, CSS, etc; or a programming or scripting language) MUST be fully documented, and copies of the documentation given to the club, society, or department for whom you are creating the site.

Please understand that you MUST abide by the rules and guidelines in section 5, ‘Netiquette’ and section 7, ‘Requirements for site authors and designers’. If you breach these you will lose access to the site you are working on, and this will not be restored until we have a written request from the Student Union (or in the case of work for the College, from the department or office you were working for), undertaking to act as guarantor of your adherence to the rules and guidelines in future.

⇛ Contacting by email

Note that for security and legal reasons external contact addresses like HotMail, Yahoo, etc cannot be used under any circumstances. All students and postgraduates have a UCC email address—you were assigned one when you registered. If you aren't using your UCC address, you SHOULD start using it now: go to the HelpDesk and activate it. You can set it to forward your mail elsewhere if you want to read it from another mail system, but all official communications will be sent to your UCC address only.

If your mailbox overflows, or becomes otherwise inaccessible, your web site will be disabled until you fix your email—we MUST at all times have a working email address for you. Persistent refusal to provide a working contact address will result in your web site being deleted.

If you cease to be responsible for a site, or hand over control to someone else, you MUST give them this document, along with details of the account (host, username, password, and any ancillary keys like passphrases, web logins, or MySQL database names and passwords) because all this applies to them as well.

When a club or society gets a web account, it comes with an email address for you as Webmaster: This is different from any generic public club/society address that you will already have been allocated by the Student union (which is in the form of or You can request further generic addresses for general club/society use by contacting the SU. You cannot use external addresses like Yahoo or HotMail as your club or society's point of contact on your web site: UCC provides UCC addresses for this purpose. Any such external addresses found on club or society web sites will be replaced with the UCC ones and such pages locked.

Up to start of section1.5. Conventions

In this document, the following conventions apply (taken from RFC 2119):

  • MUST means it is compulsory: failure to do so will result in your web site being deleted or made inaccessible.

  • SHOULD means it is strongly recommended but not compulsory.

  • CAN and MAY mean that it is optional and at your discretion.

Imperatives preceded or followed by NOT or NEVER have the same requirement level for the opposite meaning.

  • Examples of instructions are in typewriter type.

  • Examples of variables (names, dates, etc) for which you must substitute a meaningful value are underlined.

ToC2. Becoming a web site owner in UCC

There are just a few things you need to do before you actually start:

  1. Make sure you have access to a computer connected to the Internet. You can use a home computer if it has a full Internet connection (broadband or dialup): it's slower than UCC's connection but many people prefer to develop their sites in the evenings at home this way.

  2. Install a HTML editor or web site creation program (see section 3.2, ‘Creating and editing HTML’), and a graphics editor if you want to create or edit your own images (pictures, icons, etc—see section 3.2.7, ‘Other web development software’).

  3. Make sure you're using a machine that you have permanent access to (ie not shared with others in a lab, where the software and your files might get wiped off); or arrange to store your copy of the site on a floppy disk, CD-ROM, USB stick, CF card or other removable device.

  4. Read Walt Howe's advice on how to avoid making your site a turn-off for readers.

  5. Read the Accessible Site Design Guide for information about how to make your pages work in all browsers.

  6. Read the Irish National Disability Authority IT Accessibility Guidelines and ensure that your pages are viewable by those with disabilities.

  7. Test your pages (and other people's!) in the script at

  8. Read the article by Jeffrey Zeldman, 99.9% of Websites Are Obsolete, to see why designing for a single browser only is a bad idea.

  9. Apply to the Webmaster for an account on the web server. See section 2.6, ‘Applying for an account’ below for details.

Up to start of section2.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.

⇛ Most sites are managed from within the Content Management System (CMS) and will use the templates provided, which help ensure that the site adheres to the UCC branding. Non-CMS sites MUST also adhere to the UCC branding, but responsibility for doing so resides with the site owner (you).

⇛ IT Services provides the campus networking infrastructure, connectivity to the Internet, and backups; and the Academic and Collaborative Technologies (ACTS) Group looks after the running of the web server, including support for technical queries. Training courses in the use of the CMS are available from the Training Centre, but neither IT Services nor ACTS have the resources to design or write your pages for you: you have to do this yourself.

Please note that IT Services cannot make changes to your web pages for you except in emergency circumstances: running your own web site means you (or your department) MUST acquire the skills to do these tasks yourself, and make provision for continuity when trained staff leave.

⇛ Please check with the Digital Estate Working Group  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 onlyand may not be used for other file storage or personal email. All work on UCC computers is subject to the Acceptable Use Policy.

Up to start of section2.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:

⇛ The web is first and foremost an information system, and the information in your web site (your text) is what Google and other web indexes will use to find and rank your pages so that people can see them. The graphic design is very important as a means of making the information attractive and easy to read, but it is not more important than the information itself.

Up to start of section2.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.

Up to start of section2.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.

Up to start of section2.5. A brief UCC web history

The service began unofficially in 1991 when the then 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. IT Services 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.

Up to start of section2.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.

⇛ Security

You MUST use your UCC email address for this and all messages about the running of your site. For obvious security reasons we cannot accept queries or applications from non-UCC addresses. All site owners MUST be contactable via their UCC address: you can read your UCC mailbox from anywhere in the world using our staff web mail and student web mail.

Up to start of section2.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..

Up to start of section2.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  or run your SSH program and type 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
	$ ssh
The authenticity of host 'www (' 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.'s password:       
Last login: Mon Jul 21 10:21:35 from
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 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.

Please note that it is impossible to find out what a current password is. If you lose or forget your password, we can reset it for you, but it will be a different password.

ToC3. How to create your web files

The files you create as an information provider have to be in a format usable by any computer anywhere in the world, so ordinary wordprocessor files are not meaningful, as they are only designed for printing. The file formats used on the web—HyperText Markup Language (HTML) and  (XML)—have been designed to work with almost every known computer in existence: the opposite of wordprocessor files, which are only intended for printing, and then only by people using the same kind of computer and software as you.

Up to start of section3.1. Basic principles

If you are preparing text for use on the web, it MUST be in HTML or plaintext 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:

SeaMonkey Composer editing a web page

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=""></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

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

⇛ 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.

Note that you SHOULD NOT use the font and size formatting built into your editor to affect the text directly, but instead use a CSS stylesheet. Some editors do this automatically; others still use the deprecated direct-formatting technique: check the documentation that came with your editor.

⇛ 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=""></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

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

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.

⇛ Font abuse

Be very careful not to use fonts which are only available on your own computer. No-one else will be able to see them! For best results, use only Times, Helvetica, and Courier, because they are available on all graphical browsers.

Never use private fonts or font names which are Microsoft-only or Mac-only or Unix-only (like Arial, Verdana, Chicago, Schumacher, etc) by themselves alone: always provide a fall-back list of alternatives in your CSS styling, ending with one of the three generic font names like serif, sans-serif, or monospace, eg

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).

Up to start of section3.2. Creating and editing HTML

It is possible to use any plaintext editor to create HTML (HyperText Markup Language) 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.

⇛ The CMS and page editing

The main UCC web server uses a Content Management System (CMS) to handle the site design, and this is required for all UCC web sites (with some exceptions, see the warning panel ‘Using the Content Management System’). A CMS lets colleges, departments, units, sections, projects, etc enter the information for their web site without the need to know any HTML at all, and have it automatically appear in the standard UCC design.

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 IT Services either under site licence or at reduced cost. Other products are free and can be downloaded.

Up to start of subsection3.2.1. ‘Dumb’ plaintext editors

Don't use these for creating HTML unless you are an expert: most of them don't have any proper facilities for HTML, so it will be incredibly tedious and error-prone. Keep these editors for data and configuration files like the .htaccess file mentioned in section 4.10, ‘Restricting access’. If you want to edit HTML in plaintext mode, use one like Emacs or BBedit, which do have full HTML facilities.


The default editor on Microsoft Windows systems. Limited to files up to 64Kb only, and with almost no editing features at all. Strongly discouraged.


The default editor on Unix systems. vi is an antique dual-mode editor (press  i  to start inserting text and  Esc  to stop). Use  Z  >  Z  to save and exit, and  :  >  q  >  !  to quit without saving. Only for masochists.

TeachText and SimpleText

For years the default editors on old Mac systems, now superseded by TextEdit. Like NotePad, very plain, and only really usable for simple data.


‘Programmer's File Editor’, a good plaintext editor for Microsoft Windows systems, available from WinSite or SimTel, but without HTML.


It may not look like sticking to the rules matters, because browsers don't care one way or the other, but if you are creating any pages which are going to be permanent, durable, or persistent, then making them obey the rules of HTML now will save you a lot of trouble in the future a) if you or others want to re-use or re-edit your pages with other software; or b) if you want to convert your files to a newer system like XML (). Creating invalid HTML nowadays, because you place more importance on what your pages look like than on what they say, is just laying up trouble for the future.

Up to start of subsection3.2.2. Simple editors

These are HTML editors with very basic functionality. They are good for beginners and for simple pages which do not need complex formatting. Bear in mind that you MUST know some HTML to use these.

Up to start of subsection3.2.3. Mid-range editors

These editors can hide the HTML from view, so that it's easier to edit text (although harder to edit structure). Although it is possible to create pages without knowing or seeing HTML, an understanding of it will make things a lot easier.

HoTMetaL Pro *

Reliable, robust web editor from one of the most experienced companies on the web (Softquad, who sold out to Corel). The only synchronous typographical HTML editor guaranteed to produce fully valid files according to the W3C specification (important if you plan to migrate to XML later on). Slightly unimaginative interface and fewer bells and whistles than FrontPage or DreamWeaver, but good Word import. Runs on Microsoft Windows only.

FrontPage *

Microsoft's own HTML editor, comes as part of Microsoft Office. Easy to use, but also easy to abuse. If you're experienced with HTML and the odd behaviour of browsers, you can produce good pages, but it tries hard to make pages which look great in Microsoft's own browser (Internet Explorer) and poor in other browsers, by silently letting you use special Microsoft-only features which make the pages non-portable (and transgress the requirements of UCC sites). It's good at importing Word files, although it also has a very impoverished interface compared with NVU and HoTMetaL. If you have the knowledge, skill, and discipline to keep away from the special Microsoft-only features, however, and you are prepared to accept the more restricted interface, it works quite well. Runs on Microsoft Windows only.

Up to start of subsection3.2.4. Advanced editors

These are larger packages for the expert designer who knows both HTML and page design. Beginners SHOULD NOT normally use these packages.


Large and powerful package from Macromedia aimed at the professional designer. Produces moderate quality HTML, and if you have some flair for design, this is probably a good choice. Optional templating makes it approach the capabilities of a CMS for small-scale use. Great caution is needed to avoid the involuntary inclusion of its own proprietary scripting and markup, which makes it too easy to hide all your information inside images, leaving no text for indexing (which means your pages won't be found). Runs on Microsoft Windows and Apple Macs.


Adobe's web editor is similar in power and scope to Dreamweaver, with a slightly easier interface but a habit of introducing (without telling you) hundreds of lines of Javascript or VBscript in order to perform some formatting. Good solution for the advanced user. Runs on Microsoft Windows and Apple Macs.

Emacs/psgml (free)

For those who prefer a text-mode interface, GNU Emacs with psgml-mode is a popular free plain-text editor with many sophisticated HTML, SGML, and XML editing features, including dynamic parsing and validation, syntactic markup colorisation, structure indentation, markup normalisation, menu-driven markup and editing control, and full programmability. It's the only free text-mode HTML editor with full validation (it uses nsgmls). It can even open broken or damaged files for repair. Very good for those who already know HTML or XML thoroughly. Runs on Microsoft Windows, Unix/Linux, and Apple Macs. Not recommended for the non-technical user.

Up to start of subsection3.2.5. To be avoided

Some systems have been found to produce poor quality HTML. These SHOULD NOT be used at all, except for very transient information, or in the direst emergency.

  • Microsoft Word's ‘Save As…HTML’ creates a form of invalid XHTML designed for re-use only in Word and Internet Explorer, which makes it virtually impossible to edit with anything else later. It also introduces dependencies which may cause problems with non-Microsoft browsers, and may reveal properties of your file which you prefer the world not to see. Do not use this method if at all possible, and if you do, follow the instructions in the 17th item ‘Document properties’ in the list in §7 to make sure your document properties are correctly set.

  • The ‘Save As…HTML’ function built into WordPerfect, OpenOffice, AbiWord, and most other wordprocessors is marginally more usable but should not be regarded as a substitute for a real HTML editor. Both of the first two wordprocessors do have real HTML editors built in anyway, which are quite adequate, and WordPerfect has a fully-fledged XML editor as well.

Up to start of subsection3.2.6. XML editors

If you are planning on using XML for your pages, these are some of the editors we have found useful.

Bear in mind that it is not recommended to serve raw XML at the moment: not enough browsers support the CSS formatting or the XSLT transformation correctly. Both the major browsers (Firefox [Netscape/Mozilla] and Microsoft Internet Explorer—in their current versions) still have bugs, missing facilities, and unexpected behaviours; and anything older than these probably doesn't support much XML at all, which will cut out a very large percentage of your readers. The solution is to serve via a system like Cocoon, which converts to HTML on the server, so any browser can read it. This involves writing an XLST transformation stylesheet to specify what XML element types get converted to what HTML element types. For details contact the Electronic Publishing Unit.

The big benefit of XML is that you only have to maintain a single master source document from which you can create both HTML for the web, PDF () for publication, and many other formats (eg Braille, WAP, etc). However, it does mean that your text markup system needs to be properly designed—not the appearance but the tags you use—which means rationalising your information and making it consistent. If you can't do that, or don't understand any of this, stick with HTML.

Emacs (free)

This is the old standby for everything, as it runs on all platforms (Windows, Linux, Macs, etc) and handles almost everything you can throw at it. It's text-mode only, so there's no built-in typographic rendering, but you can use a browser window for that, like most of the other editors do. With psgml-mode and xxml-mode and a copy of nsgmls it is an excellent validating XML editor, and with xslide-mode you have a full XSL Integrated Development Environment for writing and running XSL and XSLT. The tdtd-mode lets you create and edit DTDs, and there is a mode available for editing RelaxNG Schemas. Even if you don't use it in production, you should have a copy for use when all other systems fail. Copies available from the /elec-pub/homepage.

XMetaL (midprice)

The big sister of HoTMetaL, derived from the original Author/Editor, for years the workhorse of SGML users (eg the CELT Project). SoftQuad sold it to Corel, who sold it on to BlastRadius, but it remains one of the MS-Windows standards for XML document editing. It's only an editor, no XSL or XSLT, so it silently creates a CSS file when you start formatting. The new version 4 omits the CSS creator: you need to specify the Developer's Version to get that (deliberate, as many sites only want one person creating CSS, but many people editing the XML).

XML Spy (expensive)

A good partner to XMetaL if you are developing XSL or XSLT. Like Emacs, it combines an editor for XML, an editor for DTDs and Schemas, and an IDE for producing XSL and XSLT. The text-document editing is not as sophisticated as XMetaL, though, but it's a good developer's tool, if rather expensive (a month's free trial from

epcEdit (cheap)

A good simple multiplatform editor for XML documents from Written in Tcl, so it runs on Windows and Linux, it lacks the formatting sophistication of XMetaL, but if the documents are going to be server by other means (eg Cocoon) then you probably don't want to waste time on local formatting anyway. Very reliable, quite fast, and a friendly interface. There's a month's free trial, and the academic price is very low (under €100).

WordPerfect (free in UCC)

Corel have been producing an SGML (and now XML) editor built into WordPerfect for over a decade, so this is a very robust and usable Windows-only editor. It comes as part of WordPerfect, which is available from /software/homepage on UCC site license, but it's an optional extra click to install it. It has its own stylesheet, so it doesn't produce CSS or XSLT, but it's one of the few products where you can open your XML file and Save As...Word, allowing you to export your files to non-XML-equipped Microsoft Word users (they keep the formatting but lose the markup). WordPerfect XML is used extensively along with Emacs in many academic textbase projects (WordPerfect itself is a significantly better document editor than Word for academic texts).

Microsoft Word (Office-11 and Office-12 only)

Versions 11 and 12 of Microsoft Word and Excel (professional Version only) include a full built-in XML editor (at last: they were only 15 years behind the rest of the industry!). This works with W3C Schemas only, not DTDs, so it's really aimed at the e-commerce market, not the text-document market, but it does work, although the interface is complex and confusing. Version 12 is due for release in late 2007.

If you are going to be developing your pages for Cocoon, using XSLT, we strongly recommend installing a copy of Saxon, the standalone XSLT transformation engine, so you can test your formatting from the console without using the server every time. Get it from

While it's tempting to use Microsoft Windows for everything, Unix-based systems like Apple Macs and Linux provide much better tools for web-based development. It's a big move, and only for the technically-experienced user or the user who is prepared to spend a little time learning some new skills in return for a more productive and reliable environment—but the increases are significant if you are doing a lot of work with text.

Up to start of subsection3.2.7. Other web development software

If you are developing web pages, a graphics editor is probably essential to do images and icons.

GIMP (free)

Good, reliable graphics editor with lots of filters and manipulation features. Interface requires some foreknowledge and understanding of graphics technology. Runs on Microsoft Windows and Unix/Linux.

PaintShop Pro

Excellent mid-range graphics editor from Corel with many web-oriented features. Very easy to use, an extremely close second to PhotoShop. Runs on Microsoft Windows only.


Vast and powerful picture editor from Adobe for the professional graphic artist. Wonderful features, definitely the choice if you know what you want, but needs some serious learning. Runs on Microsoft Windows and Apple Macs.

Ulead *

Comes ‘free’ with some distributions of HoTMetaL and other popular HTML editors. Extensive facilities, but a little more cumbersome to use than the rest. Runs on Microsoft Windows only.

InkScape (free)

If you are going to be producing diagrams or charts rather than editing photographs, you need to use a vector editor rather than a bitmap editor. The web standard is SVG (Standard Vector Graphics), and while it's built into big systems like PhotoShop, InkScape provides a cheap and convenient platform-independent program for creating and editing infinitely rescalable graphics. Recommended.

Up to start of section3.3. Publishing your site

When you request a web account, the EPU will create a username on the UCC main web server ( 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.

⇛ Replacement sites

If you are completely re-doing your site and changing its URI (web address) please refer to section 3.4, ‘Removing or replacing a site’.

Replacement sites are now REQUIRED to use the SiteManager content management system.

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

The correct settings for your SFTP program are:

username as supplied
password as assigned
initial directory web
upload protocol sftp (port 115)

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.

⇛ Web editor publish/upload URIs

If you are using the built-in SFTP uploader/publisher of your HTML editor, do not try to use the URI of your web site in place of any of these settings. Your URI is just a public address for users to get to your site: it is not the name of the directory where you put your files (which is called web or intranet, as described above), and your public URI is not the address for uploading files; it's just the public address where users can find your site. By all means use your URI as a label for the drop-down menu of your Publish or Upload menu (what some systems call the ‘Profile Name’), but not as the directory name, login name or anything else.

⇛ Be aware that Microsoft FrontPage's site upload/publish feature makes the erroneous assumption that you are uploading to an IIS server, and seriously confuses the upload directory with the public URI. You are very strongly advised to use a standalone SFTP program instead for uploading pages done with FrontPage (and read the documentation on using SFTP if you haven't used SFTP before).

Please do not publicise any URI (web address) for your site until you have agreed with the Webmaster what it will be. Don't guess: you may accidentally pick an invalid address or one which is already in use.

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

Publishing a page in SeaMonkey Giving your password 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.

⇛ Default files

The default entry-point (homepage) file in any directory MUST be called index.html. Other files you create can be called anything you like but the default file is always named index.html. This is the name the web server looks for if a user accesses your site (URI) giving just the directory name without a filename. This file MUST exist in your homepage directory.

If there is no index.html file in a directory, then any web user will be able to see all the names of all the other files in that directory. If you don't want them exposed like this, make sure every directory contains its correct index.html.

(In fact index.shtml or index.php or index.xml are also permitted, but only if you know what you are doing. If you don't know what these are, avoid them and stick to index.html.

Be especially careful if you have prepared your files on a Microsoft Windows machine because it may capitalise the filename (to Index.html or INDEX.HTM or index.HTM) without telling you! : other filenames can be any mix of upper and lower case you like, but do not rely on Microsoft Windows when you make HTML links (the <a href="..."> and <img src="..."> elements) because they may be wrongly capitalised: always check them manually.

Take care that you use only the normal forward slash (/) as the separator between folders and filenames in your links and image references. Under no circumstances whatever should you use the backslash (\) because that character is illegal in URIs (Internet Explorer is broken in this respect and allows it: other browsers correctly refuse to use it). Spaces are also illegal in URIs: see below.

If you already have your homepage (entry-point) file called something else, rename 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.

⇛ Illegal or meaningless names

Filenames, directory names, and fieldnames (see section 4.8, ‘Mail-in forms’) MUST contain only the characters A-Z, a-z, 0-9, full stop (period), and underscore (_). Other characters, especially the space character, are illegal in URIs and fieldnames, and cannot be used, so do not under any circumstances use spaces or other punctuation in filenames, as these will cause some browsers and servers to return faulty information, and will prevent some users seeing your pages at all. Filenames and directory names SHOULD also have some meaning to the user rather than being a jumble of codes, and MUST be spelled correctly!

Up to start of section3.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) with one or more spaces separating the two URIs, eg

/academic/ontology/courses.html  /ontology/modules.html
/academic/ontology/stafflist.html  /ontology/staff.html
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. Make sure that you clear or refresh your browser's cache before testing your new site, otherwise you risk seeing what your browser thinks are the right pages from its old memory. For details, see this excellent page from Indiana University.

ToC4. Other facilities

The following facilities are available to all site owners.

Up to start of section4.1. Email addresses and lists

Up to start of subsection4.1.1. Web site email address

The account which is created for your web pages is to contact you as Webmaster for your department or society. The address will be your web account username When your web account is created, your own UCC email address will be set as the forwarding address, so any email to your new will be auto-forwarded to your UCC email address.

This account is used as the means of communication from the Webmaster to you about your site and the server, so you or your deputy are required to read mail coming to you via this address. Please note that for security and legal reasons we cannot forward to off-site addresses (eg HotMail, Yahoo, etc): we MUST use your UCC address. As mentioned earlier, we cannot communicate information about the management of your site (eg password changes) to a non-UCC address.

⇛ As set out in the last paragraph in section 1.2.1 ‘Contacts’ in section 7 ‘Requirements for site authors and designers’ , all sites MUST show a UCC email address for contact on their home page or a contacts page. This address MUST be a UCC address (this applies especially to student clubs and societies: the use of off-site addresses is not allowed as a primary contact address). The address can be your web account email address as explained in this section, or another UCC address if you have one (eg an existing departmental address).

If you need additional email addresses, for example separate Club or Society addresses for different functions, please contact the HelpDesk.

Up to start of subsection4.1.2. Mailing lists

There is a LISTSERV mailing list server available for you to run mailing lists in conjunction with your web site. This is intended for relatively low-volume use, principally within UCC. If you need a very high-volume public or international list, this can be arranged with HEAnet in Dublin, who run a much larger LISTSERV system on behalf of the Irish academic community.

LISTSERV is very easy to use and will handle almost all the administrative work for you, especially if you opt for allowing users to subscribe themselves. You should be aware, however, that owning a mailing list does entail a small commitment in time and effort, especially if you opt for a moderated list (where you vet each post before it is sent) or for a list where a human (you!) has to vet applicants wanting to join.

Up to start of subsubsection4.1.2.1. Creating a new mailing list

Check the list of UCC mailing lists to make sure that there isn't already a list for your purpose!

Then fill in the online form. Applications for lists which already exist will be rejected.

You MUST give your real (personal) UCC email address in this form: for security we have to know who owns each list. A generic address for your department/project/unit/club/society cannot be used here.

Up to start of subsubsection4.1.2.2. Taking over an existing list

If you are the recently-appointed person taking over a list from an existing owner (in a club or society, for example, or where the previous owner has left UCC), send email to them asking to have your name and UCC address added to the list of owners.

The address to email is (replacing listname with the actual name of the list that you found in the list of UCC mailing lists).

Once they have added you, you can then login as co-owner at (again, replacing the listname with the name of the list). The first time you do this, it will ask you to create yourself an owner password. You can then delete their old address from the list.

If they do not respond to your email, contact the ListMaster (using your UCC address: for obvious security reasons, requests cannot be accepted from external addresses).

Up to start of subsubsection4.1.2.3. Documentation

Documentation, details of LISTSERV operation, and what it means to be a List Owner are on in the manuals listed on the UCC LISTSERV home page (check out the LISTSERV list owner's quick start first).

Up to start of section4.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.

Up to start of section4.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
$ ssh
ontology@www's password:       
Last login: Mon Jul 21 10:21:35 from
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
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

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

Up to start of section4.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 is the operating system used on the UCC web server.


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


This is a popular implementation of the SQL database interface.


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


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:

If you run PHP, either homebrew or from elsewhere (eg gallery scripts, guestbooks, WordPress, etc), you MUST monitor the site frequently and regularly, and update it with the latest releases 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.

Up to start of section4.5. Scripts

IT Services 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.

Up to start of section4.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 name, we can provide you with a subdomain name for your site, ending in 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.

web directory /home/ontology/web
Physical location /var/www/html/academic/ontology
Default URI
Shortcut URI (alias)
Virtual Domain

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 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 are NOT permitted unless a site is physically located across several machines within the subdomain (for example,,, where it is needed to distinguish between them. In the case of a single machine the extra www just confuses users and MUST NOT be used.

⇛ Short and long versions of virtual hosts

  1. It is possible to have the the www prefix as an extra redirect in order to catch naïve users who add the www out of ignorance or carelessness, but only on the strict understanding that the longer name is never publicised, mentioned, or used as a link. In this case would point at a separate page on the main web server where a warning message would give the correct URI.

  2. The use of local hostnames (the domain name minus the is not supported in Virtual Host cnames. You have to use the fully-qualified domain name, because the shortened version will not work off-site, because it fails to identify the host as a UCC host.

Up to start of section4.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:

The interface for users is at 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.

Up to start of subsection4.7.1. Making yourself findable

To ensure your documents are properly represented in the site search as well as in Google and other search engines, follow the simple rules:

If you use a web editor which concentrates on formatting rather than meaning, you will produce poor-quality pages which cannot easily be found by search engines.

Up to start of subsection4.7.2. Hiding old pages

If you need to leave old, outdated, or obsolete files or folders on your site for reference or later re-use, put them in a subdirectory called old. This will avoid them being picked up by the indexing engines, both on and off campus: the search engine indexers are instructed never to look in any UCC directory called old.

If you try to do it some other way, such as renaming the file to end with .old or _old, it will still get indexed, which means users will still be able to find your outdated information.

Up to start of section4.8. Mail-in forms

⇛ Withdrawal of web forms service

To improve security we are withdrawing the web forms service with effect from 25 May 2018. From that date, web forms will no longer be handled by this service. If you have forms in your pages you MUST move them to use Google Drive Forms or Microsoft One-Drive Forms (either will do).

In particular, the accumulation of data in CSV or XML files will no longer be available. If you have such accumulated data, please download it before 25 May 2018.

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
<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:

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:


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.


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).


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.


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.


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.


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.


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


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.


If set to yes, the data from the form will not be logged, neither in the web form log file nor in the XML file used for data recovery. This is to comply with data security requirements that sensitive data not be kept on the web server. It is also used to ensure that the data is sent by secure (TLS) email to the recipient.

webform_sender *

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


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).

Up to start of section4.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 Any student site owner (club, society…) can have a discussion site on this system: contact the Student Union for details.

Up to start of section4.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
    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
      require valid-user
    • To allow access from within UCC without a password, but ask external users for a username/password:

      Terminal Commands
      deny from all
      allow from
      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
      deny from all
      allow from
      allow from 143.239.
      satisfy any
    • To allow access from within UCC only and ask for a username/password as well:

      Terminal Commands
      deny from all
      allow from
      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 SHOULD 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/ 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
    /usr/local/bin/  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).

⇛ Additional features of HTAccess

The .htaccess file allows many other web server features to be customised on a per-directory basis. You MUST NOT use these features to defeat or deny the identity of a site as a UCC site.

In particular, the use of transparent redirects to send users off-site is NOT permitted—use a static web page with a META Refresh instead, and a message explaining that the site has moved, giving the new URI.

Up to start of section4.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 may 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 need have the relevant software installed to see the file.

 (PDF) 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 SHOULD check with your target audience first to make sure they are all equipped with the relevant software.

ToC5. Netiquette

You are sharing the computer with several hundred other site owners as well as thousands of visitors, so please be responsible in your usage. Please remember that being an information provider carries with it some responsibilities.

Up to start of section5.1. General approach

Up to start of section5.2. File formats

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’.

ToC6. Technical details of the UCC main web server

This is a Dell PowerEdge 64-bit running CentOS 6.3 (Red Hat Enterprise) and Apache 2.2.15-15.

The server also runs PHP 5.3.3-14, MySQL 5.1.61-4, Java (JDK 1.6.00-, and Java Servlet Pages (Apache Tomcat 6.0.35-1 JSP).

It does not run proprietary technologies such as ASP or the FrontPage Extensions. SSL is not currently installed but is due for installation in 2013.

Access is by HTTP to port 80 (Apache) and 8080 (Tomcat) and SSH/sftp for file transfer.

ToC7. Requirements for site authors and designers

All UCC web pages are required on the specific instructions of the College to be viewable (completely, but not necessarily optimally) in all browsers. The publishing of pages which will only work with a specific make or version of browser is not permitted unless they are intended for a restricted set of users such as members of an intranet site or committee, where it is known that all those users have the required software, and where control of the software version is possible.

‘Completely, but not necessarily optimally’ means that your information MUST be visible to all users even if it means sacrificing some of the aesthetics of layout or formatting for those users who do not have the full level of technology available. While the development of pages which present a ‘rich browsing experience’ (to use the designer/marketing jargon) is encouraged, this MUST NOT be at the expense of those who cannot see the information.

All designers MUST read the note about the Web Content Management System. All new UCC web sites for colleges, faculties, departments, offices, units, and centres MUST conform to the standard UCC page designs by using the CMS. The former free-for-all of allowing any site to look any way is not permitted. There are some exceptions for research projects, and for student clubs and societies: see the warning panel ‘Using the Content Management System’.

Do not write pages which lock out specific classes of users (eg Microsoft users, Mac users, Unix users, users with disabilities, etc). Pages which infringe these rules will be removed or made inaccessible without warning and replaced by a functional version which fulfils this requirement. For further information on making pages accessible to those with disabilities, please see the Irish National Disability Authority IT Accessibility Guidelines.

Remember that the site you are in charge of is not your information, it's UCC's information: you are only the custodian for the time being. Don't do things which will foul it up for whoever comes after you.

Designers are REQUIRED to provide technical documentation which describes what they have written and how to maintain it in future. Sites which are created without functional documentation will be deleted.

Designers SHOULD read the article by Jeffrey Zeldman referred to earlier, 99.9% of Websites Are Obsolete, which explains some of the reasons why these rules are here.

RSS newsfeedKeep up to date with our RSS newsfeed