1
1
Documentation Format
2
2
====================
3
3
4
- The Symfony documentation uses `reStructuredText `_ as its markup language and
5
- `Sphinx `_ for building the output (HTML, PDF, ...).
4
+ The Symfony documentation uses reStructuredText _ as its markup language and
5
+ Sphinx _ for generating the documentation in the formats read by the end users,
6
+ such as HTML and PDF.
6
7
7
8
reStructuredText
8
9
----------------
9
10
10
- reStructuredText *"is an easy-to-read, what-you-see-is-what-you-get plaintext
11
- markup syntax and parser system" *.
11
+ reStructuredText is a plaintext markup syntax similar to Markdown, but much
12
+ stricter with its syntax. If you are new to reStructuredText, take some time to
13
+ familiarize with this format by reading the existing `Symfony documentation `_
12
14
13
- You can learn more about its syntax by reading existing Symfony ` documents `_
14
- or by reading the `reStructuredText Primer `_ on the Sphinx website .
15
+ If you want to learn more about this format, check out the ` reStructuredText Primer `_
16
+ tutorial and the `reStructuredText Reference `_ .
15
17
16
18
.. caution ::
17
19
@@ -24,14 +26,14 @@ or by reading the `reStructuredText Primer`_ on the Sphinx website.
24
26
Sphinx
25
27
------
26
28
27
- Sphinx is a build system that adds some nice tools to create documentation
28
- from reStructuredText documents. As such, it adds new directives and
29
- interpreted text roles to the standard reST ` markup `_.
29
+ Sphinx is a build system that provides tools to create documentation from
30
+ reStructuredText documents. As such, it adds new directives and interpreted text
31
+ roles to the standard reST markup. Read more about the ` Sphinx Markup Constructs `_.
30
32
31
33
Syntax Highlighting
32
34
~~~~~~~~~~~~~~~~~~~
33
35
34
- All code examples uses PHP as the default highlighted language . You can change
36
+ PHP is the default syntax highlight applied to all code blocks . You can change
35
37
it with the ``code-block `` directive:
36
38
37
39
.. code-block :: rst
@@ -41,7 +43,7 @@ it with the ``code-block`` directive:
41
43
{ foo: bar, bar: { foo: bar, bar: baz } }
42
44
43
45
If your PHP code begins with ``<?php ``, then you need to use ``html+php `` as
44
- the highlighted pseudo-language :
46
+ the name of the highlighted syntax :
45
47
46
48
.. code-block :: rst
47
49
@@ -51,16 +53,18 @@ the highlighted pseudo-language:
51
53
52
54
.. note ::
53
55
54
- A list of supported languages is available on the `Pygments website `_.
56
+ Besides all of the major programming languages, the syntax highlighter
57
+ supports all kinds of markup and configuration languages. Check out the
58
+ list of `supported languages `_ on the syntax highlighter website.
55
59
56
60
.. _docs-configuration-blocks :
57
61
58
62
Configuration Blocks
59
63
~~~~~~~~~~~~~~~~~~~~
60
64
61
- Whenever you show a configuration, you must use the ``configuration-block ``
65
+ Whenever you include a configuration sample, use the ``configuration-block ``
62
66
directive to show the configuration in all supported configuration formats
63
- (``PHP ``, ``YAML ``, and ``XML ``)
67
+ (``PHP ``, ``YAML `` and ``XML ``). Example:
64
68
65
69
.. code-block :: rst
66
70
@@ -96,32 +100,31 @@ The previous reST snippet renders as follow:
96
100
97
101
The current list of supported formats are the following:
98
102
99
- =============== ==============
100
- Markup format Displayed
101
- =============== ==============
102
- html HTML
103
- xml XML
104
- php PHP
105
- yaml YAML
106
- jinja Twig
107
- html+jinja Twig
108
- html+php PHP
109
- ini INI
110
- php-annotations Annotations
111
- php-standalone Standalone Use
112
- php-symfony Framework Use
113
- =============== ==============
103
+ =================== ======================================
104
+ Markup format Use it to display
105
+ =================== ======================================
106
+ ``html `` HTML
107
+ ``xml `` XML
108
+ ``php `` PHP
109
+ ``yaml `` YAML
110
+ ``jinja `` Pure Twig markup
111
+ ``html+jinja `` Twig markup blended with HTML
112
+ ``html+php `` PHP code blended with HTML
113
+ ``ini `` INI
114
+ ``php-annotations `` PHP Annotations
115
+ =================== ======================================
114
116
115
117
Adding Links
116
118
~~~~~~~~~~~~
117
119
118
- To add links to other pages in the documents use the following syntax:
120
+ The most common type of links are **internal links ** to other documentation pages,
121
+ which use the following syntax:
119
122
120
123
.. code-block :: rst
121
124
122
- :doc:`/path/to/page`
125
+ :doc:`/absolute/ path/to/page`
123
126
124
- Using the path and filename of the page without the extension, for example:
127
+ The page name should not include the file extension (`` .rst ``). For example:
125
128
126
129
.. code-block :: rst
127
130
@@ -131,14 +134,29 @@ Using the path and filename of the page without the extension, for example:
131
134
132
135
:doc:`/cookbook/configuration/environments`
133
136
134
- The link text will be the main heading of the document linked to. You can
135
- also specify alternative text for the link :
137
+ The title of the linked page will be automatically used as the text of the link.
138
+ If you want to modify that title, use this alternative syntax :
136
139
137
140
.. code-block :: rst
138
141
139
142
:doc:`Spooling Email </cookbook/email/spool>`
140
143
141
- You can also add links to the API documentation:
144
+ .. note ::
145
+
146
+ Although they are technically correct, avoid the use of relative internal
147
+ links such as the following, because they break the references in the
148
+ generated PDF documentation:
149
+
150
+ .. code-block :: rst
151
+
152
+ :doc:`controller`
153
+
154
+ :doc:`event_dispatcher/introduction`
155
+
156
+ :doc:`environments`
157
+
158
+ **Links to the API ** follow a different syntax, where you must specify the type
159
+ of the linked resource (``namespace ``, ``class `` or ``method ``):
142
160
143
161
.. code-block :: rst
144
162
@@ -148,7 +166,7 @@ You can also add links to the API documentation:
148
166
149
167
:method:`Symfony\\Component\\HttpKernel\\Bundle\\Bundle::build`
150
168
151
- and to the PHP documentation:
169
+ ** Links to the PHP documentation** follow a pretty similar syntax :
152
170
153
171
.. code-block :: rst
154
172
@@ -158,20 +176,55 @@ and to the PHP documentation:
158
176
159
177
:phpfunction:`iterator_to_array`
160
178
161
- Testing Documentation
162
- ~~~~~~~~~~~~~~~~~~~~~
179
+ New Features or Behavior Changes
180
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
163
181
164
- To test documentation before a commit:
182
+ If you're documenting a brand new feature or a change that's been made in
183
+ Symfony, you should precede your description of the change with a
184
+ ``.. versionadded:: 2.X `` directive and a short description:
165
185
166
- * Install `Sphinx `_;
167
- * Install the Sphinx extensions using git submodules: ``git submodule update --init ``;
168
- * (Optionally) Install the bundle docs and CMF docs: ``bash install.sh ``;
169
- * Run ``make html `` and view the generated HTML in the ``build `` directory.
186
+ .. code-block :: text
187
+
188
+ .. versionadded:: 2.3
189
+ The ``askHiddenResponse`` method was introduced in Symfony 2.3.
190
+
191
+ You can also ask a question and hide the response. This is particularly [...]
192
+
193
+ If you're documenting a behavior change, it may be helpful to *briefly * describe
194
+ how the behavior has changed.
195
+
196
+ .. code-block :: text
197
+
198
+ .. versionadded:: 2.3
199
+ The ``include()`` function is a new Twig feature that's available in
200
+ Symfony 2.3. Prior, the ``{% include %}`` tag was used.
201
+
202
+ Whenever a new minor version of Symfony is released (e.g. 2.4, 2.5, etc),
203
+ a new branch of the documentation is created from the ``master `` branch.
204
+ At this point, all the ``versionadded `` tags for Symfony versions that have
205
+ reached end-of-life will be removed. For example, if Symfony 2.5 were released
206
+ today, and 2.2 had recently reached its end-of-life, the 2.2 ``versionadded ``
207
+ tags would be removed from the new 2.5 branch.
208
+
209
+ Testing Documentation
210
+ ~~~~~~~~~~~~~~~~~~~~~
170
211
171
- .. _reStructuredText : http://docutils.sourceforge.net/rst.html
172
- .. _Sphinx : http://sphinx-doc.org/
173
- .. _documents : https://github.com/symfony/symfony-docs
174
- .. _reStructuredText Primer : http://sphinx-doc.org/rest.html
175
- .. _markup : http://sphinx-doc.org/markup/
176
- .. _Pygments website : http://pygments.org/languages/
177
- .. _Sphinx quick setup : http://sphinx-doc.org/tutorial.html#setting-up-the-documentation-sources
212
+ When submitting a new content to the documentation repository or when changing
213
+ any existing resource, an automatic process will check if your documentation is
214
+ free of syntax errors and is ready to be reviewed.
215
+
216
+ Nevertheless, if you prefer to do this check locally on your own machine before
217
+ submitting your documentation, follow these steps:
218
+
219
+ * Install Sphinx _;
220
+ * Install the Sphinx extensions using git submodules: ``$ git submodule update --init ``;
221
+ * (Optionally) Install the bundle docs and CMF docs: ``$ bash install.sh ``;
222
+ * Run ``make html `` and view the generated HTML in the ``build/ `` directory.
223
+
224
+ .. _reStructuredText : http://docutils.sourceforge.net/rst.html
225
+ .. _Sphinx : http://sphinx-doc.org/
226
+ .. _`Symfony documentation` : https://github.com/symfony/symfony-docs
227
+ .. _`reStructuredText Primer` : http://sphinx-doc.org/rest.html
228
+ .. _`reStructuredText Reference` : http://docutils.sourceforge.net/docs/user/rst/quickref.html
229
+ .. _`Sphinx Markup Constructs` : http://sphinx-doc.org/markup/
230
+ .. _`supported languages` : http://pygments.org/languages/
0 commit comments