SIGDOC Website Manager

Maintain online infrastructure for a professional organization

Client/Project: Special Interest Group on Design of Communication
Objectives: Provide maintenance and ongoing development of organization website.
  • Mike McLeod, SIGDOC Board, Website Manager
My Role: Information architecture, content management, content strategy, WordPress support
Categories: , , , , ,


This is a case where I was recruited by a professional organization to help get its digital assets in order. The organization had multiple publications, including podcasts, a scholarly publication, and multiple websites in need not only of basic maintenance but a thorough reorganization to make them all accessible and sustainable. This is the story of how I helped that organization accomplish these goals and establish solid workflows and procedures that would help sustain them as volunteers changed positions each year.


I was recruited in March 2016 to be on the board of directors of the Special Interest Group on Design of Communication, or SIGDOC, a group within the Association of Computer Machinery, or ACM. The SIGDOC chair, Claire Lauer, asked me to join as the website manager because my of tech background but also because my “experience in and out of the classroom represents a perfect amalgam of both worlds [academia and industry] and your perspective would be a welcome addition”.

The SIGDOC website as of October 2018 with the WordPress theme I developed.

As an organization, SIGDOC produces a number of publications, including a podcast, conference proceedings, and a scholarly journal. They also hold an annual conference for which they maintain and host their own websites. Stepping into the role of website manager meant  I would be responsible not only for regular support and maintenance of SIGDOC’s web presence (all running on WordPress), but also supporting these publications when new materials were ready for release.

Getting Started – Triage

I started the position in May of 2016. I had the previous website manager, Michael Trice, at my disposal to answer questions, but the only documentation to help me find my way around was a short Google Doc with account passwords. I needed to do some detective work to find out what the server situation was, how WordPress was configured, and where files were located.

Conference sites: I discovered quickly that SIGDOC’s technology setup exposed them to a number of vulnerabilities. First, their system for hosting conference websites was a WordPress multisite (MU) setup. There normally isn’t a problem with MU, but in this case each year’s conference had a fully-functional WordPress site that was not receiving active maintenance or updates. In effect, SIGDOC had four neglected websites begging to be hacked, and in fact I found all of them were riddled with spam comments and junk code.

The list of past conferences on the SIGDOC website. When I began as website manager, each of these links was to an active WordPress site.

Unknown Malware Domain: One of the first and scariest things I found while assessing SIGDOC’s assets was that it owned a domain ( that nobody seemed to know about. Not only did no one I could speak to know who owned this domain or how to access it, but the domain had been flagged by Google and other browser as serving malware.

The org had seemingly forgot that it owned a domain that had been flagged by Google as serving malware.

In addition to challenging infrastructure issues, the organization’s institutional memory (in the form of its publications and other digital assets) were not stored in a centralized location. Rather, they were spread across WordPress’s uploaded file folder, which itself is a nested series of folders for each year, month, and day. In effect, these materials would never be seen again unless someone pulled them out and reorganized them.

What Changed

I sort the work I did for SIGDOC into three categories – security and sustainability, maintenance procedures, and organization. There was more work than this, including advising the board about issues related to the conferences, but my work as the website manager necessitated these as the bulk of how I spent my time.

Critical Maintenance

Find domain and server details – my first order of business was to gain access to every server and domain name SIGDOC was responsible for. Part of this was learning that the ACM hosted all of SIGDOC’s technology resources, including the mystery malware domain, which they helped me hunt down and clear the malware warning, eventually getting it to redirect properly to

Kill outdated WordPress sites – the next step was to eliminate the security threats posed by the abandoned WordPress sites for past conferences. The sites couldn’t be outright deleted because SIGDOC maintains them for institutional memory, so I used the WP Static Site Generator plugin to render those WordPress sites as flat HTML files. Then, I deleted those WordPress instances and put the flat files in their place, leaving the content usable and searchable while closing those security holes.

The new conference setup in WordPress Multisite - the most recent conference, the current conference, and the next conference, with all past conferences saved as flat files and then deleted.

Automate WordPress backups – one of the risks of any website is being hacked or server crashes and SIGDOC had no way to address such an issue if it were to happen. To address this, I subscribed them to Duplicator Pro, a plugin that will replicate all WordPress files and databases into a remote location, making it easy to restore the site in the event of a catastrophic failure.

Organizing Information

Centralizing files and archives – One of the immediate problems coming on board with SIGDOC was that it was difficult to find where files lived and who had custody of them. I eventually found most of what I needed buried in WordPress upload folders, but it needed to be arranged in more permanent and accessible locations so that others could use those files as well.

The organization structure I established for SIGDOC using Dropbox to both centralize where files were located but also ensure backups in the event of data loss.

I used Dropbox as our remote file service because several people in the organization already used it and we could use it at the free tier without additional cost. I created a folder structure that I thought best matched the types of files I’d found and proceeded to arrange those files.

The SIGDOC publication, Communication Design Quarterly, with all of their publications since 2012 organized with the same naming structure in the same Dropbox folder.

As one example, SIGDOC’s scholarly journal, Communication Design Quarterly, is hosted on the SIGDOC website, but it was uploaded to the website using WordPress, which means it was distributed across a network of folders. I found all of those CDQ PDFs and created a new file in Dropbox so that they would all be accessible from a single place, if needed. At the same time, I created documentation for my successors so that the process could be repeated each time there was a new publication:

  1. Rename PDF to standard pattern: CDQ_X.Y_Month_YYYY.pdf
    1. X = issue number
    2. Y = volume number
    3. Month = month of publication
    4. YYYY = four-digit year
  2. Create a post on the SIGDOC blog (example)
    1. Include table of contents in the issue
    2. Upload the PDF as a media object; link to it and embed (if possible)
  3. Update Publications page at with new issue
  4. Archive: upload PDF file to Dropbox folder SIGDOC Archive -> CDQ

I repeated the process for the SIGDOC podcast and each of the other instances where someone would be responsible both for updating the website and preserving an archive. This way, each resource should stay up-to-date and comprehensive.

Security and Sustainability

Locking down WordPress – with the WordPress setups optimized and organized, I took several steps to secure them from attack:

  • Changed database table names
  • Changed default usernames (away from admin or sigdoc)
  • Installed Disable Comments plugin to block commenting robots
  • Installed Login Lockdown plugin to avoid repeated login guesses
  • Installed Simple History plugin to illustrate all recent changes and updates
  • Installed Sucuri Security  for security hardening and monitoring

Documentation – I inherited a Google Doc with some very basic details, but as described, there was a lengthy process of discovery and organization to find account details, server configuration info, publishing procedures, etc. I updated this document regularly as I worked and learned new things and set up new procedures to that they would be accessible and repeatable by anyone who followed me.

The Google Doc in which I assembled critical information for my successor - account details, publishing procedures, contact info, etc.

Observations / Takeaways

I didn’t learn anything new necessarily from my work as SIGDOC’s website manager, but the project was large enough that I saw several different practices at play and informing each other reminding me of the importance of:

  • Documentation – not having one place to find critical account information or contact details or publishing procedures all but guarantees multiple ad-hoc solutions for solving problems.
  • Routine maintenance – finding four abandoned WordPress installations riddled with spam and junk content reinforced just how important it is not only to lock down WordPress vulnerabilities but also to perform regular updates.
  • Keeping content organized – finding critical documents stored over a range of WordPress folders and inaccessible to anyone but someone with server access demonstrated just how important it is to keep things stored in one place, where everyone can access them, in an archive, or else they risk being lost forever.