Architected Futures™

Tools and strategies ... for boiling the ocean

Site Facilities Overview

Introduction

​This needs review and work. It s taken from the (WP32) BuddyPress site and not yet adjusted for the Drupal decision. It is placed here mainly in anticipation of wanting something along the lines of this content as an anchor for the content  which follows in the module pages. This section should provide a general overview of the module strategy and architecture for the site.

a/o 2017 Needs to be updated to define matrix view of "facilities or capabilities"  by "delivery technologies." This provides a tracking grid of feature sets, current vs planned, current technology vs target technologies, etc. Some stuff may "get worse" before it gets better. (In some cases, the number of technologies to do a task, like content creation, can get worse by adding additional tools, before it gets better by having generic core implementations that can be "mapped" to distinct forms using generic mappers.

Purpose

This section of the site documentation describes the major facilities used in the construction and management of the site. Its primary purpose is to serve as a reference for site administrators and other people with a need to work with the site infrastructure. In the spirit of open architecture, it may also be useful to assist with establishing sister sites that may be required to use similar or compatible facilities. These may be community sites that serve a similar purpose as ours but with a different subject focus, or they may be sites with a similar subject focus that want to to inter-operate with this site.

Overview

Why Drupal

The core platform for the development of this Architected Futures™ website is the Drupal content management system. It creates the technical foundation for the site. It was chosen after examining and experimenting with a number of alternative platforms. My focus over time had always been PHP-based, open source content management systems with an open structure that allowed customization and extension. A key requirement being a documented, comprehensible architecture. Most recently I had been experimenting and prototyping with both Drupal, which offers a powerful structure and a lot of nice core features in the Drupal V7+ system, and WordPress blog tool and publishing platform. What I found especially heavy about Drupal was the administrative overhead involved in development of the site. I needed a tool where one person (yours truly) could develop and maintain the web-site, contribute to and manage the content, moderate the community (at least initially) and still be able to have some form of a life. Drupal V6 did not appear to be that tool and I was driven to look for alternatives. WordPress and its associated tools at the WP 3.2 level seem capable of achieving that goal and I began some extensive review of the affiliated BuddyPress package as a platform for my community web site development.

Infrastructure

The foundation infrastructure for the site is defined by WordPress. What platform will the currently used version of WordPress run on. These elements include:

  • A web hosting environment (brand agnostic)
  • PHP scripting engine (version dependent, needs synchronization with WordPress version)
  • MySQL database engine (version dependent)

On top of this we are running WordPress as the remaining component of the infrastructure for our site. Just like the lower level elements were defined by what hosting support WordPress required, the remaining facilities are also defined by what WordPress supports, and how WordPress supports them.

Primary Plugins

The next level of facilities design addresses the following major requirements:

  1. We need a mechanism to organize and structure content within the site. Remember, we have a fundamental focus on structured and semi-structured content creation, discussion and dissemination, and we have multiple content types and discussion techniques.
  2. We need a mechanism to organize and structure how people interact with the content, and to manage the hopeful evolution of a growing population of interested participants.
  3. We need a mechanism to make the site and the content visually appealing.

The key tools we've chosen to meet these primary requirements are:

  1. BuddyPress
  2. Memberships
  3. A custom child theme based on the XYZ Theme System

These plugins and the theme provide the general framework for our site. After WordPress all of the technical capabilities, and dependencies, of our site are based on these elements.

BuddyPress

The key extension to WordPress that enables this website as a facility to organize and enable a community of practice is BuddyPress. BuddyPress is designed as an integrated plugin collection that directly addresses the first two of our requirements: organizing content and participants. BuddyPress is specifically designed to provide community discussion functionality on top of a WordPress base. It provides for organizing users into groups based on common traits and for managing communications between members of the groups using a variety of tools. A key sub-component of BuddyPress is the bbPress module which provides the forums functionality the groups.

Memberships

Memberships is another mechanism for structuring participation on the site and enhances the facilities provided by BuddyPress. Memberships provides for segmenting participants into levels for purposes of authorizing what content they may interact with. BuddyPress has some of this capability, but Memberships extends this to a much finer degree which is useful over a diverse and large content set.

XYZ Theme

From a visual side theming is also very important. The theme chosen for WordPress goes a long way toward not only defining the visual appeal of the site, but also the ease of mechanics of gathering and presenting content for users. BuddyPress adds special requirements and adds a degree of constraint on the theme selection options. For this site we've chosen the Custom Community Pro theme. A major consideration was the fact that the theme component was designed by its creators as a BuddyPress community theme. [af-admin-note] Support pages should include a list of all the WordPress facilities used. It should detail what modules we use for what functions, and why those modules were chosen. In that discussion, it would be helpful to detail what other modules were reviewed for the same or similar functions, and why those modules were not chosen. This will help over time in subsequent reviews and in determining how to make future decisions as the site becomes more complex, as some of the modules lose support and compatibility with new releases and as new modules become available. Inter-module dependencies should be documented. Also our use of module dependencies in our own code should be noted. Links should be provided to the websites of the authors of the used modules (possibly by use of the credits module). On the Drupal site, this included a section for modules and then a sub-page for each module. In that case the initial documentation included a [possibly editted] copy of the readme for the module. [/af-admin-note]

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.