Building Architected Futures™https://architectedfutures.info
Working with Community-Oriented Open SourceTue, 26 Sep 2017 21:43:28 +0000enhourly1http://wordpress.com/https://secure.gravatar.com/blavatar/1ad8a41eac3857c78383e809dd907802?s=96&d=https%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.pngBuilding Architected Futures™https://architectedfutures.info
About meta-values to guide more effective action about global crises.https://architectedfutures.info/2017/08/24/about-meta-values-to-guide-more-effective-action-about-global-crises/
https://architectedfutures.info/2017/08/24/about-meta-values-to-guide-more-effective-action-about-global-crises/#respondThu, 24 Aug 2017 21:06:50 +0000http://architectedfutures.info/2017/08/24/about-meta-values-to-guide-more-effective-action-about-global-crises/Abbe Boulah's Weblog: The increasing urgency and global scope of crises like climate change has incited discussions for how humanity can take more more effective action about these challenges. One suggestion was for the common adoption…]]>

Updating thoughts and implementation frameworks beyond where this started.

The increasing urgency and global scope of crises like climate change has incited discussions for how humanity can take more more effective action about these challenges. One suggestion was for the common adoption of ‘systemic meta-values’ that would guide decisions (LinkedIn ‘Systems Thinking World’: ‘Can systemic values help overcome the doctrinal blindness…) The suggestion triggered some discussion about the advisability of the idea, that highlighted its importance. The LI format with its length limitations of posts prevented a more constructive and ‘systemic’ examination. So it seems it might be meaningful to develop a more comprehensive look at the range of arguments, on a platform that permits longer entries.

For the sake of argument, let’s assume that some meaningful meta-value or values can be identified. To assess whether and how well they / it would guide decisions about ‘more effective actions’ (About climate change or any other issue), questions arise, such…

]]>https://architectedfutures.info/2017/08/24/about-meta-values-to-guide-more-effective-action-about-global-crises/feed/0joevansteenSecurity, Part 1https://architectedfutures.info/2012/08/18/security-part-1/
https://architectedfutures.info/2012/08/18/security-part-1/#respondSun, 19 Aug 2012 04:11:35 +0000http://architectedfutures.info/?p=402Continue reading →]]> My original intention in terms of a security article was to publish a post that talked about Drupal’sTaxonomy Access Control (TAC) module. As mentioned within my Drupal Configuration post, TAC is the module I selected for access management of the content in my architectedfutures.net site. My thought was that it might be helpful to detail how I was configuring TAC according to how I wanted to manage access to the various content items on the site for different audiences. Public content, administrative content, content reserved for registered users, etc. However, as I’ve spent time on the site recently, building up content, I’ve also been keeping an eye on how the site is being discovered and accessed by anonymous users. This is prior to any serious advertising or publication of the site URL. (Until I get to a certain critical mass of useful content, I’m not actively trying to drive people to the site. I want to wait a bit for that.) What I’ve seen though is a discovery process based on web crawlers. People and software that go out of their way to make it their business to find new sites and new content on the web. This seems to break down into a few general categories.

First among these are the search engines. This is to be expected, and is actually appreciated. As I build up public content on the site, I want that content indexed and advertised through the search engines. In some cases this was actually advertised, since I notified Google and Yahoo! of my site and my ownership of the site. For others, it was a bit of a surprise. Especially Baidu, the Chinese search engine. I was surprised to find that a Chinese search engine would be that quick to discover a brand new, out-of-the-way site such as mine.

Next there is a certain amount of crawler discovery that is taking place for businesses that make it their purpose to track and keep statistics on what types of sites exist on the web. They don’t seem to really care about the content, just that the site exists, and potentially trying to figure out what technology is being used to create aggregate statistics for the web. I don’t know that this helps me a lot, but it is harmless.

Obviously I can see my activity as I edit the content on the site, and there is a small amount of activity from visitors whom I have notified of some of the content. And there is an occasional hit that comes through a search engine.

But I’ve also noticed another group of visitors who are less welcome. Visits by what I would categorize as malware (as in malicious robots), or malicious users.

Identification

The first part of the process is awareness. Identification of what is happening on the site. And trying to find which of the previously identified categories any particular visitor may fall into. For this I’ve primarily been using two logging mechanisms:

The logs maintained by the Drupal software.

The logs maintained for my site by my hosting provider.

The Drupal logs give me an internal view of what is happening on the site. The general site logs however give me a view of activity that never makes it to Drupal. Together, the two offer a reasonably complete survey of what is happening on the site. What becomes especially interesting in these logs are attempts to get access to non-existing content. Some of which can clearly be distinguished as random probing on the part of the visitor. For example, attempts to use wp-login on my Drupal site. Where clearly someone is trying to use the site as though it were constructed with WordPress for purposes of trying to then log-in. And clearly this is an automated script running, since nowhere on my site is there a reference to wp-login nor is there any reason such a reference should exist anywhere else. Then, there are also the attempts to use the Drupal login facility to log into the site using arbitrary credentials. Happening once is mischievous. Happening daily for multiple days in a row moves somewhat beyond that in my mind.

The normal conversation around web site security focuses on various forms of hacking. Such as this post on cmswire.com. These are discussions of SQL injection, cross site scripting, authorization bypass, password cracking, etc. And the techniques to defeat them when they happen on your site. Which is important, and I am in no way advocating that anyone ignore that aspect of security. Rather, this post asks a different question and addresses a different issue.

Once you have found someone whom you suspect is trying to hack your site in some way, why sit back and play a game of war with them, trying to find out if your software’s defenses are stronger than their ever-changing best means of attack on your site?

From my perspective, once someone demonstrates that they did not come to my site as a friendly visitor, they immediately lose any good will on my part to offer up access to my site or my content. I’m not interested in playing games to find out if my security software can withstand their attacks. I will pay attention to that aspect of security management, but these visitors are simply not welcome on the site. I have no wish to waste my bandwidth on them.

Blocking Malicious Visitors

Given that I’ve identified someone as a malicious visitor, what can be done about it? One answer is blocking access to the site. My site runs using an Apache web-server and supports the use of .htaccess files. This gives me a set of options:

The links provided by the bullet points above give instructions on how to go about implementing these options.

In fact I use both of these techniques. If, on review of my log files, I’ve identified a malicious user based on IP address, then I deny further access to my site for that IP. In addition, I’ve identified a series of referrer domain names which make absolutely no sense as legitimate referrers to my site. These include such referrers as erotic sites within the ru domain and others. I can’t conceivably think of a legitimate scheme for such referrers other than their being used as a basis to support hacking, or their having been hacked and being used as components of a botnet being used to try to hack my site as part of their expansion. Therefore, I’m not interested in traffic from these sites and they are also part of my block list.

Identifying Malicious Parties

When I started this IP and referrer blocking process I was basing the decision of what IP addresses and domain names to include in my block lists on those sites which I had identified in my own log files. Since a number of the malicious IP addresses and referrer domain names had originated in China and Russia, I was curious as to whether other people had built up a list of malicious addresses that could be leveraged. A search turned up www.parkansky.com, which in turn provided a pointer to wizcrafts.net. I’ve found the wizcrafts site to be especially useful. It provides five distinct block lists which can be copy and paste incorporated into my .htaccess file, and it incorporates a page change monitoring facility that allows me to be automatically notified when any of the lists are updated. The block lists include:

All of these lists may be joined into one .htaccess file to include protection from all sites identified on any of the lists. And, since all the lists are maintained by the same person, I don’t have to worry in detail about editing the lists for overlap. (If you find the lists as valuable as I do, you may want to express your appreciation by making a PayPal contribution toward keeping this facility updated and current.) In addition, you can do what I’ve done, and add any other sites which do not appear on these lists but which you’ve identified as persona non grata for your site.

]]>https://architectedfutures.info/2012/08/18/security-part-1/feed/00.000000 0.0000000.0000000.000000Malware_logojoevansteenDrupal Configurationhttps://architectedfutures.info/2012/05/20/drupal-configuration/
https://architectedfutures.info/2012/05/20/drupal-configuration/#commentsSun, 20 May 2012 21:04:02 +0000http://architectedfutures.info/?p=382Continue reading →]]>It’s time to install Drupal on the site. Actually we’re past that point. My last post was about Site Construction Planning and, while I didn’t elaborate on it, I installed Drupal on the site twice. I did this to ensure that my web hosting site configuration was actually compatible with the Drupal software and how Drupal wanted to interact with the hosting environment. That consisted of two, bare-bones, minimal installations. One to test Drupal operating as the primary content for the architectedfutures.NET site, the second as my development and testing environment, operating as a sub domain on the same web hosting account. My chief concern was that multiple Drupal sites could work from the one account, with each Drupal install using all the critical Drupal features, such as clean URLs, and not interfere with each other. Now it’s time to actually configure the Drupal installs into useful, operational websites.

Drupal Installation

I’m not going to spend much time talking about either the detail install process for Drupal, or the physical module installation. There is a quite extensive installation guide provided on the Drupal.org site. There are, however, probably a few points worth mentioning here.

Module Initialization

The first point has to do with the overall method for initializing the site. A lot of discussions I have seen talk about building the site first on a development machine and then uploading the completed configuration and database to the hosting environment. Essentially building the site offline, and then moving it to the online hosting system. This makes a lot of sense for a lot of sites, but is not the path I followed.

I did build a complete site offline on my desktop computer at home. But that site was not what I wanted to start with as my public website. My home development site was created as a prototype to demonstrate Drupal as a group web site. I experimented with and loaded modules like Organic Groups and others to see how those features would work. And I experimented with other modules whereby I built a group interaction ability using features supplied by other modules, piece by piece. These group features are the types of facilities I think I may want on the web site if a community were to form around some of my concepts. And my development site gave me an understanding and assurance that I would be able to do what I wanted with respect to those features. However, I am not sure I want to carry out the community features with the current modules I am using on the development machine. Also, I do not need those features for getting started. So I don’t want to simply copy that environment.

Instead, I have the ability to build multiple environments on my shared hosting account, so I’m going to build a fresh install using that environment, and then replicate that new, scaled-down configuration into the public production web site. In addition, I’m going to be evolving my site in-place over time, growing function as I add content. I want to start that mode of site management, and discover its problems, from the start.

Installation Profile

The second point has to do with the choice of installation profile. I am not using any of the special Drupal installation distributions which are available to initialize things like group sites, news sites, conference organizing sites, etc. However, there is still a basic installation profile choice to be made: minimal versus standard. While I wanted a minimal installation to use as a base, I did what most books recommend and I selected standard. This is a point of confusion which I had that I thought could trip up others, which is why I mention it. Standard really is minimal, and minimal is really bare bones. This Drupal.org documentation node details the difference between the two profiles in terms of what gets configured when selecting each profile.

It’s Never Completely Done

An additional point is that while Drupal was installed as part of my site configuration, by the time I actually completed my development machine testing, for how I wanted to theme the site, a Drupal security release and a bug-fix release were issued. So a Drupal core upgrade was in order as part of the Drupal configuration process. First on my desktop development machine, then on the A2Hosting shared hosting web sites. Since the shared hosting installs had not yet been customized with add-on modules and themes, the updates were a little less cumbersome than normal. But an interesting part of the development machine update included a problem that appeared in the Backup and Migrate module. I used the module to backup my database prior to the Drupal upgrade. When I tried to backup again, after the upgrade, I was unable to do so because of an error in the Backup and Migrate module that only appeared with the new version of Drupal. Updating that module with a new version fixed the error, but running though the process was another reminder of the work effort that I can look forward to associated with maintaining the site.

Strategy

My general Drupal configuration strategy is to try to be conservative in terms of engineering and security issues and to be evolutionary in terms of functionality and capability.

What this means to me is that unless there is a very special need, I want to only use modules on my public web site that are full production release versions. Alpha, beta and release candidate modules are not considered fully ready for use on production web sites; so I want to avoid using those features until a final module version is released. Since I am using Drupal 7, this limits some of my choices. Some functions that are fully released for Drupal 6 do not yet have final release D7 versions, so I need to find alternatives or hold back on those functions. It also means that I want to stay current on security releases, and I want to install a few extra modules that will help me manage security related issues on the site.

What it also means is that in terms of the public site I want to use an evolutionary approach. If you’ve followed my blog posts you might remember that part of my objective is to be able to support a community of practice web site. But that involves a lot of function and is well beyond where I am now. I wanted to choose a web platform that could grow to that ability, but I don’t need it all now. I just need to initialize something a little more advanced than a simple blogging platform, and then slowly grow the additional functions, as the need develops, over time.

Modules

Core Modules

As I mentioned above the standard Drupal installation profile activates a number of core modules when the system is installed. I used that option because I want most of these modules and it saves time to use the standard profile to activate them. Two exceptions in my case are the core Toolbar and Shortcut modules. Instead I want to use the Administration Menu module. However, at the time I configured my site the Administration Menu module had not yet released a finished version for Drupal 7. Only a Release Candidate version was available. So I left both of these modules activated. Later, when a final Administration Menu module is available, I’ll implement that and disable the Toolbar and Shortcut modules.

In addition to the modules activated as part of the standard profile, I activated the following core modules:

Aggregator — This module can gather, read, and display news, text, images, and other content from external news sites and blogs around the internet. Especially as I am getting started, this provides a mechanism for me to establish some community between my content and purpose and others on the internet who are publishing and involved in similar interests and concerns.

Blog — Blogging doesn’t really need a special module, but I want to lay a base to support multiple blogs down-stream, if the need develops; and I don’t want to go through the hassle of conversion or style changes at that point. So, I’m going to implement the blog function on my site with the Drupal core Blog module, which supports both single and multi-user blogs.

Book — This module provides a mechanism for adding a navigable content type which is more suitable for some of the documentation I want to publish on the site. The standard profile implemented a basic page content type and an article content type, but neither of those includes the automatic navigation functions associated with this feature.

Contact — This provides a simple way to build a Contact Page for the site, and provides a feature where registered users will also be able to interact with one another through personal contact pages.

Statistics — For a busy, high performance site I have read that this module is not recommended. However, that is a problem I only hope to have at some later date. In the mean time, this will offer an easy, integrated method for me to check statistics about how the site is being used.

Community Modules

The following add-on (community supported) modules were also implemented as part of my initial installation:

Backup and Migrate — Simplifies database backup and migration from within the Drupal framework.

Display Suite — Allows full control over how my content is displayed using a drag and drop interface.

Footnotes — Used to create numbered footnote references into book pages, articles or posts.

Freelinking — Implements a text filter for the easier creation and management of HTML links to other pages in the site or external sites.

Global Redirect — Works with Pathauto to force single clean URLs for each node. (Probably to be replaced by Redirect, which is currently in a beta state for D7.)

IMCE — IMCE is an image/file up-loader and browser that supports personal directories and quota. This allows images for use in content to be maintained integral to Drupal content management functionality.

Mollom — Provides spam protection to the Drupal site using an external anti-spam service. I’ve been using the Akismet service to handle comment spam on this (WordPress-based) site and am pleased with how it operates. Mollom is a similar service by the creator of Drupal. I hate spam and a spam filter seems like a hard requirement for me.

Panels — Drag and drop content manager that lets me visually design a layout and place content within that layout. The focus and purpose are a little different from Display Suite. See a discussion of this in Display Suite vs Panels.

Pathauto — Generates URL/path aliases for various kinds of content (nodes, taxonomy terms, users) without requiring the user to manually specify the path alias. This allows me to have URL aliases like /category/my-node-title instead of /node/123.

Revisioning — supports management of content under a revision control system, where new and revised content may be viewed and managed between authors and editors and not allowed to be accessed by general users. Once content is approved and published, it then becomes generally available for users. This is very helpful in a group collaboration environment. I’ve also found this useful in a single author environment where I want to have a more professional, controlled management process over what I am publishing.

Security Review — A helper module for review of security issues on the site.

Taxonomy Access Control — Provides access control (permissions) for user roles based on taxonomy categories (vocabulary, terms). There are multiple schemes available. This is my preferred method after reviewing the alternatives.

Token — Tokens are small bits of text that can be placed into larger documents via simple placeholders, like %site-name or [user] and then globally replaced with other values when and wherever they occur. The Token module provides a central API for modules to use these tokens, and expose their own token values.

Views — The Views module provides a flexible method for Drupal site designers to control how lists and tables of content, users, taxonomy terms and other data are presented. This tool is essentially a smart query builder that, given enough information, can build the proper query, execute it, and display the results.

WYSIWYG — Allows and simplifies the use and management of client-side editors to edit content.

Theme

I’ve played a bit with a few themes in the course of my experimentation with Drupal versus WordPress. Mainly I’ve been looking for something uncomplicated and clean. (Which was also my choice here for this blog.) When I first tried Drupal, and was using D6, I liked the Nitobe theme. However, when I came back to do a more intense WordPress versus Drupal comparison using D7, there was no D7 version available. Even now, as I write this, it is only available as a beta version.

This set me off on a different path. I started looking for something following a theme/sub-theme arrangement. This was something I liked in the WordPress environment. Which led me to Zen and then to the Contented5 sub-theme which I liked, and which I used for a while. I read reviews and discussions, and more experimentation finally brought me to Omega and a responsive grid layout. I really like the idea of responsive themes which self-adapt to the viewing platform. In the old days it was (just) browsers that were of paramount concern, and maybe looking for fluid versus fixed width capability. How will the content look using IE? Firefox? Chrome? 15″ screens versus 20″ screens versus notebooks. But now we have the platform format issues too, for tablets and phones and who knows what, so the responsive themes make a lot of sense to me.

In terms of responsive themes I was impressed by a review on friendly-machine.com and an interview with Jurriaan Roelofs, the author of the Arctica base-theme and the Respondr premium theme discussed in the review. This is also a responsive framework. I like the overall logic Jurriaan expresses in terms of his design choices and the idea of not just adapting to the size but also the features of the new formats. However, I found some of the components a little confusing and there is a lack of documentation on this theme at this point, so I decided to back away from the bleeding edge in this regard and stick with Omega as the theme for architectedfutures.net, at least for the time being.

Resources

The following links name some of the other resources which I found useful in this stage of implementing the website.

Books

Front End Drupal — a great introduction to Drupal theming, but watch for the new D7 edition

]]>https://architectedfutures.info/2012/05/20/drupal-configuration/feed/10.000000 0.0000000.0000000.000000drupliconjoevansteendrupliconSite Construction Planninghttps://architectedfutures.info/2012/04/13/site-construction-planning/
https://architectedfutures.info/2012/04/13/site-construction-planning/#respondSat, 14 Apr 2012 00:59:47 +0000http://architectedfutures.info/?p=341Continue reading →]]>Having made a decision on the website software (Drupal), and a choice for a web hosting provider (A2Hosting), it’s time to do some detail planning for how to lay down the software on the hosting framework. And, there are a number of options. Since I’m using a shared hosting solution, the first decision is whether or not to have the Drupal software installed and managed using A2Hosting’s auto-installer. That option would give me an easy “one click” installation process; but it also removes detail control of the configuration from my hands, so that isn’t the option I want. I actually want to follow a route that gives me more detail control over how the site will be configured. Of course, that also means I have to take more responsibility for getting the job done.

Requirements

One of my key criteria in the configuration of the hosting environment for architectedfutures.NET is how I expect the platform to be initially used. The reality is that I am starting out with a website where I hope to attract visitors; but which, in essence, is really a place for me to begin to assemble and document my thoughts about my work in a publicly visible, transparent way. The site will be a place for me to put my documentation and notes about my thinking. A place where those notes can be viewed and commented on by others, but a place which may not have a large initial audience. This was the same criteria that told me it was okay to use a shared hosting environment, and not a VPS or more advanced hosting arrangement. This same line of thinking leads me to think about my hosting platform as potentially a multi-functional platform, and not something that needs to be fine-tuned for a dedicated, high-performance application. And that line of thinking influences how I want to configure the site.

From an architectural perspective what I am dealing with is two things, and it is important to understand the difference between them.

architectedfutures.net is a soft entity. From a practical basis it is the information and visualization that appears on a web browser when anyone visits the site. This is independent of the hardware and software platform that may have generated that information.

The A2Hosting web hosting facility is a hard entity. It consists of an actual set of hardware and software configured in a particular way to generate the architectedfutures.netHTML stream.

The first and key requirement for the configuration of the hosting facility is how the architectedfutures.net web presence and the hosting platform come together. architectedfutures.net needs to seem to the user as a complete and independent entity with a clean and exclusive identity. This means that the content should not appear as a sub domain nor should it appear under a visible sub-directory. Any web link or browser reference to “http://www.architectedfutures.net” or to “architectedfutures.net” should directly reference and engage the primary content of the site as delivered by the Drupal software, as though that were the only content on the site. And, as the needs of the architecturedfutures.net website change over time, perhaps to the point of needing to be upgraded to a more robust platform, that change should be able to be accommodated transparently. I should be able to separate the two things, by moving architecturedfutures.net to some other facility as its needs change, and the change in hosting platform should not be visible to the users of the site. Changes in hosting platform should also be transparent to any search engine data base that may have accumulated by that point. Given that as primary, I then have some extra requirements for how I want the hosting facility configured:

For purposes of being able to manage site updates, Drupal should in fact be implemented from a sub-directory. This would allow multiple independent Drupal installs to be implemented on the same facility. architectedfutures.net should direct to the “current” or “primary” or “production” implementation. But development.architectedfutures.net, for example, should access a development or test version of the site hosted on the same web hosting facility. (The reason for this, is to be able to test changes to the site, on the site, before the change becomes effective as the default code for public access. Only persons who know the test access path will have access to the test code. The test code should run against a test database, but otherwise be as representative as possible of the production environment. Changes may include styling of new content, changes in presentation, module upgrades, the introduction of new modules, or minor or major upgrades to the Drupal core code.)

The primary site should support the implementation of SSL for at least some functions, but the development site(s) may not need or use SSL.

I want to have the option of hosting other applications on the site if desired. These may include such simple things as raw HTML or simple PHP code, or some other application like a wiki or a polling system. The extra applications need not be SSL protected. These applications would probably be related in some fashion to architectedfutures.net and could either be addressed as subdomains or as functional sub-areas (sub-directories) of the main site.

I want to be able to simply and quickly “nullify” the site at any point, if needed, by replacing the site with a fixed HTML page.

I want a fallback, contingency option in the event that Drupal fails to satisfy my needs or requirements. I want to be able to redevelop the site using some other software suite on the facility, and then have a simple cut-over procedure to “flip” the site when it is ready, if that were to become necessary.

Solution

Preamble

Prior to getting into the details of the solution, there is an item of note that should be mentioned. When I started to research how to carry out a solution to my requirements a lot of what I found on the internet were discussions about how to create a Drupal “multi-site” configuration. This is NOT a Drupal “multi-site” configuration. Drupal multi-site is designed to drive multiple Drupal sites from a single code base. It’s created for “sharing” the code. It’s designed to minimize the effort required to keep the Drupal code base for multiple websites up to date and synchronized. The whole idea with Drupal multi-site is that multiple sites are all using the same versions of the same Drupal code. The whole idea here is to NOT share the code, but to have multiple sites, each with their own code. Updating one set of code should have no effect on the other site. This is necessary to run simultaneous different versions of Drupal, or different versions of modules, or different module configurations independently. One instance can then be used as a staging or testing area without impacting what is operating in the other area. The staging “sub domain” can be the last test stage for a configuration change before the main site is modified. This way the changes actually get tested in the same hardware and software environment as the public site before the change is installed on the primary site.

Overview

The general solution to my requirements is to sub-divide my web hosting resources and to place each distinct version of my Drupal software into its own directory space. The Drupal software will be uploaded and installed multiple times, once in each directory. This increases my maintenance effort, but it will allow me to run multiple different versions of the Drupal code from the same resources. Each installation will be completely and independently configurable. And, because my hosting plan provides for multiple databases, I am going to use a separate database for each Drupal install. The only new requirement this places on any other applications which I may want to run from the same environment is that they must be able to be installed and operated from their own independent sub-directory.

The main document directory for my hosting resource, the document root, becomes my point of control for any global actions I want to take across the entire set of resources.

Addressing

The issue of addressing has two perspectives:

What does a user need to type, technically how does a URI need to be written, to get the data or execute the interaction which the user desires.

What assumptions do search engines and related tools make based on the way URIs for the site are configured.

As soon as I started playing with sub-directories I began down a road where the implications of URI addresses needed to be confronted. (Actually the issue existed before that, but it was a lot less complex.) My understanding is that search engines will treat each domain or sub domain as a separate entity. Sub-directories within a domain are all generally considered to be the same site. I definitely do not want the search engines to assume that everything in my hosting environment is all part of my architectedfutures.net website. I especially don’t want the development/staging site to be confused with the production site. And I don’t want users of architectedfutures.net to need to include a sub-directory name as part of every URI for the site. I may want some of any “add-on” facilities to seem to be part of the main website, but I probably want others to seem to both users and search engines as distinct and separate. This is all about addressing.

So I have a couple of challenges:

I want to eliminate the need for the knowledge or use of the sub-directory label as part of the main architectedfutures.net website, and

I want to “flag” the content of some sub-directories as being distinct from the main site.

For the components of the site that I want to be viewed as separate, such as the development/staging area(s), I’m going to use subdomains. These will take the form of names like development.architectedfutures.net, test1.architectedfutures.net, etc. Each of these will be given a separate sub-directory under the document root, and for each one I’ll use my hosting provider’s cPanel facility to create a unique sub domain name pointing to the proper sub-directory.

Access Management

This is where the core of the solution happens, in the .htaccess file. Since I’m dealing with a shared hosting environment, I don’t have access to the Apacheconfiguration file for my website. But the .htaccess file allows me to do the specific access management configuration which I need to do. Since the .htaccess code can get confusing, especially the rewrite conditions and rules, I’ll discuss the configuration elements in sections to describe how I’m going about getting the results I want.

For my configuration I am actually making adjustments to more than one .htaccess file. These are discussed in sections below.

Document Root .htaccess File

The following constitutes the adjustments for the .htaccess file located in the document root of the web server. In my case, at A2Hosting, this is in the public_html folder. Directives applied here will also apply to any sub-directories unless they are overruled by an .htaccess file in a lower level directory.

# Turn off indexing so as not to allow browsing of file directories
Options -Indexes
# Configure for redirection
RewriteEngine on
Options +FollowSymLinks

These first few lines in .htaccess can be considered preamble. The lines beginning with ‘#’ are comments. These lines can be eliminated, but I like to leave in the comments to remember why I did certain pieces. The “Options -Indexes” line tells the Apache web server to not generate indexes for web folders which do not have an “index” file. I consider this a good security policy. The “RewriteEngine on” line tells Apache to activate the rewrite engine, the facility that enables rewrite rules. And the last line tells Apache to follow symbolic links. This enables processing for the instructions which come below.

These next lines eliminate issues related to search engines or other spidersthinking that http://www.architectedfutures.net and architectedfutures.net might be two websites with duplicate content. Any references to http://www.architectedfutures.net are redirected to architectedfutures.net (without the ‘www’ sub domain). The specification is provided in the form of two statements, a rewrite condition (RewriteCond), followed by a rewrite rule (RewriteRule). Multiple conditions may be joined and applied to a rule, but in this case we are only using one condition: all HTTP_HOST target specifications beginning with ‘www.’ are being redirected to the same specification without the ‘www.’ portion of the URI. The ‘[NC]’ flags at the end of the rewrite condition makes the test case insensitive (upper and lower case differences are ignored). The ‘R=301’ flag on the rewrite rule forces an external redirection request through the requesting agent (the browser or search engine) and provides the agent with an error code ‘301’ on the initial request. This tells the user agent, the browser, to reissue the request to the adjusted name (without the ‘www.’ sub domain) and informs the agent that the ‘www.’ named site has been permanently moved to the renamed site without the ‘www.’ sub domain. The ‘L’ flag indicates that the redirection instruction should be executed immediately and no further .htaccess processing should occur for this request. With this instruction in place, anyone who references our site using a ‘www.’ sub domain should see the site name changed to remove the ‘www.’ portion of the name in the address bar of their browser. Their bookmarks and other references should be updated to remove ‘www.’ prefixes. And search engines will recognize that both names are equal and there is only one site behind both names. (A slightly different form of these instructions could be used if I wanted to standardize on always using the ‘www’ prefix for the site, but my choice is no ‘www’ prefix.)

Next come three sets of rewrite conditions and rules which do the redirection of requests for the primary web domain. This functionality is what I want to have processed by the primary Drupal installation in the ‘drupal’ sub-directory.

This third rewrite specification redirects all requests that do not specify actual file or directory requests. They are adjusted to be processed by Drupal (index.php) in the production Drupal sub-directory.

This last directive is really a model and not a real directive in my .htaccess file. I need multiple copies of this RedirectMatch directive in the file, one for each sub domain on my site.

The directive is similar to the canonical addressing rewrite rule identified above for the main website. However, rather than rewriting www prefixed URLs, this directive is used to rewrite all attempts to access the sub-directories which have been set up to support sub domains, and force access through the sub domain names. The sub-directory folders are being blocked from access as parts of the primary domain website. Instead, they are being forced to be accessed via the sub domain URL. One such line is supplied for each sub domain where the ‘sdd‘ literal in the RedirectMatch line identifies the name of the folder or sub-directory, and the ‘sdn‘ portion of the directive defines the sub domain name assigned to the independent website. For example, ‘develop‘ might be a directory containing a testing and development version of Drupal addressed as development.architectedfutures.net, where ‘development‘ is the sub domain name. This allows multiple development sites to be hosted on the same hosting facility depending on my needs. I could also create another instance in a directory called ‘d8’ to support advanced testing of Drupal V8 if I so desired. Or I could create different versions to test different module combinations. Each of these would get their own RedirectMatch line and each would be established as a sub domain using the cPanel facilities.

Primary Domain (/drupal) .htaccess File

Drupal includes an .htaccess file in the root of each directory set where Drupal is installed. Some of the reference resources I have supplied below suggest modifying the Drupal supplied file to eliminate the rewrite directive processing. On review of the file as supplied with Drupal 7 I have not done this. The rewrite directives in the file are in addition to the ones I have identified above, and they appear to make sense and work fine if left alone. I have found no need to adjust the file in the primary Drupal installation.

Sub Domain .htaccess File

For my development sub domain Drupal also creates an .htaccess file (one for each install). Again, this file works fine and supplies Drupal’s standard desired attributes for a Drupal installation. However, for my development directories I did make a change. The file supplies two sets of directives, both commented out, that can be used to force canonical names for the website. I’ve uncommented a set of these directives to standardize my sub domain names. As with the main domain name, my practice is to disallow the ‘www‘ prefix on these sub domains. This change is accomplished in the .htaccess file in each Drupal sub domain.

settings.php

When installing Drupal you create a file named settings.php which you create by copying a file named default.settings.php. Both files are located in the /sites/default directory. The file is Drupal’s site-specific configuration file. Most of the content for this file is created by the Drupal install program based on information you give when you run the install process. I have found it necessary to change one entry in the file after the install process has completed, but only for the primary site.

The file has a commented entry for the base_url variable. It looks like this:

# $base_url = 'http://www.example.com'; // NO trailing slash!

In the settings.php file for the primary site this entry needs to be uncommented and adjusted to reflect the canonical name for the website. In my case, this looks like the following:

$base_url = 'http://architectedfutures.net'; // NO trailing slash!

Without this change I have found that sometimes after executing some Drupal process the address bar of my browser will refer to the home page of my site with an address that includes the directory in which I have Drupal installed. With this change in place, that does not occur.

Again, I have only found this setting required on the primary Drupal install, not on the development install that is accessed through a sub domain. I suspect the reason for this to be that the sub domains all have rewrite directives which issue 301 error codes when they are addressed this way, but there is no such rewrite directive when the primary domain is addressed this way. (Attempting to create such a rewrite directive tends to generate an infinite rewrite processing loop.) In any case, this eliminates the confusion on the browser address bar for the client.

Robots.txt

The robots.txt file is a special file which resides at the root of a domain to keep search engines and other web crawlers from indexing or accessing those parts of the overall site which we do not want to be available as search engine content. Some documentation on the web implies that these files need to be in the document root directory. The authors then offer various .htaccess rules to manipulate a set of robots.txt files to serve up the correct version of robots.txt depending on which sub domain is being accessed. In my research, including some experimentation with the Google WebMaster tools, I have NOT found this to be necessary. The robots.txt file simple needs to be available for access as though it were in the root of a web domain as a file directly addressed under the domain name as though it were in the root of the domain. For example, as in http://www.example.com/robots.txt, or http://www.sub1.example.com/robots.txt. What this means is that it is possible to avoid special .htaccess rules if the robots.txt files are simply placed appropriately on the site. In effect, the robots.txt files are no different from the Drupal index.php files for each “domain” we are supporting. The robots.txt file for a domain simply needs to be in the relative root for the domain. (It needs to be in the sub-directory of the hosting site which serves as the root for that domain.) My robots.txt for architectedfutures.net goes in the public-html/drupal sub-directory, and my robots.txt for development.architectedfutures.net goes in the public-html/develop sub-directory.

Primary Domain robots.txt Content

The robots.txt file for my primary domain came as part of my Drupal install package. For the most part, I want to leave this alone. It accurately reflects how I want my website viewed by the search engines. However, I want to add some specifications.

The Drupal supplied robots.txt file assumes that Drupal was installed at the document root of the website, in my case it assumes it is positioned in the public-html directory. However, in my case it is actually in the public-html/drupal directory. The Drupal robots.txt file provides appropriate search engine instructions for everything under the public-html/drupal directory (addressed as architectedfutures.net/something), but it fails to specify anything about the other directories under public-html which may also be addressed as directories under architectedfutures.net. So I want to add entries to the robots.txt file in public-html/drupal to disallow searching in these other directories. The following lines do this:

For the most part these lines should not be needed. References to these directories should not generally exist outside of my website. However, if any do exist, these lines will keep search engines from using those references to rediscover any areas of my site through non-standard access paths.

Sub Domain robots.txt Content

My development and/or test sub domains which are Drupal installations also include robots.txt files. However, in these cases I don’t really want the sites indexed and documented in search engines. So, for these domains I need to replace the robots.txt files which came as part of the Drupal install package with a new robots.txt file which disallows all access. The following robots.txt replacement file does this task:

# robots.txt
# For all robots
User-agent: *
# Disallow all crawling of the site
Disallow: /

A copy of this file replaces any other supplied robots.txt file and goes in the main sub-directory supporting each of my development and testing sub domains.

Final Note

One last note about site configuration. As a general rule I do not believe in security by obscurity. However it does make sense as a defense in depth measure. I have read multiple tutorials like what I have presented here that discuss using a ‘drupal‘ directory as the name for your primary Drupal install, and using a ‘develop‘ directory as the name for a development or staging area. Just as I have done here. In actual practice these are NOT good names for the associated directories, nor is it a good idea to publish your directory names on a public website, such as what I am doing. That would not be good sense nor would it be a good security practice. One of the benefits of moving your website deeper into your hosting facility is to make it harder to hack the site. If you are going to take the trouble to do that, don’t use names that are easy to guess and don’t publish your directory names. The names supplied above are not the names I use on my site. Don’t use them on your site either!

Resources

The following links identify some of the resources which I found useful in this stage of planning the website.

]]>https://architectedfutures.info/2012/04/13/site-construction-planning/feed/00.000000 0.0000000.0000000.000000120px-040329-N-8937A-063joevansteenWhere and How to Host the Sitehttps://architectedfutures.info/2012/03/19/where-and-how-to-host-the-site/
https://architectedfutures.info/2012/03/19/where-and-how-to-host-the-site/#respondMon, 19 Mar 2012 19:45:25 +0000http://architectedfutures.info/?p=333Continue reading →]]>Ok, so I want to build my site with Drupal, and I’d like to customize it with a theme of my choice and modules specific to my desired functionality. But where to host the site, and what kind of hosting plan? That’s the next big question. What I’ve been doing during my evaluation process is building a series of web sites on my home computer. That’s not giving me a 100.000% accurate picture of how the final site will behave, but it’s been plenty close enough for what I’m doing. And it’s been telling me what’s possible. But now it’s time to move on.

Luckily, this isn’t the first time I’ve entered these waters. As I mentioned in some earlier posts I had played a little with setting up a small website back when I first retired from Bank of America in 2005. At the time, even though I was coming out of an extended career in system development at the bank, I didn’t have any real (professional) experience in web development. So I was reading ads for hosting providers with very little understanding of how to decide what I needed, and where to get it. Pricing was a big consideration. Based on price, and the apparent benefits of “one stop shopping” (not a good scheme BTW), I ended up buying a shared hosting package from GoDaddy. Not the right thing to do, either as a selection technique or as a landing-place.

After working in that environment for a while, I found I was having issues with the system, I was not greatly pleased with the support, and I was having problems with the software package I was trying to use at that point (PostNuke and then TikiWiki). So I researched hosting providers again and found a new provider that was TikiWiki friendly – HostDime.com. And, that worked for a while. But then another problem came into play. At the time I was using TikiWiki as a framework and trying to use it to host some custom functionality of my own that I had developed using PHP, which was also a new experience for me. As I got deeper into the development task I found that I wanted to move from PHP4 to PHP5 for the stricter OOP environment. Well, HostDime at the time was firmly attached to PHP4 and didn’t offer a PHP5 environment. My account at HostDime was again a shared hosting account, so I was back in the market for another provider. That search led me to A2Hosting.com in Ann Arbor. A2Hosting offered both PHP4 and PHP5 on shared hosting accounts. They offered TikiWiki. They had competitive rates. And they were supportive and responsive when I had questions or issues. Definitely a better environment. I stayed with A2Hosting until I finally bailed on the TikiWiki exercise and no longer needed the account.

Following that experience I’ve spend time chasing a number of paths toward my objectives. Some of those paths have been PHP-based, some have been Java-oriented. Some have been web-centric, others have been desktop oriented for the presentation layer. My current path is two-fold, and is split over two technologies. My primary focus for the core tool set which I am interested in is Java-oriented, and my current primary focus for that development is based on the Eclipse framework. At the same time, I am moving into an open development mode for my Entity Architecture Tool Suite™ (EATS™). I want a web platform for communication and collaboration of EATS™ concepts. The collaboration platform is the architectedfutures.net website. Theoretically everything I’m doing with EATS™ could provide a framework for a website built on EATS™ as an infrastructure. However, that would really send me out into left field building scaffolding for my scaffolding. And there is so much else that is available. So, for architectedfutures.net the technology framework I’ve selected is Drupal. That’s the site I’m looking to host.

As I’ve gone down this road, I’ve accomplished some tangential research about web platforms and hosting alternatives. One exercise had to do with hosting facilities for a possible Java servlet-based implementation. This tended to push me toward VPS (virtual private server) solutions and caused some research in that space. More recently as I was investigating both Drupal and WordPress I began looking at recommendations for hosting techniques and providers in both of those communities. There is no perfect provider. For every provider there seems to be someone out there who has had a bad experience. Billing. Installation. Performance. Of course some providers have larger groups of “anti-fans” than others.

One of the issues of concern to me as I did my evaluation between Drupal and WordPress was performance. Performance is a major factor in terms of usability. If you are putting up a website for people to interact and enjoy, it has to be usable. Consistent multi-second (or longer) page flips can really be a problem. There are a lot of factors that go into performance as experienced by the end-user. Within the blog commentary on Drupal performance and hosting I saw a lot of comments that seem to favor VPS over shared hosting. And this concerned me a bit. As I mentioned, I had looked at VPS, but I really wasn’t thrilled with going down that road right away. Straight VPS meant that I needed to configure and support my own virtual machine environment. Pick my Linux implementation, install it, maintain it. This is something I could do, but not something I wanted to do. On the other hand there was Managed VPS. But the price goes up for the added services, and the configuration options go down.

Before this whole issue became to much of making a mountain out of a molehill, I sat down and did a little more research, did some practical evaluation of where I’m at and what I’m doing, and thought back about some of my past experiences.

For extended research I posted a LinkedIn discussion thread on a Drupal discussion board asking for advice from other more experienced users on the skills and time requirements to manage and run a Drupal website in a VPS environment. I was very pleased to find that this actually brought out some counter-opinion that indicated VPS wasn’t necessarily a requirement for a successful, functional Drupal site. People started identifying that shared hosting was being used quite successfully to operate viable sites at the smaller end of the spectrum. And, I got a lot of good input into how to set up a VPS site if I wanted to go that route. From a practical basis I had to consider that I really didn’t want to spend much money for the initial site, and … I was unlikely in the beginning to have much audience demand on resources. (Had this been a business site, or an internal corporate site the demand forecast might have generated a different result.) And, from earlier experience I knew I wanted a vendor that was responsive and customer friendly, someone who offered up-to-date, although not necessarily bleeding edge, technologies. This sent me back to A2Hosting. I searched some more and started finding references to A2Hosting being used by others for Drupal sites. Not a lot of references, but almost all positive. And, when peoiple identified their domains, I checked out their sites. Just to see how responsive they were. And things looked pretty good.

So, that’s one more task out of the way. I’m targeting an A2Hosting shared hosting environment as my first home for architectedfutures.net. They offer SSH access to shared hosting accounts. They seem to be staying current on technology options. They offer VPS and Managed VPS options if the need arrives to go that route. They are familiar with Drupal. They aren’t the least expensive, but they have a nice plan which is very reasonable for getting my started. And I’ve dealt with them before and had a good customer experience. Lets see how this works out.

]]>https://architectedfutures.info/2012/03/19/where-and-how-to-host-the-site/feed/00.000000 0.0000000.0000000.000000joevansteenInternetPart 4, Decision Timehttps://architectedfutures.info/2012/01/05/part-4-decision-time/
https://architectedfutures.info/2012/01/05/part-4-decision-time/#respondThu, 05 Jan 2012 22:28:05 +0000http://architectedfutures.info/?p=301Continue reading →]]>I’ve gone back and forth on this for a while now, but from a practical basis I’ve made a decision. Not that I haven’t made this same decision multiple times in the past months, and each time in a different direction. But I’ve found myself spending almost all my time in one camp for the last few months as I pursue architectedfutures.NET, and I find my intention is to stay in that camp unless something significant proves unworkable. In my way of thinking, that’s worth logging as a decision.

I’ve been holding back from declaring a ‘final’ choice in this evaluation because I was still waffling, I wanted to make an informed decision and I wanted my decision to ‘settle.’ Now, after having spent some time working with both WordPressand Drupal, building prototypes and testing various versions of what I want to do with architectedfutures.NET using both systems, I’ve decided to spend my efforts going forward working exclusively with Drupal as my platform of choice. This is definitely not the decision I would recommend for everyone. And it’s not the decision I saw myself making once I broke out and began seriously exploring BuddyPress last year. But it’s the decision that I believe makes the most sense for what I am trying to do, the way I’m trying to do it. What I’ll try to do in the rest of this post is explain some of my reasons for going this way. What I’ll also do as I go forward is to show how I’m planning on using Drupal to build architectedfutures.NET. What are some of my detailed functional requirements? How am I getting those requirements satisfied? What problems and technical issues am I running into, and how am I going about resolving those items? As I’ve mentioned before there is no fully correct answer, and there is no free lunch. There are going to be some problems and frustrations with Drupal. (I’ve probably picked the more difficult path to follow.) But it’s a new year and it’s time to formalize a decision and move forward with the project.

Recap

How did I get here?

My Road to Here and Now post defines the general back story for this journey. It talks about different tools and approaches that I’ve tried over the years and how the scope of the effort has grown over time. It also provides some introduction to the essential elements of my problem space, my Entity Architecture Tool Suite™ and communities of practice.

In Part 1 of this series I presented my first Drupal versus WordPress contrast relative to my objectives. I also took some time to talk about functional and non-functional requirements, and I explained how to use a decision matrix for scoring criteria.

In Part 2 I talked about my goals and objectives. I talked about what form of social network I want to support with my website and who the participants are likely to be. I also discussed how I might handle a situation where the software solution might be different in the initial launch stage than at a later stage with a mature community. Given this framework I then defined a high level specification for the software to support my planned website.

In Part 3 I reflected on Architecturally Significant Requirements – ASRs. For me, this is the critical area for the decision, especially when dealing with a choice where the functional requirements don’t define an overwhelming favorite. Key ASRs discussed in that post included learning curve requirements, the customer focus of the support organizations and the “architectural match” between the alternative platforms (Drupal or WordPress) and my intended website.

Today’s post is an extension of the discussion on ASRs that drove toward the Drupal decision.

Decision Factors

Security

One of the tasks I accomplished after writing my last post was to undertake an analysis of security concerns I have for architectedfutures.net and an evaluation of how well those concerns are addressed using either of the two proposed platforms. I spent 35 years working in a corporate IT environment and security ranks as one of the top concerns in my mind. In this area I found the following differentiating factors to be significant in my decision:

Organizational focus on security – I like the idea that the Drupal community includes a security team who take on the task of inspecting Drupal core and community contributed modules for security risks, and, after fixes have been identified, informing users of the potential problem areas. WordPress, to my knowledge, has no such program or process. In fact, I find it disturbing when I read advice in the WordPress community that advocates security through obfuscation.

User roles and permissions are a cornerstone of Drupal thinking. The permission system (which users are authorized to do what functions or see what data) is an integral part of the Drupal architecture and an element that is part of most community contributed components. This is a far more advanced and comprehensive approach than that implemented by WordPress.

Required Functionality

All of the critical things I had on my list of functional requirements could be implemented using either system. That’s partly why I was waffling in my decision. However, there is a certain style or approach to the way the features are implemented in Drupal that I find more appealing. I find the implementation of the Drupal core functions, and the suite of capabilities implemented by the Drupal community, more in line with my tastes, my desires and my objectives. I feel that Drupal offers me a better CMS base platform on which to build a customized system of my own design. In terms of how those specific capabilities match to my functional requirements, my intention is to focus on different details of what I’m doing in follow-on posts. I’ll explain the approach I’m taking for selected features and how I’m addressing the requirements with different Drupal modules.

Functional Richness and Granularity

Functional features are something where either system can be programmed to implement a custom module to perform some identified function. The question is, how many of those modules already exist in useful form, or do you have to code most, or all, of them yourself. The available feature set is something that gives you an idea of what the rest of the user community is doing with the system. Where is the community going and what might you expect to find in the way of contributed modules over time. This is the area where I was very impressed with the activity I saw happening with the BuddyPress plugin for WordPress. However, after working with Drupal 7 for a while now, I’ve found a number of significant capabilities that are hard to ignore. This includes not just capabilities similar to those available in BuddyPress to support an online community, but other facilities like RDF web page encoding and related tools to enable the semantic web. And the structure of the feature set is more to my liking.

With WordPress/BuddyPress I found myself working with course grained function sets. This was nice in terms of getting a large block of functionality working quickly. But it becomes more difficult to shape and modify how the details of that package work, and then to be able to keep up with new revisions as the base software is changed. With Drupal it is sometimes very hard to figure out how best to put together a collection of finer grained modules to collectively accomplish a larger task. But when you piece things together component-by-component you get a collection that is much more tailored to your objective, and the individual parts are easier to replace or modify without as many issues coming up in terms of maintenance over time.

CODE MANAGEMENT

There are a number of factors related to code management that caused me to move back and forth between Drupal and WordPress. In Part 3 of this series I opened the post talking about change and change management. A major concern in my head was quick movement between major code releases in an open source world driven toward change. WordPress has some nice attitudes and practices which I appreciate. These include providing code warning messages and publishing lists of deprecated functions, and attempting to maintain some backwards compatibility before dropping an obsolete technique. New major releases of Drupalprovide no backward compatibility with the previous Drupal code. There is a data contract but no function contract across major versions. In the beginning I was very much taken aback by this Drupal philosophy. However, now that I’ve worked with it for awhile, I’m still not crazy about the policy but the practical effects seem a little less onerous. I’ve found some mitigating circumstances.

For one, Drupal maintains coding conventions and standards for contributed code. There is a project in the Drupal contributed code library named Coder which can be used to perform an automated code review of any module. The Coder project also supports a module which can be used to assist in upgrading modules from one major version to another. So, if you happen to be using a module which has been abandoned by its support team, and you need that module in your system, you at least have a fighting chance at being able to upgrade the module yourself to keep it functioning in an upgraded system.

For another, the major code release and adoption cycle for new versions of the Drupal core may not be as quick paced as I anticipated. This is something that will take time to determine, but the adoption cycle for Drupal 7 has been slower than I expected. It may prove that as the user base builds up, there is a longer time delay between major releases. An interesting observation in this regard is that Acquia, the company led by Drupal‘s founder, Dries Buytaert, offers hosted versions ofDrupal as a service product. At least some of these versions are still operating onDrupal v6 almost a year after Drupal v7 was released. If Drupal‘s policy is to only maintain and support two major versions for bug fixes and security releases, I have to assume that either the Acquia product suite will migrate to D7 before Drupal v8 is released, or the policy will change to support three versions. In any event it is helpful to have the company dealing with issues as a co-consumer of its own policies. (Note. A similar situation exists with Automattic‘s operation of WordPress.COM. Although in that case there is less dependence on contributed plugin modules. In the case of Drupal Commons, the Acquia community site package I investigated, it is community provided modules making up part of the package functionality that is preventing the move to Drupal 7. That puts Acquia in a position a lot closer to its user base.)

Lastly, I like the visibility of release differentiation and compatibility as handled by Drupal compared to WordPress. On the WordPress.ORG download site there is a single version published for a plug-in module. Typically that version has a statement by the author that it is compatible between a minimal and a maximal version of the WordPress core. Sometimes the most recent version published for compatibility is obsolete because the author hasn’t updated it, but the code still works with newer versions. As a second point of reference there is a place for user’s of the code to record their experience matching a module version with a WordPress version and voting it up or down. Its something of a crap shoot if you want the functionality the module promises but it doesn’t quite match up to the core version you are using. (And ideally you should be trying to stay up to date with a reasonably current core.) With Drupal you are dealing with two major releases of supported core code. And user contributed modules are hard coded to claim compatibility with a specific release of core. A claim that is enforced by the core code. On the Drupal.ORG module download site modules can be searched and are identified for download for Drupal versions from 4.7 through the developmental version 8. Most modules continue to offer their most recent versions for old releases for download, even though the code may no longer be maintained. And most modules offer current production releases, alpha or beta releases of new versions as they become available, and downloads of development releases (which sometimes include early access to fixes for reported problems).

Alignment With EATS™

Compatibility and alignment with EATS™ concepts and ideas was something I did not really expect to find. When I was considering building architectedfutures.net with Drupal 6, and when I was considering building it with WordPress/BuddyPress, EATS™ was a separate entity in my vision. What I envisioned was the community web site providing a vehicle for documentation and discussion about EATS™, but that the actual prototype and development would be done in Java as a separate entity. Now, with Drupal 7, I find that limited vision being challenged. A full-blown, fully implemented EATS™ platform still probably wants to be implemented as a Java (or similar language) installation, not PHP. But some form of an early, experimental version might actually make sense under a Drupal framework. It’s to early to tell how that might work out, but that would be a very nice outcome.

Conclusions

As I proceed with my task, I find that some of my concepts are changing. This is entirely typical. It’s very hard, if not impossible, when setting out to create a new system to completely and accurately specify all of the details of how the final product should behave. That’s partly why we have found some success in systems development by moving toward iterative development methods.

One of the things that I’m finding is that I want to build my platform using tools that provide me greater facilities as a web development platform, rather than simply a publication and interaction facility. And, while I’ve spent a lot of my professional life as a software blacksmith, building my own tools, I want to be able to spend more time experimenting with and integrating tool sets built by others, rather than needing to construct almost everything on my own.

This is what’s led me to move forward with Drupal as my platform of choice. I hope that by having documented some key aspects of how I’ve made my decision, I’ve shed some light on the process so that my journey can also help you in making a better choice for your project. In some cases by selecting a different route.

Thanks for reading, and “good luck” with your effort.

]]>https://architectedfutures.info/2012/01/05/part-4-decision-time/feed/00.000000 0.0000000.0000000.000000Unbalanced_scalesjoevansteenPart 3, ASRs and Riding the Wave of Changehttps://architectedfutures.info/2011/09/21/part-3-asrs-and-riding-the-wave-of-change/
https://architectedfutures.info/2011/09/21/part-3-asrs-and-riding-the-wave-of-change/#commentsWed, 21 Sep 2011 20:52:22 +0000http://architectedfutures.info/?p=288Continue reading →]]>One of the problems with life is dealing with change. Nothing is static. Everything is constantly changing. While that has always been true, the pace of change has accelerated in modern times. The volume of changes that seem to have some impact on us has gone up, and the awareness of change has intensified. We are constantly told that newer and better stuff is now available, to replace the stuff we just bought yesterday, which we may not have had a chance to use yet. We live in an era where we now measure things in internet time. Stability and constancy are old-fashioned virtues. This is a hallmark of technology and is particularly true when dealing with computers and software. Open source software is no exception; in fact, quite the opposite is true. Drupaland WordPress have different schemes for how they drive change into their user communities and offer different facilities to their users to comprehend and administration change. These differences are not inconsequential.

What Are Architecturally Significant Requirements (ASRs)?

Architecturally significant requirements are those requirements that play an important role in determining the architecture of the system. Such requirements require special attention. Not all requirements have equal significance with regards to the architecture.

ASRs are either functional or non-functional requirements (see part 1). What makes them significant is the impact they have on the architectural solution. If the ASRs aren’t satisfied the customer, the user, isn’t just inconvenienced, the solution doesn’t work; it doesn’t do the job. The architecture is wrong for the problem. It doesn’t provide a solid and stable solution, or it fails to please the user in how it achieves its function. Deciding what is architecturally significant is a matter of skill and judgment. Determining how well a particular solution fills requirements, especially before the fact (a priori), is again a matter of skill and judgment.

ASRs are typically defined in terms of key requirements that are the motivating factors in the design of the architecture for the system. Some of these requirements are functional. A lot of these requirements arequalitative. But what does that mean? In the architecture of buildings there is a significant difference between a church, an office building and an airplane manufacturing facility. That’s functional. But the difference between a church, a chapel and a cathedral isn’t so much functional (putting aside the aspect of scale), it’s qualitative. Or compare the differences between a half-dozen major office buildings, or compare a half-dozen architect designed 3 bedroom, 3 bath, two car garage houses. The differences in the architecture of the office buildings, or the houses, isn’t functional so much as qualitative. The same is true of other systems, including software systems and social systems. “What is it?” tends to be about function. The way it gets done, the style, the attitude, tends to be qualitative. And quality matters. Quality can drive durability. Quality can drive satisfaction.

Architected Futures Community of Practice ASRs

For my evaluation of Drupal versus WordPress (versus whatever) as the technology platform for the Architected Futures Community of Practice (AFCoP), the object being architected is AFCoP, not WordPress or Drupal. I am not writing the specifications for, nor am I designing, Drupal or WordPress. So, I am not trying to define, nor am I overly concerned with WordPress or Drupal ASRs. I am concerned and focused with AFCoP ASRs.

What I’m saying is that things exist in layered, compositional hierarchies. At some point we draw a line around something and that becomes the object of focus. The architected object. The environment it exists in is outside of the object. It may have interactions with other things in that environment, but they are external to the object of concern. You don’t really design your environment. You come to grips with it; you learn to deal with it. As you look at what is inside you decompose the object into parts. If the parts are novel, you may need to design (architect) them. As you do that, you decompose those parts into other parts. If the parts aren’t novel, you can either design new parts, if you feel the need, or you can obtain pre-fabricated parts from a catalog; or you can do a little of each by making adjustments to catalog parts. This is the internal mechanics of the object. However, at some point, you become unconcerned with the details of how the remaining parts work. It stops being a primary issue with respect to operation of the object you are concerned with. The parts just need to do a job. Catalog parts are fine. You don’t want to design how they do that job, as long as the job gets done. If one part doesn’t work to your satisfaction, you swap it out and get another part.

There are two layers of architected entities that I am primarily concerned about in the creation of my community of practice.

The first, outer layer, is AFCoP – the community of interacting people. This is essentially the architecture of a social system, a Community of Practice. That community will exist in an environment of planet Earth, human beings, the internet, etc. The components involve topics, interaction policies, the involved people, groups and sub-groups, technology for communicating, etc.

The inner layer of concern to me is the architecture of the technology platform to support the Community of Practice. The technology platform architecture is a part of the Community of Practice architecture. The platform will be architectedfutures.net. The environment for architectedfutures.net will be the AFCoP community, a hosting service, the internet, external support services, etc. The components of architectedfutures.net will include a lower level (nested) technology platform (WordPress or Drupal), a particular set of add-on modules, etc.

The AFCoP technology platform, architectedfutures.net, is an ASR for AFCoP. How well the community is able to interact is critically dependent on the facilities provided by the technology platform. To meet that ASR architectedfutures.net is being designed specifically to meet the needs of AFCoP. This won’t be a social network site for a church group or a book club. It has special requirements to support the mission and focal interest of the Architected Futures™ community. If certain features, some functional, some qualitative, aren’t there, then the success of the community will be jeopardized. In a similar way, the choice of base platform (Drupal, WordPress, some other package, custom code, etc.) is an ASR for architectedfutures.net. The structure, the support requirements and the way the functional capabilities are provided by the infrastructure is a critical factor in the success of architectedfutures.net. But it isn’t all or nothing. The Drupal and WordPress platforms are being evaluated as candidate components to provide the base for architectedfutures.net‘s architecture. Some tasks can be done with either platform, although they may vary somewhat in how they are done. Other tasks or functions aren’t so benign. Their presence or absence may be critical to the community, or the way they are achieved may have a major effect on the community. That impact makes those qualities of the infrastructure architecturally significant to the community of practice. Those are the key qualities I want to focus on in terms of my decision.

]]>https://architectedfutures.info/2011/09/21/part-3-asrs-and-riding-the-wave-of-change/feed/10.000000 0.0000000.0000000.000000By Original: Cpl. Megan L. Stiner. Later edits:Solitude at en.wikipedia [Public domain], via Wikimedia CommonsjoevansteenPart 2, The Specificationhttps://architectedfutures.info/2011/09/11/part-2-the-specification/
https://architectedfutures.info/2011/09/11/part-2-the-specification/#commentsMon, 12 Sep 2011 04:01:09 +0000http://architectedfutures.info/?p=265Continue reading →]]>The next step in this community of practice software evaluation is to define my goals, and to brainstorm the initial requirements to achieve those goals. Not everything in this series of posts will follow this top-down, linear path; but starting out with this material will give context and add structure to the evaluation process.

Long Range Objective

My long-range objective is to explore and develop architectural engineering methods as part of an automated tool suite to manage the evolution of future environments.

Ultimately this is a journey, not a destination. You do not need to grok that statement or identify with this goal to benefit from following along with this series on my Drupal–WordPress evaluation process. Your goal might be very different from mine. To get the most benefit from this series your goal should have something to do with creating and maintaining an online community. If so, you can probably use a lot of what I will discuss.

If the goal that I’ve stated above is meaningful to you and interests you, you may also be interested in following, or joining, the online community at architectedfutures.net once that site goes on the air. You can use the Contact page to send me a note and I’ll keep you informed when that happens.

If the goal is just gobbledygook to you, here is an attempt to translate:

I view architecture in a general sense. My definition of architecture is:

The art and science of designing synergistic structures in a manner which achieves utility, durability, and delight to its users. The architecture of an object is the manner in which its components are assembled into a unified whole designed to satisfy a cohesive purpose. Architecture as a practice is the art and science of designing structures, systems of composite elements, into unified wholes to achieve that purpose. The quality of an architecture can be measured by its social relevance in terms of utility and satisfaction of function, its soundness of engineering and durability, and its esthetic characteristics and the ability to bring delight to its users.

There is architecture to buildings, towns and cities; but there is also architecture to software systems, planes, trains and automobiles. There is architecture to social systems and governments. There is architecture to all composite systems where the parts act together as some form of unified whole for a purpose that is derived from the whole, not from the individual parts.

Paraphrasing Wikipedia architectural engineering is the application of engineering principles and technology to the design and construction of an architected system, an architected entity or an architected element.

So, my goal is to design and build a suite of software tools which foster taking a holistic view of architected entities, and applying engineering principles and methods to help manage change in, and on, those entities; to move them (evolving them) to achieve a more desired or more beneficial future form. In theory, these tools might be used to manage the evolution of a software system, a business entity, an ecosystem or a society. All of which might be considered to be architected entities.

I’m a futurist. I’m fascinated with what will be and what can be, and how things can be shaped or steered so that certain outcomes can become more likely, goals achieved, problems avoided, etc. As a software developer you build systems today for use by people to help them perform functions more effectively tomorrow. As a planner, designer or architect, you create a product to change an environment to operate in a different, hopefully better, manner than the way it was operating without your changes. Your product is composed of components that need to work according to certain parameters to meet your design objectives. And your product operates within, is impacted by and changes the environment it is placed within. The scale of the problem of understanding the relationships and complications of these issues boggles the mind for most products (processes, organizations, …) of reasonable complexity in today’s world; and the impact of not understanding some potentially critical relationships can be disastrous. Bridges fall, cars crash and financial systems collapse. I believe there is a need for good tools to help with this task. That’s a need I would like to help fill.

If that’s still gobbledygook, suffice it to say that my goal is to build a software product to help people make better decisions about things that impact how the future will unfold.

]]>https://architectedfutures.info/2011/09/11/part-2-the-specification/feed/10.000000 0.0000000.0000000.000000Johnson's_specification,_1857joevansteenDrupal-WordPress Evaluation, Part 1https://architectedfutures.info/2011/09/02/drupal-wordpress-evaluation-part1/
https://architectedfutures.info/2011/09/02/drupal-wordpress-evaluation-part1/#commentsFri, 02 Sep 2011 20:37:38 +0000http://architectedfutures.info/?p=248Continue reading →]]>One purpose of this blog is to provide payback to the open source community and to contribute to the knowledge-base that is freely available on the web. Take a little, give a little. As I develop architectedfutures.net I want to put some of my process and analysis on the web in a form that allows others to critique, copy or emulate what I am doing. The criticism should help me improve my product. Providing useful content for others to emulate is payback for what I have been able to obtain gratis in my research efforts. This is the start of a series of posts in that vein. The series will detail my decision process for selecting the base platform for the architectedfutures.net site.

As covered in other posts, a big thing I want to talk about on this site is a Drupal vs WordPress decision I’m making for the architectedfutures.net site. Depending on the discoveries I make and the feedback I get, that may turn into an evaluation that also includes Joomla – or possibly some other alternative. Right now, for resource and time management reasons, I’m going to leave it at just two: Drupal and WordPress. I mention Joomla because it seems to come up in other serious evaluations that I’ve seen. (Plone is also mentioned but I ruled it out because I want to stick with a PHP implementation. Plone is Python-based.) From the evaluations I’ve seen I would think that Joomla (and potentially Plone) should also be part of any serious CMS competitive evaluation, unless you (like me) have already ruled them out in a higher level screening. In my case I based that screening on language choices and research looking at evaluations done by others, not a detailed analysis. That means that as I go down this path I’m going to leave Joomla out, but I’m open to bringing it in if an appropriate case is made. Right now, I just can’t afford the resources to include it, and from what I’ve read, I doubt that I will have missed my best alternative for what I want to do.

First, I want to say that this is not a marketing pitch. I’m sure that for some folks, in fact for a lot of folks, WordPress will be the best alternative. For others, Drupal is really what you want to use. And yes, for others Joomla or Plone is your best choice. And there are some people who should use brands x, y or z. Go to cmsmatch.com or cmsmatrix.org. There are lots, and lots of alternatives. For most people, more than one can probably do a good job. There probably is not a “best” fit that is head-and-shoulders above the crowd for you, or the one that is best for you may not be the same one 99.99% of the rest of the population would have chosen. But you need to make a choice and get on with life. What you want is to make a “good” choice and realize that every choice will involve some trade-offs.

In this first post I’m going to talk about configuring the process of making the choice. I’m not going to delve into any of the detail product comparison. So if that’s what you wanted and why you are here, you should probably bail now. However, if you’re interested in making a serious comparison that will have some lasting impact on your business plan or your community project, then you may want to keep reading. For those who have done serious product evaluations before, you too may want to bail on this particular post and come back to read some of the detail follow-up in the series. I’m hoping that you’ll at least skim the rest of this though, and offer a comment if you see something glaring that should change, be deleted or be added. I will follow-up this post with others that look at specific elements of the systems, either on a head-to-head basis, or on a one-off basis (like what I did in my BuddyPress – WordPress Profile Synchronization post). Those follow-up posts on my part will fill in the details of the process for me. If you are in a hurry, you don’t have to wait for me to complete my choice. You can use the process I’m describing here and use other research from other sources to fill in the detail scores. If you follow the overall process, you will still have a good chance of coming up with a very good answer for you. The type of answer you will be able to sell to your customers, associates and/or management, and one that you can live with without regrets.

(More on page 2, below)

]]>https://architectedfutures.info/2011/09/02/drupal-wordpress-evaluation-part1/feed/60.000000 0.0000000.0000000.000000By ???? ??????????? at uk.wikipedia [GFDL (www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-sa/3.0/)], from Wikimedia CommonsjoevansteenBy ???? ??????????? at uk.wikipedia [GFDL (www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-sa/3.0/)], from Wikimedia CommonsFunctional Requirementshttps://architectedfutures.info/2011/08/31/functional-requirements/
https://architectedfutures.info/2011/08/31/functional-requirements/#respondThu, 01 Sep 2011 01:06:40 +0000http://architectedfutures.info/?p=240Continue reading →]]>Today I found a great resource documenting Functional Requirements for Community-Oriented Software and Technologies. Go to the web page and click on the HTML button, or the small “x” button next to it. I may come back and review this document again later in a discussion of evaluating and rating alternatives, but I didn’t want to wait in terms of sharing the resource.

For anyone trying to search out and evaluate community-oriented software, this looks like a useful resource. It is an Excel spreadsheet identifying a series of functional requirements broken out in groups. It include detail functions which can be measured against candidate solutions. It is dated and identifies itself to be a work-in-progress, but it has a nice list of things to think about and evaluate already included in the document.

Another resource that I’ve known about for some time and which I used in my own process can be found at idealware. They are “a 501(c)(3) nonprofit, provid[ing] thoroughly researched, impartial and accessible resources about software to help nonprofits make smart software decisions.” They publish a nice report comparing WordPress, Drupal, Joomla and Plone for use by non-profit organizations. Their report includes evaluations of systems in key areas and includes ratings in terms of how well each software system performs: none, fair, solid or excellent. They update the report periodically to keep it fresh and up to date.