diff --git a/src/Page.js b/src/Page.js index d8483132ed..6e90d83232 100644 --- a/src/Page.js +++ b/src/Page.js @@ -1060,6 +1060,7 @@ class Page { .then(result => this.postRender(result)) .then(result => this.collectPluginsAssets(result)) .then(result => markbinder.processDynamicResources(file, result)) + .then(result => MarkBind.unwrapIncludeSrc(result)) .then((result) => { // resolve the site base url here const { relative } = urlUtils.getParentSiteAbsoluteAndRelativePaths(file, this.rootPath, diff --git a/src/lib/markbind/src/preprocessors/componentPreprocessor.js b/src/lib/markbind/src/preprocessors/componentPreprocessor.js index cf3fc6e829..ef2f9fe607 100644 --- a/src/lib/markbind/src/preprocessors/componentPreprocessor.js +++ b/src/lib/markbind/src/preprocessors/componentPreprocessor.js @@ -108,9 +108,23 @@ function _getSrcFlagsAndFilePaths(element, context, config) { // We do this even if the src is not a url to get the hash, if any const includeSrc = url.parse(element.attribs.src); - const filePath = isUrl - ? element.attribs.src - : path.resolve(path.dirname(context.cwf), decodeURIComponent(includeSrc.path)); + const baseUrlRegex = new RegExp('^{{\\s*baseUrl\\s*}}[/\\\\]'); + + let filePath; + if (isUrl) { + filePath = element.attribs.src; + } else { + const includePath = decodeURIComponent(includeSrc.path); + + if (baseUrlRegex.test(includePath)) { + // The baseUrl has not been resolved during pre-processing, but we need the source file path + const parentSitePath = urlUtils.getParentSiteAbsolutePath(context.cwf, config.rootPath, + config.baseUrlMap); + filePath = path.resolve(parentSitePath, includePath.replace(baseUrlRegex, '')); + } else { + filePath = path.resolve(path.dirname(context.cwf), includePath); + } + } const boilerplateFilePath = _getBoilerplateFilePath(element, config, filePath); const actualFilePath = boilerplateFilePath || filePath; diff --git a/test/functional/test_site/expected/index.html b/test/functional/test_site/expected/index.html index f8b5285162..64785b4b8e 100644 --- a/test/functional/test_site/expected/index.html +++ b/test/functional/test_site/expected/index.html @@ -338,7 +338,9 @@
This is a page from another Markbind site. The purpose of this page is to ensure that reuse works as expected. All the following images should display correctly.
Some variables:
@@ -401,6 +403,40 @@Include a file using baseUrl
+As we establish requirements, they should be recorded in some way for future reference, usually called a requirement specification. Furthermore, it is advisable to show these requirements to stakeholders, and refine requirements based on their + feedback. The next phase is to convert requirements into a product specification that specifies how the product will address the requirements.
+same test with panels
Include a file in a sub-folder that uses baseUrl
+Requirements gathering, requirements elicitation, requirements analysis, requirements capture are some of the terms commonly and interchangeably used to represent the activity of understanding what a software product should + do.
+same test with panels
Include a file in a sub-folder that uses baseUrl using baseUrl
+Requirements gathering, requirements elicitation, requirements analysis, requirements capture are some of the terms commonly and interchangeably used to represent the activity of understanding what a software product should + do.
+same test with panels
Include a file in a sub-site that uses baseUrl
+same test with panels
Include a file in a sub-site that uses baseUrl using baseUrl
+same test with panels
Trimmed include
Fragment with leading spaces and newline
Trimmed include fragment
diff --git a/test/functional/test_site/expected/requirements/SpecifyingRequirements._include_.html b/test/functional/test_site/expected/requirements/SpecifyingRequirements._include_.html new file mode 100644 index 0000000000..352bb5ca51 --- /dev/null +++ b/test/functional/test_site/expected/requirements/SpecifyingRequirements._include_.html @@ -0,0 +1,18 @@ +
+
Given next are some tools and techniques that can be used to specify requirements. Note that they can also be used for establishing requirements too.
+This is the most straight forward way of describing requirements. A textual description can be used to give a quick overview of the domain/system that is understandable to both the users and the development team. Textual descriptions are especially useful + when describing the vision of a product. However, lengthy textual descriptions are hard to follow.
+It is a list of features (or functionalities) grouped according to some criteria such as priority (e.g. must-have, nice-to-have, etc. ), order of delivery, object or process related (e.g. order-related, invoice-related, etc.). Here is a sample feature + list from Minesweeper (only a brief description has been provided to save space).
+Requirements gathering, requirements elicitation, requirements analysis, requirements capture are some of the terms commonly and interchangeably used to represent the activity of understanding what a software product should do.
+