Unlike many architectures, for Drupal the database doesn't stand front and center. The database layer is not a module, nor do modules need to declare a specific relationship with the database. In fact, many Drupal modules do not ever interact directly with the database. For that reason, a module can exist, yet not have any database structures models , a central controller, or even any user-centered theming view. In stead of treating the database as a central architectural component, Drupal merely provides an API for working with the database.
In Drupal, the database is just a place to store data. Need custom tables? Drupal provides a system for declaring them. Need to get data out of the database, or insert or update new data? Drupal provides functions and an OO library for doing so. However, if you don't need such features for your code, you needn't work with the database at all.
In fact, in the next chapter we will write our first module without writing a single SQL query. Later in this book, we will see how to interact with the database using Drupal's robust database tools. The Drupal database does not store just application data or content , but also configuration, caches, metadata data about data , structural information, and sometimes even PHP code.
While Drupal may not be database centric, it most certainly requires a database. During initialization, Drupal will connect to a database and retrieve certain configuration data. Later, as many of the core modules load, they too, contact the database to retrieve or update information. For most Drupal modules, the database is the location for data storage.
The final component from our initial architectural diagram is the theme system. Drupal separates the look-and-feel components of the system from the rest of Drupal, and provides a programmatic way for theming data. The system for handling this is collectively called the theme system. Some of the theme system resides in the Drupal core libraries. This part is responsible for initializing themes and locating what theme functions and templates should be applied under certain circumstances.
A theme is a structured bundle of code like a module that provides tools for transforming raw data into formatted output. Sites use at least one theme to apply a consistent and custom look-and-feel to all of the pages on the site.
However, Not all theme code resides inside of a theme. One of the distinct advantages offered by Drupal is the capability to define default theming inside modules, and then provide mechanisms by which the theme layer can selectively override those themes. In other words, a module might declare a rough layout for a component, but Drupal provides the structure for a theme developer to later modify the theme not the module to re-layout that component in a different way.
If this all sounds conceptually difficult, don't worry. Chapter 3 and Chapter 4 of this book are dedicated to working with the theming system. Now that we've had a quick architectural overview, let's change perspectives and quickly peruse the major subsystems offered by Drupal. In the previous section we took a birds-eye view of Drupal's architecture. Now we are going to refine our perspective a bit. We are going to walk through the major subsystems that Drupal 7 has to offer.
The theme subsystem was introduced above, and since Chapter 3 and Chapter 4 will cover it, we won't dwell too much on it here. However, there are a few details that should be mentioned at the outset. The responsibility of theming a given piece of data is spread out over the Drupal core, the modules, and the applied theme itself. While we don't modify the Drupal core code, it is important for developers to be able to understand that both module code and theme code can manipulate the look and feel of data.
In this book, our focus will be on the module perspective. We work primarily with theming functions and templates that are defined within the module. Typically, it is the best practice to work this way first—to ensure that every module has the ability to theme it's own data. Drupal not only maintains content, but also details about how the site itself is organized. That is, it structures how content is related. The principle way that it does this is through the menu subsystem.
This system provides APIs for generating, retrieving, and modifying elements that describe the site structure. Put in common parlance, it handles the system's navigational menus. One source of frustration for developers new to Drupal is the fact that the application's front controller is called the menu router.
However, this system is not identical to the menu subsystem. Its responsibility is to actually map the URLs to callback functions. We will return to the menu router in later chapters. Menus are hierarchical, that is, they have a tree-like structure. A menu item can have multiple children, each of which may have their own children, and so on. In this way, we can use the menu system to structure our site into sections and subsections.
Perhaps the most important subsystem to know is the node system. In Drupal parlance, a node is a piece of text-based, publishable content. It can have numerous fields defined, but typically it has a title, a body, and various pieces of auxiliary data, such as timestamps, publishing state, and author identification. In computer science, the term "node" often has a special meaning. Drupal's own definition of node is distinct. It is not a point on a graph, but rather a piece of content. One might prefer to think of a Drupal node as a structured document.
The node system is mostly implemented in the node module. This sophisticated module provides dozens of hooks, though means that many other modules can and do interact with the node module via hook implementations. Since nodes account for the content of the site, understanding the node system is an indispensable requirement for the Drupal developer.
For that reason, we discuss aspects of the system throughout the book. In previous versions of Drupal, externally generated files notably images were not handled directly by Drupal itself.
Instead, there were a plethora of modules available for working with files. This has changed in Drupal 7, which now has a file-centered subsystem. This means working with images, documents, and so on is now substantially easier. While Drupal has long had a sophisticated suite of tools for dealing with the filesystem in the files. Drupal is not designed to be merely a CMS, but also a platform for social media. Central to any concept of social media is a robust user system that can support not only administrative users, but also site members.
Drupal offers a powerful user subsystem that allows developers to work with just about all aspects of user lifecycle, from what fields show up on a user profile, to what permissions at a fine-grained level users have, to what particular encryption scheme is used to encrypt the user's password. Drupal's user system even provides tools for making authentication and other aspects of user management pluggable.
Modules provide, for instance, LDAP integration or authentication through many of the publicly available authentication services like OpenID. Perhaps the most common social media tool is comments.
Drupal provides a subsystem that provides comment functionality for nodes and by extension, other data types. While one could imagine that comments are merely a type of node and, in fact, there are modules that do this , Drupal developers have chosen to implement comments as a separate type. The comment module contains the majority of the comment code. However, again, as with the node system, it provides numerous hooks, and thus many other modules interact with the comment system.
In previous versions of Drupal, the node system was really the only system for creating structured pieces of textual content. Comments are too focused to be generally useful for extension. In order to extend node content beyond simple title and body fields, one needed to either write custom node types or use the Content Construction Kit CCK to build node types.
The fields system brings most of CCK's functionality into core. The entities system makes it possible to define other structured data types that are not nodes. Already these new systems are making waves among Drupal developers, with the Drupal Commerce module leading the way in defining sophisticated entities that are not nodes. These two subsystems are new, important, and also complex. So we will cover them in detail in Chapter 6. This system provides a robust programmatic tool for defining, displaying, validating, and submitting forms.
It takes much of the busy-work out of developing forms, and also adds a layer of security. FAPI is so integral to Drupal that we use it numerous times throughout the book. More sophisticated Drupal use-cases may benefit from the ability to customize the installation process. Drupal provides an installation profile subsystem that can be leveraged to create a custom installer.
Using this, developers can set custom themes and modules, change installation parameters, and generally streamline the process of installing sophisticated Drupal sites. Programmatically testing code is a well-established practice in the software development industry. In Drupal 7, it is a capability of the core Drupal distribution. Using the Simple Test framework, developers can now use functional and unit tests to validate their code.
We employ testing throughout this book. In fact, we will write some of our first tests in Chapter 2. Along with the primary content, most web pages also have additional content displayed along the top, bottom, or sides of the page.
Drupal's block subsystem handles the configuration and display of these units of content. Most of this functionality is concentrated in the block module, and we will develop our first custom block in Chapter 2. In this section, we have provided some basic information on several high-profile subsystems.
However, this list is not exhaustive. There are numerous others, and even some very important ones like Views that are not in core, but provided by third party modules. Some of these other subsystems will be introduced and discussed throughout this book. However, Drupal is a sophisticated system, and no book of a manageable length can go into all of the details. For that reason, we provide references throughout the book pointing developers to the appropriate resources on the web and elsewhere.
Drupal is a sophisticated platform, and from the glimpse above we can see already that there are numerous systems and structures to keep track of. In this section, we try to provide tools that simplify or streamline the development process. We assume that you have your own web server stack and your own PHP development tools.
The authors of this book each use different editors, operating systems, and web server stacks, so we collectively understand that there are many good tools for developing PHP applications.
And Drupal itself doesn't require anything special. While running a PHP debugger is certainly not necessary, you may find running Xdebug or the Zend Debugger to be useful. One of the authors of this book first learned how Drupal worked by stepping through an entire page load.
Managing source code is a major part of any software development lifecycle. In this regard, Drupal 7 coincides with a major transition period for the Drupal community. However, Drupal has grown and the needs of the community have changed. Drupal is now moving to the Git distributed version control system. As we begin working with Drupal code, it will help to be able to have the tools necessary to work with Git. From command-line programs to full-featured desktop applications, there is no shortage of tools for this.
Please note that the manual library process is not as streamlined an install as a prepackaged module. Webform 8. If you use Webform, do not attempt to upgrade to Drupal 9 until you have upgraded Webform to its new 6. Upgrading to Drupal 9. Drupal Version. Drupal 8. Notes, tips, and tricks for upgrading a Drupal 8 site to Drupal 9 Moving to Drupal 9 from Drupal 8 does not involve near as much planning and preparation work as previous major version upgrades thanks to changes the Drupal organization has made to the development process.
Drupal 9 requires a settings. To upgrade to Drupal 9, you must be on Drupal 8. If you are already on 8. Drupal 9 requires all active themes and modules to declare Drupal 9 compatibility: Compatibility is indicated by a line in the theme or module's. Drupal 9 as did Drupal 8. If you are using any add-on CKEditor plugins, check each one to see if there's a 4.
Composer should maintain the compatible plugin version with a Drupal 9-compatible release. As an example, Balloon Panel, used by Accessibility Checker, was one that needs to be up-to-date to work in Drupal 9. Custom view modes and custom fields can also be defined. The Drupal Devel module is a very handy tool for developers and site admins. It is widely used in testing purposes because of its ability to generate a lot of content for nodes, comments, users and various content types and entities.
Also, it allows developers debug any problems with node access. Page footers can be added for all pages with the help of its submodule called Webprofiler. Webprofiler also gives the site admins an insight to some analytics about the caching abilities, database queries, resource utilization and much more. Having a well-structured URL does not only improve the user experience, it is very vital for search engine optimization too.
The Drupal Pathauto module is definitely a must-have module in every Drupal project. Site admins can also change the pattern system by changing the tokens it uses. The Drupal Google Analytics module adds Google analytics tracking system to your website.
Using this Drupal module, all features of Google analytics can be accessed and integrated with your website. It allows for domain tracking, users tracking, monitoring tracked links, monitoring downloaded files, site search, Adsense support and much more. Be it personalization modules, social media integration modules, marketing automation modules or any other module, you can always find more than one for each functionality.
Before you download a module, you should know if it is going to be compatible with your version of Drupal. You just cannot install a version 7 module into your Drupal 8 installation without cross checking if it is supported.
To find out what version of the module has been released in Drupal. You must keep in mind that although the contributed Drupal modules are free of cost, they are not feather light. Unused modules can unnecessarily consume a lot of space and resources which can make your Drupal website heavier and slower.
So, before you download a module, analyze if you really need it or if any other core module can perform the same functionality for your website. Also, feel free to abandon those hardly used and inactive modules to make your website feel healthier and light. It is very important to choose modules that are actively maintained, updated and published by the developers. Also, you will be sure that an updated new version is on its way soon.
Using popular modules means you can trust the module to do the job and be secure with less issues. On clicking on the link, you will be able to see a detailed report of all bugs and issues.
0コメント