Use short code block syntax where possible

Author: ddeboer

doc/cache-invalidator.rst

@@ -9,9 +9,7 @@ Setup
 -----
 
 Create the cache invalidator by passing a proxy client as
-`adapter <http://en.wikipedia.org/wiki/Adapter_pattern>`_:
-
-.. code-block:: php
+`adapter <http://en.wikipedia.org/wiki/Adapter_pattern>`_::
 
     use FOS\HttpCache\CacheInvalidator;
     use FOS\HttpCache\ProxyClient;
@@ -34,19 +32,15 @@ Invalidating Paths and URLs
     Make sure to :doc:`configure your proxy <proxy-configuration>` for purging
     first.
 
-Invalidate a path:
-
-.. code-block:: php
+Invalidate a path::
 
     $cacheInvalidator->invalidatePath('/users')
         ->flush()
     ;
 
 See below for the :ref:`flush() <flush>` method.
 
-Invalidate a URL:
-
-.. code-block:: php
+Invalidate a URL::
 
     $cacheInvalidator->invalidatePath('http://www.example.com/users')->flush();
 
@@ -62,9 +56,7 @@ Refreshing Paths and URLs
 
     $cacheInvalidator->refreshPath('/users')->flush();
 
-Refresh a URL:
-
-.. code-block:: php
+Refresh a URL::
 
     $cacheInvalidator->refreshPath('http://www.example.com/users')->flush();
 
@@ -86,15 +78,11 @@ You can invalidate all URLs matching a regular expression by using the
 with a regular expression for the content type and/or the application hostname.
 
 For instance, to invalidate all .css files for all hostnames handled by this
-caching proxy:
-
-.. code-block:: php
+caching proxy::
 
     $cacheInvalidator->invalidateRegex('.*css$')->flush();
 
-To invalidate all .png files on host example.com:
-
-.. code-block:: php
+To invalidate all .png files on host example.com::
 
     $cacheInvalidator
         ->invalidateRegex('.*', 'image/png', array('example.com'))
@@ -114,9 +102,7 @@ You can also invalidate the cache based on any headers.
 Cache client implementations should fill up the headers to at least have the
 default headers always present to simplify the cache configuration rules.
 
-To invalidate on a custom header ``X-My-Header``, you would do:
-
-.. code-block:: php
+To invalidate on a custom header ``X-My-Header``, you would do::
 
     $cacheInvalidator->invalidate(array('X-My-Header' => 'my-value'))->flush();
 
@@ -148,9 +134,7 @@ Assume you sent four responses:
 | ``/four``  | ``tag-four, group-b``   |
 +------------+-------------------------+
 
-You can now invalidate some URLs using tags:
-
-.. code-block:: php
+You can now invalidate some URLs using tags::
 
     $cacheInvalidator->invalidateTags(array('group-a', 'tag-four'))->flush();
 
@@ -174,9 +158,7 @@ Flushing
 --------
 
 The CacheInvalidator internally queues the invalidation requests and only sends
-them out to your HTTP proxy when you call ``flush()``:
-
-.. code-block:: php
+them out to your HTTP proxy when you call ``flush()``::
 
     $cacheInvalidator
         ->invalidateRoute(...)
@@ -208,9 +190,7 @@ These exception are of two types:
 * ``\FOS\HttpCache\ProxyResponseException`` when the caching proxy returns an
   error response, such as 403 Forbidden.
 
-So, to catch exceptions:
-
-.. code-block:: php
+So, to catch exceptions::
 
     use FOS\HttpCache\Exception\ExceptionCollection;
 
@@ -233,27 +213,21 @@ Logging errors
 ~~~~~~~~~~~~~~
 
 You can log any exceptions in the following way. First construct a logger that
-implements ``\Psr\Log\LoggerInterface``. For instance, when using Monolog_:
-
-.. code-block:: php
+implements ``\Psr\Log\LoggerInterface``. For instance, when using Monolog_::
 
     use Monolog\Logger;
 
     $monolog = new Logger(...);
     $monolog->pushHandler(...);
 
-Then add the logger as a subscriber to the cache invalidator:
-
-.. code-block:: php
+Then add the logger as a subscriber to the cache invalidator::
 
     use FOS\HttpCache\EventListener\LogSubscriber;
 
     $subscriber = new LogSubscriber($monolog);
     $cacheInvalidator->addSubscriber($subscriber);
 
-Now, if you flush the invalidator, errors will be logged:
-
-.. code-block:: php
+Now, if you flush the invalidator, errors will be logged::
 
     use FOS\HttpCache\Exception\ExceptionCollection;
 

doc/conf.py

@@ -8,6 +8,7 @@
 
 lexers['php'] = PhpLexer(startinline=True, linenos=1)
 primary_domain = 'php'
+highlight_language = 'php'
 
 # If extensions (or modules to document with autodoc) are in another directory,
 # add these directories to sys.path here. If the directory is relative to the

doc/proxy-clients.rst

@@ -15,9 +15,7 @@ Varnish Client
 
 At minimum, supply an array containing IPs or hostnames of the Varnish servers
 that you want to send invalidation requests to. Make sure to include the port
-Varnish runs on if it is not port 80.
-
-.. code-block:: php
+Varnish runs on if it is not port 80::
 
     use FOS\HttpCache\ProxyClient\Varnish;
 
@@ -26,9 +24,7 @@ Varnish runs on if it is not port 80.
 
 This is sufficient for invalidating absolute URLs. If you also wish to
 invalidate relative paths, supply the hostname (or base URL) where your website
-is available as the second parameter:
-
-.. code-block:: php
+is available as the second parameter::
 
     $varnish = new Varnish($servers, 'my-cool-app.com');
 
@@ -41,9 +37,7 @@ Nginx Client
 
 At minimum, supply an array containing IPs or hostnames of the Nginx servers
 that you want to send invalidation requests to. Make sure to include the port
-Nginx runs on if it is not port 80.
-
-.. code-block:: php
+Nginx runs on if it is not port 80::
 
     use FOS\HttpCache\Invalidation\Nginx;
 
@@ -52,16 +46,12 @@ Nginx runs on if it is not port 80.
 
 This is sufficient for invalidating absolute URLs. If you also wish to
 invalidate relative paths, supply the hostname (or base URL) where your website
-is available as the second parameter:
-
-.. code-block:: php
+is available as the second parameter::
 
     $nginx = new Nginx($servers, 'my-cool-app.com');
 
 If you have configured Nginx to support purge requests at a separate location,
-supply that location to the class as the third parameter:
-
-.. code-block:: php
+supply that location to the class as the third parameter::
 
     $nginx = new Nginx($servers, 'my-cool-app.com', '/purge');
 
@@ -100,9 +90,7 @@ Purge
 If the caching proxy understands :term:`purge` requests,
 its client should implement ``PurgeInterface``. Use the ``purge($url)`` method to
 purge one specific URL. The URL can be either an absolute URL or a relative
-path:
-
-.. code-block:: php
+path::
 
     $client
         ->purge('http://my-app.com/some/path')
@@ -115,9 +103,7 @@ Refresh
 
 If the caching proxy understands :term:`refresh` requests,
 its client should implement ``RefreshInterface``. Use ``refresh()`` to refresh
-one specific URL. The URL can be either an absolute URL or a relative path:
-
-.. code-block:: php
+one specific URL. The URL can be either an absolute URL or a relative path::
 
     $client
         ->refresh('http://my-app.com/some/path')
@@ -126,9 +112,7 @@ one specific URL. The URL can be either an absolute URL or a relative path:
     ;
 
 You can specify HTTP headers as the second argument to ``refresh()``. For
-instance, to only refresh the JSON representation of an URL:
-
-.. code-block:: php
+instance, to only refresh the JSON representation of an URL::
 
     $client
         ->refresh('/some/path', array('Accept' => 'application/json')
@@ -146,31 +130,23 @@ You can invalidate all URLs matching a regular expression by using the
 for the path to invalidate and an optional content type regular expression and
 list of application hostnames.
 
-For instance, to ban all .png files on all application hosts:
-
-.. code-block:: php
+For instance, to ban all .png files on all application hosts::
 
     $client->banPath('.*png$');
 
-To ban all HTML URLs that begin with ``/articles/``:
-
-.. code-block:: php
+To ban all HTML URLs that begin with ``/articles/``::
 
     $client->banPath('/articles/.*', 'text/html');
 
 By default, URLs will be banned on all application hosts. You can limit this by
-specifying a host header:
-
-.. code-block:: php
+specifying a host header::
 
     $client->banPath('*.png$', null, '^www.example.com$');
 
 If you want to go beyond banning combinations of path, content type and hostname,
 use the ``ban(array $headers)`` method. This method allows you to specify any
 combination of headers that should be banned. For instance, when using the
-Varnish client:
-
-.. code-block:: php
+Varnish client::
 
     use FOS\HttpCache\ProxyClient\Varnish;
 

doc/testing-your-application.rst

@@ -55,9 +55,7 @@ Compare this library’s configuration to see how the constants are set:
 Overriding Getters
 ~~~~~~~~~~~~~~~~~~
 
-You can override getters in your test class in the following way.
-
-.. code-block:: php
+You can override getters in your test class in the following way::
 
     use FOS\HttpCache\Tests\VarnishTestCase;
 
@@ -80,9 +78,7 @@ Usage
 -----
 
 This example shows how you can test whether the caching headers your
-application sets influence Varnish as you expect them to.
-
-.. code-block:: php
+application sets influence Varnish as you expect them to::
 
     use FOS\HttpCache\Tests\VarnishTestCase;
 
@@ -109,9 +105,7 @@ application sets influence Varnish as you expect them to.
     }
 
 This example shows how you can test whether your application purges content
-correctly:
-
-.. code-block:: php
+correctly::
 
     public function testCachePurge()
     {

doc/user-context.rst

@@ -51,9 +51,7 @@ Calculating the User Context Hash
 
 The user context hash calculation (step 3 above) is managed by the HashGenerator.
 Because the calculation itself will be different per application, you need to
-implement at least one ContextProvider and register that with the HashGenerator.
-
-.. code-block:: php
+implement at least one ContextProvider and register that with the HashGenerator::
 
     use FOS\HttpCache\UserContext\HashGenerator;
 
@@ -71,9 +69,7 @@ Context Providers
 Each provider is passed the `UserContext <../../../src/UserContext/UserContext.php>`_
 and updates that with parameters which influence the varied response.
 
-A provider that looks at whether the user is authenticated could look like this:
-
-.. code-block:: php
+A provider that looks at whether the user is authenticated could look like this::
 
     use FOS\HttpCache\UserContext\ContextProviderInterface;
     use FOS\HttpCache\UserContext\UserContext;
@@ -99,9 +95,7 @@ Returning the User Context Hash
 -------------------------------
 
 It is up to you to return the user context hash in response to the hash request
-(``/auth.php`` in step 3 above):
-
-.. code-block:: php
+(``/auth.php`` in step 3 above)::
 
     $hash = $hashGenerator->generateHash();
 
@@ -147,9 +141,7 @@ The Original Request
 
 After following the steps above, the following code renders a homepage
 differently depending on whether the user is logged in or not, using the
-*credentials of the particular user*:
-
-.. code-block:: php
+*credentials of the particular user*::
 
     // /index.php file
     header('Cache-Control: max-age=3600');