Imagine an application that could hold any kind of data you could think of. Not just text and images — structured data. Named fields. Defined relationships. Information that knows what it is and where it belongs.
Imagine that application could sort that data, filter it, combine it, and display it in any format you needed. A list. A calendar. A map. A chart. A feed. An API. All from the same underlying information.
Imagine it could manage who sees what. A volunteer sees their own records. A manager sees everyone's. An editor can write but not publish. An administrator can do everything except the things only the site owner can do.
Imagine it could present all of that through a graphical interface on the internet that anyone with a browser could use — no training required, no software to install, no IT department needed.
Imagine it was built by a global community of thousands of developers, designers, and thinkers who have been refining it for over twenty years.
Imagine it was free.
It exists.
It's called Drupal.
Oh — and by the way — you can also use it to run a website.
This book is not about websites.
It is about understanding what you actually need — which, in most cases, is something considerably more useful than a website. A website is just the part people see. What you need is the system underneath it.
To understand that distinction, meet Gerald.
Gerald sells shoes. He is good at it. He knows his customers, he knows their preferences, and he knows that Mr. Henderson in the third row of the congregation takes a wide fit and will cheerfully spend two hundred dollars on a pair of dress shoes if you put them in front of him at the right moment.
Gerald keeps this information in a spreadsheet. This is not a character flaw. Spreadsheets are genuinely useful tools and Gerald is not an unreasonable man.
The spreadsheet has columns: name, phone number, email, last purchase date, and notes. The notes field is where Gerald puts everything else. Size 12 wide. Prefers brown. Wife's birthday in March. Allergic to synthetic liners. Referred by the Hendersons. Interested in the new boot line when it comes in.
Gerald's spreadsheet is a small portrait of twenty years of attentive customer relationships. It is also, from a data perspective, a disaster waiting to happen.
It happens at Christmas.
Gerald wants to send a card — a real card, a thoughtful gesture — to every customer who takes a size 12. He has hundreds of customers in that spreadsheet. Some of them are size 12. He knows this because he typed it into the notes field, right there between the preferred color and the wife's birthday.
He cannot get to it.
Not without opening every row and reading every note. Not without spending an afternoon doing manually what a computer should be able to do in three seconds. The data exists. Gerald put it there himself. But it is not structured data — it is text in a box, and text in a box cannot be sorted, filtered, or queried. It can only be read.
Gerald's nephew built the website. Gerald got a perfectly serviceable site with a contact form and some nice photos of the shop window. The nephew does good work. Gerald has no complaints.
But nobody asked Gerald what he needed to do with his information. Nobody asked him to describe the shape of it. Nobody sat down with him and said: what is a customer record, really? What are its parts? What questions do you want to ask of it, today and five years from now?
Gerald's nephew builds websites. That is a different job.
Here is the thing about a proper content management framework: it is slightly annoying before it is useful.
It asks questions. It wants to know what a customer is, before it will let you create one. It wants named fields, not a notes box. It wants shoe size to be a field — a real field, with defined values, that the system understands as shoe size and not as a piece of prose that happens to contain a number.
This feels like bureaucracy. It is actually clarity. The system is not being difficult. It is asking you to do the thinking that will save you at Christmas.
Once shoe size is a field, every customer with a size 12 is one click away. Every customer whose last purchase was more than a year ago. Every customer who expressed interest in the new boot line. Every customer referred by the Hendersons, sorted by how recently they visited, grouped by their preferred style.
Gerald's spreadsheet contains all of this information. It just isn't structured. The difference between structured and unstructured data is the difference between information you can use and information you merely have.
This book is about the thinking that comes before the building.
It will not tell you everything about Drupal. The official documentation does that, and it does it well, and you should read it. What this book will do is explain why Drupal thinks the way it does — why it asks those annoying questions, why it separates content from layout, why it insists on defined fields and named relationships and explicit permissions.
By the time you finish it, you will not be an expert. But you will understand the shape of the problem. You will know what questions to ask before you build. You will not be Gerald at Christmas, staring at a notes field that contains everything and gives you nothing.
You will understand that nobody needs a website.
They need a content management framework that can display information online.
The website is the easy part.