Need help? Kindly email support@droptor.com or call (781) 728-5151. We are also on Twitter as @droptor.
We've accumulated our best tips and tricks to using Droptor to make you faster and save you time.
It's a read-only, secure (read the next FAQ) and light-weight module that plugs in each Drupal site you want to track with our service. It provides our service with information about your site, like installed module versions and Drupal variables. Our services hits this feed a few times a day. You can download the module, check out the source code and see screenshots on the drupal.org project page and in the screenshot tour.
Yes! We take security very seriously. While the data feed that this module provides doesn't contain any authentication information, we do secure the feed in three important ways:
No. The module is lean and optimized to re-use as much data as possible from the cache. In total, there are about 16 queries, 6 of which are COUNT(*) queries. The module uses lots of system variables but these are stored in memory and thus don't add any database roundtrips.
Drupal 6 or 7.
Yes we do!
You just need to run a site that uses any version of Drupal 6 or 7 and has the Update module (part of core) enabled.
Yes! Since each site in a multisite installation has its own content and configuration you will need to add each site to Droptor. This will ensure each site is correctly configured.
Droptor sends several different emails:
You can set as many recipients as you want for emails 1, 2 & 3
(by default these go to the email address you use to login).
The Secure Pages allows you force users to use a secure connection on certain sections of your site that benefit from a secure connection, such as the user login screen. We're big fans of this module.
SSL will substantially increase the security of your site. You should enable SSL on your site, install the Secure Pages module and force SSL connections for login, so that username and passwords are not passed in clear text (clear text is like yelling your password to your buddy at the other end of a cafeteria).
Install the Secure Pages module and go to the configuration screen for that module. Enter in "user*" (without quotes) in the "Secure these pages" box. Be sure to select the "Secure only these pages" radio button.
Here are some things to try:
Still stuck? Feel free to contact support, we are here to help!
Uncontrolled admin level access undermines the security of your entire site. A Drupal user that has the "administer users" or "administer permissions" permission essentially has access to the entire Drupal site. We flag a site if there are more than two users with either (or both) permissions.
If you need team members to manage the user list but otherwise have restricted access to the system, consider the User Protect module. Read more about this at Drupal.org.
Three reasons:
Your most critical, core Drupal settings exist in a file called settings.php. This file needs write file permissions during installation. After install, the file should be set to read-only. Why? Because files with write permissions are more vulnerable to hackers than files with read-only permisssions.
Fix this by connecting to your site with FTP (any client will do; we like Filezilla because it's free and we're cheap), right click on the file and uncheck any "write" checkboxes you see. There might be as many as three "write" boxes to uncheck.
Note: The Drupal status report ignores the presence of a write permission at the user level access of a file. So a setting of 755 will be OK in the Drupal status report but still flagged (correctly) in Droptor.
Yes! Droptor does work with aggressive caching. However, by design aggressive caching doesn't implement two Drupal features we need to track memory usage on pages so we won't be able to capture this data for anonymous traffic.
The core set of files that make up Drupal contain several help files (in .txt format) that are not needed in order to run Drupal. These files contain information that may provide details to malicious users trying to compromise your site. It's best to remove the following files:
The user 1 account in Drupal has special access privileges to your entire site. Since user 1 is so powerful it's an attractive target to malicious users. Using a common name like admin for this user means that half of the authentication mechanism is known (username + password).
Nope! Your website will likely use a self-signed cert by default. These certificates are just as secure as paid certificates and are fine to use for a non-ecommerce site, and sites with a small user base that you know. GoDaddy also has super cheap certificates, which won't pop-up with a warning in any major browser we tested: IE6+, FF2+, Chrome 1+, Safari 1+.
Both.
The watchdog table should be regularly trimmed by the cron process on your site. Without this constant trimming even a low traffic site will cause the watchdog table to grow unyieldy, eventually brining your site down. The most likely cause of an untrimmed watchdog table is cron isn't running. Make sure cron is running without error (check your Drupal logs). Another cause of watchdog growth is excessive logging, usually in a custom module.
We take security very seriously. If you think you've found a security issue, let us know right away. Please see our Security page for more information.
You bet. If you aren't happy, we don't want your money. Check out our refund policy.
Drupal needs regular housekeeping to stay fully functional, tuned and stable. This daily housekeeping is handled by cron. You need to configure cron to run at least once a day, preferably more often for larger sites. Drupal.org has a great article on how to setup cron.
You can use the "dismiss" link to punt on most checklist items that you are unable to complete. However, some items are too critical to be ignored, such as core Drupal updates, and cannot be dismissed.
Consider using the login security module. This module can automatically locks user accounts (for a set amount of time) for too many failed logins.
The Droptor module running on your site runs a variety of different checks. One way is by making HTTP requests
that originate on your site back to the site itself. You can safely ignore log entries that look like this:
page not found CHANGELOG.txt http://www.example.com/CHANGELOG.txt 192.168.1.194 1277417829
You have three choices:
Two reasons: It's messy and it leaves too many old modules that don't include important security patches.
Ironically, no. However, it is built entirely with the same open source tools that power Drupal like PHP, MySQL and Apache.
Yes, but be sure to add the Droptor feed URL (see the link in the settings page for Droptor) to the Boost exclusion list.
This means that the module release you are using has been completely removed from Drupal.org to prevent any future use of the module. A revoked module usually has a serious security issue. Upgrade right away.
Often a module will be revoked shortly before a new release is available. If the security vulnerability is seriuos consider disabling the module until an updated version is released.
More information on update status codes are found in the function _update_message_text.
Yes! While the memory monitoring routine does run on every page call -- including cached pages -- the code is lean. It's just one array creation, one microtime() call and one INSERT command. You can turn this off whenever you like.
Each time your site feed is provided to Droptor we delete the data in this table to ensure that no uncontrolled growth occurs.
Increasing the database log ensures a good balance between a lean database size and having enough data to troubleshoot problems and detect security issues.
Yep!
From the drupal.org project page.
Droptor bills each month based on the highest number of sites you have in a given month. For example, if you have 10 sites, and you add 2 more, then delete 1, your current site count is 11 but your high water mark is 12. We reset your high water mark at the start of every billing cycle.
The Page title module allows greater control over the default page title for nodes and allows individual titles to be customzied. Requires the Token module.
Caveat emptor: Just enabling the module doesn't do anything. You need to fine tune the default title settings and get in the habit of fine tuning your page titles at the time of content creation.
In 2010, Google announced that it would take into account the speed with which a web site loaded when ranking a page in search results. So goes Google so goes the rest of the world. Like it or not, you have a need for speed.
Having a custom 404 page is an important part of your site's overall presentation. If you need inspiration, consider 60 Really Cools and Creative Error 404 Pages or 49 Nice and Creative Error Pages.
The alert feed is an RSS feed of every proactive trigger for every site in your account. You can add this RSS feed to any RSS reader -- like Google Reader or Outlook -- to monitor and review your alerts.
You don't need to be logged into Droptor to access the feed, but you do need a secret hash in the URL. When you enable the alert feed in your account we generate a new hash for your account and provide a link to the RSS feed in your settings screen. If you disable and reenable the feed we will generate a new hash automatically and you will need to update your RSS readers.
The new push version of the module (4.x) will
automatically sync your site every time cron runs. You can also trigger a manual sync by running
cron manually or using drush: drush dropsend.
Droptor calculates module release information independent of your Drupal sites. One important difference is we don't consider a dev release current. If we see a dev release of a module we will flag it as not current and recommend the latest official release in the same branch (1.x, 2.x, etc).
Why? Because you shouldn't be using a dev snapshot of a module on a production web site.
Unfortunately, you can't update the URL for a site in Droptor. If the URL changes you will need to delete the site in Droptor and add it as a new site (you will need to update the hash as well). You will only lose older memory and activity data. All other information will instantly be brought in during the first sync.
In SEO, a site map is a file (or set of files) that lists a link to every page in your site in a structured format that is readable my other machines. Using a site map ensures that the search engines find all of your content. Consider using either the Site map module or the XML sitemap module.
The access log is a Drupal log that records every visit to every page on your site. To use the access log you must have the Statistics module enabled (it's part of core). Even for a site with moderate traffic, the access log can quickly become huge, resulting in a massive database file, slow backups, and wasted CPU cycles.
If you don't need the access log, disable the Statistics module. If you do need it, ensure the log is being trimmed for any logs older than three days.
Rackspace Cloud Sites hosting uses a reverse proxy server for every request made to your site over SSL. This means if Droptor is trying to connect to your site over SSL then it won't work without telling Drupal it's behind a reverse proxy.
Contact Rackspace support to find out the reverse proxy IP address. Then, add these two lines of code to the bottom of your sites/default/settings.php file, replacing "IP ADDRESS FROM RACKSPACE" with the IP Rackspace provides:
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('IP ADDRESS FROM RACKSPACE');
We don't believe a development snapshot of a module should be used on a production system. But some of the modules that Droptor suggests you use -- like Secure Pages -- do not yet have an official release for Drupal 7. Until official releases are available we suggest you hit "ignore" on these items.
As of February 11, 2011 the Secure Pages, Site map, XML sitemap, CAPTCHA, and Pathauto modules do not not have official releases for Druapl 7.
No worries! We are here to help: support@droptor.com or (781) 728-5151.