Merge branch 'release/v1.4.0'

Makefile

@@ -66,7 +66,7 @@ singlehtml:
 	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
 
 livehtml:
-	sphinx-autobuild -B --ignore "*/.git/*" --ignore "*/roadiz_rtd_theme/*" --ignore "*.pickle" --ignore "*.doctree" --ignore "*HEAD" --ignore "*FETCH_HEAD" -b html $(ALLSPHINXOPTS) ${SOURCEDIR} $(BUILDDIR)/html
+	sphinx-autobuild -B --ignore "*/$(BUILDDIR)/*" --ignore "*/.git/*" --ignore "*/roadiz_rtd_theme/*" --ignore "*.pickle" --ignore "*.doctree" --ignore "*HEAD" --ignore "*FETCH_HEAD" -b html $(ALLSPHINXOPTS) ${SOURCEDIR} $(BUILDDIR)/html
 
 pickle:
 	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle

conf.py

@@ -76,7 +76,6 @@
     'sphinx.ext.viewcode',
     'sphinx.ext.ifconfig',
     'pygments_markdown_lexer'
-
 ]
 
 # Add any paths that contain templates here, relative to this directory.
@@ -106,9 +105,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = '1.3.1'
+version = '1.4.0'
 # The full version, including alpha/beta/rc tags.
-release = '1.3.1'
+release = '1.4.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
@@ -125,7 +124,7 @@
 
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
-exclude_patterns = [u'_build', u'_themes']
+exclude_patterns = [u'_build', u'_themes', u'README.md']
 
 # The reST default role (used for this markup: `text`) to use for all
 # documents.
@@ -411,6 +410,5 @@ def setup(app):
     app.add_config_value('recommonmark_config', {
         'auto_toc_tree_section': 'Contents',
         'enable_eval_rst': True,
-        'enable_auto_doc_ref': True,
     }, True)
     app.add_transform(AutoStructify)

developer/attributes/index.rst

@@ -15,7 +15,7 @@ The attribute "Color" can be set to "red" for one node and set to "green" for an
 Okay, but now what is the difference between *attributes* and node-type fields? Not so much
 because node-type fields describe your node' features too, but they are fixed and defined by
 the developer. Once your node-type fields are created, you have to implement your feature in
-your *Twig* templates, and tranlate it in your XLF files too.
+your *Twig* templates, and translate it in your XLF files too.
 
 Attributes are meant to be created and added by editors so they can use them in your website lifecycle
 without needing any further development.
@@ -29,6 +29,11 @@ without any additional development.
     <ul class="block-attributes">
         {% for attributeValueTranslation in nodeSource|attributes %}
             <li>
+                {% if attributeValueTranslation.attribute.documents|length %}
+                    {% for document in attributeValueTranslation.attribute.documents %}
+                        <figure>{{ document|display }}</figure>
+                    {% endfor %}
+                {% endif %}
                 <strong>{{ attributeValueTranslation|attribute_label(translation) }}:</strong>
                 {% if attributeValueTranslation is datetime %}
                     {{ attributeValueTranslation.value|localizeddate('medium', 'short') }}
@@ -43,6 +48,42 @@ without any additional development.
         {% endfor %}
     </ul>
 
+If you grouped your attributes, you can use ``grouped_attributes`` filter instead:
+
+.. code-block:: html+jinja
+
+    <ul class="block-attributes">
+        {% for item in nodeSource|grouped_attributes %}
+            <li>
+                {% if item.group %}
+                    <strong>{{ item.group|attribute_group_label(translation) }}</strong>
+                {% endif %}
+                <ul>
+                    {% for attributeValueTranslation in item.attributeValues %}
+                        <li>
+                            {% if attributeValueTranslation.attribute.documents|length %}
+                                {% for document in attributeValueTranslation.attribute.documents %}
+                                    <figure>{{ document|display }}</figure>
+                                {% endfor %}
+                            {% endif %}
+                            <strong>{{ attributeValueTranslation|attribute_label(translation) }}:</strong>
+                            {% if attributeValueTranslation is datetime %}
+                                {{ attributeValueTranslation.value|localizeddate('medium', 'short') }}
+                            {% elseif attributeValueTranslation is date %}
+                                {{ attributeValueTranslation.value|localizeddate('medium') }}
+                            {% elseif attributeValueTranslation is country %}
+                                {{ attributeValueTranslation.value|country_iso(request.locale) }}
+                            {% else %}
+                                {{ attributeValueTranslation.value }}
+                            {% endif%}
+                        </li>
+                    {% endfor %}
+                </ul>
+
+            </li>
+        {% endfor %}
+    </ul>
+
 Attributes types
 ^^^^^^^^^^^^^^^^
 
@@ -77,7 +118,9 @@ Filters
 -------
 
 - ``attributes``: same as ``node_source_attributes()`` method, get all available attributes from a ``NodesSources``.
-- ``attribute_label``: get attribute translated ``label`` or ``code`` if not translated.
+- ``grouped_attributes``: same as ``node_source_grouped_attributes()`` method, get all available attributes from a ``NodesSources`` and gather them into their **group**.
+- ``attribute_label(translation)``: get attribute translated ``label`` or ``code`` if not translated.
+- ``attribute_group_label(translation)``: get attribute group translated ``name`` or ``canonicalName`` if not translated.
 
 Tests
 -----

developer/contributing.rst

@@ -31,7 +31,7 @@ Unit-tests can be launched by the following command:
 
 .. code-block:: console
 
-    bin/phpunit -v --bootstrap=tests/bootstrap.php tests/
+    php bin/phpunit -v --bootstrap=tests/bootstrap.php --whitelist ./src tests/
 
 If your are writing a feature, don't forget to write a unit test for it. You can find some example in the folder ``tests``.
 In Roadiz, there are 4 types of tests:
@@ -53,21 +53,26 @@ You can copy and paste the following command-lines to check easily:
 
 .. code-block:: console
 
-    bin/phpcs --report=full --report-file=./report.txt \
-                --extensions=php --warning-severity=0 \
-                --standard=PSR2 \
-                --ignore="*/node_modules/*,*/.AppleDouble,*/vendor/*,*/cache/*,*/gen-src/*,*/tests/*,*/bin/*" \
-                -p ./
+    php bin/phpcs --report=full --report-file=./report.txt -p ./
 
 Or you can use *phpcbf* to automatically fix code style issues.
 
 .. code-block:: console
 
-    bin/phpcbf --report=full --report-file=./report.txt \
-                --extensions=php --warning-severity=0 \
-                --standard=PSR2 \
-                --ignore="*/node_modules/*,*/.AppleDouble,*/vendor/*,*/cache/*,*/gen-src/*,*/tests/*,*/bin/*" \
-                -p ./
+    php bin/phpcbf --report=full --report-file=./report.txt -p ./
 
 Please take those rules into account, we aim to have a clean codebase. A coherent codestyle will contribute to Roadiz stability.
 Your code will be checked when we will be considering your pull requests.
+
+Static analysis
+---------------
+
+Then we use ``phpstan`` as a static code analyzer to check bugs and misuses before they occur:
+
+.. code-block:: console
+
+    php bin/phpstan analyse -c phpstan.neon -l 1 src themes/Rozier themes/Install
+
+.. topic:: Standard Edition
+
+    Roadiz *Standard Edition* comes with a ``Makefile`` to make it easier to test your sources and your theme. Just execute ``make test`` and ``phpcbf`` and ``phpstan`` will test your theme sources. If you are using *Gitlab CI/CD* with our ``.gitlab-ci.yml`` file, those tests will be executed at each pipeline trigger.

developer/first-steps/docker.rst

@@ -39,7 +39,7 @@ reflect your local user **UID** during image build.
 
 So use the same uid in your `.env` file **before** starting and building your Docker image.
 
-.. code-block:: dotenv
+.. code-block:: bash
 
     USER_UID=1000
 

developer/first-steps/index.rst

@@ -9,7 +9,7 @@ First steps
    installation
    docker
    vagrant
-   php_server
+   php_server.md
    manual_config
    upgrading
    moving

developer/first-steps/manual_config.rst

@@ -250,8 +250,8 @@ use for the on-the-fly image processing with `Intervention Request <https://gith
         # List additionnal Intervention Request subscribers
         subcribers: []
 
-Additionnal *Intervention Request* subscribers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Additional *Intervention Request* subscribers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Any *Intervention Request* subscriber can be added to configuration with its ``classname``
 and its constructor arguments. Here is an example with ``WatermarkListener`` which will

developer/first-steps/moving.rst

@@ -13,8 +13,7 @@ Moving to a SSH+Git hosting plan or an other development machine
 
 From this point you can install your new web-server, as described in :ref:`Install section <installation>`.
 Pay attention that if your theme needs some additional *composer* dependencies you should
-*clone/copy* it into your *themes/* folder **before** running ``composer install --no-dev``. That way
-*composer* will download theme libraries at the same time as Roadiz’ ones (:ref:`See how to use Composer in your themes <theme_composer>`).
+*clone/copy* it into your *themes/* folder **before** running ``composer install --no-dev``.
 
 Then import your dump and files into your new server.
 
@@ -39,6 +38,8 @@ Now you can perform a schema update without losing your nodes data:
     bin/roadiz orm:schema-tool:update --force;
     bin/roadiz cache:clear -e prod
     bin/roadiz cache:clear -e prod --preview
+    bin/roadiz cache:clear-fpm -e prod
+    bin/roadiz cache:clear-fpm -e prod --preview
 
 .. note::
     If you are using an OPcode cache like XCache or APC, you’ll need to purge cache manually
@@ -92,28 +93,28 @@ Moving to a non-SSH hosting plan
 --------------------------------
 
 You have nearly finished your brand new website using Roadiz. You have been working on your own
-server using Git and Composer, up to this point everthing went well.
+server using Git and Composer, up to this point everything went well.
 
 Now you have to push to production, but your prod-server has no SSH connection. You are stuck with
 an SFTP connection or worst, an old FTP one. Don’t panic, it will take a little more time but it is still possible.
 
 .. warning::
-    Many shared-plan hosters offer you only one or two databases. When moving a Roadiz website, make sure
+    Many shared-plan hosting companies offer you only one or two databases. When moving a Roadiz website, make sure
     that your database is empty and do not contain orphan tables, you must respect the rule “One app = One database”.
 
 .. note::
     If you can ZIP on your production server or if you are going to push your files via FTP,
     do not forget to exclude ``.git`` and ``node_modules`` folders! These folders have **lots** of useless files
-    for a production SSH-less environnement.
+    for a production SSH-less environment.
     Here is a sample ZIP command to exclude them:
     ``zip -r mywebsite.zip mywebsite/ -x "mywebsite/.git/*" "mywebsite/themes/**/static/node_modules/*"``.
 
-* Before transfering your website, make sure you have ``.htaccess`` file in every sensitive folders. You can use the ``bin/roadiz generate:htaccess`` on your computer.
+* Before transferring your website, make sure you have ``.htaccess`` file in every sensitive folders. You can use the ``bin/roadiz generate:htaccess`` on your computer.
 * If you have at least SFTP, you should have to rights to zip/unzip on your distant server. So zip the whole Roadiz folder.
 * If you only have FTP, you must be prepared to transfer your Roadiz folder, file-by-file. Just get yourself a nice cup of coffee.
 * Once everything is copied on your production server, verify than you have the same files as on your dev-server.
 * Import your database dump with phpmyadmin or pgmyadmin.
 * Edit your ``conf/config.yml`` to match your new database credentials.
-* Verify that root ``.htaccess`` file contains every informations to enable Apache url-rewriting.
+* Verify that root ``.htaccess`` file contains every information to enable Apache url-rewriting.
 * Try to connect to your website
-* If it doesn’t work or display anything, read your PHP log file to understand where the problem comes from. It might be your database credentials or an oudated PHP version. Check that your hoster has installed every needed PHP extensions, see :ref:`requirements`.
+* If it doesn’t work or display anything, read your PHP log file to understand where the problem comes from. It might be your database credentials or an outdated PHP version. Check that your hosting manager has installed every needed PHP extensions, see :ref:`getting-started`.