\midcom_services_permalinks

Permalink management service.

This service is intended to abstract permalink usage away and replaces the original Permalink system integrated into the NAP system.

It is fully decoupled from NAP, so objects, which should be reachable by Permalinks no longer need NAP entries. To make the transition to this service transparent, the system still includes a NAP GUID reverse-lookup, for backwards compatibility.

The component interface is used to provide a selective way to resolve content objects to their URLs, with some heuristics to speed up lookups if they can be mapped to a topic.

The current Permalink implementation limits granularity to a GUID level -- permalinks map object GUIDs to pages. If you have multiple pages showing the same object, you need to decide which one you wish to have as permalink and provide that URL for resolution. For the forward lookup, it is allowed to have multiple pages set the same permalink.

Permalinks are always of the form $midcom_root_page_prefix/midcom-permalink-$guid and will redirect using a Location HTTP header. Since regular content pages are created, the result will be cacheable using the content caching system. This obviously means, that if you modify the permalink lookup rules, you have to invalidate all guids that affected by the changes. MidCOM will assume that the resolution of Permalinks to real URLs is stable over time otherwise. You can also set the no_cache flag during the resolver callback execution if you discover that it is a URL you are responsible for but the result should not be cached. See there for details.

Summary

Methods
Properties
Constants
resolve_permalink()
create_permalink()
create_attachment_link()
No public properties found
No constants found
No protected methods found
No protected properties found
N/A
_resolve_permalink_in_topic()
No private properties found
N/A

Methods

resolve_permalink()

resolve_permalink(string  $guid) : string

Resolve any GUID into a fully qualified URL which can be relocated to. Operates in multiple phases:

  1. Check, whether the GUID is already known by NAP. In case we have the corresponding node/leaf loaded, use its linking information directly.
  2. Look if we have a topic, in that case, we get the corresponding NAP node and use it to resolve the permalink. If that object is not retrievable, the lookup fails.
  3. We check whether the object in question has a topic as one of its ancestors. If yes, that topic and its corresponding component is used to lookup the GUID, which might fail.
  4. As a last resort we have to iterate over all NAP topics to do the resolving.

Parameters

string $guid

The GUID to resolve.

Returns

string —

The full HTTP relocation'able URL to the GUID.

create_permalink()

create_permalink(string  $guid) : string

Create Permalink URLs from GUIDs. They always point to the live site (given correct system configuration).

Parameters

string $guid

The Guid to link to.

Returns

string —

The full URL of the Permalink.

create_attachment_link()

create_attachment_link(string  $guid, string  $filename) : string

Create Permalink URLs for attachments.

They always point to the live site (given correct system configuration).

Parameters

string $guid

The GUID to link to.

string $filename

The attachment's filename

Returns

string —

The full URL of the Permalink.