velocity.ini [DeploySettings]
The block [DeploySettings] of settings/velocity.ini, with 4 setting(s).
Never edit settings/velocity.ini itself: an update replaces it. Put the settings you change in an override, which wins over the shipped file:
settings/override/velocity.ini.append.phpfor every siteaccess,settings/siteaccess/<siteaccess>/velocity.ini.append.phpfor one siteaccess,extension/<extension>/settings/velocity.ini.append.phpin an extension (read when the extension is active).
PhpFpmService
exp:velocity deploy: everything a PHP code change needs, in order.
The PHP-FPM service it reloads, so the web server in front of this
installation (Apache, nginx) runs the new code too:auto find it: the FPM pool named after this installation's hosting
domain (/var/www/vhosts/<domain>/..., as Plesk names pools), or
one whose configuration names this installation's directory.
Looked for in /opt/plesk/php/*/etc/php-fpm.d (Plesk, service
plesk-php<XY>-fpm), /etc/php-fpm.d (php-fpm), /etc/php/*/fpm/pool.d
(php<X.Y>-fpm) and /etc/opt/remi/php*/php-fpm.d (php<XY>-php-fpm).
disabled reload nothing; for an installation served by Velocity alone.
<unit> that systemd service, or several, comma-separated.It is a reload (systemctl reload): the master re-reads its code and replaces
its workers as each finishes, so no request is dropped. Needs root; run as
anyone else, the step is skipped with a note naming the service.
Default: auto.
# settings/override/velocity.ini.append.php
[DeploySettings]
PhpFpmService=auto
*/ ?>PhpFpmReload
Whether that reload is done at all:
auto only when needed. When the pool's OPcache revalidates the files
(opcache.validate_timestamps on, revalidate_freq at most 60 s,
read from the php-fpm binary and the pool file), every changed
PHP file is recompiled within revalidate_freq seconds; the step
waits that long instead of reloading. Without OPcache it waits
for nothing.
always reload every time (as before).
never neither reload nor wait.A reload is not free, and not for this site alone: the master asks every
child of every pool to finish its request and starts no new child until the
last one has (up to process_control_timeout, 300 s on Plesk). Each request
that arrives in between waits for the longest one running on any site of
that PHP version: one open 25 s event stream made the next page wait 22 s,
and a long request elsewhere turned waiting requests into 504s (#374).
deploy --fpm-reload forces a reload: after a php.ini or pool change, a new
PHP extension, or PHP files removed or renamed in place.
Default: auto.
# settings/override/velocity.ini.append.php
[DeploySettings]
PhpFpmReload=auto
*/ ?>WarmUpURL
Pages requested once each, one after the other, by a background process at
the end of a deploy, so the first visitor does not wait while the templates
are compiled and the INI, override, translation, design and packed-file
caches are rebuilt (and several first visitors do not rebuild them at the
same time). Anonymous requests: a site's front page, an admin's login page.
The deploy does not wait for them. Empty: no warm-up.WarmUpURL[]=https://www.example.com/
WarmUpURL[]=https://www.example.com/admin/user/login
Default: an empty list.
# settings/override/velocity.ini.append.php
[DeploySettings]
# an empty "WarmUpURL[]" first replaces the shipped list; without it the items are added
WarmUpURL[]
*/ ?>Migrate
Whether a deploy runs the pending migrations (./console exp:migration:migrate
--apply, with its captions, record, commit and push), after the caches of
settings and templates and before PHP-FPM and Velocity run the new code. A
migration that fails stops the deploy there. enabled: every deploy;
disabled: only deploy --migrate. deploy --no-migrate skips them either way.
Default: disabled.
# settings/override/velocity.ini.append.php
[DeploySettings]
Migrate=disabled
*/ ?>Related
Generated by ./console exp:help:examples from settings/velocity.ini. Do not edit this page: change the source and generate again (how). Free documentation: GFDL 1.3 or later.