XalokNext Documentation

Appearance

Configuration ​

Redis ​

  • wf_cms.redis_key_prefix

In order to be able to hold multiple instances of the CMS on the same computer (dev mode, for example), all the redis keys are prefixed with %wf_cms.redis_key_prefix% parameter (defined in app/config/parameters/project.yml)

Tracking ​

  • wf_tracking.nodejs.host The host that the nodejs server should bind (default 127.0.0.1)
  • wf_tracking.nodejs.port The port on which the nodejs server should listen. In a common setup the tracker server runs on the same server as the middle, which already binds port 80, default 8080. The frontend (Varnish) is setup to forward requests that start with /track to this backend
    if (req.url ~ "^/track/") {
        set req.backend = track;
        return (pipe);
    }
  • wf_tracking.redis.host
  • wf_tracking.redis.port The host and port of Redis where keys should be stored.
  • wf_cms.redis_key_prefix Same as in the Redis section above

Locking editor ​

The CMS can warn a user if another user (or same user but using a different browser tab) has an editor open for the current version article/board. Configuring this is controlled through the following parameters:

  • lock_host the public host that the user's browser will connect to
  • lock_port the public port that the user's browser will connect to
  • lock_binding_port (optional) the port to which the server will bind. By default, it uses the same value as lock_port, but you can add this parameter if you want the server to bind on one port (e.g.: 8080) and then setup proxying in front of that server, so the public port would be 80.

To start the locking server:

./app/admin/console wf:cms:nodejs:start

Customize locking UI ​

To see the lock owner user when other try to edit a locked content and place the buttons to enable request unlock and accept or deny, you can edit the translation keys:

xml
<trans-unit id="571" approved="yes">
    <source><![CDATA[wfed.editor.claim_lock_emited]]></source>
    <target><![CDATA[Se ha solicitado el contenido al usuario "<%-username%>". Espere.]]></target>
</trans-unit>
<trans-unit id="575" approved="yes">
    <source><![CDATA[wfed.editor.lock_status]]></source>
    <target><![CDATA[<p>Recurso bloqueado por "<%-username%>"</p>]]></target>
</trans-unit>
<trans-unit id="576" approved="yes">
    <source><![CDATA[wfed.editor.lock_status_claim]]></source>
    <target><![CDATA[<p>Recurso bloqueado por "<%-username%>"</p><%=claim%>]]></target>
</trans-unit>
<trans-unit id="577" approved="yes">
    <source><![CDATA[wfed.editor.lock_claim]]></source>
    <target><![CDATA[Reclamar edición del contenido]]></target>
</trans-unit>
<trans-unit id="644" approved="yes">
    <source><![CDATA[wfed.page_edit_error.claim_options]]></source>
    <target><![CDATA[<p>El usuario "<%-username%>" reclama el recurso ¿concederlo?</p><p><%=accept%>&nbsp;<%=deny%></p>]]></target>
</trans-unit>

Claiming locked articles ​

In the translation above see the usage of <%=claim%>. This is used when an editor opens a locked article - it will display a link with the text wfed.editor.lock_claim (see example translation above), when clicking the link, a message will appear on the owner of the lock saying wfed.page_edit_error.claim_options (see example translation above). With this message, the owner of the lock has the option to accept or deny the lock claim request. They have 5 minutes (ovewritable in wfed/view/page_edit_form::isConsideredInactiveAfter) to respond, if this times out, the claim will be automatically accepted - that is, the user claiming the lock will be granted access to edit the article.

Note: Prior to v7.3, this feature works only for articles, the wfed.editor.lock_status translation that is used for boards cannot accept the <%=claim%> placeholder (it throws an error if it's used).

v7.3+ Claiming locked boards ​

Starting with v7.3+ , the same claiming is also available in boards and the same options will be shown when a user try to edit a board and another one is already editing.

The second user will see an option to claim the edition and the current editing user will see an option to accept or reject the claim.
On accept, the board will be closed for the current user and will be reloaded for the claiming user. The claiming user then will take control of the board on its last version.

So, for v7.3+, the wfed.editor.lock_status translation key should include the <%=claim%> placeholder:

xml
<trans-unit id="575" approved="yes">
    <source><![CDATA[wfed.editor.lock_status]]></source>
    <target><![CDATA[<p>Recurso bloqueado por "<%-username%>"</p><%=claim%>]]></target>
</trans-unit>

Force unlock ​

If a user let their browser in a locked content other users cannot modify the content (i.e. the board group button is disabled to add new boards), in /admin/editor_lock/ you can watch and unlock the current locks.

NOTE is supposed the active lock list is not too big (i.e. a bunch of thousands, no more).

Installation specific configuration ​

php.ini ​

There are some settings that you should pay attention to in php.ini:

  • date.timezone = America/Jamaica - set this to your local timezone (there's a list of available timezones here: http://php.net/manual/en/timezones.america.php) - php throws a warning if this is not set.
  • upload_max_filesize = 200M and post_max_size = 200M - allow uploading larger files
  • memory_limit = 2G - on backend the memory limit should be increased to allow (among others) processing larger images.
  • max_input_vars = 10000 - on backend, increase the number of variables that PHP allows in GET/POST objects. The default value of 1000 can prove to be small for boards where there is a large number of modules.

Webserver entry point ​

Each of the apps (backend and frontend) has a pair of front controllers (entry points). Thus, we have web/app_admin.php, web/app_admin_dev.php, web/app_public.php, web/app_public_dev.php . The "..._dev.php" should be included (pointed at in the webserver config) in a DEV environment, where the developer makes changes often. These files run the Symfony2 app with DEV settings, which has a few advantages:

  • The developer doesn't have to manually clear the cache after each change to the source files, Symfony2 automatically refreshes the cache for the changed files
  • The Symfony2 developer toolbar is added to the pages for extra information on the current page.

Application configuration ​

Each of these files includes a main configuration file.

web/app_admin.php includes app/admin/config/config_prod.yml
web/app_admin_dev.php includes app/admin/config/config_dev.yml
web/app_public.php includes app/public/config/config_prod.yml
web/app_public_dev.php includes app/public/config/config_dev.yml

All the above files include the parameters file app/config/parameters/local.yml

These files are ignored by the git repository, so they can be used to overwrite any configuration of the project with details specific only to the current installation, like the database connection parameters or the address of the ElasticSearch or Redis server.

assets_base_urls ​

To output absolute paths from the {{ asset }} twig function, you should add:

yaml
framework:
    templating:
        assets_base_urls: %wf_cms.admin.publicUrl%
trusted_proxies ​

On middles, you must configure framework:trusted_proxies to the IPs of the Varnish servers and the IP of the loadbalancer:

yaml
framework:
    trusted_proxies: [192.168.0.2,192.168.0.3]

This setting is needed:

  • to make sure $request->getClientIp() returns the actual user's IP and not the IP of the Varnish server or that of the load balancer - in case the project's code relies on the getClientIp method
  • for ESI routes generated using {{ render(controller(...)) }}. For these routes, Symfony generates an internal URL (/_fragment/__DETAILS_OF_THE_CONTROLLER_ACTION__), and then checks to make sure the request comes from the Varnish server - throwing 403 - Forbidden if a public client tries to access it. If the trusted_proxies are not configured correctly, it would throw 403 for Varnish requests also (without knowing the IPs of Varnish, all requests look like coming from the outside world)

local.yml and local.yml.dist ​

When running composer install on a deploy, composer runs a script that checks that all the parameters defined in local.yml.dist are also defined in local.yml, prompting the user to enter the value for these parameters. Therefore, if a parameter is required by the app, but the value most likely differs for each environment, the key should be added to local.yml.dist file, with a sensible default. The rule of thumb is to use as default value the values needed by the developers to run the project.

.make-config ​

Another file that is ignored by the git is .make-config. This file is included by the main Makefile, and can be used to overwrite default values and/or tasks used by the make command. The most common overwrites are:

  • ADMIN_SF_ENV and PUBLIC_SF_ENV - both default to dev. These are used as part of the make tasks that call Symfony2 console, to pass the correct enviroment. In production should be set to prod
  • ADMIN_HOST (default admin-wfcms.lo) and PUBLIC_HOST (default wfcms.lo). The web app deducts the values from the current running environment (http host), but there are some make tasks that need to contact the webserver where the application responds and use these variables.

Another common/suggested task for installations is to use the .make-config file to define a deploy task that should be ran after deploying a new version of the app. An example of such task would be:

deploy:
    touch app/admin/version
    touch app/public/version
    make clean
    composer --optimize dumpautoload
    make compass_compile_admin_prod
    make wf_assets
    make assetic-dump

The modfication time of app/admin/version and app/public/version files are used as a convenience by the Assetic bundle to add a hash after the assets (<link rel="stylesheet" href="/css/screen.css?__VERSION__" />)