# Project replacement expanding to  \<$include:…\> prints \<$include:…\> statement

**URL:** <https://forum.literatureandlatte.com/t/project-replacement-expanding-to-include-prints-include-statement/43159>\
**Category:** Beta Testing (Mac)\
**Created:** [November 4, 2018, 7:55am UTC](https://forum.literatureandlatte.com/t/project-replacement-expanding-to-include-prints-include-statement/43159 "2018-11-04T07:55:03Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![nostodnayr](https://forum.literatureandlatte.com/letter_avatar_proxy/v4/letter/n/d2c977/32.png) [@nostodnayr](https://forum.literatureandlatte.com/u/nostodnayr)\
**Post date:** [November 4, 2018, 7:55am UTC](https://forum.literatureandlatte.com/t/project-replacement-expanding-to-include-prints-include-statement/43159/1 "2018-11-04T07:55:03Z")

</div>

A project text replacement (and it seems format-specific ones, too) that references an \<$include:Text\> placeholder, upon compiling, only outputs the raw placeholder, not its referenced text.

[size=85]Scrivener 3.0.9 r9414[/size]  
[size=85](Apologies if this is a technical limitation present in previous versions; I have only used 3.0.1 previously and experienced a corrected \<$include\> bug in that build.)  
[/size]  
Steps:

1. Create a two texts: one inside the Draft (‘test’), the other outside the Draft (‘marker text’)
2. Add some text to ‘marker text’. Add text to ‘test’ but end it with !m on a blank line by itself
3. Open Compile screen and add a project replacement for !m which expands into \<$include:marker text\> (regex, case sensitive, whole word: all disabled)
4. Compile to PDF

Expected Result:  
Final document includes the text written in both ‘test’ and ‘marker text’.

Actual Result:  
Final document includes the text in ‘test’ and \<$include:marker text\>.

---

<div class="post-metadata">

**Author:** ![KB](https://forum.literatureandlatte.com/letter_avatar_proxy/v4/letter/k/e47774/32.png) [@KB](https://forum.literatureandlatte.com/u/KB)\
**Post date:** [November 4, 2018, 3:01pm UTC](https://forum.literatureandlatte.com/t/project-replacement-expanding-to-include-prints-include-statement/43159/2 "2018-11-04T15:01:33Z")

</div>

\<$include\> and other tags are themselves types of replacements, so you cannot rely on them being done in any particular order. The text is first built (compiled) and \<$include\> tags replaced, and then replacements are run on the built text. So what you are seeing is expected behaviour.

---

<div class="post-metadata">

**Author:** ![nostodnayr](https://forum.literatureandlatte.com/letter_avatar_proxy/v4/letter/n/d2c977/32.png) [@nostodnayr](https://forum.literatureandlatte.com/u/nostodnayr)\
**Post date:** [November 5, 2018, 3:06am UTC](https://forum.literatureandlatte.com/t/project-replacement-expanding-to-include-prints-include-statement/43159/3 "2018-11-05T03:06:04Z")

</div>

> [@KB](#):
>
> \<$include\> and other tags are themselves types of replacements, so you cannot rely on them being done in any particular order. The text is first built (compiled) and \<$include\> tags replaced, and then replacements are run on the built text. So what you are seeing is expected behaviour.

Thank you for clearing that up. I’ll find a workaround for what I’m trying to do.