</details><p>Flask uses a concept of <em>blueprints</em> for making application components and
supporting common patterns within an application or across applications.
Blueprints can greatly simplify how large applications work and provide a
central means for Flask extensions to register operations on applications.
A <aclass="reference internal"href="api.html#flask.Blueprint"title="flask.Blueprint"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">Blueprint</span></code></a> object works similarly to a <aclass="reference internal"href="api.html#flask.Flask"title="flask.Flask"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">Flask</span></code></a>
application object, but it is not actually an application. Rather it is a
<em>blueprint</em> of how to construct or extend an application.</p>
<sectionid="why-blueprints">
<h2>Why Blueprints?<aclass="headerlink"href="#why-blueprints"title="Link to this heading">¶</a></h2>
<p>Blueprints in Flask are intended for these cases:</p>
<ulclass="simple">
<li><p>Factor an application into a set of blueprints. This is ideal for
larger applications; a project could instantiate an application object,
initialize several extensions, and register a collection of blueprints.</p></li>
<li><p>Register a blueprint on an application at a URL prefix and/or subdomain.
Parameters in the URL prefix/subdomain become common view arguments
(with defaults) across all view functions in the blueprint.</p></li>
<li><p>Register a blueprint multiple times on an application with different URL
rules.</p></li>
<li><p>Provide template filters, static files, templates, and other utilities
through blueprints. A blueprint does not have to implement applications
or view functions.</p></li>
<li><p>Register a blueprint on an application for any of these cases when
initializing a Flask extension.</p></li>
</ul>
<p>A blueprint in Flask is not a pluggable app because it is not actually an
application – it’s a set of operations which can be registered on an
application, even multiple times. Why not have multiple application
objects? You can do that (see <aclass="reference internal"href="patterns/appdispatch.html"><spanclass="doc">Application Dispatching</span></a>), but your
applications will have separate configs and will be managed at the WSGI
layer.</p>
<p>Blueprints instead provide separation at the Flask level, share
application config, and can change an application object as necessary with
being registered. The downside is that you cannot unregister a blueprint
once an application was created without having to destroy the whole
<p>When you bind a function with the help of the <codeclass="docutils literal notranslate"><spanclass="pre">@simple_page.route</span></code>
decorator, the blueprint will record the intention of registering the
function <codeclass="docutils literal notranslate"><spanclass="pre">show</span></code> on the application when it’s later registered.
Additionally it will prefix the endpoint of the function with the
name of the blueprint which was given to the <aclass="reference internal"href="api.html#flask.Blueprint"title="flask.Blueprint"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">Blueprint</span></code></a>
constructor (in this case also <codeclass="docutils literal notranslate"><spanclass="pre">simple_page</span></code>). The blueprint’s name
does not modify the URL, only the endpoint.</p>
</section>
<sectionid="registering-blueprints">
<h2>Registering Blueprints<aclass="headerlink"href="#registering-blueprints"title="Link to this heading">¶</a></h2>
<p>So how do you register that blueprint? Like this:</p>
<p>The first one is obviously from the application itself for the static
files. The other two are for the <codeclass="code docutils literal notranslate"><spanclass="pre">show</span></code> function of the <codeclass="docutils literal notranslate"><spanclass="pre">simple_page</span></code>
blueprint. As you can see, they are also prefixed with the name of the
blueprint and separated by a dot (<codeclass="docutils literal notranslate"><spanclass="pre">.</span></code>).</p>
<p>Blueprints however can also be mounted at different locations:</p>
<h2>Blueprint Resources<aclass="headerlink"href="#blueprint-resources"title="Link to this heading">¶</a></h2>
<p>Blueprints can provide resources as well. Sometimes you might want to
introduce a blueprint only for the resources it provides.</p>
<sectionid="blueprint-resource-folder">
<h3>Blueprint Resource Folder<aclass="headerlink"href="#blueprint-resource-folder"title="Link to this heading">¶</a></h3>
<p>Like for regular applications, blueprints are considered to be contained
in a folder. While multiple blueprints can originate from the same folder,
it does not have to be the case and it’s usually not recommended.</p>
<p>The folder is inferred from the second argument to <aclass="reference internal"href="api.html#flask.Blueprint"title="flask.Blueprint"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">Blueprint</span></code></a> which
is usually <codeclass="code docutils literal notranslate"><spanclass="pre">__name__</span></code>. This argument specifies what logical Python
module or package corresponds to the blueprint. If it points to an actual
Python package that package (which is a folder on the filesystem) is the
resource folder. If it’s a module, the package the module is contained in
will be the resource folder. You can access the
<aclass="reference internal"href="api.html#flask.Blueprint.root_path"title="flask.Blueprint.root_path"><codeclass="xref py py-attr docutils literal notranslate"><spanclass="pre">Blueprint.root_path</span></code></a> property to see what the resource folder is:</p>
<p>By default the rightmost part of the path is where it is exposed on the
web. This can be changed with the <codeclass="docutils literal notranslate"><spanclass="pre">static_url_path</span></code> argument. Because the
folder is called <codeclass="docutils literal notranslate"><spanclass="pre">static</span></code> here it will be available at the
<codeclass="docutils literal notranslate"><spanclass="pre">url_prefix</span></code> of the blueprint + <codeclass="docutils literal notranslate"><spanclass="pre">/static</span></code>. If the blueprint
has the prefix <codeclass="docutils literal notranslate"><spanclass="pre">/admin</span></code>, the static URL will be <codeclass="docutils literal notranslate"><spanclass="pre">/admin/static</span></code>.</p>
<p>The endpoint is named <codeclass="docutils literal notranslate"><spanclass="pre">blueprint_name.static</span></code>. You can generate URLs
to it with <aclass="reference internal"href="api.html#flask.url_for"title="flask.url_for"><codeclass="xref py py-func docutils literal notranslate"><spanclass="pre">url_for()</span></code></a> like you would with the static folder of the
<p>However, if the blueprint does not have a <codeclass="docutils literal notranslate"><spanclass="pre">url_prefix</span></code>, it is not
possible to access the blueprint’s static folder. This is because the
URL would be <codeclass="docutils literal notranslate"><spanclass="pre">/static</span></code> in this case, and the application’s <codeclass="docutils literal notranslate"><spanclass="pre">/static</span></code>
<p>For static files, the path can be absolute or relative to the blueprint
resource folder.</p>
<p>The template folder is added to the search path of templates but with a lower
priority than the actual application’s template folder. That way you can
easily override templates that a blueprint provides in the actual application.
This also means that if you don’t want a blueprint template to be accidentally
overridden, make sure that no other blueprint or actual application template
has the same relative path. When multiple blueprints provide the same relative
template path the first blueprint registered takes precedence over the others.</p>
<p>So if you have a blueprint in the folder <codeclass="docutils literal notranslate"><spanclass="pre">yourapplication/admin</span></code> and you
want to render the template <codeclass="docutils literal notranslate"><spanclass="pre">'admin/index.html'</span></code> and you have provided
<codeclass="docutils literal notranslate"><spanclass="pre">templates</span></code> as a <codeclass="code docutils literal notranslate"><spanclass="pre">template_folder</span></code> you will have to create a file like
this: <codeclass="file docutils literal notranslate"><spanclass="pre">yourapplication/admin/templates/admin/index.html</span></code>. The reason
for the extra <codeclass="docutils literal notranslate"><spanclass="pre">admin</span></code> folder is to avoid getting our template overridden
by a template named <codeclass="docutils literal notranslate"><spanclass="pre">index.html</span></code> in the actual application template
folder.</p>
<p>To further reiterate this: if you have a blueprint named <codeclass="docutils literal notranslate"><spanclass="pre">admin</span></code> and you
want to render a template called <codeclass="file docutils literal notranslate"><spanclass="pre">index.html</span></code> which is specific to this
blueprint, the best idea is to lay out your templates like this:</p>
<p>And then when you want to render the template, use <codeclass="file docutils literal notranslate"><spanclass="pre">admin/index.html</span></code> as
the name to look up the template by. If you encounter problems loading
the correct templates enable the <codeclass="docutils literal notranslate"><spanclass="pre">EXPLAIN_TEMPLATE_LOADING</span></code> config
variable which will instruct Flask to print out the steps it goes through
to locate templates on every <codeclass="docutils literal notranslate"><spanclass="pre">render_template</span></code> call.</p>
</section>
</section>
<sectionid="building-urls">
<h2>Building URLs<aclass="headerlink"href="#building-urls"title="Link to this heading">¶</a></h2>
<p>If you want to link from one page to another you can use the
<aclass="reference internal"href="api.html#flask.url_for"title="flask.url_for"><codeclass="xref py py-func docutils literal notranslate"><spanclass="pre">url_for()</span></code></a> function just like you normally would do just that you
prefix the URL endpoint with the name of the blueprint and a dot (<codeclass="docutils literal notranslate"><spanclass="pre">.</span></code>):</p>
<h2>Blueprint Error Handlers<aclass="headerlink"href="#blueprint-error-handlers"title="Link to this heading">¶</a></h2>
<p>Blueprints support the <codeclass="docutils literal notranslate"><spanclass="pre">errorhandler</span></code> decorator just like the <aclass="reference internal"href="api.html#flask.Flask"title="flask.Flask"><codeclass="xref py py-class docutils literal notranslate"><spanclass="pre">Flask</span></code></a>
application object, so it is easy to make Blueprint-specific custom error
pages.</p>
<p>Here is an example for a “404 Page Not Found” exception:</p>
<p>Most errorhandlers will simply work as expected; however, there is a caveat
concerning handlers for 404 and 405 exceptions. These errorhandlers are only
invoked from an appropriate <codeclass="docutils literal notranslate"><spanclass="pre">raise</span></code> statement or a call to <codeclass="docutils literal notranslate"><spanclass="pre">abort</span></code> in another
of the blueprint’s view functions; they are not invoked by, e.g., an invalid URL
access. This is because the blueprint does not “own” a certain URL space, so
the application instance has no way of knowing which blueprint error handler it
should run if given an invalid URL. If you would like to execute different
handling strategies for these errors based on URL prefixes, they may be defined
at the application level using the <codeclass="docutils literal notranslate"><spanclass="pre">request</span></code> proxy object:</p>
