<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://ark.lparchaeology.com/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=John+Layt</id>
		<title>ARK - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://ark.lparchaeology.com/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=John+Layt"/>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php/Special:Contributions/John_Layt"/>
		<updated>2026-05-18T07:45:43Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.1</generator>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124991</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124991"/>
				<updated>2021-09-22T11:58:50Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Debian Stable (Stretch) */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd mariadb imagemagick icu4c&lt;br /&gt;
 brew install php@7.4&lt;br /&gt;
 pecl install apcu imagick xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer@2 phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install node@14&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php@7.4&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian ===&lt;br /&gt;
&lt;br /&gt;
Since Debian Stretch, Debian has enabled the parallel install of multiple PHP versions using PHP-FM. However each release of Debian ships with a different default version and only that version is officially supported in that release. In order to install other versions such as PHP 5.6 and 7.4 you need to use the packages made available by the Debian Maintainer in his personal development repo. Check your version of Debian to determine what you need. LP Archaeology use this solution for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for adding PHP repo: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
Summary of install commands for PHP 7.4 current requirement:&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install php7.4 php7.4-apcu php7.4-apcu-bc php7.4-bcmath php7.4-bz2 php7.4-cli php7.4-common php7.4-fpm php7.4-gd \&lt;br /&gt;
   php7.4-geoip php7.4-imagick php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.1-readline php7.4-sqlite3 \&lt;br /&gt;
   php7.4-tidy php7.4-uuid php7.4-yaml php7.4-xml php7.4-zip phpmyadmin php-pear&lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.4-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.4-fpm&lt;br /&gt;
 sudo a2enconf php7.4-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite mysite&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://gitlab.com/arklab/arkserver.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://gitlab.com/arklab/arkserver&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd arkserver/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124990</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124990"/>
				<updated>2021-09-21T17:05:27Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* macOS */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd mariadb imagemagick icu4c&lt;br /&gt;
 brew install php@7.4&lt;br /&gt;
 pecl install apcu imagick xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer@2 phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install node@14&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php@7.4&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian Stable (Stretch) ===&lt;br /&gt;
&lt;br /&gt;
Debian Stretch ships with PHP 7.0 by default, but also enables the parallel install of other PHP versions using PHP-FM. PHP 5.6 and 7.1 are not in the official repositories, but the Debian maintainer has made them available in his repo pending their being pushed to Debian Backports. LP Archaeology use this combination for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for PHP 7.1: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Summary of install commands&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server \&lt;br /&gt;
 php7.1 php7.1-bcmath php7.1-bz2 php7.1-cli php7.1-common php7.1-enchant php7.1-fpm php7.1-gd php7.1-intl \&lt;br /&gt;
 php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-readline php7.1-sqlite3 \&lt;br /&gt;
 php7.1-tidy php7.1-xml php7.1-zip phpmyadmin php-apcu php-apcu-bc php-geoip php-getid3 php-imagick \&lt;br /&gt;
 php-pear libphp-phpmailer php-php-gettext php-phpseclib php-tcpdf php-uuid php-yaml &lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.1-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.1-fpm&lt;br /&gt;
 sudo a2enconf php7.1-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite dime&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://gitlab.com/arklab/arkserver.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://gitlab.com/arklab/arkserver&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd arkserver/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124989</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124989"/>
				<updated>2021-09-21T17:04:54Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* macOS */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd mariadb imagemagick icu4c&lt;br /&gt;
 brew install php@7.4&lt;br /&gt;
 pecl install apcu imagick xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer@2 phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install node@14&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php@7.4&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost:8080 and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost:8080/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian Stable (Stretch) ===&lt;br /&gt;
&lt;br /&gt;
Debian Stretch ships with PHP 7.0 by default, but also enables the parallel install of other PHP versions using PHP-FM. PHP 5.6 and 7.1 are not in the official repositories, but the Debian maintainer has made them available in his repo pending their being pushed to Debian Backports. LP Archaeology use this combination for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for PHP 7.1: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Summary of install commands&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server \&lt;br /&gt;
 php7.1 php7.1-bcmath php7.1-bz2 php7.1-cli php7.1-common php7.1-enchant php7.1-fpm php7.1-gd php7.1-intl \&lt;br /&gt;
 php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-readline php7.1-sqlite3 \&lt;br /&gt;
 php7.1-tidy php7.1-xml php7.1-zip phpmyadmin php-apcu php-apcu-bc php-geoip php-getid3 php-imagick \&lt;br /&gt;
 php-pear libphp-phpmailer php-php-gettext php-phpseclib php-tcpdf php-uuid php-yaml &lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.1-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.1-fpm&lt;br /&gt;
 sudo a2enconf php7.1-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite dime&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://gitlab.com/arklab/arkserver.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://gitlab.com/arklab/arkserver&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd arkserver/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Spatial&amp;diff=124988</id>
		<title>ARK2/Spatial</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Spatial&amp;diff=124988"/>
				<updated>2021-09-21T16:00:29Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Design */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Requirements ==&lt;br /&gt;
&lt;br /&gt;
Basic spatial support is required, e.g. storing find points or area bounding boxes, as well as the advanced mapping interface options, such as spatial search and processing. We use the [http://www.opengeospatial.org/standards/sfs OpenGIS standard] as defined by the OGC and implemented by various spatial databases.&lt;br /&gt;
&lt;br /&gt;
Basic back-end support:&lt;br /&gt;
* Lossless storage of standard geometries, including CRS&lt;br /&gt;
* Validate geometries&lt;br /&gt;
* Interchange geometries via API&lt;br /&gt;
&lt;br /&gt;
Advanced back-end support:&lt;br /&gt;
* Spatial search&lt;br /&gt;
* Spatial processing&lt;br /&gt;
* File import/export&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
The lossless storage and interchange of spatial data is a core function, but cross-database support is poor:&lt;br /&gt;
* MySQL/MariaDB has a native GEOMETRY type, but this is only 2D&lt;br /&gt;
* PostgreSQL and SQLite have 3D support, but only by adding extensions (PostGIS and Spatialite)&lt;br /&gt;
* Adding extensions may be difficult on hosted platforms, or the additional spatial functions provided may not be needed by a site&lt;br /&gt;
&lt;br /&gt;
The lossless storage of geometries in the database therefore needs to use standard datatypes in either WKT or WKB format. The downside to this is that the data cannot then be used for spatial search or processing within the database. If spatial search or processing is required, then the data will need to be duplicated in proper spatial fields.&lt;br /&gt;
&lt;br /&gt;
Again, support for spatial search and processing is uneven:&lt;br /&gt;
* MySQL supports standard SQL spatial functions from 5.6 onwards, and spatial indexes for InnoDB from 5.7.6 onwards&lt;br /&gt;
* MariaDB supports standard SQL spatial functions from 5.5 onwards, and spatial indexes for InnoDB from 10.2.2 onwards&lt;br /&gt;
* Both MySQL and MariaDB support spatial indexes in MyISAM from 5.5 onwards&lt;br /&gt;
* PostgreSQL and SQLite support spatial functions but only by adding extensions (PostGIS and Spatialite)&lt;br /&gt;
&lt;br /&gt;
As spatial search and processing are extended functions, enabling them will require installation on an appropriate platform, however fallbacks will be provided to the extent a platform supports them:&lt;br /&gt;
* On PostGIS and Spatialite the full native facilities will be used on a copy of the data&lt;br /&gt;
* On MySQL between 5.6 and 5.7.6 and on MariaDB, a MyISAM table will be used to store a copy in a GEOMETRY field with a spatial index and processed using the native spatial functions&lt;br /&gt;
* On MySQL 5.5, a MyISAM table will also be used, but the functions will either be the limited set available, or using GEOS if available&lt;br /&gt;
* On PostgreSQL and SQLite if GEOS is available then it will be used on the original data&lt;br /&gt;
* Otherwise spatial search and processing will be unavailable&lt;br /&gt;
* An option is to ship Spatialite with ARK and run it as the spatial engine only&lt;br /&gt;
&lt;br /&gt;
A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.&lt;br /&gt;
&lt;br /&gt;
Idea to investigate: if using Redis for cache, then has geospatial cache which can be used for spatial search in bounding box or radius.&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
&lt;br /&gt;
A number of OpenGIS compliant libraries do exist, but none that meet our full requirements:&lt;br /&gt;
* https://github.com/brick/geo - OpenGIS geometry library, requires GEOS, MySQL, PostGIS, or Spatialite. Has WKT and WKB support, but no file import/export support. Provides DBAL data types. Current but low-level maintenance, but not widely used.&lt;br /&gt;
* https://github.com/phayes/geoPHP - OpenGIS geometry library, internal routines but supports GEOS, lots of basic file import/export 2D only, effectively unmaintained but widely used, would need to fork and do major cleanups.&lt;br /&gt;
* https://github.com/creof/doctrine2-spatial - Modern, currently maintained, Doctrine ORM integration, but MySQL and PostGIS only. Could write backends for spatialite and GEOS?&lt;br /&gt;
* https://github.com/symm/gisconverter (and several others) - Various file importer libraries with partial OpenGIS class support but no functions.&lt;br /&gt;
&lt;br /&gt;
Likely solution will be to use Brick and fork various file libraries to work with it. May also fork geoPHP to work as a Brick backend? Alternative is major refactor of geoPHP, or piecemeal integration of each converter library.&lt;br /&gt;
&lt;br /&gt;
Front-end support will continue to use OpenLayers.&lt;br /&gt;
&lt;br /&gt;
== Platform Support ==&lt;br /&gt;
&lt;br /&gt;
* MySql &amp;gt;= 5.5 supports 2D geometry &amp;amp; MyISAM spatial index, &amp;gt;= 5.6 spatial processing, &amp;gt;= 5.7.6 for InnoDB spatial indexing&lt;br /&gt;
* MariaDB &amp;gt;= 5.5 supports 2D? geometry and spatial processing natively, spatial index in InnoDB &amp;gt;= 10.2.2 https://mariadb.com/kb/en/mysqlmariadb-spatial-support-matrix/&lt;br /&gt;
* PostGIS native 3D geometry, spatial index, and spatial processing&lt;br /&gt;
* Spatialite native 3D geometry, spatial index, and spatial processing&lt;br /&gt;
* Postgresql no support, fake using WKT storage&lt;br /&gt;
* SQLite no support, fake using WKT storage&lt;br /&gt;
* GEOS provides spatial processing&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Spatial&amp;diff=124987</id>
		<title>ARK2/Spatial</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Spatial&amp;diff=124987"/>
				<updated>2021-09-21T15:58:22Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Platform Support */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Requirements ==&lt;br /&gt;
&lt;br /&gt;
Basic spatial support is required, e.g. storing find points or area bounding boxes, as well as the advanced mapping interface options, such as spatial search and processing. We use the [http://www.opengeospatial.org/standards/sfs OpenGIS standard] as defined by the OGC and implemented by various spatial databases.&lt;br /&gt;
&lt;br /&gt;
Basic back-end support:&lt;br /&gt;
* Lossless storage of standard geometries, including CRS&lt;br /&gt;
* Validate geometries&lt;br /&gt;
* Interchange geometries via API&lt;br /&gt;
&lt;br /&gt;
Advanced back-end support:&lt;br /&gt;
* Spatial search&lt;br /&gt;
* Spatial processing&lt;br /&gt;
* File import/export&lt;br /&gt;
&lt;br /&gt;
== Design ==&lt;br /&gt;
&lt;br /&gt;
The lossless storage and interchange of spatial data is a core function, but cross-database support is poor:&lt;br /&gt;
* MySQL/MariaDB has a native GEOMETRY type, but this is only 2D&lt;br /&gt;
* PostgreSQL and SQLite have 3D support, but only by adding extensions (PostGIS and Spatialite)&lt;br /&gt;
* Adding extensions may be difficult on hosted platforms, or the additional spatial functions provided may not be needed by a site&lt;br /&gt;
&lt;br /&gt;
The lossless storage of geometries in the database therefore needs to use standard datatypes in either WKT or WKB format. The downside to this is that the data cannot then be used for spatial search or processing within the database. If spatial search or processing is required, then the data will need to be duplicated in proper spatial fields.&lt;br /&gt;
&lt;br /&gt;
Again, support for spatial search and processing is uneven:&lt;br /&gt;
* MySQL supports standard SQL spatial functions from 5.6 onwards, and spatial indexes for InnoDB from 5.7.6 onwards&lt;br /&gt;
* MariaDB supports standard SQL spatial functions from 5.5 onwards, but no spatial indexes for InnoDB yet&lt;br /&gt;
* Both MySQL and MariaDB support spatial indexes in MyISAM from 5.5 onwards&lt;br /&gt;
* PostgreSQL and SQLite support spatial functions but only by adding extensions (PostGIS and Spatialite)&lt;br /&gt;
&lt;br /&gt;
As spatial search and processing are extended functions, enabling them will require installation on an appropriate platform, however fallbacks will be provided to the extent a platform supports them:&lt;br /&gt;
* On PostGIS and Spatialite the full native facilities will be used on a copy of the data&lt;br /&gt;
* On MySQL between 5.6 and 5.7.6 and on MariaDB, a MyISAM table will be used to store a copy in a GEOMETRY field with a spatial index and processed using the native spatial functions&lt;br /&gt;
* On MySQL 5.5, a MyISAM table will also be used, but the functions will either be the limited set available, or using GEOS if available&lt;br /&gt;
* On PostgreSQL and SQLite if GEOS is available then it will be used on the original data&lt;br /&gt;
* Otherwise spatial search and processing will be unavailable&lt;br /&gt;
* An option is to ship Spatialite with ARK and run it as the spatial engine only&lt;br /&gt;
&lt;br /&gt;
A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.&lt;br /&gt;
&lt;br /&gt;
Idea to investigate: if using Redis for cache, then has geospatial cache which can be used for spatial search in bounding box or radius.&lt;br /&gt;
&lt;br /&gt;
== Implementation ==&lt;br /&gt;
&lt;br /&gt;
A number of OpenGIS compliant libraries do exist, but none that meet our full requirements:&lt;br /&gt;
* https://github.com/brick/geo - OpenGIS geometry library, requires GEOS, MySQL, PostGIS, or Spatialite. Has WKT and WKB support, but no file import/export support. Provides DBAL data types. Current but low-level maintenance, but not widely used.&lt;br /&gt;
* https://github.com/phayes/geoPHP - OpenGIS geometry library, internal routines but supports GEOS, lots of basic file import/export 2D only, effectively unmaintained but widely used, would need to fork and do major cleanups.&lt;br /&gt;
* https://github.com/creof/doctrine2-spatial - Modern, currently maintained, Doctrine ORM integration, but MySQL and PostGIS only. Could write backends for spatialite and GEOS?&lt;br /&gt;
* https://github.com/symm/gisconverter (and several others) - Various file importer libraries with partial OpenGIS class support but no functions.&lt;br /&gt;
&lt;br /&gt;
Likely solution will be to use Brick and fork various file libraries to work with it. May also fork geoPHP to work as a Brick backend? Alternative is major refactor of geoPHP, or piecemeal integration of each converter library.&lt;br /&gt;
&lt;br /&gt;
Front-end support will continue to use OpenLayers.&lt;br /&gt;
&lt;br /&gt;
== Platform Support ==&lt;br /&gt;
&lt;br /&gt;
* MySql &amp;gt;= 5.5 supports 2D geometry &amp;amp; MyISAM spatial index, &amp;gt;= 5.6 spatial processing, &amp;gt;= 5.7.6 for InnoDB spatial indexing&lt;br /&gt;
* MariaDB &amp;gt;= 5.5 supports 2D? geometry and spatial processing natively, spatial index in InnoDB &amp;gt;= 10.2.2 https://mariadb.com/kb/en/mysqlmariadb-spatial-support-matrix/&lt;br /&gt;
* PostGIS native 3D geometry, spatial index, and spatial processing&lt;br /&gt;
* Spatialite native 3D geometry, spatial index, and spatial processing&lt;br /&gt;
* Postgresql no support, fake using WKT storage&lt;br /&gt;
* SQLite no support, fake using WKT storage&lt;br /&gt;
* GEOS provides spatial processing&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124986</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124986"/>
				<updated>2021-09-21T15:40:34Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Supported Platforms */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.4 is required due to new language features. The minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.7.8 or later (lowest supported MySQL, required for timestamps, full-text index, spatial index, and JSON type), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v10 or later&lt;br /&gt;
* SQLite 3.9 or later (required for multiple inserts, full-text index, JSON type), Spatialite extension for spatial data&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
For practical purposes during alpha development of ARK Server 2.0 a simplified approach will be used:&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch where code changes are developed&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch will occasionally be refreshed from &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; with finished near-stable features&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to test server the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production server the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward for testing&lt;br /&gt;
* Test server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch and rebased when new test releases occur. Test config settings may be committed to the repo here.&lt;br /&gt;
* Production server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur. Prod config settings may be committed to the repo here.&lt;br /&gt;
&lt;br /&gt;
The steps to set this up on GitLab are:&lt;br /&gt;
* Create the new project&lt;br /&gt;
* Create the dev branch tracking the arklab/arkserver release branch&lt;br /&gt;
* Create the test branch tracking the dev branch&lt;br /&gt;
* Create the prod branch tracking the test branch&lt;br /&gt;
* Protect the test and prod branches to allow only push/merge by Masters&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up on a local server:&lt;br /&gt;
* mkdir &amp;lt;project&amp;gt;&lt;br /&gt;
* cd &amp;lt;project&amp;gt;&lt;br /&gt;
* git init&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t test dev&lt;br /&gt;
* git branch -t prod test&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARKmatrix&amp;diff=124985</id>
		<title>ARKmatrix</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARKmatrix&amp;diff=124985"/>
				<updated>2018-12-10T09:58:05Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Harris Matrix Software */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Harris Matrix Software =&lt;br /&gt;
&lt;br /&gt;
This page summarises L - P : Archaeology&amp;#039;s ongoing work on Harris Matrix software.&lt;br /&gt;
&lt;br /&gt;
* Our ARK Matrix software: https://gitlab.com/arklab/ArkMatrix&lt;br /&gt;
* Our survey of the State of the Art in 2015: http://archaeologic.al/wiki/Harris_Matrix&lt;br /&gt;
* The Matrix Reloaded - CAA UK 2016 presentation by John Layt of L - P : Archaeology https://www.youtube.com/watch?v=geLD7Fo6crU&lt;br /&gt;
&lt;br /&gt;
== ARK Matrix Software ==&lt;br /&gt;
&lt;br /&gt;
High-level sketch of docs - a Work-in-Progress!&lt;br /&gt;
&lt;br /&gt;
=== Strat Units ===&lt;br /&gt;
&lt;br /&gt;
Unit Attributes&lt;br /&gt;
* Site Code&lt;br /&gt;
* Unit ID&lt;br /&gt;
* Label&lt;br /&gt;
* Class [Context, Subgroup, Group, Landuse]&lt;br /&gt;
* Type [Deposit, Fill, Cut, Masonry, Skeleton, Timber]&lt;br /&gt;
* Status [Allocated, Assigned, Void]&lt;br /&gt;
* Aggregate Unit&lt;br /&gt;
* Phase&lt;br /&gt;
* Period&lt;br /&gt;
&lt;br /&gt;
=== Strat Relations ===&lt;br /&gt;
&lt;br /&gt;
* Above / Below (directed graph)&lt;br /&gt;
* Same-As (undirected graph)&lt;br /&gt;
* Contemporary With (undirected graph) [REMOVE?]&lt;br /&gt;
&lt;br /&gt;
=== Rules / Heuristics ===&lt;br /&gt;
&lt;br /&gt;
Any Relations:&lt;br /&gt;
* Cannot be between same Unit&lt;br /&gt;
* Both Units must be same Class&lt;br /&gt;
&lt;br /&gt;
Above/Below Relations:&lt;br /&gt;
* Adding relation should not create cycles (no intersection between successors and predecessors)&lt;br /&gt;
&lt;br /&gt;
Same-As Relations:&lt;br /&gt;
* Both Units must be Context class&lt;br /&gt;
* Adding relation should not create cycles (no intersection between successors and predecessors)&lt;br /&gt;
* Both Units must have the same Aggregate Unit if set&lt;br /&gt;
* Both Units must have the same Period / Phase if set&lt;br /&gt;
&lt;br /&gt;
=== Processing ===&lt;br /&gt;
&lt;br /&gt;
Load&lt;br /&gt;
&lt;br /&gt;
Validate&lt;br /&gt;
* Validate Units&lt;br /&gt;
* Validate Above/Below relations&lt;br /&gt;
* Validate Same-as Units&lt;br /&gt;
&lt;br /&gt;
Resolve&lt;br /&gt;
* For each Same-As relationship add all Above/Below relations to each Unit&lt;br /&gt;
&lt;br /&gt;
Validate&lt;br /&gt;
&lt;br /&gt;
Reduce&lt;br /&gt;
* Remove all redundant Above/Below relations (transitive reduction)&lt;br /&gt;
&lt;br /&gt;
Aggregate&lt;br /&gt;
* Validate all Context Units have an Aggregate Unit&lt;br /&gt;
* For each Context Above/Below relation where the Aggregate Unit is different between the Above and Below Units, add an Above/Below relation between the Aggregate Units to the Subgroup matrix&lt;br /&gt;
* Reduce the Subgroup matrix&lt;br /&gt;
* Validate all Subgroup Units have an Aggregate Unit&lt;br /&gt;
* For each Subgroup Above/Below relation where the Aggregate Unit is different between the Above and Below Units, add an Above/Below relation between the Aggregate Units to the Group matrix&lt;br /&gt;
* Reduce the Group matrix&lt;br /&gt;
&lt;br /&gt;
== Development Plans ==&lt;br /&gt;
&lt;br /&gt;
* https://github.com/anvaka/graph-drawing-libraries&lt;br /&gt;
* https://github.com/ArsMasiuk/qvge&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124984</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124984"/>
				<updated>2018-11-01T19:55:14Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Install */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd&lt;br /&gt;
 brew install mariadb&lt;br /&gt;
 brew install php71 php71-imagick php71-intl php71-opcache php71-xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install nodejs&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php71&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost:8080 and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost:8080/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian Stable (Stretch) ===&lt;br /&gt;
&lt;br /&gt;
Debian Stretch ships with PHP 7.0 by default, but also enables the parallel install of other PHP versions using PHP-FM. PHP 5.6 and 7.1 are not in the official repositories, but the Debian maintainer has made them available in his repo pending their being pushed to Debian Backports. LP Archaeology use this combination for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for PHP 7.1: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Summary of install commands&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server \&lt;br /&gt;
 php7.1 php7.1-bcmath php7.1-bz2 php7.1-cli php7.1-common php7.1-enchant php7.1-fpm php7.1-gd php7.1-intl \&lt;br /&gt;
 php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-readline php7.1-sqlite3 \&lt;br /&gt;
 php7.1-tidy php7.1-xml php7.1-zip phpmyadmin php-apcu php-apcu-bc php-geoip php-getid3 php-imagick \&lt;br /&gt;
 php-pear libphp-phpmailer php-php-gettext php-phpseclib php-tcpdf php-uuid php-yaml &lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.1-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.1-fpm&lt;br /&gt;
 sudo a2enconf php7.1-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite dime&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://gitlab.com/arklab/arkserver.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://gitlab.com/arklab/arkserver&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd arkserver/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124983</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124983"/>
				<updated>2018-11-01T19:52:45Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Environment */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd&lt;br /&gt;
 brew install mariadb&lt;br /&gt;
 brew install php71 php71-imagick php71-intl php71-opcache php71-xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install nodejs&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php71&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost:8080 and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost:8080/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian Stable (Stretch) ===&lt;br /&gt;
&lt;br /&gt;
Debian Stretch ships with PHP 7.0 by default, but also enables the parallel install of other PHP versions using PHP-FM. PHP 5.6 and 7.1 are not in the official repositories, but the Debian maintainer has made them available in his repo pending their being pushed to Debian Backports. LP Archaeology use this combination for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for PHP 7.1: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Summary of install commands&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server \&lt;br /&gt;
 php7.1 php7.1-bcmath php7.1-bz2 php7.1-cli php7.1-common php7.1-enchant php7.1-fpm php7.1-gd php7.1-intl \&lt;br /&gt;
 php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-readline php7.1-sqlite3 \&lt;br /&gt;
 php7.1-tidy php7.1-xml php7.1-zip phpmyadmin php-apcu php-apcu-bc php-geoip php-getid3 php-imagick \&lt;br /&gt;
 php-pear libphp-phpmailer php-php-gettext php-phpseclib php-tcpdf php-uuid php-yaml &lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.1-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.1-fpm&lt;br /&gt;
 sudo a2enconf php7.1-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite dime&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://github.com/lparchaeology/ark2.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://github.com/lparchaeology/ark2&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd ark2/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124982</id>
		<title>ARK2/Install</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Install&amp;diff=124982"/>
				<updated>2018-11-01T19:50:55Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Git / GitLab */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Install =&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://gitlab.com/arklab GitLab], so you will need a free GitLab account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find a desktop application easier to use such as [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken], or the support built-in to your IDE like Atom.&lt;br /&gt;
&lt;br /&gt;
== Environment ==&lt;br /&gt;
&lt;br /&gt;
To develop ARK requires the following tools to be installed:&lt;br /&gt;
* [https://git-scm.com/ Git]&lt;br /&gt;
* [https://getcomposer.org/ Composer]&lt;br /&gt;
* [https://nodejs.org/en/ Node.js] (for frontend/theme development only)&lt;br /&gt;
&lt;br /&gt;
You will also require PHP, a web server (Apache/PHP), a database server (MySQL/PostreSQL/SQLite), a web browser (Chrome/Firefox), and a an API client (Postman).&lt;br /&gt;
&lt;br /&gt;
The following tools are recommend to adhere to ARK code quality standards:&lt;br /&gt;
* php-cs-fixer&lt;br /&gt;
* PHP CodeSniffer&lt;br /&gt;
&lt;br /&gt;
=== macOS ===&lt;br /&gt;
&lt;br /&gt;
On macOS, while you can install the requirements via standalone packages such as [https://www.mamp.info/en/ MAMP], we recommend using HomeBrew as it makes installing and updating all the tools used easier. Using macOS is only recommended for local hosting or development purposes only, internet-connected production sites should be run on a properly supported server installation, such as Debian Stretch.&lt;br /&gt;
&lt;br /&gt;
* Install XCode from the App Store and run it to accept the license, or from the command line: &amp;lt;pre&amp;gt;sudo xcodebuild -license accept&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Check you have the Command Line Tools (including Git) installed and enabled: &amp;lt;pre&amp;gt;sudo xcode-select --install&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Download and install [http://brew.sh/ HomeBrew]: &amp;lt;pre&amp;gt;/usr/bin/ruby -e &amp;quot;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)&amp;quot;&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify your ~/.profile file to add brew packages to your $PATH and to enable Git completion&lt;br /&gt;
&amp;lt;pre&amp;gt; export PATH=/usr/local/bin:/usr/local/sbin:$PATH&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-completion.bash&lt;br /&gt;
 source /Library/Developer/CommandLineTools/usr/share/git-core/git-prompt.sh&lt;br /&gt;
 GIT_PS1_SHOWDIRTYSTATE=true&lt;br /&gt;
 PS1=&amp;#039;\u@\h \W$(__git_ps1 &amp;quot; (%s)&amp;quot;) \$ &amp;#039;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Source your modified ~/.profile file to start using it: &amp;lt;pre&amp;gt;source ~/.profile&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Install the required packages from Brew: &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew install httpd&lt;br /&gt;
 brew install mariadb&lt;br /&gt;
 brew tap homebrew/php&lt;br /&gt;
 brew install php71 php71-imagick php71-intl php71-opcache php71-xdebug&lt;br /&gt;
 brew install composer php-code-sniffer php-cs-fixer phpdocumentor phplint phpmyadmin&lt;br /&gt;
 brew install nodejs&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify /usr/local/etc/httpd/httpd.conf to enable PHP-FPM, aliases, vhosts and rewrite by uncommenting the following lines:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 LoadModule proxy_module lib/httpd/modules/mod_proxy.so&lt;br /&gt;
 LoadModule proxy_fcgi_module lib/httpd/modules/mod_proxy_fcgi.so&lt;br /&gt;
 LoadModule vhost_alias_module lib/httpd/modules/mod_vhost_alias.so&lt;br /&gt;
 LoadModule alias_module lib/httpd/modules/mod_alias.so&lt;br /&gt;
 LoadModule rewrite_module lib/httpd/modules/mod_rewrite.so&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Add the following after the DocumentRoot section to enable PhpMyAdmin:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Alias /phpmyadmin /usr/local/share/phpmyadmin&lt;br /&gt;
&amp;lt;Directory /usr/local/share/phpmyadmin/&amp;gt;&lt;br /&gt;
    Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
    AllowOverride All&lt;br /&gt;
    Require all granted&lt;br /&gt;
&amp;lt;/Directory&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Modify the DirectoryIndex section to appear as follows:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
#&lt;br /&gt;
# DirectoryIndex: sets the file that Apache will serve if a directory&lt;br /&gt;
# is requested.&lt;br /&gt;
#&lt;br /&gt;
&amp;lt;IfModule dir_module&amp;gt;&lt;br /&gt;
    DirectoryIndex index.html index.php&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;IfModule proxy_fcgi_module&amp;gt;&lt;br /&gt;
    &amp;lt;FilesMatch &amp;quot;.+\.ph(ar|p|tml)$&amp;quot;&amp;gt;&lt;br /&gt;
        SetHandler &amp;quot;proxy:fcgi://127.0.0.1:9000&amp;quot;&lt;br /&gt;
    &amp;lt;/FilesMatch&amp;gt;&lt;br /&gt;
&amp;lt;/IfModule&amp;gt;&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Start the required services:&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
 brew services start mariadb&lt;br /&gt;
 brew services start php71&lt;br /&gt;
 brew services start httpd&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
* Point your browser to localhost:8080 and you should see the default Apache page&lt;br /&gt;
* Point your browser to localhost:8080/phpmyadmin and sign in to confirm that PHP and MariaDB are running correctly&lt;br /&gt;
&lt;br /&gt;
=== Debian Stable (Stretch) ===&lt;br /&gt;
&lt;br /&gt;
Debian Stretch ships with PHP 7.0 by default, but also enables the parallel install of other PHP versions using PHP-FM. PHP 5.6 and 7.1 are not in the official repositories, but the Debian maintainer has made them available in his repo pending their being pushed to Debian Backports. LP Archaeology use this combination for our servers and we strongly recommend you use this method for both simplicity and reliability.&lt;br /&gt;
&lt;br /&gt;
Instructions for NodeJS: https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions&lt;br /&gt;
&lt;br /&gt;
Instructions for PHP 7.1: https://packages.sury.org/php/README.txt.  See also https://github.com/oerdnj/deb.sury.org/wiki/Managing-Multiple-Versions&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Summary of install commands&lt;br /&gt;
&lt;br /&gt;
 sudo apt-get install build-essential git apache2 mariadb-client mariadb-server \&lt;br /&gt;
 php7.1 php7.1-bcmath php7.1-bz2 php7.1-cli php7.1-common php7.1-enchant php7.1-fpm php7.1-gd php7.1-intl \&lt;br /&gt;
 php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql php7.1-opcache php7.1-readline php7.1-sqlite3 \&lt;br /&gt;
 php7.1-tidy php7.1-xml php7.1-zip phpmyadmin php-apcu php-apcu-bc php-geoip php-getid3 php-imagick \&lt;br /&gt;
 php-pear libphp-phpmailer php-php-gettext php-phpseclib php-tcpdf php-uuid php-yaml &lt;br /&gt;
&lt;br /&gt;
 curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -&lt;br /&gt;
 sudo apt-get install -y nodejs&lt;br /&gt;
&lt;br /&gt;
 curl -sS https://getcomposer.org/installer -o composer-setup.php&lt;br /&gt;
 php composer-setup.php --install-dir=/usr/local/bin --filename=composer&lt;br /&gt;
&lt;br /&gt;
Enabled FPM&lt;br /&gt;
&lt;br /&gt;
 sudo service php7.1-fpm start&lt;br /&gt;
 sudo systemctl enable  php7.1-fpm&lt;br /&gt;
 sudo a2enconf php7.1-fpm&lt;br /&gt;
 sudo a2enmod proxy_fcgi rewrite&lt;br /&gt;
&lt;br /&gt;
Once ARK is installed (see below), configure Apache to serve the site, using either alias or symlink.&lt;br /&gt;
&lt;br /&gt;
sudo vim /etc/apache2/sites-available/mysite.conf&lt;br /&gt;
&lt;br /&gt;
Using a simple alias on a subdirectory:&lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName localhost&lt;br /&gt;
      ServerAdmin sysadmin@localhost&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel debug&lt;br /&gt;
      Alias &amp;quot;/mysite&amp;quot;&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Using a vhost on a subdomain &lt;br /&gt;
&lt;br /&gt;
  &amp;lt;VirtualHost *:80&amp;gt;&lt;br /&gt;
      ServerName mysite.example.com&lt;br /&gt;
      ServerAdmin admin@example.com&lt;br /&gt;
      DocumentRoot /srv/www/lib/ark2/sites/mysite/web&lt;br /&gt;
      DirectoryIndex index.html index.php&lt;br /&gt;
      LogLevel warn&lt;br /&gt;
      ErrorLog /path/to/logs/&amp;lt;site&amp;gt;/error.log&lt;br /&gt;
      CustomLog /path/to/logs/&amp;lt;site&amp;gt;/access.log combined&lt;br /&gt;
      &amp;lt;Directory &amp;quot;/srv/www/lib/ark2/sites/mysite/web&amp;quot;&amp;gt;&lt;br /&gt;
          Options FollowSymLinks&lt;br /&gt;
          Require all granted&lt;br /&gt;
          AllowOverride None&lt;br /&gt;
          AcceptPathInfo On&lt;br /&gt;
          RewriteEngine On&lt;br /&gt;
          RewriteCond %{REQUEST_FILENAME} !-f&lt;br /&gt;
          RewriteRule ^(.*)$ /index.php [QSA,L]&lt;br /&gt;
     &amp;lt;/Directory&amp;gt;&lt;br /&gt;
  &amp;lt;/VirtualHost&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 sudo a2ensite dime&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -t&lt;br /&gt;
&lt;br /&gt;
 sudo systemctl reload apache2&lt;br /&gt;
&lt;br /&gt;
 sudo apache2ctl -S&lt;br /&gt;
&lt;br /&gt;
== Install ==&lt;br /&gt;
&lt;br /&gt;
To install using git, create the folder where the library code will be located, then clone the ARK2 repository.&lt;br /&gt;
&lt;br /&gt;
For example, for Debian stretch:&lt;br /&gt;
&lt;br /&gt;
 mkdir -p /srv/www/lib&lt;br /&gt;
 cd /srv/www/lib&lt;br /&gt;
 git clone https://github.com/lparchaeology/ark2.git&lt;br /&gt;
&lt;br /&gt;
Alternatively download and unzip the file from https://github.com/lparchaeology/ark2&lt;br /&gt;
&lt;br /&gt;
Then run composer to install the required PHP libraries:&lt;br /&gt;
&lt;br /&gt;
 cd ark2/&lt;br /&gt;
 composer install&lt;br /&gt;
 &amp;lt;may need github token...&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Run the Sysadmin console to check your install:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin&lt;br /&gt;
 ./bin/sysadmin system:about&lt;br /&gt;
&lt;br /&gt;
Check the database server config file is correct for your install:&lt;br /&gt;
&lt;br /&gt;
 less sites/servers.json&lt;br /&gt;
&lt;br /&gt;
If you need to add different server details:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin database:server:add&lt;br /&gt;
&lt;br /&gt;
To create a new site:&lt;br /&gt;
&lt;br /&gt;
 ./bin/sysadmin site:create &amp;lt;site&amp;gt;&lt;br /&gt;
 ./sites/&amp;lt;site&amp;gt;/bin/console&lt;br /&gt;
&lt;br /&gt;
Now edit the site config files to reflect your site settings. Most settings will have the correct default, but some may need tweaking:&lt;br /&gt;
&lt;br /&gt;
 vim sites/&amp;lt;site&amp;gt;/config/site.json&lt;br /&gt;
&lt;br /&gt;
If using vhosts, see above for instructions.&lt;br /&gt;
&lt;br /&gt;
If not using vhosts, for local development, edit your Apache config to alias the site folder:&lt;br /&gt;
&lt;br /&gt;
 Alias /&amp;lt;site&amp;gt; /path/to/ark2/sites/&amp;lt;site&amp;gt;/web&lt;br /&gt;
 &amp;lt;Directory /path/to/ark2/sites/&amp;lt;mysite&amp;gt;/web&amp;gt;&lt;br /&gt;
     Options Indexes FollowSymLinks MultiViews&lt;br /&gt;
     AllowOverride All&lt;br /&gt;
     Require all granted&lt;br /&gt;
 &amp;lt;/Directory&amp;gt;&lt;br /&gt;
&lt;br /&gt;
 http://localhost/&amp;lt;site&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To rebuild the frontend&lt;br /&gt;
 cd build&lt;br /&gt;
 npm install&lt;br /&gt;
 ./build frontend:all &amp;lt;frontend&amp;gt;&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124981</id>
		<title>Brother A3</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124981"/>
				<updated>2018-08-22T14:45:04Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Scanning Permatrace */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Brother A3 Printer / Scanner =&lt;br /&gt;
&lt;br /&gt;
LP owns a number of Brother A3 Printer / Scanners, primarily for scanning Permatrace, but also for printing large A3 plans and drawings, or colour documents where an office does not have a colour laser printer.&lt;br /&gt;
&lt;br /&gt;
NOTE: These printers are Ink Jet printers, which means the inks are not archivally stable and so cannot be used for printing Recording Sheets and any other documents to be deposited as part of the site archive. You must use a laser printer for these purposes.&lt;br /&gt;
&lt;br /&gt;
== Setup ==&lt;br /&gt;
&lt;br /&gt;
The printers should be setup to connect via the office network, although sometimes they may be directly connected via USB to a machine. If you need any assistance with this please contact the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
Apple macOS will automatically detect the printer and scanner once they are connected to the network and they can be immediately used from the macOS print dialog or Image Capture app (under the Shared section, click on more to display). They will usually be listed with a model number like &amp;#039;&amp;#039;Brother MFC J6930DW&amp;#039;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
If you need to use some advanced features, or do large volumes of Permatrace scanning, then you will need to install the official Brother drivers and app. The drivers can be found in the Library/Software/Printer Scanner Drivers/Brother A3/ folder, or downloaded from http://support.brother.com/g/b/countrytop.aspx?c=gb&amp;amp;lang=en. If you need Admin rights to install the drivers, please talk to your managing partner or the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
== Scanning Permatrace ==&lt;br /&gt;
&lt;br /&gt;
You can use the standard Apple Image Capture app to scan permatrace using the Automatic Document Feeder (ADF), but this app will only allow you to do so at A3 paper size. While the image resolution will be correct you will have to manually crop the image to permatrace size afterwards.&lt;br /&gt;
&lt;br /&gt;
The Brother Control Centre app enables you to scan custom page sizes using the ADF. You can find the app in the Finder under Applications / Brother / Control Centre. If it is not installed, see the Setup section for installation instructions.&lt;br /&gt;
&lt;br /&gt;
Run the Control Centre, choose the printer &amp;#039;&amp;#039;Model&amp;#039;&amp;#039; you want to use, and click on the &amp;#039;&amp;#039;Custom Scan&amp;#039;&amp;#039; tab to see if the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; option has already been added:&lt;br /&gt;
&lt;br /&gt;
[[File:Brother_scan_custom.png]]&lt;br /&gt;
&lt;br /&gt;
Load the scanner ADF with up to 30 sheets of permatrace. Click on the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; button to get the &amp;#039;&amp;#039;Save to File&amp;#039;&amp;#039; dialog:&lt;br /&gt;
&lt;br /&gt;
[[File:Brother_scan_file.png]]&lt;br /&gt;
&lt;br /&gt;
Change the file name prefix to the LP standard format for the site and drawing type you are scanning. This will usually be something like cxt_STE18_ for context drawings for site STE18 (see the LP Data Standards for further guidance). &lt;br /&gt;
&lt;br /&gt;
Use the &amp;#039;&amp;#039;Browse&amp;#039;&amp;#039; button to select the folder to save the scans to. We recommend saving to a local folder and not the server as it will be faster and easier to manage the files afterwards.&lt;br /&gt;
&lt;br /&gt;
Ensure all other settings are as displayed above.&lt;br /&gt;
&lt;br /&gt;
Click &amp;#039;&amp;#039;Start Scanning&amp;#039;&amp;#039; button which will show the &amp;#039;&amp;#039;Brother TWAIN&amp;#039;&amp;#039; dialog to set the image scan details. This will default to the last used values, you should not change these once set the first time:&lt;br /&gt;
&lt;br /&gt;
[[File:Brother_scan_settings.png]]&lt;br /&gt;
&lt;br /&gt;
Once you click start the permatrace will start feeding through the ADF and saving to your local folder. You need to watch the ADF carefully as dirty permatrace misfeeds easily. If it does misfeed you have to unload all the permatrace, close the scan dialog, reload the permatrace, and start the scan again. If the ADF clicks on a misfeed you have enough time &lt;br /&gt;
&lt;br /&gt;
To create the Permatrace option  click on the Configuration button and choose the Custom1 option to edit:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This will show a Config dialog which needs to be set up as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Click OK to save and you&amp;#039;ll have the Permatrace option. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
You&amp;#039;ll only need to fill these in the first time, afterwards it will remember them once you click Start.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124980</id>
		<title>Brother A3</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124980"/>
				<updated>2018-08-22T14:34:50Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Scanning Permatrace */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Brother A3 Printer / Scanner =&lt;br /&gt;
&lt;br /&gt;
LP owns a number of Brother A3 Printer / Scanners, primarily for scanning Permatrace, but also for printing large A3 plans and drawings, or colour documents where an office does not have a colour laser printer.&lt;br /&gt;
&lt;br /&gt;
NOTE: These printers are Ink Jet printers, which means the inks are not archivally stable and so cannot be used for printing Recording Sheets and any other documents to be deposited as part of the site archive. You must use a laser printer for these purposes.&lt;br /&gt;
&lt;br /&gt;
== Setup ==&lt;br /&gt;
&lt;br /&gt;
The printers should be setup to connect via the office network, although sometimes they may be directly connected via USB to a machine. If you need any assistance with this please contact the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
Apple macOS will automatically detect the printer and scanner once they are connected to the network and they can be immediately used from the macOS print dialog or Image Capture app (under the Shared section, click on more to display). They will usually be listed with a model number like &amp;#039;&amp;#039;Brother MFC J6930DW&amp;#039;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
If you need to use some advanced features, or do large volumes of Permatrace scanning, then you will need to install the official Brother drivers and app. The drivers can be found in the Library/Software/Printer Scanner Drivers/Brother A3/ folder, or downloaded from http://support.brother.com/g/b/countrytop.aspx?c=gb&amp;amp;lang=en. If you need Admin rights to install the drivers, please talk to your managing partner or the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
== Scanning Permatrace ==&lt;br /&gt;
&lt;br /&gt;
You can use the standard Apple Image Capture app to scan permatrace using the Automatic Document Feeder (ADF), but this app will only allow you to do so at A3 paper size. While the image resolution will be correct you will have to manually crop the image to permatrace size afterwards.&lt;br /&gt;
&lt;br /&gt;
The Brother Control Centre app enables you to scan custom page sizes using the ADF. You can find the app in the Finder under Applications / Brother / Control Centre. If it is not installed, see the Setup section for installation instructions.&lt;br /&gt;
&lt;br /&gt;
Run the Control Centre, choose the printer &amp;#039;&amp;#039;Model&amp;#039;&amp;#039; you want to use, and click on the &amp;#039;&amp;#039;Custom Scan&amp;#039;&amp;#039; tab to see if the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; option has already been added:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_custom.png]]&lt;br /&gt;
&lt;br /&gt;
Load the scanner ADF with up to 30 sheets of permatrace. Click on the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; button to get the &amp;#039;&amp;#039;Save to File&amp;#039;&amp;#039; dialog:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_file.png]]&lt;br /&gt;
&lt;br /&gt;
Change the file name prefix to the LP standard format for the site and drawing type you are scanning. This will usually be something like cxt_STE18_ for context drawings for site STE18 (see the LP Data Standards for further guidance). &lt;br /&gt;
&lt;br /&gt;
Use the &amp;#039;&amp;#039;Browse&amp;#039;&amp;#039; button to select the folder to save the scans to. We recommend saving to a local folder and not the server as it will be faster and easier to manage the files afterwards.&lt;br /&gt;
&lt;br /&gt;
Ensure all other settings are as displayed above.&lt;br /&gt;
&lt;br /&gt;
Click &amp;#039;&amp;#039;Start Scanning&amp;#039;&amp;#039; button which will show the &amp;#039;&amp;#039;Brother TWAIN&amp;#039;&amp;#039; dialog to set the image scan details. This will default to the last used values, you should not change these once set the first time:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_settings.png]]&lt;br /&gt;
&lt;br /&gt;
Once you click start the permatrace will start feeding through the ADF and saving to your local folder. You need to watch the ADF carefully as dirty permatrace misfeeds easily. If it does misfeed you have to unload all the permatrace, close the scan dialog, reload the permatrace, and start the scan again. If the ADF clicks on a misfeed you have enough time &lt;br /&gt;
&lt;br /&gt;
To create the Permatrace option  click on the Configuration button and choose the Custom1 option to edit:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This will show a Config dialog which needs to be set up as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Click OK to save and you&amp;#039;ll have the Permatrace option. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
You&amp;#039;ll only need to fill these in the first time, afterwards it will remember them once you click Start.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124979</id>
		<title>Brother A3</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=Brother_A3&amp;diff=124979"/>
				<updated>2018-08-22T14:34:26Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: Created page with &amp;quot;= Brother A3 Printer / Scanner =  LP owns a number of Brother A3 Printer / Scanners, primarily for scanning Permatrace, but also for printing large A3 plans and drawings, or c...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Brother A3 Printer / Scanner =&lt;br /&gt;
&lt;br /&gt;
LP owns a number of Brother A3 Printer / Scanners, primarily for scanning Permatrace, but also for printing large A3 plans and drawings, or colour documents where an office does not have a colour laser printer.&lt;br /&gt;
&lt;br /&gt;
NOTE: These printers are Ink Jet printers, which means the inks are not archivally stable and so cannot be used for printing Recording Sheets and any other documents to be deposited as part of the site archive. You must use a laser printer for these purposes.&lt;br /&gt;
&lt;br /&gt;
== Setup ==&lt;br /&gt;
&lt;br /&gt;
The printers should be setup to connect via the office network, although sometimes they may be directly connected via USB to a machine. If you need any assistance with this please contact the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
Apple macOS will automatically detect the printer and scanner once they are connected to the network and they can be immediately used from the macOS print dialog or Image Capture app (under the Shared section, click on more to display). They will usually be listed with a model number like &amp;#039;&amp;#039;Brother MFC J6930DW&amp;#039;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
If you need to use some advanced features, or do large volumes of Permatrace scanning, then you will need to install the official Brother drivers and app. The drivers can be found in the Library/Software/Printer Scanner Drivers/Brother A3/ folder, or downloaded from http://support.brother.com/g/b/countrytop.aspx?c=gb&amp;amp;lang=en. If you need Admin rights to install the drivers, please talk to your managing partner or the Sysadmins.&lt;br /&gt;
&lt;br /&gt;
== Scanning Permatrace ==&lt;br /&gt;
&lt;br /&gt;
You can use the standard Apple Image Capture app to scan permatrace using the Automatic Document Feeder (ADF), but this app will only allow you to do so at A3 paper size. While the image resolution will be correct you will have to manually crop the image to permatrace size afterwards.&lt;br /&gt;
&lt;br /&gt;
The Brother Control Centre app enables you to scan custom page sizes using the ADF. You can find the app in the Finder under Applications / Brother / Control Centre. If it is not installed, see the Setup section for installation instructions.&lt;br /&gt;
&lt;br /&gt;
Run the Control Centre, choose the printer &amp;#039;&amp;#039;Model&amp;#039;&amp;#039; you want to use, and click on the &amp;#039;&amp;#039;Custom Scan&amp;#039;&amp;#039; tab to see if the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; option has already been added:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_custom]]&lt;br /&gt;
&lt;br /&gt;
Load the scanner ADF with up to 30 sheets of permatrace. Click on the &amp;#039;&amp;#039;Permatrace&amp;#039;&amp;#039; button to get the &amp;#039;&amp;#039;Save to File&amp;#039;&amp;#039; dialog:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_file]]&lt;br /&gt;
&lt;br /&gt;
Change the file name prefix to the LP standard format for the site and drawing type you are scanning. This will usually be something like cxt_STE18_ for context drawings for site STE18 (see the LP Data Standards for further guidance). &lt;br /&gt;
&lt;br /&gt;
Use the &amp;#039;&amp;#039;Browse&amp;#039;&amp;#039; button to select the folder to save the scans to. We recommend saving to a local folder and not the server as it will be faster and easier to manage the files afterwards.&lt;br /&gt;
&lt;br /&gt;
Ensure all other settings are as displayed above.&lt;br /&gt;
&lt;br /&gt;
Click &amp;#039;&amp;#039;Start Scanning&amp;#039;&amp;#039; button which will show the &amp;#039;&amp;#039;Brother TWAIN&amp;#039;&amp;#039; dialog to set the image scan details. This will default to the last used values, you should not change these once set the first time:&lt;br /&gt;
&lt;br /&gt;
[[File::Brother_scan_settings]]&lt;br /&gt;
&lt;br /&gt;
Once you click start the permatrace will start feeding through the ADF and saving to your local folder. You need to watch the ADF carefully as dirty permatrace misfeeds easily. If it does misfeed you have to unload all the permatrace, close the scan dialog, reload the permatrace, and start the scan again. If the ADF clicks on a misfeed you have enough time &lt;br /&gt;
&lt;br /&gt;
To create the Permatrace option  click on the Configuration button and choose the Custom1 option to edit:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This will show a Config dialog which needs to be set up as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Click OK to save and you&amp;#039;ll have the Permatrace option. &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
You&amp;#039;ll only need to fill these in the first time, afterwards it will remember them once you click Start.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2&amp;diff=124978</id>
		<title>ARK2</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2&amp;diff=124978"/>
				<updated>2018-08-07T12:34:00Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Aims */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;This page details the progress on development of ARK 2.0&lt;br /&gt;
&lt;br /&gt;
== Aims ==&lt;br /&gt;
&lt;br /&gt;
The primary aims of ARK2 are:&lt;br /&gt;
* Full code re-write to modern standards using modern components&lt;br /&gt;
* Separate the ARK Database backend from the ARK Web frontend&lt;br /&gt;
* Implement a modern REST API to allow other frontends and apps to access and update the ARK Database&lt;br /&gt;
* Simplify the setup and configuration of ARK by moving the config into the database and providing online config tools&lt;br /&gt;
* Improve the overall performance and data integrity of ARK&lt;br /&gt;
* Make it possible to provide an ARK hosting service&lt;br /&gt;
&lt;br /&gt;
Modern frontend&lt;br /&gt;
* HTML5&lt;br /&gt;
* Bootstrap based&lt;br /&gt;
* Twig templates&lt;br /&gt;
* Front Controller model&lt;br /&gt;
* Config driven pages views&lt;br /&gt;
&lt;br /&gt;
Modern backend&lt;br /&gt;
* Full REST API to access and update all ARK data&lt;br /&gt;
* Database abstraction and Object Relational Mapping&lt;br /&gt;
* Config driven data schema&lt;br /&gt;
* Controlled Vocabularies and Linked Open Data&lt;br /&gt;
* User Authentication via internal user/password and external OAuth2 providers (Facebook, Google, etc)&lt;br /&gt;
* User Authorisation via Role Based Access Control (RBAC) using hierarchical Roles and Permissions structure&lt;br /&gt;
* Field-level data access control&lt;br /&gt;
* Data Workflows in conjunction with User Authorisation control&lt;br /&gt;
&lt;br /&gt;
== Documentation ==&lt;br /&gt;
&lt;br /&gt;
Details of ARK2 can be found in the following sections:&lt;br /&gt;
&lt;br /&gt;
* [[ARK2/Design|Design]] - High Level Design Decisions&lt;br /&gt;
* [[ARK2/Technical|Technical]] - Technical details, Development tools and procedures&lt;br /&gt;
* [[ARK2/The_ARK_Way|The ARK Way]] - Web Development - The ARK2 Way&lt;br /&gt;
* [[ARK2/Install|Install]] - Installation Instructions&lt;br /&gt;
* [[ARK2/Architecture|Architecture]] - System Architecture&lt;br /&gt;
* [[ARK2/Database|Database]] - Database / ORM details&lt;br /&gt;
* [[ARK2/Cache|Cache]] - Cache details&lt;br /&gt;
* [[ARK2/Model|Model]] - Data model / Schema&lt;br /&gt;
* [[ARK2/View|View]] - Views on the Data Model&lt;br /&gt;
* [[ARK2/Spatial|Spatial]] - Spatial data&lt;br /&gt;
* [[ARK2/Vocabulary|Vocabulary]] - Controlled Vocabularies&lt;br /&gt;
* [[ARK2/Files|File Management]] - File, Image, and other Media Management&lt;br /&gt;
* [[ARK2/Localization|Localization]] - Internationalization, Localization, and Translation&lt;br /&gt;
* [[ARK2/Security|Security]] - Security, Authentication, Authorisation, User Management&lt;br /&gt;
* [[ARK2/API|API]] - REST API implementation&lt;br /&gt;
* [[ARK2/Frontend|Frontend]] - Web Frontend&lt;br /&gt;
* [[ARK2/Templates|Templates]] - Using Twig for the Web Frontend&lt;br /&gt;
* [[ARK2/Console|Console]] - Admin Consoles&lt;br /&gt;
* [[ARK2/Admin|Admin]] - Admin Frontend&lt;br /&gt;
* [[ARK2/Branding|Branding]] - Branding of the ARK Project, Products, and Service&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124977</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124977"/>
				<updated>2018-04-27T09:30:40Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Custom Forks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
For practical purposes during alpha development of ARK Server 2.0 a simplified approach will be used:&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch where code changes are developed&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch will occasionally be refreshed from &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; with finished near-stable features&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to test server the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production server the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward for testing&lt;br /&gt;
* Test server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch and rebased when new test releases occur. Test config settings may be committed to the repo here.&lt;br /&gt;
* Production server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur. Prod config settings may be committed to the repo here.&lt;br /&gt;
&lt;br /&gt;
The steps to set this up on GitLab are:&lt;br /&gt;
* Create the new project&lt;br /&gt;
* Create the dev branch tracking the arklab/arkserver release branch&lt;br /&gt;
* Create the test branch tracking the dev branch&lt;br /&gt;
* Create the prod branch tracking the test branch&lt;br /&gt;
* Protect the test and prod branches to allow only push/merge by Masters&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up on a local server:&lt;br /&gt;
* mkdir &amp;lt;project&amp;gt;&lt;br /&gt;
* cd &amp;lt;project&amp;gt;&lt;br /&gt;
* git init&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t test dev&lt;br /&gt;
* git branch -t prod test&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124976</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124976"/>
				<updated>2018-04-27T09:29:08Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Custom Forks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
For practical purposes during alpha development of ARK Server 2.0 a simplified approach will be used:&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch where code changes are developed&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch will occasionally be refreshed from &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; with finished near-stable features&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;qa&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the &amp;#039;&amp;#039;&amp;#039;qa&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to test server the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production server the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward for testing&lt;br /&gt;
* Test server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;test&amp;#039;&amp;#039;&amp;#039; branch and rebased when new test releases occur. Test config settings may be committed to the repo here.&lt;br /&gt;
* Production server deployment is a clone of the dev repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur. Prod config settings may be committed to the repo here.&lt;br /&gt;
&lt;br /&gt;
The steps to set this up on GitLab are:&lt;br /&gt;
* Create the new project&lt;br /&gt;
* Create the dev branch tracking the arklab/arkserver release branch&lt;br /&gt;
* Create the test branch tracking the dev branch&lt;br /&gt;
* Create the prod branch tracking the test branch&lt;br /&gt;
* Protect the test and prod branches to allow only push/merge by Masters&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up on a local server:&lt;br /&gt;
* mkdir &amp;lt;project&amp;gt;&lt;br /&gt;
* cd &amp;lt;project&amp;gt;&lt;br /&gt;
* git init&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t test dev&lt;br /&gt;
* git branch -t prod test&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124975</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124975"/>
				<updated>2018-04-26T12:11:00Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Custom Forks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
For practical purposes during alpha development of ARK Server 2.0 a simplified approach will be used:&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch where code changes are developed&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch will occasionally be refreshed from &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; with finished near-stable features&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the local &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward&lt;br /&gt;
* Production deployment will usually be a clone of the development repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur. Prod config settings may be committed to the repo here.&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up are:&lt;br /&gt;
* Either clone an empty project created on GitLab or create a new local repository&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t prod dev&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124974</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124974"/>
				<updated>2018-04-26T12:08:59Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Branching Strategy */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
For practical purposes during alpha development of ARK Server 2.0 a simplified approach will be used:&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch where code changes are developed&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch will occasionally be refreshed from &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; with finished near-stable features&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the local &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward&lt;br /&gt;
* Production deployment will usually be a clone of the development repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up are:&lt;br /&gt;
* Either clone an empty project created on GitLab or create a new local repository&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t prod dev&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124973</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124973"/>
				<updated>2018-04-26T11:57:46Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Custom Forks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch until the first stable release of ARK Server 2.0 when a proper code management policy will be applied&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the local &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward&lt;br /&gt;
* Production deployment will usually be a clone of the development repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up are:&lt;br /&gt;
* Either clone an empty project created on GitLab or create a new local repository&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t prod dev&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124972</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124972"/>
				<updated>2018-04-26T11:49:17Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Custom Forks */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch until the first stable release of ARK Server 2.0 when a proper code management policy will be applied&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the local &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward&lt;br /&gt;
* Production deployment will usually be a clone of the development repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur&lt;br /&gt;
&lt;br /&gt;
The git commands required to set this up are:&lt;br /&gt;
* Either clone a new project from GitLab or create a new local repository&lt;br /&gt;
* git remote add arklab git@gitlab.com:arklab/arkserver.git&lt;br /&gt;
* git fetch arklab&lt;br /&gt;
* git branch -t dev arklab/master&lt;br /&gt;
* git branch -t prod dev&lt;br /&gt;
* git checkout dev&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124971</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124971"/>
				<updated>2018-04-26T11:39:23Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Git / Github */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Project Management ==&lt;br /&gt;
&lt;br /&gt;
The ARK project is hosted on [https://gitlab.com/ GitLab], so you will need a free GitLab account to contribute to development. Bug reports may be opened using a Google or Facebook account. The code is also mirrored on GitHub.&lt;br /&gt;
&lt;br /&gt;
The umbrella ARK project is organised under the [https://gitlab.com/arklab @arklab] group on GitLab, which includes the [https://gitlab.com/arklab/arkserver ARK Server] project. All public development and supported releases occur in this project repository. All code, issues, and wiki documentation on this project are public. All code contributions must pass formal code review before being merged. A separate GitLab group for [https://gitlab.com/lparchaeology L - P : Archaeology] manages private client forks and deployments of ARK Server.&lt;br /&gt;
&lt;br /&gt;
GitLab provides a very powerful web application for managing projects, but most local development is done using the standard git command line tools. If you are new to Git, you may find a desktop application easier to use. Options include [https://www.sourcetreeapp.com/ SourceTree], [https://www.gitkraken.com/ GitKraken], and [https://desktop.github.com/ Github desktop].&lt;br /&gt;
&lt;br /&gt;
=== Branching Strategy ===&lt;br /&gt;
&lt;br /&gt;
We will use a simplified version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is a temporary unstable development branch until the first stable release of ARK Server 2.0 when a proper code management policy will be applied&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
=== Custom Forks ===&lt;br /&gt;
&lt;br /&gt;
The following approach is recommended for developing custom versions of ARK Server outside the main ARK Server project&lt;br /&gt;
* Create a new empty development repository&lt;br /&gt;
* Add the arklab/arkserver repository as a git remote&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch tracking a formal release branch on arklab/arkserver&lt;br /&gt;
* Create a &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch tracking the local &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* All custom code development occurs on the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* When custom code is stable for deployment to production the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is merged into the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch&lt;br /&gt;
* Production hotfixes can be developed on &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; or a branch forked from &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* When a new ARK Server version is released the &amp;#039;&amp;#039;&amp;#039;dev&amp;#039;&amp;#039;&amp;#039; branch is rebased onto the new remote release branch for testing and then merged forward&lt;br /&gt;
* Production deployment will usually be a clone of the development repository checked-out to the &amp;#039;&amp;#039;&amp;#039;prod&amp;#039;&amp;#039;&amp;#039; branch and rebased when new production releases occur&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124970</id>
		<title>ARK2/Technical</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Technical&amp;diff=124970"/>
				<updated>2018-04-25T09:15:52Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Git / Github */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Technical Details =&lt;br /&gt;
&lt;br /&gt;
== Supported Platforms ==&lt;br /&gt;
&lt;br /&gt;
ARK2 will only actively support platforms that are actively supported with security fixes by the upstream developers. ARK2 may run on platforms not actively supported, but this is not guaranteed and ARK2 may in the future require features only available in the supported platform versions.&lt;br /&gt;
&lt;br /&gt;
* Apache is supported and will require mod_rewrite, other servers may work.&lt;br /&gt;
* PHP: PHP 7.1 is required due to new language features. In future the minimum version will be the minimum supported by PHP (see in [http://php.net/supported-versions.php PHP Supported Versions].&lt;br /&gt;
* PHP intl extension and ICU will be required, the opcache and APCu cache extensions are strongly recommended for performance.&lt;br /&gt;
* MySQL/MariaDB v5.5 or later (lowest supported MySQL, 5.5 for timestamps, 5.6 for full-text index, 5.7.5 for spatial index), utf8mb4 codeset only&lt;br /&gt;
* PostgreSQL v9.2 or later&lt;br /&gt;
* SQLite 3.7.11 or later (required for multiple inserts)&lt;br /&gt;
* Redis is recommended for data caching&lt;br /&gt;
* Linux and Mac are actively supported, Windows is also supported but minimally tested&lt;br /&gt;
&lt;br /&gt;
== Browsers ==&lt;br /&gt;
&lt;br /&gt;
ARK2 uses Bootstrap 3 for the default frontend. ARK2 therefore supports the browser versions supported by Bootstrap 3:&lt;br /&gt;
&lt;br /&gt;
* Android 2.3&lt;br /&gt;
* Android &amp;gt;= 4&lt;br /&gt;
* Chrome &amp;gt;= 20&lt;br /&gt;
* Firefox &amp;gt;= 24&lt;br /&gt;
* Explorer &amp;gt;= 8&lt;br /&gt;
* iOS &amp;gt;= 6&lt;br /&gt;
* Opera &amp;gt;= 12&lt;br /&gt;
* Safari &amp;gt;= 6&lt;br /&gt;
&lt;br /&gt;
Note that particular features provided by add-ons may not support this set of browsers. Due to the separation of the ARK2 frontend, you are free to implement your own frontend in any toolkit should you have other requirements.&lt;br /&gt;
&lt;br /&gt;
== Standards ==&lt;br /&gt;
&lt;br /&gt;
The [http://www.php-fig.org/psr/ PHP-FIG standards] will be used:&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-1/ PSR-1] and [http://www.php-fig.org/psr/psr-2/ PSR-2] Coding Standards&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-3/ PSR-3] Logging API Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-4/ PSR-4] Auto-Loading Standard&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-5/ PSR-5] PHPDoc Standard Proposal&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-6/ PSR-6] Caching API Standard&lt;br /&gt;
* [http://symfony.com/doc/current/components/http_foundation.html Symfony HTTP Foundation] for interchangeable Request/Response objects&lt;br /&gt;
* [http://www.php-fig.org/psr/psr-7/ PSR-7] HTTP Message Interface for interchangeable Request/Response objects if required for some components&lt;br /&gt;
* HTML5 / CSS3 ES vTBD&lt;br /&gt;
* All files will be UTF8 using UNIX LF&lt;br /&gt;
&lt;br /&gt;
Plugins are available for Eclipse, Atom, and other IDEs to automatically check and/or apply these standards.&lt;br /&gt;
&lt;br /&gt;
== Framework and Components ==&lt;br /&gt;
&lt;br /&gt;
The chosen framework is the [http://silex.sensiolabs.org/ Silex] micro-framework built using [http://symfony.com/ Symphony] components, with a future upgrade path to the full Symfony Framework&lt;br /&gt;
&lt;br /&gt;
Components will be carefully chosen to be well supported, stable, and interchangeable wherever possible. A number of criteria will be applied in selection:&lt;br /&gt;
* Must be standards compliant&lt;br /&gt;
* Must be well supported with a solid development history&lt;br /&gt;
* Must be well documented&lt;br /&gt;
* Must be widely used and supported&lt;br /&gt;
* Must have a strong community, small one-person efforts will only be considered if they are the de-facto standard or a &amp;#039;well-known&amp;#039; developer&lt;br /&gt;
* Any database access must use Doctrine DBAL or ORM&lt;br /&gt;
&lt;br /&gt;
Significant and reliable sources of components include:&lt;br /&gt;
* [https://packagist.org/ Packagist], the Composer index &lt;br /&gt;
* [http://symfony.com/components Symfony]&lt;br /&gt;
* [http://thephpleague.com/#packages PHP League]&lt;br /&gt;
* [https://zendframework.github.io/ Zend]&lt;br /&gt;
* [http://docs.sylius.org/en/latest/components/index.html Sylius], components from an e-commerce platform based on Symfony&lt;br /&gt;
* [http://auraphp.com/ Aura]&lt;br /&gt;
* [https://github.com/silexphp/Silex/wiki/Third-Party-ServiceProviders-for-Silex-2.x Silex providers]&lt;br /&gt;
&lt;br /&gt;
== PHP Autoloading ==&lt;br /&gt;
&lt;br /&gt;
PSR-4 is used for packaging, namespace and auto-loading of code.&lt;br /&gt;
* [https://getcomposer.org/ Composer] will be required for dependency management and PSR-4 auto-loading&lt;br /&gt;
* All external libraries will be installed by Composer under vendor/&lt;br /&gt;
* All code to be Object Oriented and implemented using a namespace of ARK&lt;br /&gt;
* All code will be under src/&amp;lt;namespace&amp;gt;&lt;br /&gt;
&lt;br /&gt;
A good series of articles explaining PSR-4 and modern development and packaging in general can be found at the following:&lt;br /&gt;
* http://culttt.com/2013/01/07/what-is-php-composer/&lt;br /&gt;
* http://culttt.com/2014/03/12/build-php-package/&lt;br /&gt;
* http://culttt.com/2014/05/07/create-psr-4-php-package/&lt;br /&gt;
&lt;br /&gt;
== Git / Github ==&lt;br /&gt;
&lt;br /&gt;
Development is hosted on [https://github.com/lparchaeology Github], so you will need a free Github account to contribute code.&lt;br /&gt;
&lt;br /&gt;
If you are new to Git, you may find the [https://desktop.github.com/ Github desktop application] easier to use. Alternatives are [https://www.sourcetreeapp.com/ SourceTree] and [https://www.gitkraken.com/ GitKraken].&lt;br /&gt;
&lt;br /&gt;
We will use a simplifed version of the [https://wiki.qt.io/Branch_Guidelines Qt git workflow].&lt;br /&gt;
* &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; branch is the semi-stable development branch for the next release which should always be in a stable enough state to pass CI testing&lt;br /&gt;
* New feature or bugfix branches for the next release are branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; prefixed with the name of the author/group/client and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;jlayt/linked-data&amp;#039;&amp;#039;&amp;#039; or &amp;#039;&amp;#039;&amp;#039;jlayt/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Once a new feature is finished and passes testing, it is rebased onto the current &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and merged via a merge request with review&lt;br /&gt;
* Alpha and Beta testing releases will be tagged on &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; and not branched&lt;br /&gt;
* Once &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; is deemed feature complete and stable enough for a Release Candidate then a release branch will be branched off &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; with the minor release number, e.g. &amp;#039;&amp;#039;&amp;#039;release/2.0&amp;#039;&amp;#039;&amp;#039;, &amp;#039;&amp;#039;&amp;#039;release/2.1&amp;#039;&amp;#039;&amp;#039;, etc&lt;br /&gt;
* Further testing will take place on the release branch, with fixes applied to to the release branch as required&lt;br /&gt;
* Once ready for release, the release will be tagged with the point release number (e.g. 2.0.0) and all bugfixes merged back into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
* Any bugfixes for the stable release will be made in the earliest release branch they apply to and then merged forward through each release then eventually into &amp;#039;&amp;#039;&amp;#039;master&amp;#039;&amp;#039;&amp;#039; (merges may be immediate or periodic depending on the volume)&lt;br /&gt;
* Bugfix branches for the stable release are branched off the release branch prefixed with the name of the branch and including the feature or bug number, e.g. &amp;#039;&amp;#039;&amp;#039;fix/2.1/issue-1234&amp;#039;&amp;#039;&amp;#039;&lt;br /&gt;
&lt;br /&gt;
== Folder Structure ==&lt;br /&gt;
&lt;br /&gt;
The following install root folder structure is used by ARK2, based on the default Silex and Composer structure, but adapted to support multi-site and multi-tenant.&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- bin/&lt;br /&gt;
   |- sysadmin&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- &amp;lt;see [[ARK2/Frontend|Frontend]]&amp;gt;&lt;br /&gt;
 |- sites/&lt;br /&gt;
 |- src/&lt;br /&gt;
 |- tests/&lt;br /&gt;
 |- var/&lt;br /&gt;
   |- cache/&lt;br /&gt;
   |- log/&lt;br /&gt;
 |- vendor/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;bin&amp;#039; folder holds any executable binaries, primarily the sysadmin console script&lt;br /&gt;
* The &amp;#039;build&amp;#039; folder holds tools and source files for building [[ARK2/Frontend|frontends]]&lt;br /&gt;
* The &amp;#039;sites&amp;#039; folder holds the site specific files in a way that supports multi-site installs&lt;br /&gt;
* The &amp;#039;src&amp;#039; folder holds the namespaced source code, e.g. src/ARK, src/MySite, etc&lt;br /&gt;
* The &amp;#039;tests&amp;#039; folder holds the ARK auto-tests&lt;br /&gt;
* The &amp;#039;var&amp;#039; folder holds install-wide transitory files, such as caches and logs (site-specific go in the site folder)&lt;br /&gt;
* The &amp;#039;vendor&amp;#039; holds the component library code managed by Composer&lt;br /&gt;
&lt;br /&gt;
Tarball packaging for release will not include the &amp;#039;build&amp;#039;, &amp;#039;test&amp;#039;, or &amp;#039;vendor&amp;#039; folders.&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;src&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- src/&lt;br /&gt;
   |- ARK/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- api/&lt;br /&gt;
       |- admin/&lt;br /&gt;
       |- core/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- php/&lt;br /&gt;
       |- schema/&lt;br /&gt;
         |- database/&lt;br /&gt;
         |- json/&lt;br /&gt;
   |- &amp;lt;project&amp;gt;/&lt;br /&gt;
     |- frontend/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
     |- server/&lt;br /&gt;
       |- &amp;lt;custom&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;src/ARK&amp;#039; folder holds the ARK Project specific code, this code is not intended for custom site code and will be over-written by any ARK update&lt;br /&gt;
* The &amp;#039;src/ARK/server&amp;#039; folder holds the ARK Server code, i.e. the backend code, API, database, etc&lt;br /&gt;
* The &amp;#039;src/ARK/frontend&amp;#039; folder holds the ARK Web Front-end code. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
* The &amp;#039;src/ARK/schema&amp;#039; folder holds the ARK Server data schemas, such as database table definitions, instance data models, etc&lt;br /&gt;
* The &amp;#039;src/&amp;lt;project&amp;gt;&amp;#039; folder would hold custom code where another project wishes to run their own multi-site install with a single custom frontend, see [[ARK2/Frontend|Frontend]] for more details&lt;br /&gt;
&lt;br /&gt;
The ARK2 &amp;#039;sites&amp;#039; folder is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- bin/&lt;br /&gt;
       |- console&lt;br /&gt;
     |- config/&lt;br /&gt;
       |- credentials.json&lt;br /&gt;
       |- database.json&lt;br /&gt;
       |- site.json&lt;br /&gt;
     |- files&lt;br /&gt;
       |- &amp;lt;see [[ARK2/Files|Files]]&amp;gt;&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- templates/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- translations/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
     |- var/&lt;br /&gt;
       |- cache/&lt;br /&gt;
       |- log/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;&amp;#039; folder holds all the custom files required for a site. This allows for multi-site installs, as well as a simple site backup/transfer strategy. The &amp;lt;site&amp;gt; name is recommended to be the reverse domain name for the site if unique (e.g. com.example.www) or the subfolder if using a shared domain (e.g. mysite).&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/bin&amp;#039; folder holds any site-specific executable binaries, primarily the site admin console script&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/config&amp;#039; folder holds all the configuration files for the site.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/files&amp;#039; folder holds all the data files for the site, such as photos and documents. See [[ARK2/Files|Files]] for more details.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/schema&amp;#039; folder holds the site specific JSON Schema files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/templates&amp;#039; folder holds the frontend template files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/translations&amp;#039; folder holds the frontend translation files.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web&amp;#039; folder is the webroot for the site, isolating the front-controller and assets in this folder improves security.&lt;br /&gt;
* The &amp;#039;sites/&amp;lt;site&amp;gt;/web/assets&amp;#039; folder holds the assets for the frontend(s), usually as a symlink back to the &amp;#039;src/ARK/web/&amp;lt;frontend&amp;gt;/assets&amp;#039; folder to allow for easy updates. See [[ARK2/Frontend|Frontend]] for more details.&lt;br /&gt;
&lt;br /&gt;
=== IDE ===&lt;br /&gt;
&lt;br /&gt;
While text editors and IDEs are a deeply personal choice, we recommend using Eclipse or [https://atom.io/ Atom] as they are cross-platform Open Source IDEs with powerful plugins to support the tools used by ARK. Using Eclipse or Atom ensures you have an environment consistent with the core ARK developers and ARK development standards.&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124969</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124969"/>
				<updated>2018-04-16T14:34:07Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Scripts */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To install a new node package to use in the frontend, run:&lt;br /&gt;
&lt;br /&gt;
  npm install &amp;lt;package&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used by a page, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page. This is the root template rendered by a page view.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
The use of Javascript in ARK2 is not very well defined or organised as yet beyond the use of jQuery and various Bootstrap-based widgets.&lt;br /&gt;
&lt;br /&gt;
Core Javascript resources in /build/core/js:&lt;br /&gt;
* alert.js - Utilies for working with the ARK2/Bootstrap alerts&lt;br /&gt;
* core-ready.js -  Initialise the core javascript on document ready&lt;br /&gt;
* form.js - Various form related tools, such as the AJAX form mappper&lt;br /&gt;
* form-ready.js - Initialise the form javascript on document ready&lt;br /&gt;
* location.js - An OpenLayers map picker widget as configured in the ark_map table.&lt;br /&gt;
* map-ol4.js - An OpenLayers map widget as configured in the ark_map table.&lt;br /&gt;
* map-ready.js - Initialise the map widget on document ready&lt;br /&gt;
* pageedit.js - Static page editing using Summernote Editor&lt;br /&gt;
* routing.js - The Routing module to use to generate paths from Route IDs.&lt;br /&gt;
* utilities.js - Some utility routines, such as debounce.&lt;br /&gt;
&lt;br /&gt;
Common vendor libraries used via NPM:&lt;br /&gt;
* jquery&lt;br /&gt;
* jquery-form&lt;br /&gt;
* moment&lt;br /&gt;
* bazinga-translator&lt;br /&gt;
* select2&lt;br /&gt;
* bootstrap&lt;br /&gt;
* bootbox&lt;br /&gt;
* bootstrap-datetime-picker&lt;br /&gt;
* bootstrap-fileinput&lt;br /&gt;
* bootstrap-table&lt;br /&gt;
&lt;br /&gt;
== Styles ==&lt;br /&gt;
&lt;br /&gt;
Styles use a combination of SASS and CSS as required with Bootstrap as the chosen ui style.&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* https://symfony.com/doc/3.4/form/form_customization.html&lt;br /&gt;
* https://symfony.com/doc/3.4/reference/forms/twig_reference.html&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124968</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124968"/>
				<updated>2018-04-16T13:56:22Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Templates */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To install a new node package to use in the frontend, run:&lt;br /&gt;
&lt;br /&gt;
  npm install &amp;lt;package&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used by a page, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page. This is the root template rendered by a page view.&lt;br /&gt;
&lt;br /&gt;
== Scripts ==&lt;br /&gt;
&lt;br /&gt;
Javascript in ARK2 is not well defined as yet beyond the use of jQuery and various Bootstrap-based widgets.&lt;br /&gt;
&lt;br /&gt;
== Styles ==&lt;br /&gt;
&lt;br /&gt;
Styles use a combination of SASS and CSS as required with Bootstrap as the chosen ui style.&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* https://symfony.com/doc/3.4/form/form_customization.html&lt;br /&gt;
* https://symfony.com/doc/3.4/reference/forms/twig_reference.html&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124967</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124967"/>
				<updated>2018-04-16T13:30:47Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Build */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To install a new node package to use in the frontend, run:&lt;br /&gt;
&lt;br /&gt;
  npm install &amp;lt;package&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used by a page, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page. This is the root template rendered by a page view.&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* https://symfony.com/doc/3.4/form/form_customization.html&lt;br /&gt;
* https://symfony.com/doc/3.4/reference/forms/twig_reference.html&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124966</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124966"/>
				<updated>2018-04-16T13:22:26Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Useful References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used by a page, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page. This is the root template rendered by a page view.&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* https://symfony.com/doc/3.4/form/form_customization.html&lt;br /&gt;
* https://symfony.com/doc/3.4/reference/forms/twig_reference.html&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124965</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124965"/>
				<updated>2018-04-16T13:21:32Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Templates */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used by a page, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page. This is the root template rendered by a page view.&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124964</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124964"/>
				<updated>2018-04-16T13:13:45Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Templates */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to be reused and repeated using Twig Block inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124963</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124963"/>
				<updated>2018-04-16T13:10:50Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Linking */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to reused and repeated use Twig Block import and inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124962</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124962"/>
				<updated>2018-04-16T13:09:36Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Templates */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create many different Views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
 |- twig/&lt;br /&gt;
   |- blocks/&lt;br /&gt;
   |- errors/&lt;br /&gt;
   |- framework/&lt;br /&gt;
   |- layouts/&lt;br /&gt;
   |- pages/&lt;br /&gt;
   |- profiler/&lt;br /&gt;
   |- user/&lt;br /&gt;
     |- emails/&lt;br /&gt;
     |- layouts/&lt;br /&gt;
&lt;br /&gt;
* blocks - Small chunks of twig code designed to reused and repeated use Twig Block import and inheritance, e.g. form fields, widgets, etc.&lt;br /&gt;
* layouts - Arrangements of blocks into generic or task specific layouts, e.g. grids, tables, custom content views, etc. &lt;br /&gt;
* pages - Definitions of the sets of standard blocks to use when building the HTML document for a particular page&lt;br /&gt;
* framework - Definition of the standard HTML document and default page blocks&lt;br /&gt;
* errors - Standard error pages, i.e. 404, 500, etc&lt;br /&gt;
* user - Required layouts for the user security system, e.g. user verification emails, login forms, etc.&lt;br /&gt;
* profiler - Custom templates to be used in the Symfony profiler&lt;br /&gt;
&lt;br /&gt;
The blocks used fall into three general groups:&lt;br /&gt;
* Standard page blocks - blocks that define or override standard page elements such as scripts, navbars, etc, which are saved in separate block files.&lt;br /&gt;
* Form blocks - blocks that define standard Symfony Form elements such as Textarea, Select, Radio, etc, which are saved in a single blocks/forms.html.twig file&lt;br /&gt;
* Custom widget blocks - blocks that define custom widgets that do not use Symfony Forms and are saved in separate block files&lt;br /&gt;
&lt;br /&gt;
The standard page blocks are:&lt;br /&gt;
* head - defines the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* styles - stylesheets to be included at the top of the document &amp;lt;head&amp;gt; element&lt;br /&gt;
* body - defines the document &amp;lt;body&amp;gt; element, usually how the navbar, sidebar, content and footer blocks are arranged in the body&lt;br /&gt;
* navbar - defines the navbar or header at the top of the document body&lt;br /&gt;
* sidebar - defines the sidebar or menu at the side of the document body&lt;br /&gt;
* content - defines the main content of the document body&lt;br /&gt;
* footer - defines the footer at the bottom of the document body&lt;br /&gt;
* scripts - scripts to be included at the bottom of the document &amp;lt;body&amp;gt; element&lt;br /&gt;
* link - defines the link element used in the navbar/sidebar/footer&lt;br /&gt;
* flash - defines the page flash element&lt;br /&gt;
&lt;br /&gt;
The standard ARK2 page view is built in Twig as follows:&lt;br /&gt;
* framework/doc.html.twig - Skeleton of the HTML5 document, includes undefined blocks for styles, head, body and scripts&lt;br /&gt;
* framework/page.html.twig - Extends doc.html.twig and defines the full default set of blocks to use for styles, head, body, and scripts, includes other default blocks used by those blocks such as navbar, but excludes the content block to be used&lt;br /&gt;
* pages/&amp;lt;page&amp;gt;.html.twig - Extends framework/page.html.twig to set the content block to be used, and overrides any standard blocks with custom blocks to be used, e.g. override the standard styles or navbar blocks on this page&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from another front-end, run the frontend:create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124961</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124961"/>
				<updated>2018-04-16T12:01:54Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Linking */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Templates ==&lt;br /&gt;
&lt;br /&gt;
Twig template resources are organised using a convention to make dynamic mixing of templates to create views possible.&lt;br /&gt;
&lt;br /&gt;
The twig folder for a frontend is organised as follows:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from another front-end, run the frontend:create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124960</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124960"/>
				<updated>2018-04-16T11:42:13Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Linking */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from another front-end, run the frontend:create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124959</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124959"/>
				<updated>2018-04-16T11:40:33Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the source folder, either by individual file names or (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, then custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools to compile the destination source code.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files to be compiled, and the javascript files that are merged to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
The javascript files are merged in the order defined in the groups, so it is recommended to explicitly list the files so that the correct order of dependencies can be defined. Sourcemap files will be created if specified in the options.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified CSS stylesheet files to be compiled, and the list of Gulp build streams required to built by the SASS compiler before being combined into that target file. For example, to build style files ark-default.min.css and ark-map.min.css you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;styles&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: [{&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;bootstrap&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/vendor.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         },&lt;br /&gt;
         {&lt;br /&gt;
             &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
             &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
                 &amp;quot;font-awesome/css/font-awesome.css&amp;quot;&lt;br /&gt;
             ],&lt;br /&gt;
             &amp;quot;core&amp;quot;: [],&lt;br /&gt;
             &amp;quot;custom&amp;quot;: [&lt;br /&gt;
                 &amp;quot;scss/default.scss&amp;quot;&lt;br /&gt;
             ]&lt;br /&gt;
         }&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: [{&lt;br /&gt;
         &amp;quot;stream&amp;quot;: &amp;quot;main&amp;quot;,&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.css&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;scss/map.scss&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }]&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
The defining of streams within each target allows for the mixing of SASS and CSS source in a defined order so the cascading of stylesheets is applied in the correct order&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124958</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124958"/>
				<updated>2018-04-16T11:27:07Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling, keyed by the Gulp module that uses them&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Not that the autoprefixer settings are those required by Bootstrap and should not be altered.&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the so source folder, either by individual file names are (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files, and the javascript files that are merged and minified to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124957</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124957"/>
				<updated>2018-04-16T11:25:11Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
Within each resource class, you must define what resources are to be included from the three resource sources: vendor, core and custom.&lt;br /&gt;
&lt;br /&gt;
For most resource classes this defines what files to copy into the so source folder, either by individual file names are (more usually for core and custom) all files in a folder:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;templates&amp;quot;: {&lt;br /&gt;
     &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
         &amp;quot;symfony-collection/jquery.collection.html.twig&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;core&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ],&lt;br /&gt;
     &amp;quot;custom&amp;quot;: [&lt;br /&gt;
         &amp;quot;twig/**/*&amp;quot;,&lt;br /&gt;
         &amp;quot;twig/**/.*&amp;quot;&lt;br /&gt;
     ]&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
When copying files in this way, the order used is vendor, core, custom, so files in core will override files in vendor and files in custom will override files in core. The vendor file paths are relative to /build/node_modules, the core files are paths relative to /build/core, and the custom files are paths relative to /build/frontends/&amp;lt;frontend&amp;gt;.&lt;br /&gt;
&lt;br /&gt;
The scripts and styles groups work differently however as they must call the SASS and JavaScript build tools.&lt;br /&gt;
&lt;br /&gt;
The scripts class defines a set of build targets, that is named minified javascript files, and the javascript files that are merged and minified to create that file. For example, to build script files ark-default.min.js and ark-map.min.js you could define the following:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;scripts&amp;quot;: {&lt;br /&gt;
     &amp;quot;ark-default&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;jquery/dist/jquery.js&amp;quot;,&lt;br /&gt;
             &amp;quot;bootstrap-sass/assets/javascripts/bootstrap.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/core-ready.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/frontend-ready.js&amp;quot;,&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;ark-map&amp;quot;: {&lt;br /&gt;
         &amp;quot;vendor&amp;quot;: [&lt;br /&gt;
             &amp;quot;proj4/dist/proj4.js&amp;quot;,&lt;br /&gt;
             &amp;quot;openlayers/dist/ol.js&amp;quot;&lt;br /&gt;
         ],&lt;br /&gt;
         &amp;quot;core&amp;quot;: [],&lt;br /&gt;
         &amp;quot;custom&amp;quot;: [&lt;br /&gt;
             &amp;quot;js/map-ready.js&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124956</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124956"/>
				<updated>2018-04-16T11:04:33Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling&lt;br /&gt;
&lt;br /&gt;
The default build options are as follows:&lt;br /&gt;
&lt;br /&gt;
 &amp;quot;options&amp;quot;: {&lt;br /&gt;
     &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
         &amp;quot;compress&amp;quot;: false&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sass&amp;quot;: {&lt;br /&gt;
         &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
         &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
         &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
             &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
         &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
         &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
             &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
             &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
             &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
             &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
             &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
             &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
             &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
             &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
         ]&lt;br /&gt;
     }&lt;br /&gt;
 },&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124955</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124955"/>
				<updated>2018-04-16T11:03:27Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: {},&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
Here you see the root level of the manifest defines the same resource classes as is used to organise the frontend source folder, i.e. these sections define the resources that will be packaged together to be installed into the source folder.&lt;br /&gt;
&lt;br /&gt;
There are also three extra root level keys:&lt;br /&gt;
* frontend - the name of the frontend used in the source path&lt;br /&gt;
* namespace - the namespace of the frontend used in the source path&lt;br /&gt;
* options - various options to be used in the build tooling&lt;br /&gt;
&lt;br /&gt;
The default options are as follows:&lt;br /&gt;
&lt;br /&gt;
    &amp;quot;options&amp;quot;: {&lt;br /&gt;
        &amp;quot;uglify&amp;quot;: {&lt;br /&gt;
            &amp;quot;compress&amp;quot;: false&lt;br /&gt;
        },&lt;br /&gt;
        &amp;quot;sass&amp;quot;: {&lt;br /&gt;
            &amp;quot;outputStyle&amp;quot;: &amp;quot;compressed&amp;quot;,&lt;br /&gt;
            &amp;quot;precision&amp;quot;: 8,&lt;br /&gt;
            &amp;quot;includePaths&amp;quot;: [&lt;br /&gt;
                &amp;quot;node_modules/bootstrap-sass/assets/stylesheets&amp;quot;,&lt;br /&gt;
                &amp;quot;node_modules/summernote/src/less&amp;quot;&lt;br /&gt;
            ]&lt;br /&gt;
        },&lt;br /&gt;
        &amp;quot;sourcemaps&amp;quot;: {&lt;br /&gt;
            &amp;quot;loadMaps&amp;quot;: true&lt;br /&gt;
        },&lt;br /&gt;
        &amp;quot;autoprefixer&amp;quot;: {&lt;br /&gt;
            &amp;quot;browsers&amp;quot;: [&lt;br /&gt;
                &amp;quot;Android 2.3&amp;quot;,&lt;br /&gt;
                &amp;quot;Android &amp;gt;= 4&amp;quot;,&lt;br /&gt;
                &amp;quot;Chrome &amp;gt;= 20&amp;quot;,&lt;br /&gt;
                &amp;quot;Firefox &amp;gt;= 24&amp;quot;,&lt;br /&gt;
                &amp;quot;Explorer &amp;gt;= 8&amp;quot;,&lt;br /&gt;
                &amp;quot;iOS &amp;gt;= 6&amp;quot;,&lt;br /&gt;
                &amp;quot;Opera &amp;gt;= 12&amp;quot;,&lt;br /&gt;
                &amp;quot;Safari &amp;gt;= 6&amp;quot;&lt;br /&gt;
            ]&lt;br /&gt;
        }&lt;br /&gt;
    },&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124954</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124954"/>
				<updated>2018-04-16T10:56:51Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Linking */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: { },&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place.&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124953</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124953"/>
				<updated>2018-04-16T10:47:55Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
 {&lt;br /&gt;
     &amp;quot;frontend&amp;quot;: &amp;quot;ark2&amp;quot;,&lt;br /&gt;
     &amp;quot;namespace&amp;quot;: &amp;quot;ARK&amp;quot;,&lt;br /&gt;
     &amp;quot;options&amp;quot;: {},&lt;br /&gt;
     &amp;quot;assets&amp;quot;: {&lt;br /&gt;
         &amp;quot;fonts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;images&amp;quot;: {},&lt;br /&gt;
         &amp;quot;scripts&amp;quot;: {},&lt;br /&gt;
         &amp;quot;styles&amp;quot;: {}&lt;br /&gt;
     },&lt;br /&gt;
     &amp;quot;bin&amp;quot;: {},&lt;br /&gt;
     &amp;quot;config&amp;quot;: {},&lt;br /&gt;
     &amp;quot;templates&amp;quot;: {},&lt;br /&gt;
     &amp;quot;translations&amp;quot;: { },&lt;br /&gt;
     &amp;quot;public&amp;quot;: {}&lt;br /&gt;
 }&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124952</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124952"/>
				<updated>2018-04-16T10:41:15Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required frontend resources into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The resources built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor resources: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core resources: Standard resources provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom resources: Custom resources developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these resources into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend resources are saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend resources is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Resources from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of resources may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the resources required, an extra step is required to copy just the required resources into the source folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and resources are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing resources&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The resources required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend resources are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of resource to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by resource source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor resources managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core resources provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom resources for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the resources provided are organised in folders by resource source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of resources that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source resource files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build resources for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124951</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124951"/>
				<updated>2018-04-16T10:33:31Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* File Layout */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required assets into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor assets: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core assets: Standard assets provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom assets: Custom assets developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these assets into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor assets managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core assets provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom assets for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the assets provided are organised in folders by asset source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124950</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124950"/>
				<updated>2018-04-16T10:30:40Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Build */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required assets into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor assets: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core assets: Standard assets provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom assets: Custom assets developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these assets into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;frontend1&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend2&amp;gt;/&lt;br /&gt;
     |- &amp;lt;frontend3&amp;gt;/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
* The /node_modules folder holds the vendor assets managed by NPM as defined in the packages.json file&lt;br /&gt;
* The/ core folder holds the core assets provided by ark2&lt;br /&gt;
* The /frontends folder holds the custom assets for the various integrated frontends&lt;br /&gt;
* The /gulpfile.js defines the Gulp build scripts&lt;br /&gt;
* The /build console runs the build scripts&lt;br /&gt;
* The /.jsbeautifyrc and /.jshintrc files define the JavaScript coding standards used in ARK2&lt;br /&gt;
&lt;br /&gt;
Within the /core folder and each custom frontend folder, the assets provided are organised in folders by asset source type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- bin/&lt;br /&gt;
    |- config/&lt;br /&gt;
    |- fonts/&lt;br /&gt;
    |- images/&lt;br /&gt;
    |- js/&lt;br /&gt;
    |- public/&lt;br /&gt;
    |- scss/&lt;br /&gt;
    |- twig/&lt;br /&gt;
    |- xliff/&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124949</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124949"/>
				<updated>2018-04-16T10:16:07Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Build Tooling */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required assets into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor assets: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core assets: Standard assets provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom assets: Custom assets developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these assets into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
* Later, each configured site in the ARK2 install links to the frontend it wishes to use&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source and source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124948</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124948"/>
				<updated>2018-04-16T10:10:54Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Frontend */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and frontend, allowing the frontend to operate completely independently. ARK2 provides a number of standard frontend implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
Two options exist for building frontends:&lt;br /&gt;
* Integrated frontends using the ARK2 PHP API via TWIG templates and Views defined in the config database&lt;br /&gt;
* Standalone frontends using calls to the ARK2 REST API&lt;br /&gt;
&lt;br /&gt;
The integrated frontends that ship with ARK2 are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported frontend libraries. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Standalone frontends could be implemented in any other technologies such as React and Vue.&lt;br /&gt;
&lt;br /&gt;
The integrated frontends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
The integrated frontends require a build process to assemble the required assets into a distributable form. This page documents the process required to do so.&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend can be obtained from three sources:&lt;br /&gt;
* Vendor assets: Third-party libraries from outside ARK2, such as Bootstrap, jQuery, and FontAwesome&lt;br /&gt;
* Core assets: Standard assets provided by ARK2 for interacting with ARK2 features, e.g. common widgets, form layouts, etc&lt;br /&gt;
* Custom assets: Custom assets developed for a particular frontend&lt;br /&gt;
&lt;br /&gt;
The build process uses tooling to combine these assets into a single source package that is able to be distributed.&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Packaged frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source and source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124947</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124947"/>
				<updated>2018-04-16T09:55:10Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124946</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124946"/>
				<updated>2018-04-16T09:43:48Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Manifest */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The frontend assets can be obtained from three sources:&lt;br /&gt;
* Vendor assets: Third-party libraries managed using NPM as installed in the /build/node_packages folder&lt;br /&gt;
* Core assets: Standard assets provided by ARK2, e.g. widgets, tables, etc&lt;br /&gt;
* Custom assets: &lt;br /&gt;
&lt;br /&gt;
The combination of assets that are built into a frontend are defined by the build manifest.json file in the root of each frontend folder, e.g. /build/frontends/ark2/manifest.json.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124945</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124945"/>
				<updated>2018-04-16T09:38:23Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Source */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source code is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend are defined by the build manifest.json file.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124944</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124944"/>
				<updated>2018-04-16T09:37:11Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Build Tooling */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Assets from multiple sources need to be combined into a single package&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend are defined by the build manifest.json file.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124943</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124943"/>
				<updated>2018-04-16T09:35:35Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* Build */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The /build folder is organised by asset source type as follows:&lt;br /&gt;
&lt;br /&gt;
 |- build/&lt;br /&gt;
   |- core/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- public/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- frontends/&lt;br /&gt;
     |- &amp;lt;name&amp;gt;/&lt;br /&gt;
       |- bin/&lt;br /&gt;
       |- config/&lt;br /&gt;
       |- fonts/&lt;br /&gt;
       |- images/&lt;br /&gt;
       |- js/&lt;br /&gt;
       |- less/&lt;br /&gt;
       |- scss/&lt;br /&gt;
       |- twig/&lt;br /&gt;
       |- xliff/&lt;br /&gt;
   |- node_modules/&lt;br /&gt;
   |- .jsbeautifyrc&lt;br /&gt;
   |- .jshintrc&lt;br /&gt;
   |- build&lt;br /&gt;
   |- gulpfile.js&lt;br /&gt;
   |- packages.json&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend are defined by the build manifest.json file.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	<entry>
		<id>https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124942</id>
		<title>ARK2/Frontend</title>
		<link rel="alternate" type="text/html" href="https://ark.lparchaeology.com/wiki/index.php?title=ARK2/Frontend&amp;diff=124942"/>
				<updated>2018-04-16T09:28:42Z</updated>
		
		<summary type="html">&lt;p&gt;John Layt: /* File Layout */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Frontend =&lt;br /&gt;
&lt;br /&gt;
ARK2 has imposed a clear separation between the backend and front-end, allowing the front-end to operate completely independently. ARK2 provides a number of standard front-end implementations, but sites can adapt or implement their own. This also supports multi-tenant mode where a single ARK2 install can be configured to run multiple ARK2 sites using different frontends.&lt;br /&gt;
&lt;br /&gt;
The standard frontends are implemented in [http://getbootstrap.com/ Bootstrap], [https://jquery.com/ jQuery], and [http://twig.sensiolabs.org/ Twig], the most popular and well-supported front-end ui component and template systems. Frontends can be cloned and modified for a specific site, allowing for easier customisation of ARK&amp;#039;s appearance by third party designers. Frontends can also be implemented in other technologies such as React and Vue using the ARK2 API.&lt;br /&gt;
&lt;br /&gt;
The standard front-ends shipped with ARK2 are:&lt;br /&gt;
* admin - A minimal Web Admin front-end for configuring an API-only server&lt;br /&gt;
* ark2 - The default front-end supporting the full ARK2 feature set&lt;br /&gt;
* bootstrap3 - A minimal Bootstrap 3 frontend designed as a base for custom frontends&lt;br /&gt;
* bootstrap4 - A minimal Bootstrap 4 frontend designed as a base for custom frontends&lt;br /&gt;
* flat - A simple, non-js, read-only front-end designed for scraping, e.g. for static archiving or web-bots&lt;br /&gt;
&lt;br /&gt;
== Source ==&lt;br /&gt;
&lt;br /&gt;
Frontend source is saved in the src directory by Namespace and Name:&lt;br /&gt;
&lt;br /&gt;
  src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For example, the main ark2 frontend in the ARK name space is stored in:&lt;br /&gt;
&lt;br /&gt;
  src/ARK/frontend/ark2&lt;br /&gt;
&lt;br /&gt;
Within each frontend source folder, the source is organised by general type:&lt;br /&gt;
&lt;br /&gt;
  |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
    |- assets/&lt;br /&gt;
      |- fonts/&lt;br /&gt;
      |- images/&lt;br /&gt;
      |- scripts/&lt;br /&gt;
      |- styles/&lt;br /&gt;
    |- bin/&lt;br /&gt;
      |- console&lt;br /&gt;
    |- config/&lt;br /&gt;
      |- credentials.json&lt;br /&gt;
      |- database.json&lt;br /&gt;
      |- site.json&lt;br /&gt;
    |- public/&lt;br /&gt;
      |- .htaccess&lt;br /&gt;
      |- index.php&lt;br /&gt;
    |- templates/&lt;br /&gt;
    |- translations/&lt;br /&gt;
&lt;br /&gt;
The following source types generally use the default source and remain unchanged:&lt;br /&gt;
* bin - Any executables used by the frontend, usually just the site console&lt;br /&gt;
* config - The default config files for the frontend, the main site.json file, the database.json file, and the credentials.json file&lt;br /&gt;
* public - The default contents of the public webroot folder, including the index.php file&lt;br /&gt;
&lt;br /&gt;
The following source types are usually modified for a custom frontend and rebuilt using the build tooling when changed:&lt;br /&gt;
* assets - The public assets for the frontend that get included under the public webroot, i.e. fonts, images, scripts and stylesheets&lt;br /&gt;
* templates - The twig templates used to render the html&lt;br /&gt;
* translations - Vendor provided translation files&lt;br /&gt;
&lt;br /&gt;
Customising the scripts and stylesheets requires various tooling which is covered in the next section.&lt;br /&gt;
&lt;br /&gt;
== Build Tooling ==&lt;br /&gt;
&lt;br /&gt;
Build tooling for frontend assets is required for a number of reasons:&lt;br /&gt;
* Bootstrap can be customised most easily by changing variables used in the Sass templates, which then requires a build step to compile them into CSS&lt;br /&gt;
* Production deployment is more efficient if CSS and JS is stripped, merged and minified, while development is easier if a map is generated for the original code&lt;br /&gt;
* Multiple versions and combinations of assets may be required for performance reasons&lt;br /&gt;
* NPM library management downloads the entire package, not just the assets required, an extra step is required to copy just the required assets into the web root folder&lt;br /&gt;
* All the steps required for packaging and release management can be automated, e.g. clean, compile, tag, package, etc&lt;br /&gt;
* The build tooling for the default ARK bootstrap and twig theme can be generalised to allow clients to build and deploy their own customised themes with minimal effort&lt;br /&gt;
&lt;br /&gt;
The build tooling works as follows:&lt;br /&gt;
* All build tooling and source assets are isolated in the /build folder so it can be excluded from any release packages or production deployments&lt;br /&gt;
* Nothing in the /build folder may be depended on by any code outside the /build folder or required for running ARK itself&lt;br /&gt;
* [https://nodejs.org/en/ Node], [https://www.npmjs.com/ npm], [http://gulpjs.com/ Gulp] and Symfony Console are used to run the tooling&lt;br /&gt;
* NPM is used to manage the Node packages used which are installed into /build/node_packages&lt;br /&gt;
* Node packages are used both for the build tools themselves and for vendor libraries providing assets&lt;br /&gt;
* Gulp is used to ensure the build scripts run cross-platform&lt;br /&gt;
* Symfony Console is used to manage and run the build tasks&lt;br /&gt;
* Running tasks will only work inside the /build folder, trying to run outside the build folder will fail&lt;br /&gt;
* The assets required to be built for a frontend are defined in a manifest file&lt;br /&gt;
* The built frontend assets are then installed into the frontend source directory&lt;br /&gt;
&lt;br /&gt;
== Build ==&lt;br /&gt;
&lt;br /&gt;
The front end build is managed by the [[ARK2/Console|Build Console]]. The Build console is in the &amp;#039;build/&amp;#039; folder and is used to build/rebuild/install a front-end if required. To run the console you must be in the build folder:&lt;br /&gt;
&lt;br /&gt;
  cd build&lt;br /&gt;
  ./build&lt;br /&gt;
&lt;br /&gt;
Running the console without a chosen command will show the list of available commands:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
ARK Build Console 1.9.80&lt;br /&gt;
&lt;br /&gt;
Usage:&lt;br /&gt;
  command [options] [arguments]&lt;br /&gt;
&lt;br /&gt;
Options:&lt;br /&gt;
  -h, --help            Display this help message&lt;br /&gt;
  -q, --quiet           Do not output any message&lt;br /&gt;
  -V, --version         Display this application version&lt;br /&gt;
      --ansi            Force ANSI output&lt;br /&gt;
      --no-ansi         Disable ANSI output&lt;br /&gt;
  -n, --no-interaction  Do not ask any interactive question&lt;br /&gt;
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug&lt;br /&gt;
&lt;br /&gt;
Available commands:&lt;br /&gt;
  help                Displays help for a command&lt;br /&gt;
  list                Lists commands&lt;br /&gt;
 cache&lt;br /&gt;
  cache:clear         Clear the system cache&lt;br /&gt;
 database&lt;br /&gt;
  database:reverse    Reverse engineer an existing database as DoctrineXML&lt;br /&gt;
 frontend&lt;br /&gt;
  frontend:all        Build an ARK frontend. (Args: frontend)&lt;br /&gt;
  frontend:assets     Build the frontend assets (Fonts, Images, Scripts, Styles). (Args: frontend)&lt;br /&gt;
  frontend:base       Build the frontend base (Bin, Config, Templates, Translations, Web). (Args: frontend)&lt;br /&gt;
  frontend:create     Create a new ARK frontend (Args: namespace, frontend).&lt;br /&gt;
  frontend:scripts    Build the frontend scripts (JavaScript). (Args: frontend)&lt;br /&gt;
  frontend:styles     Build the frontend styles (CSS and SASS). (Args: frontend)&lt;br /&gt;
  frontend:templates  Build the frontend templates (Twig). (Args: frontend)&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
The first time you need to build/rebuild a frontend, you need to install the required Node packages. You will need to have installed Node and NPM on your system first.&lt;br /&gt;
&lt;br /&gt;
  npm install&lt;br /&gt;
&lt;br /&gt;
To update an existing installation, especially after an ARK upgrade:&lt;br /&gt;
&lt;br /&gt;
  npm update&lt;br /&gt;
&lt;br /&gt;
To check the status of your Node environment (including available updates), run:&lt;br /&gt;
&lt;br /&gt;
  npm doctor&lt;br /&gt;
&lt;br /&gt;
To build a frontend run the frontend command with the name of the frontend:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:all &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This will install the built front end into &amp;#039;src/&amp;lt;namespace&amp;gt;/frontend/&amp;lt;frontend&amp;gt;&amp;#039;.&lt;br /&gt;
&lt;br /&gt;
You can also choose to build just one type of asset to save time, e.g. if you only changed a template and don&amp;#039;t want to wait for the js to be rebuilt as well:&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:styles &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:scripts &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:templates &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:assets &amp;lt;frontend&amp;gt;&lt;br /&gt;
  ./build frontend:base &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Manifest ==&lt;br /&gt;
&lt;br /&gt;
The assets built into a frontend are defined by the build manifest.json file.&lt;br /&gt;
&lt;br /&gt;
== Linking ==&lt;br /&gt;
&lt;br /&gt;
The front-end is built from the source assets files in the &amp;#039;build/&amp;#039; folder and installed in the &amp;#039;src/&amp;#039; folder. The individual site folders then symlink to the required front-end in &amp;#039;src/&amp;#039;, or copy if they wish to edit in place. (See the [[ARK2/Frontend#File Layout|FileLayout]] section below for more on this).&lt;br /&gt;
&lt;br /&gt;
To clone the build assets for a new front end from the Core front-end, run the create command. You must provide a name for your new front end, and the source code Namespace it will use, e.g. ARK, Wibble, or Foo. Only use the ARK namespace if the front end is intended for the main ARK project. This Namespace will be remembered by the system.&lt;br /&gt;
&lt;br /&gt;
  ./build frontend:create &amp;lt;namespace&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To use a front end for a site, run the System Console in the &amp;#039;&amp;lt;install&amp;gt;/bin&amp;#039; folder.&lt;br /&gt;
&lt;br /&gt;
To create an entirely new site, use the create command. This will create a new database, site folder, config and web subfolders, and link/copy the chosen front-end.&lt;br /&gt;
&lt;br /&gt;
  cd ../bin&lt;br /&gt;
  ./sysadmin database:server:add &amp;lt;server&amp;gt;&lt;br /&gt;
  ./sysadmin site:create &amp;lt;site&amp;gt; &amp;lt;frontend=core&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will be asked if you want to link or copy the front-end. It is recommended to use the default link option as you will not need to update the site folder when the front-end changes. Only copy the front-end if you want to make small changes to the front-end without having to build a new namespaced front-end. This however is discouraged, you should build a namespaced front-end instead.&lt;br /&gt;
&lt;br /&gt;
To enable a front-end other than core, you will need to edit the &amp;#039;&amp;lt;site&amp;gt;/config/site.json&amp;#039; file to set the name of the front-end. [TODO: Write a command for this!]&lt;br /&gt;
&lt;br /&gt;
To add another front-end to a site, or to refresh a copied front-end:&lt;br /&gt;
&lt;br /&gt;
  site:frontend &amp;lt;site&amp;gt; &amp;lt;frontend&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== File Layout ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Sites:&lt;br /&gt;
&lt;br /&gt;
 /&lt;br /&gt;
 |- sites/&lt;br /&gt;
   |- &amp;lt;site&amp;gt;/&lt;br /&gt;
     |- config/&lt;br /&gt;
     |- files/&lt;br /&gt;
     |- schema/&lt;br /&gt;
     |- src/&lt;br /&gt;
       |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
         |- php/&lt;br /&gt;
         |- templates/&lt;br /&gt;
         |- translations/&lt;br /&gt;
     |- web/&lt;br /&gt;
       |- .htaccess&lt;br /&gt;
       |- index.php&lt;br /&gt;
       |- assets/&lt;br /&gt;
         |- &amp;lt;frontend&amp;gt;/&lt;br /&gt;
           |- fonts/&lt;br /&gt;
           |- images/&lt;br /&gt;
           |- scripts/&lt;br /&gt;
           |- styles/&lt;br /&gt;
&lt;br /&gt;
== Useful References ==&lt;br /&gt;
&lt;br /&gt;
* http://www.helloerik.com/the-subtle-magic-behind-why-the-bootstrap-3-grid-works&lt;/div&gt;</summary>
		<author><name>John Layt</name></author>	</entry>

	</feed>