Drupalwoo ☉

Using Drupal’s link field for internal and external URLs

A Drupal editor rarely needs to know whether a destination sits inside the current website. They should be able to write “Read the grant guide” and choose the appropriate target. Drupal’s link field supports that separation by pairing visible link text with a URI, while giving administrators control over which kinds of links editors can create.

The distinction matters on an Australian content site. A Brisbane community publisher might link to its own /volunteer page and an external Queensland Government funding page in the same article. The first should stay within the current navigation, while the second must retain its complete web address, protocol and intended opening behaviour.

Internal paths should normally use aliases rather than exposed node numbers, and external destinations should use https:// with the exact hostname. That avoids broken links after a migration, when the public domain may change, and reduces the risk of sending readers to a mistyped or deceptive address.

Local publishing conditions also shape the setup. Australian council and government websites connect content across jurisdictions, and editorial teams often mix public pages with restricted document libraries. Editors need clear guidance for links to protected files, telephone numbers and email, not merely ordinary pages. The finished workflow should feel straightforward to everyday content publishers while remaining precise for every visitor.

What the link field actually stores

Under the hood, a link field stores a URI and optional display text. An internal URI can be a Drupal route such as node/48, an alias such as /contact-us, or a complete address on the current domain. Drupal can resolve the route to an internal page, but the alias gives editors and readers a meaningful destination.

The visible label is separate from the URL. A typical field widget offers Link text, URL and a new-window option, along with attributes such as a title, identifier and CSS classes. The display settings determine whether the address appears beside the label. If an editor leaves the link text blank, Drupal may fall back to showing the URL, which produces awkward results when the address contains a long query string.

Link fields are not automatic validators for every possible destination. Allowed link types and schemes determine what can be saved, but editors remain responsible for correctness. A document needs suitable file handling, a telephone number needs a tel: URI, and a page behind staff authentication is not public even when it is stored in an internal link field.

Creating a link field on a content type

Open the field-management screen for the relevant content type and add a new field. Choose Link from the field-type list, give it a label such as “Related resources” and select a suitable machine name. Clear help text is valuable here: explain that editors should enter an internal path beginning with a slash or paste a complete external https:// address. This guidance appears directly beside the widget and reduces hesitation at publication time.

Next, decide which link types the editorial team needs. Restricting the field to internal and external links creates a simple publishing workflow. Add email, phone or file links only when required, and permit only the URI schemes the site actually uses. For a public authority, allowing FTP is rarely sensible; HTTPS, mailto and tel cover most common requirements. When both internal and external links are enabled, the widget may present a type selector so the editor can identify the destination correctly.

Finally, review the form and display settings. Leaving the URL hidden keeps the link label prominent, and the field can remain optional unless every content item genuinely requires a resource. Review the new-window option rather than enabling it automatically. Opening external destinations in the same tab usually preserves orientation, especially for people reading on phones while travelling on Australian trains or buses.

Choosing reliable internal destinations

Start with the target page’s alias. If /services/fee-directory exists, use that path for an internal link labelled “Browse the fee directory”. A route such as /node/48 will work, but it conceals the page’s purpose and gives an editor no useful clue when choosing between several destinations.

The core link widget does not provide content search or alias autocomplete. On a small website, an editor can copy the path from a rendered page or paste a known alias. Larger council sites with thousands of pages often use an alias-aware autocomplete module or a structured editorial workflow. Whichever approach is used, the stored destination should be checked rather than assumed to match the surrounding content.

Link text should describe the destination or action, particularly for screen-reader users browsing a list of links. “Download the 2026–27 grant checklist” is more useful than “grant checklist”, while “Contact the coordinator” is clearer than “email us”. Avoid “click here” and repeated “read more” labels when several links appear close together. Internal links should normally open in the current window.

Adding external URLs without surprises

External destinations require a complete URI, including https://. Entering www.qld.gov.au without a protocol leaves the address open to automatic normalisation, potentially producing an insecure or unexpected destination. Enter the complete address, check the hostname and retain any meaningful path or query string. Redirects and tracking parameters deserve review rather than blind copying.

A written link policy helps editors apply the same rules across the site. Practical Drupal reference material, including this Drupal developer’s site, can complement that policy with a second implementation perspective. Choose the new-window behaviour deliberately, inspect the rendered markup and ensure it uses rel="noopener noreferrer" where appropriate. If an external-link icon is included, accompany it with accessible wording; an icon alone conveys little to assistive technology.

A convincing external URL is not a guarantee of legitimacy. Australian readers encounter government services alongside .com.au and .org.au organisations, and lookalike hostnames can exploit small spelling differences. Editors should confirm unfamiliar destinations, especially pages requesting credentials or payment. Council content should link directly to an agency’s official domain rather than a document relayed through an unrelated website.

Australian publishing patterns that affect links

A Brisbane community publisher might publish local grant information, link internally to an application guide and send readers to a Queensland Government funding portal. That government destination may sit on a .qld.gov.au domain, while the publisher’s own site could use .com.au or .org.au. The domain difference does not determine which target is internal; the relationship between the current site and the destination does.

Similar patterns appear around the country. A Sydney service may point readers to Transport for NSW information through nsw.gov.au, while a Melbourne council may direct visitors to a .vic.gov.au page about tram disruption or a local event. In Adelaide, sa.gov.au services often appear beside council material. These conventions help editors recognise destination types, but they do not replace checking the exact address.

Language and regulatory context also influence link handling. Informal Australian copy might call a 2 pm meeting an “arvo” session or use “no worries” around a service change, but link labels should remain plain and specific. Australian public-sector publishers may also need to consider the Privacy Act 1988 and the Spam Act 2003 when linking to forms, surveys or mailing lists. A link field provides navigation; it does not make a third-party data-collection process compliant.

Keeping links reliable in production

Test the field with the content tasks editors will actually perform. Save an internal destination and confirm that it reaches the intended page. Add an external target and verify the protocol, hostname and query string. Exercise the new-window behaviour and check how a reader returns to the current page. Also test an empty link label and decide whether the form should require meaningful text, even when the field itself is optional.

Accessibility applies to the destination as well as the markup. Where the project requires it, meet WCAG 2.2 AA and test keyboard focus order, visible focus indicators and screen-reader announcements. If an external indicator relies on an icon or colour, include text that works without either. Link labels should make sense when read apart from the surrounding paragraph: “the funding page” is preferable to “this page” when several links appear together.

With clear field settings and a consistent editorial routine, editors gain a dependable publishing path while visitors receive links that are easier to understand, navigate and trust.