Drupal Module Ideas
Of all the content management systems (CMSs) that one could choose for building a new website, Drupal has an advantage over most of the alternatives: One can extend the programmatic processing within a website, by using what are known as "modules". A Drupal module is a set of PHP source code files and other types of files that together, when installed and enabled on a Drupal site, change the existing functionality of Drupal or add new functionality which would not be possible with a generic installation of this CMS, which installs the default Drupal code base known as "core".
All Drupal modules are grouped into two categories: The "contrib" modules are written and contributed to the Drupal project by voluntary developers capable of employing PHP code and other web technologies. All these contrib modules can be found on the main Drupal module page. There are more than 48,000 such modules (as of this writing), although fewer than 18,000 are actively maintained and about 5000 are minimally maintained. The second category comprises "custom" modules, which are written by developers for use only on a limited number of Drupal sites usually just the site currently being built for a client and in need of custom functionality that could not be obtained from using core in conjunction with any of the existing contrib modules. For example, years ago, when I was busy building Drupal 7 sites for small businesses, there were many times when the Drupal core code and contrib modules were not enough to handle use cases specific to the client's needs, and thus I would create a custom module that could do so.
During those years, whenever I thought of a potential contrib module that could be valuable to myself and other developers, but did not have the time to create it then, I simply noted the idea, with the intention and hope of eventually being able to return to that idea and transform it into a working Drupal 7 module. However, like most computer programmers, I was overoptimistic about how soon I would be able to make time for those tasks. In addition, Drupal 8 made substantial changes in the way that modules are structured and thus built, resulting in another Drupal learning curve (in the opinion of many coders, another dreaded Drupal learning cliff, as the changes were quite significant enough to induce a large portion of such coders to avoid it by switching over to a fork of Drupal, named Backdrop).
In this article, I share these notes with the Drupal community, in the hope that they might motivate a Drupal 9 contributor to build one or more of the proposed modules, or at least to germinate some ideas on other potentially useful ones.
Apache Htaccess Save and Restore
Of the four web servers that Drupal supports, the most commonly used is Apache, which can utilize a configuration file, .htaccess (for "hypertext access"). The file is typically utilized to modify the URL and/or control visitor access to the website by comparing the URL or IP address provided by the visitor, trying to match it to specific values or text patterns, and if there is a match, making changes to the URL, forwarding the visitor to a different one, or completely denying access to the website. For instance, in the .htaccess provided in a Drupal installation, the site developer can redirect all users to always access the site either with or without the "www." prefix regardless of the original URL.
All but the most trivial of websites can end up with many such rules specified some quite critical to the operation of the site. Consequently, it could be a real problem if these rules especially on a live site were inadvertently overwritten. But this is exactly what can happen when a site developer upgrades a Drupal instance to a newer version and overwrites the existing customized .htaccess.
At first glance, the Htaccess module might seem like a solution to this problem, but sadly it isn't, because the module is merely a user interface to set the Drupal root .htaccess file settings, without having to edit the file directly. Its configuration page has radio buttons for "URL prefix redirection", "Symbolic links", and "HTTP Secure (HTTPS)"; a checkbox for "Protect Core text files"; a text field for custom settings (redirections, rewrite rules, etc.); and a text field for Boost module rules. None of this functionality preserves any custom hypertext access settings.
What is needed is a new module that saves all of those custom settings to disk, as a local or remote text file that later could be used for easily restoring those settings if for some reason they are lost from the website's .htaccess file. In other words, the module would allow one to export those settings to an external store, and later import them, thereby overriding the default or missing values of the .htaccess file included in a fresh generic Drupal installation.
Common Taxonomies
Any experienced Drupal developer will know that taxonomies and their vocabularies compose a powerful strategy for tagging and organizing all sorts of content within a website. In addition, they generally work well with many other modules, extending their capabilities. Unfortunately, even some of the most commonly used taxonomies have to be built by scratch, because the Drupal project does not appear to have an inventory of them, waiting to be used.
This proposed module would have an admin page where you could specify one or many common taxonomies to be created for you. For instance, one of them could be an up to date list of the names of all the countries in the world. For each country, there could be a taxonomy for the names of all its states/provinces/territories. In the realms of science and engineering, one taxonomy could comprise the units of measurement in the metric system, and another could comprise the names of the chemical elements in the periodic table. Drupal developers would certainly think of many more, and could contribute them to the module through feature requests on the module's project page.
FAQ Entries Reordering
The Frequently Asked Questions module allows you to easily create an FAQ page comprising entries with information that would be helpful to your site visitors.
In Drupal 7, the module would automatically and initially define a path to the FAQ page (by default, faq-page, without any trailing "/") and three useful prebuilt FAQ blocks (FAQ Categories, Random FAQs, and Recent FAQs). Also, it would add a "Frequently Asked Questions" menu item to the Navigation menu. The ordering of the entries within an FAQ page or FAQ block could be precisely controlled by adjusting the order of the associated taxonomy terms, but that requires one to create and associate such a taxonomy, and to order the terms, which can be a time consuming process if there are a large number of entries. Without the use of any taxonomy, the default ordering of the FAQ entries was reverse chronological order of their creation dates (the "Authored on" date on the "Authoring information" tab). Consequently, the newest entries were stacked on top of the list, which is usually not the order that is desired by the site builder or content manager. A workaround was to change the entry creation dates to force the entries into the desired order, but this too is tedious, as well as fragile, because anything that alters one or more of those dates will ruin the chosen ordering.
In Drupal 8 and 9, the problem of FAQ entry ordering may be moot, given that some developers are reporting that the FAQ page view and blocks are not even appearing. Moreover, the FAQ configuration page (admin/config/content/faq) doesn't even provide any FAQ page path. It is not clear whether or not these critical issues will be fixed, given the current poor support for the module, as indicated by increasing numbers of issues and bugs, and a current response rate of 0%.
However, if these particular issues are resolved for the Drupal 8+ versions of the module, then it would be wonderful if it could be enhanced to include simple drag and drop reordering of FAQ entries, or incorporated into a new and better maintained module for providing frequently asked questions and answers.
Field Labels Bulk Change Location
After a new text field has been added to a content type (such as a web form), when an instance of that content type is displayed on a Drupal website, the label of that field is, by default, located directly above the field itself. This location may be preferred for sites that will be primarily viewed on smartphones and other devices with limited width displays, so that the label does not push the field itself too far to the right. However, in most cases there is plenty of horizontal space for the label and the corresponding field to be positioned on the same line ("inline"). This is usually the best choice for content types with a large number of such fields, to minimize the user having to page down more than necessary to see all the fields.
Yet for versions of Drupal from at least D6 onwards, the default label position is "Above" and not "Inline". This means that when you are adding many new fields to a content type and you want the labels to be inline, you have to manually specify that for each field. Later, if you or the site owner decide to change all the field label positions to a different setting, then you have to manually change all of them (on the content type's "Manage Display" tab). Also, if the decision is to standardize for all content types used on the site, then again all of them have to be changed manually. Depending upon the HTML generated (by all the Drupal components that can affect the markup), it may be possible to change all the label positions using CSS. But even then, those styling changes might later be overridden by CSS styles with higher precedence or lost if the default Drupal theme is changed to a different one.
In any such scenario, it would be wonderful to have a simple contrib module that, when a content type and some of its text fields are specified in an admin area, the module could set all the field label positions to one of the two values, with no need for any CSS changes to any themes.
Log Messages Extra Filtering
As the multitudinous components of a Drupal website are performing their various operations, they generate and store in the database numerous log messages, which can be viewed within the admin area on the "Recent log messages" page (admin/reports/dblog). The messages displayed can be filtered by message type (action, content, cron, system, and user) and message severity (emergency, alert, critical, error, warning, notice, info, and debug). Even with the strict use of filtering, the number of log messages displayed can be overwhelming, mostly because some processes will generate large numbers of identical messages in a short amount of time. As a result, it can be difficult and frustrating for you or any other administrator to go through pages of messages in order to find the one that could mean the difference between quickly resolving a problem versus never discovering its root cause. What would be quite helpful would be an admin page created by a new module that allows you to easily limit the message logs even more, in two ways.
Firstly, and most obviously, we should be able to filter out any duplicates, leaving just the unique messages. This raises the question of which datetime should be displayed for each unique message? That could be controlled by a radio button that allows you to choose either the datetime of the most recent message or the first message. (The latter option would probably be the most useful for discovering the origin of any given problem.) Any developer interested in creating such a module may want to first check the wrapper function in the Unique Logs module (still in beta, as of this writing).
Secondly, we should be able to limit the displayed messages to just those associated with a particular node. Countless times that would have been incredibly valuable in my own debugging work.
Page Caching Disabled for Local Server
As part of the performance configuration settings of a standard Drupal website, page caching can be enabled for anonymous users, i.e., visitors who are not logged in to the site. For any web pages whose content does not change from one visitor to the next or from one moment to the next, page caching is worthwhile and recommended, as it avoids Drupal having to re create those static pages repeatedly, generating the exact same results each time.
However, when building a website on a local server, page caching usually should be disabled, so that every page generated regardless of whether one is logged in or not will immediately reflect any changes to the site made as it is developed. Thus, it would be handy to have a module that turns off page caching if the host name indicates that the site is on a local web server, but leaves it unchanged for remote sites.
Save Button Always Visible
As you are defining a new Drupal content type comprising many fields, or you are creating a new instance of such a content type, or you are adding a lot of text within a form page's text box, it is wise to frequently save your work, by clicking the "Save" button at the bottom of the page. Unfortunately, this requires either removing your fingers from the keyboard to scroll all the way down to the bottom of the page, or clicking outside of the currently focused field and pressing a button on your keyboard to go to the bottom. When performing the latter action, it sometimes happens that your mouse click (or, more commonly nowadays, touchpad click) does not in fact take the focus away from that field or, even worse, resets the focus to a different field to which you were likely not paying any attention at that moment. Then, if the currently focused field is a drop down list box, when you tap a key to page down or go to the bottom of the page, you will inadvertently change that field to what is probably an unintended value.
It would be much easier and convenient to have a second "Save" button always visible on the screen, i.e., above "the fold". This would allow you to click it without having to go to the bottom of the page. In other words, this proposed module would bring the button to you, so you wouldn't have to go down to it each time.
One bonus feature would be to orient the button text vertically, to minimize it covering form elements on the right side of the screen. Optionally, using JavaScript or jQuery, the button could reorient itself horizontally when the mouse pointer is within a minimum distance on the screen. Even better, it could automatically retract into the right margin when the mouse pointer is distant, and then pop out when the mouse pointer is close to the right edge.
I hope that these module suggestions prove interesting to Drupal developers and other contributors.
