This page documents every aspect of the web site architecture and any decision taken which is not strictly in accordance with the Drupal way, or which is done by convention rather than by code. It will help future developers of the site to get up to speed.

Resource areas New[Prioritysetting]

How to create a resource area

1. click on add content -> Resource page
2. Fill in the text of the Resource page
3. URL path settings should be something simple to remember, because every page in the section will share the first part of this path.
4. Publish the page

Menu System

A section is anything at the top level of a menu. Every page in the menu system shows its section in a grey box at the top of the page.

There are virtual sections, which are top level menu items, but hidden or in another menu. These often have another menu link pointing towards them deeper in the primary menu. Resource areas do this and the press centre.

Publications and tools pages

Michael’s design for these pages was not in harmony with the actual structure of the site, so views couldn’t be used to list the categories. Instead I wrote a couple of php functions to display teasers for categories. These will use the node-publications.tpl.php template. Just be careful to be consistent when changing these pages.

Note that pages which are not filtered html may be uneditable to some users.

Resource areas

How to create a resource area

1. click on add content -> page
2. Fill in the text of the first page
3. Set the menu parent item as ‘resource areas’
4. URL path settings should be something simple to remember, because every page in the section will share the first part of this path.
5. (optional) Create a menu link to the resource area in the primary menu, using admin/build/menu-customise/primary-links to create a new item
6. Upload a picture 735×100 to /sites/default/files/resource-area-images through FTP
7. On /sites/all/themes/cohred/template.php add the resource area to switch structure in function COHRED_preprocess_page
8. Enable comments and publish the page
9. add the path to the block visibility for local_menu_1
10. exclude the path from local_menu_0

NodeQueue and Workflow

We originally planned two workflows, but I saw that it would be a lot of work to implement immediately, and first time. In the end the workflow I implemented hardly merits the module at all, and I’m not sure I really got to grips with how it is supposed to work. Currently, new documents never touch ‘creation’ state and end of as draft after the first edit. Then KSAC is notified. KSAC proofreads the document. If it needs to be sent back to the author, they can mail them a link. Otherwise tweaks are made in-house and KSAC change the state in the workflow tab to published. Nobody checks the box at the bottom of the node-form to publish, it is controled by workflow.
When a staff member edits a node, it does not unpublish itslef and wait for notification, instead it puts that node in the nodequeue for KSAC(No message)
KSAC then visit te node, note that it is thriving, and take it out of the nodequeue, using ‘remove’ on the nodequeue tag. Note that the node was published all along.

Languages

only the LTR languages have been installed and there is only one item of content for each of the non-English languages. The views will need modifying to show items of the appropriate language; now the views show items in all languages. Installing Arabic will be a big job because the theme will need reworking. Care should be taken when altering language settings as sometimes Drupal will do throw 404 if the page has the wrong setting.

Search

There are three kinds of search provided, although the faceted search will not be enabled until there is a lot more page metadata, and then it will need some testing and theming.

The search at the top of every page works well. There is a search for within groups/resource areas also, which will need testing when the resource areas have a little more content.

Two kinds of picture.

Some contentTypes have a cck imagefield, called item_logo or similar. This is a seperate field like the first picture on BBC pages – it is always there and is the visual point of reference for the article. For publications, it is a book cover, for interviews (perspectives) it is a portrait of the interviewee. But in any text field, you should be able to include (when the Text editor is replaced) other pictures. The dialogue box should help you align and scale those other pictures. There may be a maximum upload size, so try not to upload ridiculausly big pictures. Especially from Africa – resize the image to around 2-300 pixels wide beofre uploading

Related Resources and Useful info

These are optional fields found on almost every contentType. At the point of handover, some of these were rather messy. that is why the new text editor should offer only h4, p, ul and of course a for those fields. The guidelines for what these fields should contain could be clearer especially as their meanings are so close.

URL path alias.

For aesthetic reasons, path aliases should be all lower case, should use dashes instead of spaces, and should be around 2-4 words long. Google only reads the first few words, so don’t include meaningless helper words.

Note on block positions

Editing the page.tpl.php to remove blocks is absolutely unnaceptable. Each block has it’s own elaborate visibility settings

Development server

There is a development server at http://cohred.onecreationshosting.org. This server should be used for

• developing and testing new drupal modules
• developing and testing drupal theme changes
• testing drupal upgrades
• developing and testing architectural alterations

All changes to content should happen on cohred.org directly. That means that onecreations will hold a faithful copy of all files, and it will be possible to copy files to the main server at any time. It will also be possible to copy the database back from the live server to the dev server at any time.