Hide

Church database conversion to drupal

hide
Hide

Introduction

The church database was originally maintained using a csv file per county containing a row of fields for each church. Updates were made by changing this file and uploading it via sftp and this method was also used for uploading church pictures. Most maintainers tended to use the default dynamically generated web pages to display information about each church. A few did use the option to create and save static web pages for individual churches which provided more flexibility for holding the content and for displaying it.

Now the phrase 'Church database' is not a perfect description of the content but there is no single more appropriate word for it in the English language. Church isn't really appropriate for non-Christian denominations and not even for some Christian ones like the Quakers or the various types of Brethren. Then church is not used in the context of a building, but of group of people worshipping together and they do sometimes move from one building to another over time. We are interested in the records that are made by the congregation rather then the architecture or history of a building. As these records can include burials we also have entries for distinct cemeteries although there is no congregation associated with them.

The move to Drupal

The most noticeable feature of the way the church database is being moved to Drupal is that there will no longer be a csv file and no need for sftp for images as it will all be done via a web interface using Drupal Church nodes. A node is the basic Drupal entity and consists of a number of fields, just like a row in a spreadsheet so where information about each church was a spreadsheet row it is now held in a Drupal node. It is actually stored in a Drupal database entry and is thus still in a similar sort of structure as before. The node fields though are not identical to what we had previously in the csv file as some small changes have been made to overcome deficiencies in the previous model. The most important of these is that whilst in the past separate csv file rows were required for each of the locations in which a specific church met, and you had to have a non-dynamic web page to combine them, now all the locations are held within a single node for that church entry. Drupal nodes have associated templates to display the fields within them formatted as a web page.

Conversion

The conversion from csv files to Church nodes will take place once all the county web pages have been converted. This because we need a single complete search interface for all counties and the new searches will all be Drupal based. At an agreed time all the csv files and dynamic web pages will be converted for you and subsequent changes will be made by editing, or creating new, Drupal nodes. At the same time all the search interfaces will be changed to provide functionality to search the church nodes as the old database tables will have been discarded.

Fields

The fields in the church nodes are similar to the ones in the old csv file with some changes and some are used in slightly different ways. In this description they are grouped according to functionality and grouped according to the order in which you will see them on the edit screen.

Basic fields

We tend to have a common set of fields within Genuki nodes that we use to tie everything together such as the title, the url and the county. In here is one change from the old system where we did have a field containing the url of the town/parish page that this church was associated with. This has now been replaced by the Genuki place code for that town/parish page. We have moved to place codes to provide more flexibility as these are fixed whilst urls could be changed. The unique key field is now a combination of the previous id field and the county Chapman code.

There are three new fields that are similar to other Genuki nodes, Introduction and Footer to enable you to add text near the top and bottom of the page and a Quote field so you can now add quotes from a gazetteer or other source. Previously that had to be squeezed under Church History.

The Address field wasn't one in the csv file but used data from a number of the fields including the place, the street and the church url to give an address for the church building. This is the field to now hold that sort of information.

Search fields

We then have a number of fields that were previously used for two purposes, for searching and they were also used to generate content such as founing and closing used to produce a sentence under Church History. These have been retained for search filters but the information the user reads will be in under the topic headings so any chnages will need to be done in both places. The conversion puts generated content under the topic headings so work is only required for changes.

Pictures

Initially we just had the ability to hold a single picture for each church but over time we found the need for multiple pictures. This was based upon a file naming convention and only worked for images held at www.genuki.org.uk . A structure of having small linking images down the side of the page was implemented to accomodate them. This was not very flexible and there was only the ability to associate the photographer with the main picture. Titles could not be stored in the csv file and could only be added where we had distinct web pages for a church. Then the page didn't fit well on devices with small screens.

So a new system has been implemented using drupal image fields where images can be added and uploaded via the web when the node is edited, so sftp is no longer required for this. Two text fields are available with each image and we use one of these for an optional title and the other for copyright information. When you edit the node text is displayed that can be cut and pasted to add the appropriate attributions for images taken from Geograph. When the node is displayed a single image is displayed with arrows for scrolling through the images, and on touch sensitive devices you can swipe the screen to change. The images re-size to fit small screens.

Topics

The topics area contains the fields used to format paragraphs of text under our standard set of topic headings. This is done in a more sophisticated and more flexible way than that implemented for Place nodes. In Place nodes we have a different field type for every possible topic and they are all present whether used or not. Any additional topics require a number of changes in a number of areas. In church nodes we have generic topic fields with there own internal label definging their type. You only see the ones you are using and it is easy to add an additional topic from our standard set. If we increase our standard set, we only need to make an addition to the Topic Names taxonomy.

So you will normally see Church History wher you can record founding and closing dates along with other historical information. With Church Records you are likely to use the ability to specify one of our pre-defined Sub-topics such as Baptisms, Marriages & Burials to further refine you data. For further refinement there is the 'Topic description' field for your own text which could be used for 'Original records', 'Trancripts' and 'Indexes'. So you have a better layout structure than we currently have for topics on place nodes.

All our standard topics are available, but we would only expect a limited sub set are used that would contain church related items.

Locations

For many churches there will be only one location but there will be some where they started off some where small, but then outgrew it and moved elsewhere. So we do now have the ability to record multiple locations wit a set of fields for each. The basic component of a location is a geofield which holds the latitude and longitude of a point location. When you edit a church node you have the option to enter or change the latitude and longitude. Now to make it easier to see whether you have the exact point a marker is shown on a map and you can move that which adjusts the latitude and longitude. So you no longer need a separate map screen it can all be done in one place. An additional feature is the Geocode address. This is something shown on the edit screen which uses a geocoding service to convert the lat/lon into an actual address usually deducing a street, place name and post code although with local knowledge some do seem rather strange. The big advantage is that if you type in and address yourself it will choose a lat/lon for that, put it in those fields and move the marker there. So for a new church you can do that and you get an approximate location and then just adjust the marker on the map. Much easier than before.

Now we do have a few more fields for describing the location. There is one to specify whether it is exact or approximate as we've had in the past. And for those of you wondering about grid references which we used before for the UK, but not Ireland there is a field where you can enter either a UK or an Irish grid reference. It won't change the marker on the map or the lat/lon whilst editing, but when you do a save it will convert the grid reference to lat/lon, save that and clear the gridref field. It has to be cleared so it knows which value has changed. When the node is displayed to the user the lat/lon and the gridref calculated from it are shown to the user.

Now when a church has been in multiple locations there is a field to add a description. You usually put in a date range and something like the street name. The final field is another image field. We have an option to show church locations shown on map where we can show a small image of it. The default is the first image from the picture at the top of the page so this field is only used when there are multiple locations and we can then have the right picture for each location.

Finding churches

There were a number of facilities provided to get list of churches from the database and equivalent funtionality is being provided with the new system. Note that in the following examples you will see items from a limited set of data. The Lancashire ones use a fuller set of fields than the others.

The first, church-list , is to give a list in the style you would see looking at the csv file. This takes you to a view where you can see all the entries for a county or just those for an individual place code where you can sort according to the values in particular columns.

Then we have nearby-churches to show them in a table taking the latitude, longitude and optionally a distance as parameters. There is also nearby-churches-map to show them plotted on a map.

Implementation status

For along time it was anticipated that all of the counties would have to be converted at the same time in order to provide a global search facility as during conversion all the data is only in our pre-Drupal implementation version of the data. However a method has been devised to enable individual counties to be converted with minimal gaps in the searching. During this time the search from the menu at the top of every screen will be via our pre-Drupal implementation database. Within the parish pages though a flag has been added to indicate which county has been converted and we can switch the church information display via the parish page to be either our pre-Drupal implementation or the Drupal version. This has been set for Anglesey which you can see on the Aberffraw page. That now uses Drupal to add the churches to the page content and links to Drupal to show nearby churches or churches plotted on a map. These do though only show converted churches so would miss any in neighbouring counties if they had not been converted.

We now have a view which shows which counties have been converted.