Finder hooks

Finder invokes many possibilities to hook in with a module and change something. This page documents these hooks.


hook_finderapi(&$object, $op, $a3 = NULL, $a4 = NULL)

Act upon various Finder operations and make changes to the Finder object.

&$object - The Finder or Finder Element.

$op What kind of action is being performed. Possible values:

* "finder_load": The Finder has been loaded from the database, modules can make changes to the Finder here.
* "finder_presave": The Finder is about to be inserted or updated into the database.
* "finder_insert": The Finder has being created in the database.
* "finder_update": The Finder has being changed in the database.
* "finder_delete": The Finder is being deleted.
* "finder_admin_edit": An admin is about to load the edit page for the Finder.
* "finder_admin_delete": An admin is about to load the delete page for the Finder.
* "finder_element_load": The Finder Element has been loaded from the database, modules can make changes to the Element here.
* "finder_element_presave": The Finder Element is about to be inserted or updated into the database.
* "finder_element_insert": The Finder Element has being created in the database.
* "finder_element_update": The Finder Element has being changed in the database.

Theming Finder

By default, Finder comes without any styling to achieve a nice layout, in fact it tries to stay as plain as possible because it cannot anticipate what a Site Administrator might want to do.

The documentation is not intended as a theming tutorial - it is assumed you have experience overriding theme functions and using CSS to achieve desired layouts. Please familiarise yourself with the Drupal 6 theme guide if you have no experience with theme functions.

The documentation contains all the theme functions you can override, and some notes. Most of these functions contain additional unused parameters that may be useful to themers in making programmatic decisions about output.

Note: Please do not post issues for support with theming/styles unless you have theming experience - Finder is not a beginner's module for theming. Everything I know about Finder's themes is documented, and should be enough to get you started. If you don't know what to do with the information on this page, then you probably shouldn't mess with this. I cannot give you the specific theme code for your site or instructions regarding Drupal's theme system or PHP.

To begin browsing theme related documentation, visit the following link:

How to administer Finder

The first thing you need to do, after installing the module, is configure Finder's permissions (at admin/user/permissions) so you can control which user roles can use and administer Finder.

Now we will create a Finder. Go to 'Site Building' -> 'Finder' (admin/build/finder). This is the administration page for Finder.

On this page you will have to select a Finder Type. The types of Finders available are determined by which Finder base modules you have enabled. The most common base modules are 'Finder Node', 'Finder Users', and 'Finder Views'. 'Finder Node' and 'Finder Users' integrate directly with Drupal's node and users systems and allow you to create Finders for the basic field values that are associated with these objects in Drupal, such as 'username', 'title', 'node id'. They do not allow you to find values created by other modules such as CCK, Taxonomy, or Profile - for that you will need 'Finder Views'. 'Finder Views' does not find views - it uses one of your existing views to find objects within that view. It does not require 'Finder Node' or 'Finder Users' to work - infact it can find a lot more types of objects and fields from other modules, basically anything that Views can display. Each of these modules creates a corresponding Finder Type you can select from in the list.


Finder is a module that allows Site Administrators to create search forms for their users to find various things in Drupal like nodes or users, based on specific fields and values in those objects. The forms can use widgets like autocomplete textfields, radio buttons, select lists, and checkboxes. The module is designed so that each of the things it can find, and the way in which it finds them, are all controlled by seperate modules.

Secure multi-site setup using shared code-base

Building on comments from this forum topic, I've implemented a shared code-base system which has the following features:

  • keeps user data separate - no user can see the files of another user, no browser client can access information from another site
  • contributed modules/themes can be shared or single-site - commonly used modules can be shared across all sites, but custom themes or unusual modules can be installed for a single site
  • core updates can be applied selectively - one site can be updated to a new core version, another can wait (e.g. for a contributed module to to be upgraded) and upgrade later (or even revert completely using database snapshots). Multiple code-base versions can run concurrently, shared by an arbitrary number of sites as required.
  • works with PHP user_base security - this needs php.ini or httpd.conf modification to whitelist the shared code-base directory
  • prevents users modifying shared code or symlinks - all shared files and links are not owned by the site user, they have read-only access
  • works with user control panels like cPanel - installs into a user's public_html or www directory (or a sub-directory)
  • works with any file transfer method - users have full control of their own files, but no-one elses

Why doesn't Drupal hide CHANGELOG.txt?

This issue has been discussed publically several times, most notably in #79018: protect Drupal core .txt files where it was decided that there is no security benefit to hiding files such as CHANGELOG.txt.

For a more complete list of reasons please see the administration guide on Hide, obscure, or remove clues that a site runs on Drupal.


Subscribe with RSS Subscribe to RSS - Site administrators