GENUKI-2 Maintainers Technical Guide

See also the Quick Start Guide, Glossary and GENUKI Maintainers' Pages.

This document is intended to help people who have volunteered to develop sections of GENUKI (composed of country, county and/or parish pages, and of subordinate pages providing detailed information that is too lengthy to be placed within a country, county and/or parish page). Such volunteers - GENUKI maintainers - have been provided with log in names and passwords, which they need to use in order to access the means by which such GENUKI pages are edited. Note that maintainers are constrained by the system so as to able to edit only “their” sections (typically counties) of GENUKI, though a few people with Administrator roles are not so constrained. (When Administrators step in and modify a maintainer's pages they will - or at least should - as a courtesy inform the maintainer.)

Once you have logged in, your maintainer's view of any GENUKI page that you are authorised to edit will contain an extra line of commands (View, Edit, What Links Here, Revisions, Track, Clone Content and Node Export), and a Maintenance button in the blue banner at the top of the page. This provides pop-up access to  a number of additional menu items. These are: Errors & Statistics, Add Content, Recent Content, Select Nodes and Optionally Perform Bulk Operations, Support Tickets, Reports, Admin Reports and Unconverted Pages. (One further Menu command, GENUKI Drupal Implementation Plan, is available while the process of converting GENUKI to use Drupal is continuing - it is intended just for the use of those GENUKI maintainers who are directly involved in this process.)

The information provided to the viewers of GENUKI's pages ("GENUKI users") is held in a so-called "Content Management System" (CMS), in fact the Drupal system. The concept behind a CMS such as Drupal is that its role is the management of a website's data (i.e. of the website's "information content"), and of the look and feel of the website, leaving the website's maintainers to concentrate on providing the information without needing to know the technical details of constructing web pages. Maintainers are able to exercise some control of the appearance of their information, so can define some of the "mark-up" (e.g. the use of italics and bold face characters), but do not need to know the intricacies of HTML (the web page coding language). In general maintainers' information is held within the CMS, so they log on via the web to update it, rather than holding a local copy themselves. (However, we are investigating tools which would support maintainers who prefer to hold their own master copies of their information content and to upload this to Drupal.)

This document uses Drupal terminology as it enables a clear description of the maintenance tasks, and makes it much easier to relate to all the existing online Drupal documentation. (Unfortunately most of this online documentation is more concerned with setting up and managing a new Drupal site than with making use of an already-created Drupal-based site such as GENUKI.) The present document is therefore intended for GENUKI maintainers who have no prior knowledge of Drupal - your assistance in improving and clarifying this document is sought.

Nodes and Pages

The Drupal component that matches GENUKI's pages is, in general, the "node". The node is constructed to hold the various pieces of information that will be shown in the page. Two initial node types have been defined, a Place node for all the standard county, town, parish, etc., pages, and a Plain node for all those further GENUKI pages created to hold additional information in cases where this information is rather too big to go into the parish page. (A third type of node, a GENUKI topic node, which relates to part of a page rather than a whole page, is described below.) 

As a GENUKI maintainer, after you have logged in (in fact to Drupal), you then have the ability to edit Place nodes and Plain nodes, and so control the information content of the pages that these nodes define. When you have moved (either by following links, or by using the Search facility) to the page that you wish to edit, you can click on the Edit button and so reach an "Edit Template" for the node corresponding to this page. This shows you all the fields that comprise the particular type of node (Place or Plain), and provides "Help" information indicating how each field is used and is to be filled in. The initial fields in each node relate to such matters as page titles, contents listings, etc. You need to scroll past these fields to get to the field(s) where the actual data (information content) of the page is held. 

GENUKI's hierarchy of county, parish, etc., pages have a strictly defined structure and appearance. Within each such page, all information content appears under one or other of a defined set of topic headings ("Church Records", "History", etc.); a two-column listing of the contained topics is given at the head of each page. Drupal has been set up so as to facilitate, indeed to relieve maintainers from all responsibility for adhering to, this structuring. Thus each Place node's Edit Template provides an alphabetically-ordered set of  separate "fields" (in particular "topic boxes") for all the possible topics. The Edit Template shows the topic boxes that already have some information content ahead of those that are still empty. Adding to, or editing existing information just involves editing the contents of the appropriate topic box.

When information is added to a previously empty topic box,  and the Save button (near the top of the Edit Template) is clicked, the Edit Template closes and the web page will be shown with the new topic in its correct place, i.e. all the topics with information content will be visible, in alphabetical order, with the correct topic headings, below an augmented two-column listing of the topics contained.

These two columns typically appear either side of a map. The address from which Drupal is to obtain this map is defined in one of the fields that preface the set of topic fields. (In fact the vast majority of parishes already have parish pages in GENUKI, so maintainers will mainly find themselves with the straightforward task of filling in or editing topic fields in existing Place pages.)

Some information, such as map links, nearby places from the Gazetteer, and churches from the Church Database, is added to the place pages automatically, under appropriate topic headings. (Note: Such automatically-added information will not be shown in Place nodes' Edit Templates, and can only be edited via the facilities of the and the Church Database.) 

The inclusion of this information in place pages is achieved simply by providing the appropriate unique "place code" in each place node. For example the code for Lytham is LANLytham. One can find all the nodes and their associated place codes for a county via the "Nodes Column" (Column F) in the Node List which is accessible from the Statistics & Errors report - available via a link in the Maintenance Menu. Alternatively, a simple alphabetically-ordered list of place codes, filterable by county, is provided by the Places Report. (Place codes in fact are in fact held in column R of the set of places.csv files that constitute the gazetteer - Phil has code that will automatically add a suitable value to the place code (column R) for a places.csv file, using the value in existing URLs as a starting point, when a new place page is needed.)

In Place nodes there are also fields for the basic headers such as the title and a descriptive quote, and an optional image for the location map. There are also some fields (that the user doesn't see) which define where the web page that is created from the given Place node is in the GENUKI hierarchy (and hence what the "breadcrumbs" trail will show when the page is displayed), and for linking it with other information. However, it is the topic fields that are the ones that maintainers will use most. 

Each Plain node (such as the present node) similarly has various fields for the basic headers, with the actual information content of the web page being held just in the one "Body" field. Other fields are again hidden from the user and are used to hold information such as the county, and the associated place (identified using the relevant place code).

Maintainers are likely to have to create new Plain nodes, to accomodate newly-acquired information. This can be done using the Create GENUKI Plain Page facility. (There is also a Create GENUKI Place Page facility, and a Recent Content facility that provides a very useful listing of recently-added pages.) The new Plain node's Edit Template is again intended to be self-documenting, so contains explanations of how to fill in these other fields. However an alternative and often easier strategy is to use the "Clone Content" operation to copy an existing Plain page (choosing one that is in the relevant place in the GENUKI page hierarchy), and then edit the contents of the copy appropriately. In either case, there is a need to provide the new page with a URL so that it can be linked to from elsewhere - e.g. "big/eng/HEF/Lugwardine/WarMemorial" if the intent is to provide a page containing a transcript of Lugwardine's war memorial.

Each topic or body box can either be set to display HTML (when a blue command under the field is showing "Enable rich text"), or to show the contents of the field as it will be shown in the web page (when a blue command under the field is showing "Disable rich text"). This latter case is in fact providing you with a WYSIWYG ("What You See is What You Get") editing facility - see below, where you will also find a different and often better way of enabling and disbling rich text.  You can flip between the two entry modes to suit your preference.  In WYSIWIG mode no knowledge of HTML is required. In the  HTML mode the HTML is structured in the sense that it employs new lines and indenting to clarify the syntax of the HTML text. In this mode only a limited set of safe HTML codes can be used. (The allowable HTML codes are listed under the topic box.) 

You can arrange that WYSIWYG is the default mode for you, for both Place and Plain Pages, by setting "Text Formats enabled for rich-text editing" to "Filtered HTML" and "GENUKI Topic" in the Edit pane of your Account page. (This is reachable via the My Account link that is visible in the top right hand corner of each page.) 

A very important safeguard is that all nodes are set to make a new revision each time you edit them. If you make a mistake you can switch back to a previous revision. You can also compare revisions and see the changes that have been made.

As mentioned, the Edit Templates for both the Place and the Plain nodes are intended to be essentially self-documenting, i.e. they contain explanatory information aimed at describing exactly how the various fields are to be used and filled in. Suggestions for improving these explanations are welcome.

There is no direct means of changing the type of a page, e.g. a Place Page to a Plain page. You would have to create a Plain node, and cut and paste the information into it, and  give it a different (temporary) URL. Then once you have saved the new Plain page and it looks alright, delete the no-longer needed Place node so that you can replace the new Plain page's temporary URL.

WYSIWYG Editing

The What You See Is What You Get (WYSIWYG) editor (whose actual name is ckEditor) shows a field's content (text and graphics) onscreen during editing in a form closely corresponding to the appearance it will have when it is shown as a web page. The editing is performed using a set of little editing buttons along the top of the box being edited. The meaning of these icons is fairly self-evident but can, if so wished, be discovered by hovering the cursor over them so as to reveal their "hints". (Here is some tutorial material on this editing facility.) 

Of particular note is the Table icon. This enables you to create simple tables. Once a table has been created, if you position the cursor at the right hand edge of the table you can adjust the width of the table. Similarly you can position it on a column boundary to adjust the position of this boundary. If you position the cursor inside the table and do a right-click a small window opens up that provides you with a hierchical menu providing a rich set of facilities e.g. for inserting or deleting cells, rows or columns, and for configuring cell size, type, colour, and content alignment.

There are also icons for "Find" (a little magnifying glass) and "Replace" ("^b_a"). These operate within a single field. When the "<>Source" icon (see below) is set to show formatted text (i.e. to allow rich text editing), these two icons are very similar to each other. Each when pressed opens up the same little window with two Tabs - "Find" and "Replace" - the Tab that has been selected simply depending on which icon was pressed. The Find Tab has a “Find what” box that allows one to match case, and/or match a whole word, and to determine whether to search cyclically for the desired item. The Replace Tab has a similar “Find What” box, plus a second box for the replacement text, and allows one to specify Replace or Replace All. (Thus the facilities provided by the Replace icon and Tab are an extension of those provided by the Find icon and Tab.)

The WYSIWYG editor shows a field's content in a box whose size matches that needed to show the entire content.  If you are editing a large text box (i.e. larger than a single screen, as often happens in Plain nodes), it is suggested that you first press the WYSIWYG "maximise" button (the icon with the 4 arrows pointing to its 4 corners). This has the effect of keeping all the WYSIWYG editor buttons at the top of the screen while you can scroll up and down the box's content, and perform any required editing. Pressing the maximise button again will return you to the full Edit Template - something you will need to do in order to press "Save" in order to preserve the results of your editing actions.

The WYSIWYG editor's "<>Source" icon provides another (and in fact better) way of switching between seeing the content of the field as rich text, i.e. as it will appear as a web page, and as structured HTML. The WYSIWYG editor's scheme has an advantage over the switching scheme that involves the links "Enable rich text" and "Disable rich text" below the field, namely that while HTML text is being shown you can continue to use a maximised screen with the icon bar at the top, (though almost all the icons except the "<>Source" icon will be greyed out).

Find and Replace are still available when the “<>Source” icon is set to show HTML, but involve temporarily overwriting the top line of the HTML text with a "command line", and using the "Return" key to cause the command to be executed. The "Find" icon allows any sequence of characters to be specified - the first occurrence of these characters will be highlighted when Return is pressed. The "Replace" icon provides a Replace command line that includes a changeable specification of the last text to be selected (e.g. by use of "Find"). Then when Return is pressed a "With" command line takes the place of the Replace command line, and provides an opportunity to specify the replacement text. When Return is pressed again the command line is replaced by one that states "Replace?" and provides four little button"Yes", "No", "All" and "Stop" which can be used to indicate what is to be done. (This line will disappear, revealing the first line of the HTML text again, when one of these buttons, or indeed anything else, is clicked.) So once again, even when operating at the HTML level, the facilities provided by the Replace icon are an extension of those provided by the Find icon.

The WYSIWYG editor incorporates SCAYT (Spell Check as You Type), a facility that is invoked and controlled using the icon which contains "ABC" above a tick mark. (This icon is positioned just after the "Maximise" icon.) The SCAYT facility can be turned on ("enabled") using the menu that opens when you click on the icon. When SCAYT is enabled, there is a blue line under the icon, and any mis-spelled word will have a wavy red line under it. Right-clicking on such a word brings up a menu that proves some suggested alternative spellings and allows you to decide what should be done about the mis-spelling. Whether or not enabled SCAYT provides a "Check spelling" menu item that provides a means of spell-checking the entire current page, in a separate small window that is opened for the purpose. (This small window has three tabs, one for spell-checking, the others for a thesaurus and a gramar checker.) 

Note: The WYSIWYG editor re-arranges (in effect “standardises”) the format of each field’s HTML when first used on that field. It does this through the use of new lines and tab as formatting characters, and HTML formatting constructs such as “<p>&nbsp;</p>". This does not effect the field's visual appearance in the page, apart from its vertical spacing.  But it can cause searching problems with sets of pages which are a mixture of (i) such standardised HTML pages and (ii) original (perhaps rather idiosyncratic, or poorly structured) newly-imported or newly-created HTML pages. Such standardisation will be applied to all fields of text whose formats have been "enabled for rich-text editing”  by default. (Such enabling is done in the maintainer’s account page (user profile), by ticking the "Filtered html” and "Genuki topic” boxes in the Edit tab. If WYSIWYG is not set as a default, standardisation will be applied to a field’s HTML only when the enclosing page’s edit template is opened and the field's “enable rich text” command is used.) The searching problems (unexpected failure to find what is being sought) can occur if the chosen search term involves HTML text whose representation in standardised and un-standardised fields and pages might differ. However searches for single HTML “words”, i.e. strings of alphanumeric characters that do not contain spaces or new line characters, should not be affected. If and when all the pages being searched have previously been opened for WYSIWYG-enabled editing, this problem should not occur. 

See also note Caveats Regarding Use of the Drupal Editor.

WYSIWYG Tables

Extensive facilities are provided in the WYSIWYG Editor for defining and editing tables - see separate page on Creating WYSIWYG Tables.

Paths and links

As this is a CMS with the information content held in a database, we do not have a hierarchical file structure to provide URLs to the web pages. The basic URLs are in fact similar to those from other CMS-based sites and are of the form node/nnnnnn. However there is a facility whereby a friendly familiar (hierarchical-form) URL can also be assigned to a node, and that is the "path". So the path defined for, say, Lytham in Lancashire is big/eng/LAN/Lytham. A separate Plain Page containing a census transcript, say, for Lytham could have the path big/eng/LAN/Lytham/census. (Note that such paths differ from conventional URLs in that they do not end in ".html".) For non-HTML files such as images or pdfs, the path is identical to a conventional URL, so includes an ending such as ".jpg" or ".pdf".

Drupal provides facilities for uploading images and other non-HTML files. For a full guide on managing image and file uploads, see Images.

There is also a facility (the "menu system") to define where a node sits in the user-perceived hierarchy. This automatically provides a breadcrumb trail at the top of the page so that users can see where they are in the hierarchy, and easily move upwards.

There is also a facility ("What links here") that shows all the nodes that link to a given node.  This is shown as another tab alongside "View", "Edit", etc. on the node viewing screen.  

Link checking

The procedure for checking for missing and broken links is quite complicated - please see separate page on checking of links. 

Images

Images  can be uploaded so as to be available to appear within Plain pages, or (though this is less commonly done) within an appropriate topic field in a Place page. 

Uploaded images can be added to a page to be served by Drupal, either using the <img> tag when editing HTML, or by means of the Image icon (a computer screen with a small plus sign, with the hint 'Image' when you run the cursor over it) when using the WYSIWYG editor.

Note: Images inserted into pages using the WYSIWYG editor will not have a border. In order for an image to have a border you should switch to WYSIWYG's view of the HTML source and insert class="gki_image" in the <img> tag. (The border will not be shown by the WYSIWYG editor itself, but will become visible when you use "Save".)

For a full guide on managing image and file uploads, see Images.

Users and Maintainers

In contrast to ordinary users (casual visitors to the published pages), maintainers have a user name and password to logon to Drupal and gain access to the Maintainer facilities and documention, and are noted as the author of anything they create. As the author can be changed it is really the term for the (current) maintainer of that content. GENUKI maintainers can create nodes but only update the ones for which they are recorded as the author. We also have another role for some people, of 'GENUKI administrator', with more privileges such as the ability to edit nodes for which they are not noted as the author.

Each maintainer has a user account (or "profile"), reachable via the link "My Account" in the top right hand corner of each page. The Edit tab on the user account page allows mantainers to perform such tasks as: Change their password, Set the default for their editing (i.e. whether or not WYSIWYG is intially enabled when they open an edit page), Specify a signature to be used at the foot of each of their pages, and the details of their contact form, etc.

As the new Drupal-based system is in effect a flat structure (for which we are providing a hierarchical facade, using paths) we could move away from the current situation in GENUKI where a single person has to do everything for a given county. We could have people maintaining just a single parish, for instance, something that is now much simpler as all they have to do is work on the information content, not the layout. We could give them a role that just allows them to edit their own nodes, and not create any new ones.

Searching

The Search box in the top right hand corner of each page is a Drupal-provided facility, based on Lucene, that enables all GENUKI users (not just maintainers) to do case-insensitive searches on the displayed information content – not the HTML encoding - of all the current GENUKI implemantation pages, but not any pages that have yet to be converted from our previous static html format. (Note that only text that is in nodes' edit templates, not text that is dynamically added in, e.g. text from the Church Database inserted into parish pages, will be searched.)

Multiple search terms (complete words or phrases, i.e. groups of words surrounded by double quotes, such as "birth certificate") can be specified; at least one of these terms must have two or more characters.  (The search that is performed is an 'or' search that identifies pages containing any of the specified words or phrases. To do an 'and' search you must specify the AND in upper case. Thus a search specifying: 

    Clovelly AND "Herring Boats"

will only report pages that include both these terms.

It is possible to perform so-called wildcard searches. The single character wildcard search uses the '?' symbol - so to search for 'John' or 'Joan' use the search:

    Jo?n

To perform a multiple (zero or more) character wildcard search use the '*' symbol - thus the search: 

   Church*

will find 'Church', 'Churches', 'Churchyard', etc. (Both '?' and '*' can be used within a term, but cannot be used as the first character of a search, or within a phrase.)

The use of '-' before a term excludes pages that contain the term. Thus to search for pages that contain "Clovelly" but not the word "Sydney" or the phrase "Western Australia" use the query:

    Clovelly -Sydney -"Western Australia"

The resulting page of Search results includes a left hand column, the county filter, that shows the GENUKI sections, i.e. countries or counties, in which the obtained results have been found, and the numbers of such results.  This column can be used to restrict the displayed results to those from particular counties or counties. Once a given country or county has been selected as a filter,  further searches performed using the search box in the Search results page will be restricted to the selected country or county until the filter is disabled, which is done by clicking on the appropriate "(-)". 

The above outlines only some of the facilities that are provided by the Search box - more details can be found in the (rather opaque) Lucene query language documentation.

Note that, until the conversion to current GENUKI implemantation is completed, a quite separate Google-based search facility, that covers all of GENUKI, plus other sites providing UK genealogical information, is provided (to all users) by the link Search GENUKI+, just below the current GENUKI implemantation Search box.

Search and Replace

A rather different facility, in fact a powerful Search and Replace facility is provided (just to maintainers) in current GENUKI implemantation via the operation Select Nodes and Optionally Perform Bulk Operations. (Currently the page reached from this menu item is entitled "Choose Nodes and Optionally Perform Bulk Operations".) This is reached via the Maintenance menu. This operation provides means of choosing which pre-selected fields, in which pre-selected nodes, are to be involved in a "bulk operation", such as a search (and, more critically, in a replacement) activity. Choosing is done in several steps or stages. First, using the Choose operation, you select a set of nodes. You can specify criteria on which to make this choice, and the order in which the results are displayed. For example, you can choose all the nodes for which you are the author, of a given type (e.g. place nodes), containing a given set of case-insensitive search terms.  (This facility would seem also to be based on Lucene, and again is of the information content, not the underlying HTML.) You can specify that search be limited related to a particular county; and you can have the results ordered by the date on which the nodes were last updated. (It is recommended that you specify your username in the Author field, and select a single Node Type. This will make the second stage less complicated. The results give the node title, path and type of each chosen page in order to make it easy to see exactly what has in fact been chosen.) Thus the Choose facility is more selective (and hence complicated) than the Search GENUKI+ facility.

It may be that identification of this set of results is all that you were seeking, and so no bulk operation is needed. However in general the next, i.e. second, stage is to decide and indicate whether all of the results will actually be used, and if not which ones, using a tick box associated with each result, for a bulk operation. Then and only then can you choose the actual bulk operation to be applied to the chosen nodes, Search and Replace being just one of the possibilities. (The others are described briefly below.)

Pressing the Search and Replace button brings up a page of tick boxes that you use, in a third stage of selection, to indicate which particular fields of the chosen nodes are to be examined, e.g. Bibliography and History in Place Pages, and Body in Plain pages. At the foot of the page of tick boxes is the actual Search Box, which you use to indicate what HTML string is to be searched for, in the chosen set of fields in the chosen set of nodes, and a Replace Box, in which you can specify the replacement HTML string. (You can also use a tick box to "Make no changes". This simulates what changes would be made, but does not actually carry them out - a wise preliminary check to make.)

The strings in the Search and the Replace box can include HTML tags so one could for example do a search for an italicised word using <em>word</em> and replace it by <u><em>word</em></u> in order to add underlining. However in order to make such HTML changes successfully you need to be sure beforehand of exactly how the HTML is formatted - the search would have failed if the HTML text differed even slightly from the search term, say through incorporating some additional spaces: <em> word </em>. Similarly, a search on Reading & Writing will fail because the actual stored HTML text will be Reading &amp; Writing.

Indeed, there are further complications, especially concerning the use of certain characters other than letters and digits. This is because the HTML that one sees via the WYSIWYG editor, i.e. when it has been set to show HTML rather than Source, is not necessarily the actual HTML that is stored. (This is a common cause of unexpected failures of Search and Replace's Search facility to find the pages that were expected.)  To find out exactly what HTML has been stored, you have to go to your Account page, and under the Edit tab uncheck the Filtered HTML & Genuki Topic boxes!

Such unchecking of the Filtered HTML & Genuki Topic boxes is particularly advisable before trying the "Regex" ("Regular Expressions") feature of the Search and the Replace box. This requires you to tick "Use Regex", and to surround your search expression with "/" characters. However having done this, you can for example, use wild card searches, such as "Jo?n" - which will match "Joan" or "John" - but also for example "Join". (A detailed tutorial on Regex can be found here.) 

You can also make use of some Advanced Options in Choosing which nodes are to have Search & Replace applied to them, by using the appropriate button - these options enable you (i) to require the text matching be case-sensitive, (ii) to specify a prefix and a suffix for the HTML search string, and (iii) to ensure that the entire field matches the search parameters including the prefix and suffix.

Having filled in the Search and Replace fields you can then press Next, which brings up a page that is headed "Are you sure you want to perform Search and Replace on the selected items?" listing the items (fields in nodes) that have been found to satisfy your search criteria.  If you then press Confirm (rather than Cancel), you are shown a progress bar as the requested replacements are actually made. Once this task is completed, you are returned to the page Select Nodes and Optionally Perform Bulk Operations, but now headed by a listing of what has been done (which includes the full before-and-after HTML text of the changed fields!). 

Thus, in summary, the four stages of Search and Replace are:

1. Choose a set of nodes, by specifing a text search string (of one or more "words" made up of just of letters and digits), and/or a county, a maintainer, etc.
2. Use tick boxes to select from the results of this initial choice (i.e. to make a refined choice of nodes)
3. Press Search and Replace, and then (i) use tick boxes to select the fields to be involved, (ii) specify the HTML search string and replace string, to be used on the results of the refined choice of nodes, and (iii) whether the replacement is to be simulated or actually carried out
4. Press Next and then Confirm.

The other bulk operations that can be used, besides Search and Replace, are Change Maintainer, Delete Node, and Change field values. (The first two are self-explanatory - a typical use of the third is to change the Maintenance level of a page, or - for plain pages - the Place Code or Type of Place.)

Warning 1 – there is no means of undoing all the changes made by a set of replacement operations. Moreover, Search and Replace does not create a new revision of a node after it has changed something! So you cannot simply undo a change by going back a revision of each page that had been modified. Hence the cautious multi-stage character of the Search and Replace operation, and the need to exercise great care when using it, since potentially the entire current GENUKI implemantation content is at risk from a faulty Search and Replace command - hence the advice to confine uses of Search and Replace to specific pages for a particular county, and of a particular author.

Warning 2 – due to Drupal's use of cacheing, there may be a significant delay before the results of replacements become visible in the relevant pages (and findable via searching).

Warning 3 – the WYSIWYG editor runs locally in your web browser and "standardises" the html of any node that it looks at even before any editing changes are made. However until a node has been opened and saved (with WYSIWYG enabled) there may be problems using Search and Replace because the node's underlying HTML will not have been standardised and so may not be exactly as assumed. Such problems affect all pages that have been imported from our previous system, but no longer occur in any given page once that page has been opened with WYSIWYG enabled and then saved.

Note 1: In practice you may find that your browser's Find command is also a useful way of searching, though just within the currently displayed page.

Note 2: A very simple specialised version of Search and Replace, Quotes, is provided for use on the HTML text of the Quote field of town and parish place nodes. 

Page Merging

As GENUKI develops further and we take advantage of the features offered by Drupal, there will be a requirement to merge some town and parish pages - e.g. ones that have been developed by different maintainers, responsible for different counties. What we will need to do is move to having a single page for a place/parish and not have multiple pages, even where a county boundary runs through the parish or where the boundary has moved in the past from one county to another. We do not want to continue with multiple gazetteer entries for a single place in multiple counties as has occurred prior to our conversion to Drupal. A joint page should be used, which of course can be linked to from each county concerned. (A note under 'Historic Geography' should be adequate to describe and explain such situations.)

Drupal offers the facility to identify a single maintainer to look after a page, or to set things up so that multiple maintainers can update the page. Merging of towns and parishes will require the agreement and cooperation of the respective maintainers.

Merging of towns and parishes is relatively simple but does require some care in doing so. In principle, the final recipient page receives the information content of the donor page(s), which then become redundant, with some minor editing to tidy up the resultant text.

Having agreed a suitable merger with another maintainer (or maintainers), the maintainer of the recipient (or joint) page will:

1. Make a clone of the recipient page, with a suitable URL alias.
2. Insert the necessary elements from the donor page(s) into each topic section in the recipient page (ideally any auto-included text on the donor page should not be copied) this may most easily be obtained by scraping the text from the donor page and pasting into the recipient page in Rich-Text mode.
3. Check that everything necessary from the donor page has been included.
4. Edit the page to remove duplication and inconsistency, and provide a smooth flow of text (any auto-included text from the donor page should be deleted).
5. Ensure that any donor-page-related topic pages are updated to point to the new page.
6. Publish the new page as the now unique town or parish page, with the former URL alias.

Once all is complete, redundant pages and gazetteer entries can be removed.

GENUKI Gazetteer

The Gazetteer is essentially a separate subsystem - see GENUKI Gazetteer Maintenance.

GENUKI Church Database

This has been converted. The page Church Statistics shows what has been converted, and provides means of contacting the various volunteers involved. To create or modify church database entries, see the Church Database Guide.

For the moment the pages on Maintaining the Church Database may still provide useful background, but needs to be updated.

GENUKI Topic Pages

A "topic page" comprises a single Genuki topic entry for a place where the author is not the county maintainer. County maintainers will use the Genuki Plain page node type for non-place pages e.g. where they have a lot of information for a specific local topic. The Topic Page type should only be used to supply content where the author is not the county maintainer, or if the author is providing a substantial amount of data, such as a gazetteer that covers multiple places, where it is useful to be able to see sections of this within a parish page, and/or as part of a larger unit, such as all entries for a county. This provides the ability for someone just to work on a particular subject which will get combined with a standard place page, or form a collection of content such as a gazetteer or directory set. The content from this node type will be dynamically added as part of the relevant parish page, or to a larger composite entry."

This page type should NOT used by a county or parish page maintainer - which is a real benefit as neither will therefore receive any resultant error reports, which will go to the topic page author.

By this means we can have people supplying and maintaining additional information that is automatically integrated as part of the Place Pages. Additionally we could also combine it in different ways. So if used such pages for a gazetteer, we could see the appropriate section on the Place Page, but also have a page that showed all the places in a county, just as the information appeared in the original gazetteer.

Reports, Errors & Statistics

Numerous standard Drupal reports are available via the Maintenance menu.

Statistics on the usage of GENUKI are provided here. The monthly statistics give detailed overviews of which countries, browsers, and organisations been looking at GENUKI's pages, and which pages are most popular.

Also available are a Monthly Archive, which provides the headers of, and access to, each page in a section that has been newly-added, and a Monthly Changes report, that lists all the pages in the section that had been changed, during the month. 

A regularly updated listing is provided, organised by section (county), of the numbers of nodes, broken links, redirections, etc., via which you can get to all these nodes, etc.

Support Tickets

Maintainers should in general use the Support Ticket facility to document and discuss maintenance problems, and proposals for new or changed maintenance facilities, rather than email. This will help to ensure that the issues that are raised are dealt with, that it is clear who is responsible for dealing with the issue, that we all can see what is going on and what needs to be done, and that we have a record of what has been done. Any maintainer can raise a ticket and assign it to himself. Assigning a support issue to someone else should in general not be done without prior consultation (typically by email), though it may prove possible to auto-assign some problem types. Support tickets should be "closed" as soon as an issue has been resolved or a planned activity has been completed. The listing of Support tickets can be set to focus just on those that are assigned to you, those that are open, those that have already been closed, etc.

Miscellaneous minor issues

There is a problem with logging in using Safari on the Mac. When you move to another page after logging in, the page you reach sometimes shows you as logged out. The workaround is simple. When this happens, get your browser to refresh the page - you should then be shown as logged in.

It is not currently possible to create a link in one WYSIWYG field to an anchor defined in another WYSIWYG field, e.g. between a left or right contents list and the body of a Plain page. The workaround is to edit the source html. And Drupal doesn't like numerical anchors - a problem easily avoided by adding "Anchor" or even just "A" to each such anchor - and of course to any links to it.

Due to sloppy HTML the link text of an external link sometimes is not shown in blue and underlined (because it is missing the quotes round it), though the link is marked with a little box and up arrow, and does work. However if you open an Edit window on the page with this problem the WYSIWYG view of the page shows the link text complete with blue colouring and underlining. An effective and simple work-around for this problem is then to select this text and press the little link button (in the line of editing buttons), so that a window opens showing the Link Info. This information is correct, and by simply pressing OK, and then Save to return to the problem page, it will be found that the link text is now showing properly.

The "Revisions" tab does not appear on Place or Parish pages until the page has been revised (when the tab provides means of reverting to an earlier version, or of comparing two versions). And in fact it seems that bulk editing operations do not cause revised versions of the affected pages to be created, or for the "Revisions" tab to appear.

After updating a page, and logging out, one might find that the page shows initially as unchanged, even if the changed page had been visible before logging out. The delay before the changed page becomes visible to ordinary users has been known to be as short as a minute, or as long as an hour.

URLs ending is slash ("/") get reported as an error both by  the Spider and in the Drupal  "Errors & Statistics" report. However things work with or without them, so at present such error reports can be ignored.