With Drupal 4.7 coming, and the CVS version of freelinking.module being the new stable version (with lots of features over the 4.6 version), I’m starting to think of the future of the module, and some major changes.

In addition to internal changes in the code (like using preg_replace_callback() instead of the simple preg_replace()), I’d like to introduce contributed freelinking schemes. This has been touched on before in a feature request, and I’d like to implement this in some way.

Basically, the crux of the next generation of freelinking.module would be pseudoprotocols that an administrator could define, and a system of contributed includes that can define different methods for finding targets, so that the target can be more complicated than simple node title matching.

Freelinking already does this in a simple way, allowing for external links via http:, https:, ftp:, and mailto: protocols. In addition to those, freelinking should ship with title: (title search), and node: (node id) pseudoprotocols.

Contributed include files could add pseudoprotocols like:

• taxo: — link to a taxonomy term
• user: — link to a user
• usercontact: — link to user/$uid/contact, and allow for a name instead of a uid
• drupaldocs: — link to drupaldocs.org
• search: — Drupal search results
• phpdoc: — function lookup on php.net
• wikipedia: — wikipedia lookup
• you get the idea

The includes should offer a default pseudoprotocol, but the actual link format used should be up to the site or content admin. If, for example, I want to use “w:” instead of “wikipedia:”, I should be able to. The admin should also be able to choose which method is the default. Freelinking.module should ship with “title:” as the default, which would make the behavior of the new module mimic the old.

This should allow for a much richer linking syntax, making content much more readable in source, and much easier to write. Compare the following sentence with what it would take to do with conventional links:

If you need more help with the [drupaldocs:form api|forms api], you should first check the [search:formapi|search results] and see the [taxo:forms|related posts]. As a last resort, you could [usercontact:dries|contact Dries].

I also plan on evaluating the links bundle, to see if I can leverage its methods for storing and managing links.

This could, eventually, encroach into the turf of modules like interwiki, inline, and glossary. While not the intention nor the inspiration for these changes, it would be a good long-term idea, I think, to have one module that handles the various types of links that Drupal could provide. Devising a system of contributed include files would allow these types of modules to exist as pseudoprotocols within the freelinking engine.

I have absolutely no time table for any of this. It exists as little more than an idea at this point. While ideally it’d be usable during the 4.8 development cycle, I don’t know how quickly I can get something in to developers’ hands for them to assist me. I’m not ready to announce anything on drupal-devel, but due to the wonders of Drupal’s taxonomy system, this should find its way onto Planet Drupal, so developers and interested freelinking users can see it and hopefully comment.

Where I’m starting is with prototyping the settings page, but I haven’t yet found a UI for this sort of thing that makes me happy. Does anyone know how I can put form elements within a table in hook_settings()? It doesn’t seem possible, as hook_settings() must return a $form array. Am I going to have to split this stuff out into another settings page? Yuck. Perhaps hook_settings() should check what its given, allowing html as well?