My original intention in terms of a security article was to publish a post that talked about Drupal’s Taxonomy 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. Continue 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.
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. Continue 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. Continue 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 WordPress and 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 Continue 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. Drupal and 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. Continue 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. Continue 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. Continue reading
Today I found a great resource documenting Functional Requirements for Community-Oriented Software and Technologies. Continue reading
In my journey to create architectedfutures.net, one of the things I’m dealing with is a platform infrastructure choice. My current focus is an investigation of Drupal and WordPress. I haven’t chosen between them yet, and I believe either could do a good job for 80 percent of what I want to do, but there are definite differences in the way the job would get done, and, in the end, what gets done. So I’m digging in further, doing additional experimentation, and even toying with some concepts where I might use both. I often go back to basics, core principles, to help clarify my thinking in this process and ask myself: “What is the goal? What are you trying to do? Which is the better approach to getting there?” This post is a reflection in that vein. This post is also trying to document some history for those who are interested in following, or joining, my journey.