Page tree
Skip to end of metadata
Go to start of metadata

The Link Mapper module attempts to improve on blindly returning 404. Instead these events are monitored and reported back to the editors. Editors can then choose to respond to each error with either 200 (hide the error), 302, 301 (redirects), or 410 (gone) to tell servers to stop looking for it.

Status INCUBATOR
TypeVisual App
SubJar
JIRAMBLINKS
Gitlinkmapper

Installation

Maven is the easiest way to install the modules. Add the following dependencies to your bundle:

<dependency>
  <groupId>info.magnolia.linkmapper</groupId>
  <artifactId>magnolia-linkmapper</artifactId>
  <version>${linkMapperVersion}</version>
</dependency>

Versions

3.0Magnolia 5.6

Usage

Once installed and configured the link mapper module stores data on a 3rd party server. Data is being collected by the public instance(s) each time a 404 is detected. This data can then be consumed by the author instance (on-demand) in the 404Links app. Editors can examine the data and decide what redirect action (response) should be taken. These redirects can be published to the public instances much the same way a virtual URI mappings are done. The difference here is that the virtual URI mappings are handled prior to rendering while the 404 redirects are handled after rendering.

Configuration

clientIdentifier

required

To use the link mapper module you will need to obtain client identifier from Magnolia. This identifier is used to track the data obtained by the filter. This property is set in the module config.

baseUrl

required

The base URL for the 3rd party service collecting the data. Also obtained from Magnolia along with the client identifier. This property is set on the linkMapperService node in the rest-cient registry.

404Links app

From the author instance editors can use the 404Links app to view the data collected on the public instances by the broken links filter. Data is collected from the server using the Reload action. Broken links are displayed along with corresponding site name and access count (or frequency). Results can be searched and sorted in a variety of different ways.

Each entry can be adjusted and published over to the public instances. Use the Edit Link action to set the Target and Redirect Type. Upon save the item is automatically published.

When editing an item you can see referrers and query parameters of the request that led to the 404. This is sometimes helpful to fight broken links coming from within the system.

The target can be anywhere internal or external. The redirect type can be one of the following:

  • 200: keep url - Target will be served on original URI, may looks like a page duplicate.
  • 301: permanent - Use in case original URI will never exists again (default).
  • 302: temporary - Use in case original URI will exists again in future.
  • 410: blacklist - Announce that this page is permanently gone and not likely to ever appear again.

    There is also an action available from the browser view to quickly blacklist an item.

Warnings

  • This module is at INCUBATOR level.
  • Redirects are evaluated after rendering, so pages treated this way will take more time by needing to go through filter chain twice (About 20-50ms penalty). OTOH it doesn't slow anything else no matter how many you have (in difference from virtual URI mappings).
  • You may run into slowness when loading large amounts of data into the JCR from the collection server.

Changelog

  • Version 3.0 - Initial release of the extensions version of the module.

1 Comment

  1. Does the Link Mapper distinguish between bots vs. people that try to access a dead link?