-
-Now that you've created the customized form template, you need to tell Symfony
-to use it. Inside the template where you're actually rendering your form,
-tell Symfony to use the theme via the ``setTheme()`` helper method::
-
- setTheme($form, [':form']) ?>
-
- widget($form['age']) ?>
-
-When the ``form.age`` widget is rendered, Symfony will use the customized
-``integer_widget.html.php`` template and the ``input`` tag will be wrapped in
-the ``div`` element.
-
-If you want to apply a theme to a specific child form, pass it to the ``setTheme()``
-method::
-
- setTheme($form['child'], ':form') ?>
-
-.. note::
-
- The ``:form`` syntax is based on the functional names for templates:
- ``Bundle:Directory``. As the form directory lives in the
- ``templates/`` directory, the ``Bundle`` part is empty, resulting
- in ``:form``.
-
-Making Application-wide Customizations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you'd like a certain form customization to be global to your application,
-you can accomplish this by making the form customizations in an external
-template and then importing it inside your application configuration.
-
-By using the following configuration, any customized form fragments inside the
-``templates/form`` folder will be used globally when a
-form is rendered.
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/packages/framework.yaml
- framework:
- templating:
- form:
- resources:
- - 'App:Form'
- # ...
-
- .. code-block:: xml
-
-
-
-
-
-
-
-
- App:Form
-
-
-
-
-
-
- .. code-block:: php
-
- // config/packages/framework.php
- // PHP
- $container->loadFromExtension('framework', [
- 'templating' => [
- 'form' => [
- 'resources' => [
- 'App:Form',
- ],
- ],
- ],
-
- // ...
- ]);
-
-By default, the PHP engine uses a *div* layout when rendering forms. Some people,
-however, may prefer to render forms in a *table* layout. Use the ``FrameworkBundle:FormTable``
-resource to use such a layout:
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/packages/framework.yaml
- framework:
- templating:
- form:
- resources:
- - 'FrameworkBundle:FormTable'
-
- .. code-block:: xml
-
-
-
-
-
-
-
-
- FrameworkBundle:FormTable
-
-
-
-
-
-
- .. code-block:: php
-
- // config/packages/framework.php
- $container->loadFromExtension('framework', [
- 'templating' => [
- 'form' => [
- 'resources' => [
- 'FrameworkBundle:FormTable',
- ],
- ],
- ],
-
- // ...
- ]);
-
-If you only want to make the change in one template, add the following line to
-your template file rather than adding the template as a resource:
-
-.. code-block:: html+php
-
- setTheme($form, ['FrameworkBundle:FormTable']) ?>
-
-Note that the ``$form`` variable in the above code is the form view variable
-that you passed to your template.
-
-Adding a "Required" Asterisk to Field Labels
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you want to denote all of your required fields with a required asterisk
-(``*``), you can do this by customizing the ``form_label`` fragment.
-
-When using PHP as a templating engine you have to copy the content from the
-original template:
-
-.. code-block:: html+php
-
-
-
-
-
-
- humanize($name); } ?>
-
-
-
-
- *
-
-
-Adding "help" Messages
-~~~~~~~~~~~~~~~~~~~~~~
-
-You can also customize your form widgets to have an optional "help" message.
-
-When using PHP as a templating engine you have to copy the content from the
-original template:
-
-.. code-block:: html+php
-
-
-
-
- value="escape($value) ?>"
- block($form, 'widget_attributes') ?>
- />
-
-
-
- escape($help) ?>
-
-
-.. _`@Template`: https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/view
+ Starting from Symfony 5.0, PHP templates are no longer supported. Use
+ :doc:`Twig ` instead to create your templates.
diff --git a/templating/hinclude.rst b/templating/hinclude.rst
index ee5047cc124..7814e0130f6 100644
--- a/templating/hinclude.rst
+++ b/templating/hinclude.rst
@@ -97,12 +97,6 @@ in your application configuration:
],
]);
-.. versionadded:: 4.3
-
- The ``framework.fragments.hinclude_default_template`` option was introduced
- in Symfony 4.3. In previous Symfony versions it was called
- ``framework.templating.hinclude_default_template``.
-
You can define default templates per ``render()`` function (which will override
any global default template that is defined):
diff --git a/testing.rst b/testing.rst
index 3163d57721a..d79871c4432 100644
--- a/testing.rst
+++ b/testing.rst
@@ -215,10 +215,6 @@ its existence, attributes, text, etc.
The ``assertSelectorTextContains`` method is not a native PHPUnit assertion and is
available thanks to the ``WebTestCase`` class.
-.. versionadded:: 4.3
-
- The ``WebTestCase`` assertions were introduced in Symfony 4.3
-
.. seealso::
Using native PHPUnit methods, the same assertion would look like this::
diff --git a/testing/functional_tests_assertions.rst b/testing/functional_tests_assertions.rst
index 63482dd046b..812b35ef94f 100644
--- a/testing/functional_tests_assertions.rst
+++ b/testing/functional_tests_assertions.rst
@@ -4,11 +4,6 @@
Functional Test specific Assertions
===================================
-.. versionadded:: 4.3
-
- The shortcut methods for assertions using ``WebTestCase`` were introduced
- in Symfony 4.3.
-
When doing functional tests, sometimes you need to make complex assertions in
order to check whether the ``Request``, the ``Response`` or the ``Crawler``
contain the expected information to make your test succeed.
diff --git a/translation.rst b/translation.rst
index 343f0233bab..d3a33ffc5c9 100644
--- a/translation.rst
+++ b/translation.rst
@@ -256,11 +256,6 @@ The ``translation:update`` command looks for missing translations in:
* Any PHP file/class that injects or :doc:`autowires `
the ``translator`` service and makes calls to the ``trans()`` function.
-.. versionadded:: 4.3
-
- The extraction of missing translation strings from PHP files was introduced
- in Symfony 4.3.
-
.. note::
If you want to see the missing translation strings without actually updating
@@ -273,18 +268,11 @@ Translation Resource/File Names and Locations
Symfony looks for message files (i.e. translations) in the following default locations:
-#. the ``translations/`` directory (at the root of the project);
-#. the ``src/Resources//translations/`` directory;
-#. the ``Resources/translations/`` directory inside of any bundle.
-
-.. deprecated:: 4.2
-
- Using the ``src/Resources//translations/`` directory to store
- translations was deprecated in Symfony 4.2. Use instead the directory
- defined in the ``default_path`` option (which is ``translations/`` by default).
+* the ``translations/`` directory (at the root of the project);
+* the ``Resources/translations/`` directory inside of any bundle.
The locations are listed here with the highest priority first. That is, you can
-override the translation messages of a bundle in any of the top two directories.
+override the translation messages of a bundle in the first directory.
The override mechanism works at a key level: only the overridden keys need
to be listed in a higher priority message file. When a key is not found
diff --git a/workflow.rst b/workflow.rst
index e2a542c8683..37017b6ba66 100644
--- a/workflow.rst
+++ b/workflow.rst
@@ -318,7 +318,7 @@ workflow leaves a place::
class WorkflowLogger implements EventSubscriberInterface
{
private $logger;
-
+
public function __construct(LoggerInterface $logger)
{
$this->logger = $logger;
@@ -502,10 +502,6 @@ place::
}
}
-.. versionadded:: 4.1
-
- The transition blockers were introduced in Symfony 4.1.
-
Usage in Twig
-------------
@@ -559,10 +555,6 @@ The following example shows these functions in action:
Storing Metadata
----------------
-.. versionadded:: 4.1
-
- The feature to store metadata in workflows was introduced in Symfony 4.1.
-
In case you need it, you can store arbitrary metadata in workflows, their
places, and their transitions using the ``metadata`` option. This metadata can
be as simple as the title of the workflow or as complex as your own application
-
-The ``assets`` helper's main purpose is to make your application more
-portable. Thanks to this helper, you can move the application root directory
-anywhere under your web root directory without changing anything in your
-template's code.
-
-Profiling Templates
-~~~~~~~~~~~~~~~~~~~
-
-By using the ``stopwatch`` helper, you are able to time parts of your template
-and display it on the timeline of the WebProfilerBundle::
-
- start('foo') ?>
- ... things that get timed
- stop('foo') ?>
-
-.. tip::
-
- If you use the same name more than once in your template, the times are
- grouped on the same line in the timeline.
-
-Output Escaping
----------------
-
-When using PHP templates, escape variables whenever they are displayed to the
-user::
-
- escape($var) ?>
-
-By default, the ``escape()`` method assumes that the variable is outputted
-within an HTML context. The second argument lets you change the context. For
-instance, to output something in a JavaScript script, use the ``js`` context::
-
- escape($var, 'js') ?>
-
-Form Theming in PHP
--------------------
-
-When using PHP as a templating engine, the only method to customize a fragment
-is to create a new template file - this is similar to the second method used by
-Twig.
-
-The template file must be named after the fragment. You must create a ``integer_widget.html.php``
-file in order to customize the ``integer_widget`` fragment.
-
-.. code-block:: html+php
-
-
-
-
-Now that you've created the customized form template, you need to tell Symfony
-to use it. Inside the template where you're actually rendering your form,
-tell Symfony to use the theme via the ``setTheme()`` helper method::
-
- setTheme($form, [':form']) ?>
-
- widget($form['age']) ?>
-
-When the ``form.age`` widget is rendered, Symfony will use the customized
-``integer_widget.html.php`` template and the ``input`` tag will be wrapped in
-the ``div`` element.
-
-If you want to apply a theme to a specific child form, pass it to the ``setTheme()``
-method::
-
- setTheme($form['child'], ':form') ?>
-
-.. note::
-
- The ``:form`` syntax is based on the functional names for templates:
- ``Bundle:Directory``. As the form directory lives in the
- ``templates/`` directory, the ``Bundle`` part is empty, resulting
- in ``:form``.
-
-Making Application-wide Customizations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you'd like a certain form customization to be global to your application,
-you can accomplish this by making the form customizations in an external
-template and then importing it inside your application configuration.
-
-By using the following configuration, any customized form fragments inside the
-``templates/form`` folder will be used globally when a
-form is rendered.
-
-.. configuration-block::
-
- .. code-block:: yaml
-
- # config/packages/framework.yaml
- framework:
- templating:
- form:
- resources:
- - 'App:Form'
- # ...
-
- .. code-block:: xml
-
-
-
-