Path History

The path history resources work the same for

• content objects
• locations
• sections
• tags

Below is a description of how the path history works using content objects as an example.

Example: Content Path History

When the public path to a content object changes in Metro Publisher, e.g. by changing the section that the content object is in, Metro Publisher remembers the old path. If someone tries to access a content object via one of its old paths, Metro Publisher returns a 301 redirect (Permanently Moved).

In the examples below, the Metro Publisher instance already has the following objects:

• a section:
  • title: Vacations
  • urlname: vacations
  • UUID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
• two articles:
  • title: My Last Trip to Rome
    • urlname: my-last-trip-to-rome
    • UUID: 11111111-1111-1111-1111-111111111111
  • title: Last Day in Rome
    • urlname: last-day-in-rome
    • UUID: 44444444-4444-4444-4444-111111111111

Here are a few examples of how the path history works:

Example 1

The article 'My Last Trip to Rome' was mistakenly put in as a top-level/root article, so its URL is 'http://www.ourdomain.com/my-last-trip-to-rome/'. We are going to move it to the correct section, i.e. Vacations. Currently, the article has no path history:

>>> GET("/123/content/11111111-1111-1111-1111-111111111111/path_history")
{'items': []}

After we move the article to the correct section:

>>> PATCH("/123/content/11111111-1111-1111-1111-111111111111",
...       {'section_uuid': 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'})
{'url': 'https://api.metropublisher.com/123/content/11111111-1111-1111-1111-111111111111',
 'uuid': '11111111-1111-1111-1111-111111111111'}

the article's URL is now 'http://www.ourdomain.com/vacations/my-last-trip-to-rome/'. Metro Publisher recognizes that the article was moved and automatically adds an entry to the article's path history containing the old path:

>>> GET("/123/content/11111111-1111-1111-1111-111111111111/path_history")
{'items': [{'path': '/my-last-trip-to-rome/'}]}

Note

The path history is only consulted if the system returns a 404 for a given URL. If there is another article with the urlname 'my-last-trip-to-rome' in the top-level, that article is found first and returned, and the path history is ignored.

Example 2

Let's say we imported the article 'Last Day in Rome' into the Metro Publisher instance. The article used to be available at "/reports/last-day.html" in the old system but will now be available at "/vacations/last-day-in-rome/" in the Metro Publisher instance. To make sure that website visitors trying to access /reports/last-day.html do not get a 404 error page but get redirected to the new location of the article, we could add a redirect for this path using the redirect API resources. However, to keep those redirects clean and not fill them up with redirects for individual content objects, we can add a path history entry for the content object itself:

>>> POST("/123/content/44444444-4444-4444-4444-111111111111/path_history",
...              {"path": "/reports/last-day.html"})
{'msg': 'path added'}

The path history for that article now shows the added entry:

>>> GET("/123/content/44444444-4444-4444-4444-111111111111/path_history")
{'items': [{'path': '/reports/last-day.html'}]}