How to test your Drupal site
Target audience: Drupal site owners and administrators (with no professional Drupal development skills).
So, your contractor has finished working on your site and now you would like to evaluate the quality of the work done. Everything seems fine at the first glance: the site works as expected, no PHP errors are popping up, and the front end does not fall apart. But it does not mean that you have no problems. You may have overlooked something and the errors might appear in the future – with the first site visitors, after module/core updates, or when moving the site to a new platform.
You are not a professional and have no clue in programming and front-end development. How can you estimate is the site is working correctly, without using third-party audit service?
The following modules are required for this task:
-
Simpletest (for Drupal 6 only, version 7 has this module included in the core and is called Testing).
To begin with, turn on on-screen error reporting: not seeing the errors does not mean they do not exist:
D6: Administer -> Site configuration -> Error reporting
Select Error reporting: Write errors to the log and to the screen.
D7: Administer -> Configuration -> Development -> Logging and errors
Select Error messages to display: All messages.
Core and contributed modules
Sometimes negligent developers modify the code in contributed modules or in the Drupal core. This lets them quickly add new functionality or change the existing features. There is a strong reason to avoid this: during the first module or core file update all such modifications will vanish and the system will stop working as designed. To check your contributed modules and core for modifications you can use the Hacked module.
Administer -> Reports -> Hacked -> List Projects
Make sure to have the latest versions of the core and the modules installed on the site. Old versions may have vulnerabilities or just non-optimal code.
The Update module will help you check for the updates.
Administer -> Reports -> Available updates
Also, take a look at the root folder of the site. If you see any files and folders not present in the standard Drupal installation, ask the developers about their purpose. These files and folders may be added for debugging and not necessary now.
Custom modules
If your site has custom modules (developed for your site’s particular needs), estimating the code quality makes good sense. A well-written code is easier to maintain. In other words, it takes less developers’ effort - and therefore your money - to implement additional functionality in the future.
You can check the code quality with the Coder module.
D6: Administer -> Site configuration -> Code review
D7: Administer -> Configuration -> Development -> Coder
Turn on the following checks:
- Drupal Coding Standards
- Drupal Commenting Standards
- Drupal SQL Standards
- Drupal Security Checks
- Internationalization
Also, switch "show warnings at or above the severity warning level" to minor (most).
In "SELECT SPECIFIC MODULES" mark the modules to check and proceed.
Please also pay attention to the structure of the modules folder.
Database
All your site data is stored in the database. Relational databases (MySQL, for example) present the stored data as tables. Pursuing their goals, the developers could have created their own tables, change structure of the existing ones, or even delete them. It’s better to check if the database structure matches the scheme described in Drupal.
If a Drupal module provides its own database table (or changes the structure of the existing one) these changes must be described the database scheme .
The Schema module will help you check if the database scheme matches its real structure.
D6: Administer -> Site building -> Schema
D7: Administer -> Structure -> Schema
Check the indexes
Database requests may be executed slowly if required fields have no indexes. This results in high load on your database server and decreases overall performance of the site. This problem may remain unnoticed until your site has the expected amount of users and content.
First, make sure that the database really has the indexes described in the Drupal scheme. Once again, let’s use the Schema module for this purpose.
D6: Administer -> Site building -> Schema
D7: Administer -> Structure -> Schema
If the checking results show Mismatch, Missing or Extra tables it means that the real database structure differs from the one specified in Drupal.
Nonetheless, presence of the indexes does not mean absence of queries performed without them. In a MySQL database, you can check for such queries:
Enter phpMyAdmin or MySQL command-line client: mysql -u <username> -p
Execute the following query:
USE
SHOW STATUS LIKE 'Select_%';
SHOW STATUS LIKE 'Sort_%';
SHOW STATUS LIKE ‘Handler_read_rnd’;
SHOW STATUS LIKE ‘Handler_read_rnd_next’;
Alternatively, you can execute one command:
mysql -u <username> -p <<< 'USE <database>;SHOW STATUS;' | grep -P ^\(Select_*\|Sort_*\|Handler_read_rnd\|Handler_read_rnd_next\)
All the slow queries are usually logged in MySQL. To check if the logging is turned on and to see where the logs are saved, query:
SHOW VARIABLES LIKE '%slow_query_log%';
If you see non-zero values it possibly means that some queries are not optimal or the required fields have no indexes.
Theme
Check your theme with the Hacked (if the theme is contributed) or the Coder (if you are using a custom theme) module.
Please also pay attention to the following:
-
Use the StyleGuide module to see if all the standard page elements (headers, lists, etc.) are themed to the design. Thus you will not have to make up newly created pages.
-
The theme folder must be well-structured. Style files should be in the ‘css’ folder, script files – in the ‘js’ or ‘scripts’ folder, template files in the ‘templates’ folder. If you have many template files, the ‘templates’ folder should be structured: templates related to Views theming in the ‘views’ subfolder, etc.
-
The graphics folder (usually ‘images’) must not contain many small pictures. The pictures must be combined into one file which name usually contains the ‘sprites’ string.
A large number of small pictures causes browsers send separate requests for each of them, and this increases page loading time and server load).
Markup
Faulty markup may affect the site indexing by search bots and cause errors in displaying the site by different browsers (mostly in IE). You can check this with help of the W3C validator: http://validator.w3.org, or by simply viewing the site in different browsers and switching screen resolutions with help of these service: http://browsershots.org/, http://browshot.com.
If your site has an RSS feed check it with the W3C validator: http://validator.w3.org/feed/
Security
Vulnerabilities of Drupal itself and its contributed modules are usually brushed off quickly in new versions. But what if you have custom modules and themes? How can a non-professional check ша they are vulnerable?
Here are the most common vulnerabilities:
- SQL injections
- Cross Site Scripting (XSS)
- User Credentials guess
Custom modules can be checked for SQL injection and XSS vulnerabilities with the Coder module. If developers adhere to the Drupal coding standards and use API database access correctly, they would hardly make mistakes leading to such vulnerabilities. But you cannot be completely sure of this.
XSS vulnerability check
Pay attention to the forms which save the data (node creating forms and web forms) and which display it (search form). Enter strings with HTML tags into the fields. The easiest would be to use this string: <script>alert('XSS');</script>. If after submitting a form you see an alert with 'XSS' message it means that your site is vulnerable.
User Credentials guess
The developers could have created test user accounts with easily guessed login/password pairs (test/test, test_manager/test_manager etc.) and then forget to block or remove these entries. Make sure that such user accounts are removed or blocked.
User permissions
You should carefully check the permissions assigned to user roles.
D6: Administer -> User Management -> Permissions
D7: Administer -> People -> Permissions
The developers could have assigned excessive privileges to user roles for debugging needs and then forget to correct this. For example, the Anonymous user role may still have the privilege to access developer information.
If custom modules have their own privileges make sure they are really verified. Sometimes the developers add an access privilege without verification if users have it or not (i.e. it is displayed on the Permissions page but does not work in fact).
Tests
Many contributed modules provide functionality tests which allow verifying the stability of their work. If the developers have written such tests for their custom modules, this probably indicates their responsible approach.
Anyway, all the available tests are worth performing. In Drupal 6 you will need the Simpletest module (in version 7 this module is included into the core and is named Testing).
D6: Administer -> Site building -> Testing
D7: Administer -> Configuration -> Development -> Testing
Check all the listed tests and press Run tests (this may take sufficient time).
Failed tests most probably mean that the site has problems.