3.14. How do breadcrumbs work? Why don't they work locally?
^
@@ -1492,7 +1492,7 @@
are viewing the site locally, there is no domain and so there will be no extra
breadcrumbs, only the ones that are specified in skinconf.xml.
-
+
3.15. How do I make forrest run listen on a different port?
3.16. Can I run Forrest with Java debugging turned on?
^
@@ -1520,7 +1520,7 @@
to the forrest.jvmargs property in the forrest.properties
file. Don't forget to ensure the property is uncommented in that file.
-
+
3.17. How do I enable Cocoon's document checksum feature?
Doing 'forrest -v' will provide verbose build messages to the standard
output.
-
+
5.5. How to help?
^
@@ -1727,7 +1727,7 @@
particularly from newcomers—often, close proximity blinds software developers to
faults that are obvious to everyone else. Don't be shy!
More info about contributing can be found at the Contributing
to Forrest page. It is always a good idea to check the Forrest issue tracker before diving in.
All internationalistation of tokens in, for example, the skins and the menus, is carried out
by the Cocoon i18n
Transformer. You can see an example of how it works in the above linked issue.
- 2.19. How can I include HTML content that is not to be skinned by Forrest?
+ 2.19. How can I include HTML content that is not to be skinned by Forrest?
To serve, for example a legacy HTML site, add something like the following
to your project's sitemap and place the source content at the
src/documentation/content/xdocs/old_site/ directory.
@@ -293,23 +293,7 @@
<br/>
(NB maxmemory has been increased in our site-author/forrest.properties, if we resolve this issue it should be reduced again)
-
-
[FOR-713] HTML-to-document.xsl no longer generates an XDoc
html-to-document.xsl no longer converts content to an XDoc. Instead it renders converts documents to XDoc, instead it allows H1, H2 etc. elements to pass through.
-<br/>
-
-<br/>
-The result is a page that seems to render correctly and in the single test case I have used it still renders correctly in PDF and Text format. However, this is a backward incompatible change that will break sites that use includes with XPath statements such as /section[@id="foo"] (sections are no longer created)
-<br/>
-
-<br/>
-
-
-
+
[FOR-855] verify the license situation prior to each release
@@ -331,7 +315,7 @@
<br/>
-
+
[FOR-867] need doc to explain status of skins and dispatcher
@@ -343,7 +327,7 @@
<br/>
I have already commenced this xdoc.
-
+
[FOR-868] add relevant notes to the "Upgrading" xdoc
@@ -351,7 +335,7 @@
We need to add some notes to the upgrading_0*.html doc for the upcoming release. This would most easily be done after attending to <a href="http://issues.apache.org/jira/browse/FOR-865" title="Add missing entries to status.xml to generate the changes list">FOR-865</a> "Add missing entries to status.xml to generate the changes list".
-
+
[FOR-865] Add missing entries to status.xml to generate the changes list
Our home page does not pass CSS validation with <a href="http://jigsaw.w3.org/css-validator/">http://jigsaw.w3.org/css-validator/</a>
-<br/>
-
-
-
+
[FOR-572] run a memory profiler while forrest is operating
@@ -387,7 +361,7 @@
We need to run a memory profiler while forrest is operating.
-
+
[FOR-533] Auto Generate plugins.xml entry
@@ -403,7 +377,7 @@
<br/>
This change will require that the plugins.xml file be retrieved from the build directory rather than the plugins directory when building the plugin documentation pages. We will therefore need a fall back to retrieve this file from the network if it is not currently available - this can be done with the locationmap
-
+
[FOR-639] define terminology for the various aspects of Dispatcher
@@ -415,7 +389,7 @@
<br/>
-
+
[FOR-735] Plugins are not correctly deployed in webapp mode
@@ -431,7 +405,7 @@
<br/>
- the pdf links give an error "Resource Not Found"
-
+
[FOR-711] Cache results from the Locationmap
@@ -447,7 +421,7 @@
<br/>
If we test all locationmaps and find no result we should record that tere is no result in this hashmap. This will also be a good place to throw an exception so that Cocoon can better report such errors (see <a href="http://issues.apache.org/jira/browse/FOR-701" title="Missing locationmap entry gives poor error">FOR-701</a>)
-
+
[FOR-742] trouble accessing unversioned plugin for a released version of Forrest, e.g. projectInfo
@@ -585,7 +559,7 @@
<br/>
Beware that it will not work for raw files that are not linked, as this "feature" currently uses a fixed dir being being copied by Ant.
-
+
[FOR-546] Sitemap reference doc should be updated to reflect plugin architecture
@@ -617,7 +591,7 @@
<br/>
I found out about this because my sitemap uses the fo2pdf too (docbook to PDF), and had to add the serializer.
-
+
[FOR-560] Remove duplicate jars from eclipse plugins
@@ -625,7 +599,7 @@
tools/eclipse/plugins/org.apache.forrest.eclipse.servletEngine/lib contains some duplicate jars to those in the main Forrest trunk. We should find a way of reusing the jars from their existing location.
-
+
[FOR-644] code-style cleanup for xml files
@@ -635,7 +609,7 @@
<br/>
-
+
[FOR-666] clarify the sitemap matches etc. in FAQ about non-skinned html
In our forrest/site-author/content/xdocs/site.xml there are two entries without "label" attributes. Previously these documents were not being generated. Not sure if this change in behaviour is good or bad. Needs investigation.
+<br/>
+
+<br/>
+This is most likely a side-effect of the workaround for issue <a href="http://issues.apache.org/jira/browse/FOR-675" title="upgrading to commons-jxpath-1.2.jar causes failures with linkrewriter protocols site: etc.">FOR-675</a>
+
+
+
[FOR-677] leading slash in gathered URIs causes double the number of links to be processed
Doing 'forrest' starts at the virtual document called linkmap.html where the Cocoon crawler gathers the initial set of links, then starts crawling and generating pages. Any new links are pushed onto the linkmap. However, for some sites, such as our own "seed-sample" and our "site-author", there is a sudden jump in the number of URIs remaining to be processed.
+<br/>
+
+<br/>
+This is due to a URI with a leading slash (e.g. /samples/faq.html). When that URI is processed, it gains a whole new set of links all with leading slashes, and so the list of URIs is potentially doubled.
+<br/>
+
+<br/>
+This issue could be due to a user error, i.e. adding a link that deliberately begins with a slash. Sometimes, that is unavoidable.
+<br/>
+
+<br/>
+However, we do have a sitemap transformer to "relativize" and "absolutize" the links. Should it always trim the leading slash? Or are there cases where that should not happen, so cannot generalise?