Cameron McCormack wrote:
David Crossley:
Yes. See some examples in forrest/site-author/conf/cli.xconf
Not an "error". Doing 'forrest site' follows every link that it finds.
The Cocoon CLI (Command Line Interface) config enables the
powerful exclusion mechanism.
Ok. Is there a way to configure it so that if it follows a link it
doesn’t know how to generate, but that file is in the content directory,
that it doesn’t consider it an error?
I've done this on a few sites. There are three approaches (that I can
think of):
In the first, you provide a pipeline at the end of all other pipelines
that generates a "File not found" type XDoc. This pipeline will be the
final one processed and so will ensure a document is always returned. We
don't have one in the default distribution as this will hide build
errors that are really build errors, but it has the advantage of
covering all possible requests that are not matched by other pipelines.
Note that this first approach requires you to modify Forrests core
sitemaps and thus you will need to be careful when upgrading.
The second approach is to create a dummy file for each unmapped request.
This dummy file will say something like "This will be a dynamically
generated page in the live system". This works well, but requires you to
manage each page individually, however it requires no changes to the
core sitemaps. Note that you may need to add a pipeline to match special
request patterns that Forrest does not normally match (e.g. "*.cgi").
The final approach is a half way between the first two. Create a set of
pipelines in your project to match the requests affected by your issue.
these will need to be narrow enough to trap all known pages but allow
all others to pass through. The downside of this is that it can be
difficult to identify a suitable pattern (or set of patterns), I'd
recommend using the RE matcher for this unless you only have one or two
pages affected by this.
Ross
