Content Files

Guide to writing content files

Introduction

Nift has its own powerful template language which you can use in amongst any other scripting/programming/template language you want, making it even more powerful. This page outlines most of the template language with a few additional parts explained on the template files page.

[contents]

The following functions available in Nift's template language are documented on this page:

Some of the functions take input parameters and input options. A function funcName is called with @funcName{options}(parameters) or @funcName{option 1}...{option n}(parameters) where options and parameters are separated by commas. By default you can use Nift's template language with the function name, options and parameters for a function call. For example:

@input("@[contentpath]")


Note: you can also quote the function name which you will need to do if printing variables or calling functions in the function name. A contrived example is below:

@:=(string, str = "input")
@"@[str]"("@[contentpath]")


Note: for websites that have hundreds of thousands of function calls (or millions) you might find it faster to tell Nift to not parse the function name, options and parameters, for this use the option !p. For example:

@input("@{!p}[contentpath]")


Note: For options and parameters (including variable names and values), you can use:

• \n for the newline character
• \t for tabs (though normal tabs also work)
• \\ for \
• \' for '
• \" for "

Options and parameters (including variable names and values) can be unquoted, single quoted or double quoted, whichever is more convenient, integrates with the other programming/scripting/template languages you are using and/or has nice syntax highlighting with the extensions and editor(s) you are using. Also for functions that can take multiple parameters, parameters containing commas ',' should be quoted, there can also be other times that things need to be quoted, for example if you want to have equals '=' in a variable name during its definition then it will need to be quoted (though will not need to be quoted when referenced).

Escape characters

The escape character options with Nift are listed in the table below. There used to be more escape characters for Nift however they conflicted with Nift's goals to both work for more than just websites and integrate with as many different programming/scripting/template languages as possible. See the character entity section of this page for the new way to easily get (html) entities of different characters.

syntax quoted output
\@ "@"
@\\ "\"
@\t *tab*
@\n *newline*
@\@ "&commat;"
@\< "&lt;"
syntax quoted output

Newlines

You can break up one line in the source code of content/templates files in to multiple lines in the source code for the build page/file using @\n. For example if you have the following in one of your content files used to build an output file:

This is a line @\nthat is broken in to@\n three lines.


Then the built output file will have the following written to it when it reaches that point in the build process:

This is a line
that is broken in to
three lines.


If you are building html or php pages with Nift then you can use html or php coments in your content and template files which will also appear in the source code for the built pages. If you are building output files of another language with Nift, you should also have no problems using the comment syntax for that language in your content and template files which will appear in the source code for the built output files. The following syntax is available for comments that will be stripped and not appear in the source code for built output files:

type syntax
raw single-line comment @# comment-text
parsed single-line comment @// comment-text
special parsed single-line comment @!\n comment-text
raw multi-line comment <@-- comment-text --@>
parsed multi-line comment @/* comment-text @*/
parsed multi-line comment @--- comment-text @---
type syntax

The syntax for Nift comments should be reasonably easy to remember as it is very close to the comment syntax people will be used to from languages like html, php, javascript, css, bash, python, C/C++, etc.. It also has the added benefit of being easy to turn comments from those languages in to Nift comments, and being easy to turn back again.

Raw vs. Parsed: Parsed comments have the comment text parsed with Nift's template language, so for example string definitions would be recognised, whereas raw comments do not have the comment text parsed with Nift's template language.

Special parsed single-line comments are almost the same as parsed single-line comments except that in the source code for the built output file the following line is placed on the same line after the text before @!\n. You cannot put two instances of @!\n on the same line, Nift will throw a build error.

With raw and parsed multi-line comments, Nift will skip to the first whitespace (ie. to the first character that is not a space, tab or newline) after the comment and inject it to the output file where the comment started.

Inputting file information

The following information about the output file being built can be injected:

type syntax
name @[name]
title @[title]
output file path @[outputpath]
output extension @[outputext]
content file path @[contentpath]
content extension @[contentext]
script extension @[scriptext]
template path @[templatepath]
type syntax
For example in a file template/head.content you may want something along the lines of <title>sitename - @[title]</title>.

Inputting project information

The following information about the project Nift is managing can be injected:

type syntax
content directory @[contentdir]
output directory @[outputdir]
default content extension @[defaultcontentext]
default output extension @[defaultoutputext]
default script extension @[defaultscriptext]
default template @[defaulttemplate]
type syntax

Inputting operating system information

You can use @[buildOS] to add whether an output file was built using Nift on Linux, Macintosh or Windows (@[currentOS] will continue to do the same for backwards compatibility purposes).

Inputting date, time and timezone information

The date and time that an output file was built may be inputted using @[builddate] and @[buildtime] (@[currentdate] and @[currenttime] will continue to do the same for backwards compatibility purposes). The timezone this date and time information is associated with may also be inputted using @[buildtimezone] (@[timezone] will continue to do the same for backwards compatibility purposes).

The date and time that an output file was loaded in a web browser may be inputted using @[loaddate] and @[loadtime]. The timezone this date and time information is associated with (ie. where the user is browsing the internet from) may also be inputted using @[loadtimezone].

Also available are @[buildUTCtime], @[buildUTCdate], @[buildYY] and @[buildYYYY] (with @[currentUTCtime], @[currentUTCdate], @[currentYY] and @[currentYYYY] doing the same for backwards compatibility purposes), along with @[loadUTCtime], @[loadUTCdate], @[loadYY] and @[loadYYYY].

String variables

You can define string variables using @:=(string, var1-name = var1-value, …, varN-name = varN-value), where vari-name is the name of varible i and vari-value is the value for variable i. Note that you do not have to assign a value to any/all of the variables. For example you might have:

@:=(string, str = "hello, world!", str2)


Note: variable types and variable values containing commas ',' should be quoted, variable names containing commas ',' or the equals character '=' should be quoted.

You can reference string variables using @[varName] or @<varName>, where varName is the variable name. Use whichever is more convenient, integrates with the other programming/scripting/template languages you are using and/or has nice syntax highlighting with the extensions and editor(s) you are using. For example with html files, using <> non-nested often gives nice highlighting, and with markdown files, using [] non-nested often gives nice highlighting. With nesting use a combination of [] and <> with whichever resulting highlighting you prefer.

For example to reference the string str defined above use:

@[str]


Inputting text from other files

Text may be inputted from another file using @input(path-to-file), where path-to-file is the path from the main project directory to the input file.

For example suppose inside a project directory you have template/footer.content:

Page was last built on @[currentdate].


To input template/footer.content into another file write:

@input("template/footer.content")


Note: Nift will not let you create an input loop, for example you cannot have @input(page.template) inside page.template, or any of the files that page.template inputs, or any of the files that they input, and so on.

Note: If you would like to input the file only if the file exists, ie. not throw an error if the file does not exist, then use the if-exists option, eg:

@input{if-exists}(file-path)


Inputting raw text from other files

Raw text (so not parsed with Nift's template language) may be inputted from another file using @input{raw}(path-to-file), where path-to-file is the path from the main project directory to the input file.

For example suppose inside your project directory you have template/footer.content.

To raw input template/footer.content into another file write:

@input{raw}("template/footer.content")


Note: If you would like to input the file only if the file exists, ie. not throw an error if the file does not exist, then use the if-exists option, eg:

@input{raw, if-exists}(file-path)


Paths from output files to other (tracked) files

It is possible for tracked files $A$ and $B$ to be located in distinct directories yet input text from the same content file $X$. Consequently if content file $X$ contains a path to another file $Y$, you have the problem that the path from $A$ to $Y$ is not the same as the path from $B$ to $Y$. You can solve this non-constant path problem by using @pathto(tracked-name), @pathto{name}(tracked-name) or @pathtopage(tracked-name) where tracked-name is the tracked name for $Y$. When building an output file, Nift will replace @pathto(name) with the relative path from the output file being built to the output file for $Y$.

An example of when users may find this useful is when writing menus for website page templates, or adding in text for the head/header/footer/etc.. An example of a menu using @pathto(name) is below:

<nav>
<li></li>
<li class="dm_li">
<a href="@pathto(index)">Home</a>
</li>

<li class ="dm_li">
<div class="dm_text">Documentation</div>
<li class="dsm_li"><a href="@pathto(documentation/installing_nift)">Installing Nift</a></li>
<li class="dsm_li"><a href="@pathto(documentation/nift_tutorial)">Nift tutorial</a></li>
<li class="dsm_li"><a href="@pathto(documentation/nift_commands)">Nift commands</a></li>
</ul>
</li>

<li class ="dm_li">
<a href="@pathto(support)">Support</a>
</li>
<li></li>
</ul>
</nav>


When using @pathto(tracked-name), @pathto{name}(tracked-name) or @pathtopage(tracked-name), Nift will throw an error if tracked-name is not being tracked by Nift.

You can solve the non-constant path problem for arbitrary files by using @pathto(path-to-file), @pathto{file}(path-to-file) or @pathtofile(path-to-file) where path-to-file is the absolute path from the project root directory to file $Y$ (where tracked file $Y$ above has been replaced with file $Y$). When building an output file, Nift will throw an error if the file does not exist and otherwise inject the relative path from the built output file to file $Y$.

An example footer content file (inputted in the template/page.template file) is given below as an example using @pathtofile(path-to-file):

<footer>
<hr>
<center><img src="@pathtofile(site/files/nsm.png)" width="120"></center>

<p>
<b>Mirrors:</b> [<a href="https://nift.cc/">Official</a>] [<a href="https://nifty-site-manager.bitbucket.io/">BitBucket</a>] [<a href="https://nifty-site-manager.github.io/">GitHub</a>] [<a href="https://nifty-site-manager.gitlab.io/">GitLab</a>]
</p>

<p>
<b>Repos:</b> [<a href="https://bitbucket.org/nifty-site-manager/nsm/src/master/">BitBucket</a>] [<a href="https://github.com/nifty-site-manager/nsm">GitHub</a>] [<a href="https://gitlab.com/nifty-site-manager/nsm">GitLab</a>]
</p>

Page was last built on @[currentdate] at @[currenttime] (@[timezone]) using @[currentOS]. <br>

</footer>


File dependencies may be added using @dep(dep-path), where dep-path is the path from the project root directory to the dependency file.

You can also add file dependencies manually by adding a .deps file residing in the same directory as the content file. For example if you have content/index.content as the content file add a content/index.deps file containing the extra dependencies you want to track.

Running scripts

Scripts may be run using @script(script-path), where script-path is the path from the project root directory to the script, which is basically the same as the system call for the script. If you need to pass parameters to your scripts you can use:

@script(script-path, parameter 1, ..., parameter n)


For example if you want to run a script 'script.py', you can do so with:

@script('./script.py')


Also if for example you want to run a script 'script.py' while passing in the parameters "light blue" and red, you can do so with:

@script("./script.py", "light blue", "red")


Note: Scripts/programs run with @script calls are moved to the project root directory to run and have a backup copy made. If scripts/programs are so large that copying the file will take time, or you are making lots of calls which is slower at scale, you can use the !bs option to not have the script backed up, eg.:

@script{!p, !bs}('./script.py')


Alternatively you can write scripts/programs that you run yourself (not using Nift) which they themselves add the Nift build process in to them, leaving you with just one program that you need to run when building. You will still get to take advantage of Nift's unbeaten build times and powerful template language doing this.

Note: If you need to have different files/threads running the same script during the build process you will either need to set the number of build threads to 1 or put up with having to rebuild on the occassions where Nift unsuccessfully tries to run both scripts at the same time. You can always have duplicate copies of the same script in different files and have each file/thread run a different version.

Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files (this is an unfortunate limitation of C++). If you really must change directories in your scripts then you can take a reduction in build times and set the number of build threads to 1, make sure to change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message (this should be fixed soon).

Note: @script(script-path) calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few script/system calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

Inputting script output

Output from scripts may be inputted at any point when building output files using @script{inject}(script-path), where script-path is the path from the main project directory to the script, which is basically the same as the system call for the script. If you need to pass parameters to your scripts you can use:

@script{inject}(script-path, parameter 1, ..., parameter n)


This can be incredibly useful for things like conditional statements/loops, or integrating with databases, GraphQL and scripting languages etc., which is just the tip of the ice berg!

For example suppose you want to input the output from running a script "linux script.py", you can do so with:

@script{inject}('./linux script.py')


Note: Scripts/programs run with @script{inject}(script-path) calls are moved to the project root directory to run and have a backup copy made. If scripts/programs are so large that copying the file will take time, or you are making lots of calls which is slower at scale, you can use the !bs option to not have the script backed up, eg.:

@script{inject}{!p, !bs}('./script.py')


Alternatively you can write scripts/programs that you run yourself (not using Nift) which they themselves add the Nift build process in to them, leaving you with just one program that you need to run when building. You will still get to take advantage of Nift's unbeaten build times and powerful template language doing this.

Note: If you need to have different files/threads running the same script during the build process you will either need to set the number of build threads to 1 or put up with having to rebuild on the occassions where Nift unsuccessfully tries to run both scripts at the same time. You can always have duplicate copies of the same script in different files and have each file/thread run a different version.

Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files. If you really must change directories in your scripts then you will have to set the number of build threads to 1 and change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message (this should be fixed soon).

Note: @script{inject}(script-path) calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few script/system calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

Inputting script output raw

Raw output from scripts (so not parsed with Nift's template language) may be inputted at any point when building output files using @script{raw}(script-path), where where script-path is the path from the main project directory to the script, which is basically the same as the systemraw call for the script. If you need to pass parameters to your scripts you can use:

@script{raw}(script-path, parameter 1, ..., parameter n)


For example suppose you want to input the raw output from running a script "linux script.py", you can do so with:

@script{raw}('./linux script.py')


Note: Scripts/programs run with @script{raw}(script-path) calls are moved to the project root directory to run and have a backup copy made. If scripts/programs are so large that copying the file will take time, or you are making lots of calls which is slower at scale, you can use the !bs option to not have the script backed up, eg.:

@script{raw}{!p, !bs}('./script.py')


Alternatively you can write scripts/programs that you run yourself (not using Nift) which they themselves add the Nift build process in to them, leaving you with just one program that you need to run when building. You will still get to take advantage of Nift's unbeaten build times and powerful template language doing this.

Note: If you need to have different files/threads running the same script during the build process you will either need to set the number of build threads to 1 or put up with having to rebuild on the occassions where Nift unsuccessfully tries to run both scripts at the same time. You can always have duplicate copies of the same script in different files and have each file/thread run a different version.

Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files. If you really must change directories in your scripts then you will have to set the number of build threads to 1 and change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message (this should be fixed soon).

Note: @script{raw}(script-path) calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few script/system calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

Running system calls

System calls may be run using @system(system-call), where system-call is the system call or you want to run.

For example suppose you want to convert the markdown file file.md to html using pandoc and save it in out.html, you can do so with:

@system('pandoc -o out.html file.md')


Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files. If you really must change directories in your scripts then you will have to set the number of build threads to 1 and change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message.

Note: @system calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few @script calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

Inputting system call output

Output from system calls may be inputted at any point when building output files using @system{inject}(system-call), where system-call is the system call or script you want to run. This can be incredibly useful for things like conditional statements/loops, inputting text from a url using cURL, or integrating with databases, GraphQL and scripting languages etc., which is just the tip of the ice berg!

Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files. If you really must change directories in your scripts then you will have to set the number of build threads to 1 and change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message.

Note: @system{inject}(system-call) calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few script/system calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

For example suppose you want to input the text from this paste on Paste Bin, you can do so with:

@system{inject}("curl -sS https://pastebin.com/raw/atjKuxY6")


Inputting system call output raw

Raw output from system calls may be inputted at any point when building output files using @system{raw}(system-call), where system-call is the system call or script you want to run.

Note: Scripts and system calls are run from the project root directory so all paths in your scripts should start from there. Also do not change directory in your scripts as it will mess up the other threads that are also building output files. If you really must change directories in your scripts then you will have to set the number of build threads to 1 and change back to the project root directory before each script ends. Also you will not see the output of your scripts until after they have finished running, so user input is not recommended as you can not display a message.

Note: @system{raw}(system-call) calls do not scale very well to hundreds of thousands of calls, it is much better to combine as much as possible in to as few system/script calls as possible for extremely large projects (moving stuff to the pre/post build scripts is the best place, you can output stuff to file and process the files when building). For example if possible it's much faster to have a few pre-build scripts to download text from multiple urls using cURL, and/or make all the api calls, all the database queries, and work on JSON data needed and distribute the needed output in to different files to be inputted when needed. Note that file-specific build scripts have the benefit of multithreading, whereas project-wide build scripts wont have any multithreading unless you code it in there yourself.

For example suppose you want to input the text from this paste on Paste Bin, you can do so with:

@system{raw}("curl -sS https://pastebin.com/raw/atjKuxY6")


User input from command-line

To inject standard input from the user using the command-line in to the output file being built you can use @in(message) where message is the message to be displayed on the command-line to the user (you can provide no message if you want and output to the user in other ways).

For example:

@in("please enter your name:")


You can even input the message from file if you would like using @in(@input(message-file-path)), for example:

@in(@input("@[contentdir]/input-message.txt"))


User input from file

To inject input from the user from a file in to the output file being built you can use @in{from-file}(message) where message is the message/template to be displayed in the file opened up for the user to modify then save/close.

Note: you can choose which text editor is used with the unixTextEditor and winTextEditor settings in the .nsm/nift.config configuration file in your project directory.

For example:

@in{from-file}("please replace this text with your content")


You can even input the message/template from file if you would like using @in{from-file}(@input(message-file-path)), for example:

@in{from-file}(@input("@[contentdir]/input-message.txt"))


Note: If you want to input the message/template from file without it being parsed by Nift's template language yet use @input{raw}(path-to-file) rather than @input(path-to-file).

Character entities

You can get the (html) entity for many characters using @ent(code) where code is the code for the entity you want. The entities currently available with Nift are in the table below.

code output rendered
@ent('') &grave;
@ent('~') &tilde; ˜
@ent('!') &excl; !
@ent('@') &commat; @
@ent('#') &num; #
@ent('$') &dollar;$
@ent('%') &percnt; %
@ent('^') &Hat; ^
@ent('&') &amp; &
@ent('*') &ast; *
@ent('?') &quest; ?
@ent('<') &lt; <
@ent('>') &gt; >
@ent('(') &lpar; (
@ent(')') &rpar; )
@ent('[') &lbrack; 
@ent(']') &rbrack; ]
@ent('{') &lbrace; {
@ent('}') &rbrace; }
@ent('-') &minus;
@ent('_') &lowbar; _
@ent('=') &equals; =
@ent('+') &plus; +
@ent('|') &vert; |
@ent('\\') &bsol; \
@ent('/') &sol; /
@ent(';') &semi; ;
@ent(':') &colon; :
@ent('\'') &apos; '
@ent('"') &quot; "
@ent(',') &comma; ,
@ent('.') &period; .
@ent('£') &pound; £
@ent('¥') &yen; ¥
@ent('€') &euro;
@ent("section") &sect; §
@ent("+-") &pm; ±
@ent("-+") &mp;
@ent("!=") &ne;
@ent("<=") &leq;
@ent(">=") &geq;
@ent("->") &rarr;
@ent("<-") &larr;
@ent("<->") &harr;
@ent("==>") &rArr;
@ent("<==") &lArr;
@ent("<==>") &hArr;
@ent("<=!=>") &nhArr;
code output rendered

Including css files

The best way to add CSS files is:

<link rel='stylesheet' type='text/css' href='@pathtofile(path-to-css-file)'>

Note that by using @pathtofile you will get a build error if the file does not exist (anymore).

Alternatively you can include a css file using @cssinclude(path-to-css-file), where path-to-css-file is the path from the main project directory to the css file (not the path from the page/output file to the css file). When building a page/output file, Nift will replace @cssinclude(path-to-css-file) with:

<link rel='stylesheet' type='text/css' href='path-from-page-to-css-file'>


Including img files

The best way to add an images to a website page is:

<img src="@pathtofile(path-to-img-file)" width="120">

Note that by using @pathtofile you will get a build error if the file does not exist (anymore).

Alternatively, you can include an image file using @imginclude(path-to-img-file), where path-to-img-file is the path from the main project directory to the img file (not the path from the page/output file to the img file). When building a page/output file, Nift will replace @imginclude(path-to-img-file) with the following:

<img src="path-from-page-to-img-file">


Including javascript files

The best way to add a javscript file is:

<script src="@pathtofile(path-to-js-file)"></script>

Note that by using @pathtofile you will get a build error if the file does not exist (anymore).

Alternatively, you can include a javascript file using @jsinclude(path-to-js-file), where path-to-js-file is the path from the main project directory to the js file (not the path from the page/output file to the js file). When building a page/output file, Nift will replace @jsinclude(path-to-js-file) with:

<script src="path-from-page-to-js-file"></script>


Including a favicon file

The best way to add a favicon file is:

<link rel='icon' type='image/png' href='@pathtofile(path-to-favicon-file)'>

Note that by using @pathtofile you will get a build error if the file does not exist (anymore).

Alternatively, you can include a favicon file using @faviconinclude(path-to-favicon-file), where path-to-favicon-file is the path from the main project directory to the favicon file (not the path from the page/output file to the favicon file). When building a page/output file, Nift will replace @faviconinclude(path-to-favicon-file) with:

<link rel='icon' type='image/png' href='path-from-page-to-favicon-file'>


An example of using @cssinclude(path-to-css-file), @jsinclude(path-to-js-file) and @faviconinclude(path-to-favicon-file) is given below (I typically put these in a head.content file located in the template directory and included in the template/page.template file in between the <head></head> tags):

@cssinclude("site/css/pagestyle.css")
@jsinclude("site/js/motion.css")
@faviconinclude("site/files/favicon.ico")
`