Additional background information on ProcessWire including its history, what the term “ProcessWire” means, and more.
ProcessWire history
ProcessWire was released as an open source project in October, 2010. ProcessWire 3.x and 2.x originally evolved from Dictator CMS (2003) and ProcessWire 1.0 (2006). Despite intentions to do so, neither product was ever released open source, though powered numerous large scale websites for many years. ProcessWire 2.0 (2010) was the first open source version, and it is architecturally much stronger than the CMSs that preceded it. ProcessWire 3.x represents the current iteration of the software and it continues to build upon the framework introduced in ProcessWire 2.x.
Below is the video where ProcessWire was originally released as an open source project in 2010. While ProcessWire has evolved a lot since then, everything in this video remains true to this day and it continues to serve as useful introduction to the platform:
What does the term “ProcessWire” mean?
Conceptually: wiring your processes together
ProcessWire is the “wire” that delivers the electricity to your “process”. The term “ProcessWire” refers to bringing everything together simply, easily and securely. Specifically, bringing together all the processes involved in building a website or application and wiring them all together to create something whole and complete.
ProcessWire enables you to make all these connections intelligently, efficiently and easily. It is the timeless tool that works with your existing processes (whatever they may be) and seamlessly wires them together into something much greater than the sum of its parts.
In addition to the conceptual definition, you'll also find the term “ProcessWire” refers quite literally to the code that it is built from…
Literally: structure of core, modules and classes
The term “Process” refers to the type of module that ProcessWire is designed to execute as an application in order to serve an http request. All http requests in ProcessWire are served by one type of Process module or another, and there are more than a dozen of them in the core (with many more available 3rd party).
For instance, all requests on the front-end of your site are served by the ProcessPageView module, while pages are edited with the ProcessPageEdit module, just as examples. Think of a Process module kind of like an executable (.exe file) in the Windows world, or an Application in the Mac world, and think of ProcessWire as the underlying operation system that connects and executes them.
The term “Wire” refers to ProcessWire's core, since it is effectively the wire that connects everything and the wire that delivers the “electricity” to power a website or application. As such, everything related to the core literally lives in a /wire/ directory. By the way, this directory can be replaced with the same thing from any other version of ProcessWire (without touching your own website files), making upgrades a simple matter.
Finally, “Wire” is also the name of the base class for everything in ProcessWire. From an object-oriented programming perspective, almost everything in ProcessWire descends from this Wire class. As a result, everything in ProcessWire has a common and predictable base which serves as the foundation for making it all modular and hookable. Any given Wire-derived class can “wire” another Wire-derived class, which is referring to the type of dependency injection used by ProcessWire. In addition, Wire-derived classes can hook before or after the methods of other Wire-derived classes (where allowed), add new methods or properties, and replace existing methods when necessary.