Link Checker
Digest
The link checker ensures that all HTML links between assets in the system and links to external resources are valid. It is invoked after an edit is committed by clicking the 'Submit' button. If the checker detects any broken links, it forwards the user to a page detailing these errors and providing several options for dealing with them.
FAQs
- Does Cascade Server generate Search Engine friendly URLS?
- Search engine friendly, readable URLs are generated automatically according to individual page name and the folder(s) in which it is found. This gives the site a clean and logical structure from the site visitor perspective, as well as makes particular pages within the system easy to find without using the search function. If a user is looking online at the live site and sees a page that needs editing, (s)he will know how to find the page inside the system simply by looking at the URL.
- How do I create Links in Cascade Server?
Dynamic link generation is available in Cascade Server using index blocks. These blocks can be included in page templates, and can be customized to order links however the user requires. Bread crumbs and site maps are also easily added.
External links, or symlinks, can be created in Cascade Server and are treated as assets in the system. This is useful for including External sites in dynamic navigation menus.
Individual links can be inserted into content using the WYSIWYG ‘insert link’ function. These can be links to internal assets, or to outside pages. Users may select where the link is opened (new window, etc.)
- Does Cascade Server check for broken Links?
- All links are automatically checked in the system any time an asset is created, edited, or published. In the case of a broken link, an error message is generated, and users are prompted to correct the link before submitting changes.
Concept
Introduction to Link Checker
The link checker is typically turned on or off, system-wide, by an administrator. Depending on a user's permissions, the checker may be turned on or off at the page level as well.
When turned on, the link checker is invoked after a page edit is committed by clicking the ' Submit' button.
The first field for each broken link shown on this page gives the value of the link as provided by the user. The second field, 'Context', gives information on where the broken link is located.
The user then has two options for handling each broken link:
- Modify - A radio button and file chooser or text box allowing the user to choose an asset within the CMS or a new URL as the target of the link or source for the image.
- Ignore - A radio button allowing the user to disregard the broken link.
After deciding how best to handle each broken link, the user then clicks the 'Submit' button. At this point, the link checker rewrites links and uploads files as indicated and commits the user's edits.
Technical
Turning Link Checker On and Off Globally
The default value for the "Check for Broken Links" checkbox can be turned on and off globally by users who have access to System Preferences. This can be done by navigating to Tools -> Preferences -> Content.
Under the section "Default Data Checks," check the "Link Check" checkbox to enable or uncheck to disable. Then press "Submit" at the bottom of the page to save the changes.
External Links
Enabling external link checking is handled on the same screen as setting the default value of the "Check for Broken Links" checkbox mentioned above (Tools -> Preferences -> Content).
Below the preference to enable external link checking is a field where the external link check timeout can be specified. This timeout is used when making requests to external resources and will cause a link to be considered broken if either connecting to a remote server takes too long or retrieving the external resource takes too long. This timeout value is split evenly between connecting and retrieving. So, a timeout of 5000 ms will have 2500 ms dedicated to connecting and 2500 ms dedicated to retrieving the resource.
External links are verified by making a HEAD request to the resource in question. The HEAD method is used for efficiency as it does not require that the webserver return the entire HTML page (or file). If the HEAD request does not return an HTTP response code of 200, 301, or 302, however, then a GET request is made for the same resource. This two step process is used because some webservers will return 404 or another error code when a HEAD request is made on a resource. By doing a GET, false positives for broken links are eliminated in most cases.
Both HTTP and HTTPS links can be checked by the link checker. Resources using protocols like FILE, however, are treated as bad links.