remove unused ref directives

replace page refs with doc directives

docs/patterns/appdispatch.rst

@@ -1,5 +1,3 @@
-.. _app-dispatch:
-
 Application Dispatching
 =======================
 
@@ -10,25 +8,25 @@ Django and a Flask application in the same interpreter side by side if
 you want.  The usefulness of this depends on how the applications work
 internally.
 
-The fundamental difference from the :ref:`module approach
-<larger-applications>` is that in this case you are running the same or
-different Flask applications that are entirely isolated from each other.
-They run different configurations and are dispatched on the WSGI level.
+The fundamental difference from :doc:`packages` is that in this case you
+are running the same or different Flask applications that are entirely
+isolated from each other. They run different configurations and are
+dispatched on the WSGI level.
 
 
 Working with this Document
 --------------------------
 
-Each of the techniques and examples below results in an ``application`` object
-that can be run with any WSGI server.  For production, see :ref:`deployment`.
-For development, Werkzeug provides a builtin server for development available
-at :func:`werkzeug.serving.run_simple`::
+Each of the techniques and examples below results in an ``application``
+object that can be run with any WSGI server. For production, see
+:doc:`/deploying/index`. For development, Werkzeug provides a server
+through :func:`werkzeug.serving.run_simple`::
 
     from werkzeug.serving import run_simple
     run_simple('localhost', 5000, application, use_reloader=True)
 
 Note that :func:`run_simple <werkzeug.serving.run_simple>` is not intended for
-use in production.  Use a :ref:`full-blown WSGI server <deployment>`.
+use in production.  Use a production WSGI server. See :doc:`/deploying/index`.
 
 In order to use the interactive debugger, debugging must be enabled both on
 the application and the simple server. Here is the "hello world" example with
@@ -79,7 +77,7 @@ with different configurations.  Assuming the application is created inside
 a function and you can call that function to instantiate it, that is
 really easy to implement.  In order to develop your application to support
 creating new instances in functions have a look at the
-:ref:`app-factories` pattern.
+:doc:`appfactories` pattern.
 
 A very common example would be creating applications per subdomain.  For
 instance you configure your webserver to dispatch all requests for all

docs/patterns/appfactories.rst

@@ -1,10 +1,8 @@
-.. _app-factories:
-
 Application Factories
 =====================
 
 If you are already using packages and blueprints for your application
-(:ref:`blueprints`) there are a couple of really nice ways to further improve
+(:doc:`/blueprints`) there are a couple of really nice ways to further improve
 the experience.  A common pattern is creating the application object when
 the blueprint is imported.  But if you move the creation of this object
 into a function, you can then create multiple instances of this app later.

docs/patterns/caching.rst

@@ -1,5 +1,3 @@
-.. _caching-pattern:
-
 Caching
 =======
 

docs/patterns/deferredcallbacks.rst

@@ -1,5 +1,3 @@
-.. _deferred-callbacks:
-
 Deferred Request Callbacks
 ==========================
 

docs/patterns/distribute.rst

@@ -1,5 +1,3 @@
-.. _distribute-deployment:
-
 Deploying with Setuptools
 =========================
 
@@ -23,14 +21,13 @@ Flask itself, and all the libraries you can find on PyPI are distributed with
 either setuptools or distutils.
 
 In this case we assume your application is called
-:file:`yourapplication.py` and you are not using a module, but a :ref:`package
-<larger-applications>`. If you have not yet converted your application into
-a package, head over to the :ref:`larger-applications` pattern to see
-how this can be done.
+:file:`yourapplication.py` and you are not using a module, but a
+package. If you have not yet converted your application into a package,
+head over to :doc:`packages` to see how this can be done.
 
 A working deployment with setuptools is the first step into more complex
 and more automated deployment scenarios.  If you want to fully automate
-the process, also read the :ref:`fabric-deployment` chapter.
+the process, also read the :doc:`fabric` chapter.
 
 Basic Setup Script
 ------------------
@@ -38,8 +35,8 @@ Basic Setup Script
 Because you have Flask installed, you have setuptools available on your system.
 Flask already depends upon setuptools.
 
-Standard disclaimer applies: :ref:`you better use a virtualenv
-<virtualenv>`.
+Standard disclaimer applies: :ref:`use a virtualenv
+<install-create-env>`.
 
 Your setup code always goes into a file named :file:`setup.py` next to your
 application.  The name of the file is only convention, but because

docs/patterns/errorpages.rst

@@ -1,5 +1,3 @@
-.. _errorpages:
-
 Custom Error Pages
 ==================
 
@@ -41,7 +39,7 @@ even if the application behaves correctly:
     Usually happens on programming errors or if the server is overloaded.
     A terribly good idea is to have a nice page there, because your
     application *will* fail sooner or later (see also:
-    :ref:`application-errors`).
+    :doc:`/errorhandling`).
 
 
 Error Handlers
@@ -74,7 +72,7 @@ Here is an example implementation for a "404 Page Not Found" exception::
         # note that we set the 404 status explicitly
         return render_template('404.html'), 404
 
-When using the :ref:`application factory pattern <app-factories>`::
+When using the :doc:`appfactories`::
 
     from flask import Flask, render_template
 

docs/patterns/fabric.rst

@@ -1,12 +1,10 @@
-.. _fabric-deployment:
-
 Deploying with Fabric
 =====================
 
 `Fabric`_ is a tool for Python similar to Makefiles but with the ability
 to execute commands on a remote server.  In combination with a properly
-set up Python package (:ref:`larger-applications`) and a good concept for
-configurations (:ref:`config`) it is very easy to deploy Flask
+set up Python package (:doc:`packages`) and a good concept for
+configurations (:doc:`/config`) it is very easy to deploy Flask
 applications to external servers.
 
 Before we get started, here a quick checklist of things we have to ensure
@@ -15,7 +13,7 @@ upfront:
 -   Fabric 1.0 has to be installed locally.  This tutorial assumes the
     latest version of Fabric.
 -   The application already has to be a package and requires a working
-    :file:`setup.py` file (:ref:`distribute-deployment`).
+    :file:`setup.py` file (:doc:`distribute`).
 -   In the following example we are using `mod_wsgi` for the remote
     servers.  You can of course use your own favourite server there, but
     for this example we chose Apache + `mod_wsgi` because it's very easy
@@ -101,7 +99,7 @@ To setup a new server you would roughly do these steps:
 3.  Create a new Apache config for ``yourapplication`` and activate it.
     Make sure to activate watching for changes of the ``.wsgi`` file so
     that we can automatically reload the application by touching it.
-    (See :ref:`mod_wsgi-deployment` for more information)
+    See :doc:`/deploying/mod_wsgi`.
 
 So now the question is, where do the :file:`application.wsgi` and
 :file:`application.cfg` files come from?
@@ -124,7 +122,7 @@ the config at that environment variable::
     app.config.from_object('yourapplication.default_config')
     app.config.from_envvar('YOURAPPLICATION_CONFIG')
 
-This approach is explained in detail in the :ref:`config` section of the
+This approach is explained in detail in the :doc:`/config` section of the
 documentation.
 
 The Configuration File

docs/patterns/fileuploads.rst

@@ -1,5 +1,3 @@
-.. _uploading-files:
-
 Uploading Files
 ===============
 
@@ -39,7 +37,7 @@ Why do we limit the extensions that are allowed?  You probably don't want
 your users to be able to upload everything there if the server is directly
 sending out the data to the client.  That way you can make sure that users
 are not able to upload HTML files that would cause XSS problems (see
-:ref:`xss`).  Also make sure to disallow ``.php`` files if the server
+:ref:`security-xss`).  Also make sure to disallow ``.php`` files if the server
 executes them, but who has PHP installed on their server, right?  :)
 
 Next the functions that check if an extension is valid and that uploads

docs/patterns/flashing.rst

@@ -1,5 +1,3 @@
-.. _message-flashing-pattern:
-
 Message Flashing
 ================
 

docs/patterns/index.rst

@@ -1,5 +1,3 @@
-.. _patterns:
-
 Patterns for Flask
 ==================
 

docs/patterns/mongokit.rst

@@ -1,7 +0,0 @@
-:orphan:
-
-MongoDB with MongoKit
-=====================
-
-MongoKit is no longer maintained. See :doc:`/patterns/mongoengine`
-instead.

docs/patterns/packages.rst

@@ -1,7 +1,5 @@
-.. _larger-applications:
-
-Larger Applications
-===================
+Large Applications as Packages
+==============================
 
 Imagine a simple flask application structure that looks like this::
 
@@ -17,7 +15,7 @@ Imagine a simple flask application structure that looks like this::
 
 While this is fine for small applications, for larger applications
 it's a good idea to use a package instead of a module.
-The :ref:`tutorial <tutorial>` is structured to use the package pattern,
+The :doc:`/tutorial/index` is structured to use the package pattern,
 see the :gh:`example code <examples/tutorial>`.
 
 Simple Packages
@@ -129,15 +127,13 @@ You should then end up with something like that::
 
    There are still some problems with that approach but if you want to use
    decorators there is no way around that.  Check out the
-   :ref:`becomingbig` section for some inspiration how to deal with that.
+   :doc:`/becomingbig` section for some inspiration how to deal with that.
 
 
-.. _working-with-modules:
-
 Working with Blueprints
 -----------------------
 
 If you have larger applications it's recommended to divide them into
 smaller groups where each group is implemented with the help of a
 blueprint.  For a gentle introduction into this topic refer to the
-:ref:`blueprints` chapter of the documentation.
+:doc:`/blueprints` chapter of the documentation.

docs/patterns/sqlalchemy.rst

@@ -1,12 +1,10 @@
-.. _sqlalchemy-pattern:
-
 SQLAlchemy in Flask
 ===================
 
 Many people prefer `SQLAlchemy`_ for database access.  In this case it's
 encouraged to use a package instead of a module for your flask application
-and drop the models into a separate module (:ref:`larger-applications`).
-While that is not necessary, it makes a lot of sense.
+and drop the models into a separate module (:doc:`packages`). While that
+is not necessary, it makes a lot of sense.
 
 There are four very common ways to use SQLAlchemy.  I will outline each
 of them here:
@@ -109,8 +107,7 @@ Querying is simple as well:
 <User 'admin'>
 
 .. _SQLAlchemy: https://www.sqlalchemy.org/
-.. _declarative:
-   https://docs.sqlalchemy.org/en/latest/orm/extensions/declarative/
+.. _declarative: https://docs.sqlalchemy.org/en/latest/orm/extensions/declarative/
 
 Manual Object Relational Mapping
 --------------------------------

docs/patterns/sqlite3.rst

@@ -1,5 +1,3 @@
-.. _sqlite3:
-
 Using SQLite 3 with Flask
 =========================
 
@@ -62,7 +60,6 @@ the application context by hand::
     with app.app_context():
         # now you can use get_db()
 
-.. _easy-querying:
 
 Easy Querying
 -------------

docs/patterns/templateinheritance.rst

@@ -1,5 +1,3 @@
-.. _template-inheritance:
-
 Template Inheritance
 ====================
 

docs/patterns/viewdecorators.rst

@@ -59,7 +59,7 @@ Caching Decorator
 Imagine you have a view function that does an expensive calculation and
 because of that you would like to cache the generated results for a
 certain amount of time.  A decorator would be nice for that.  We're
-assuming you have set up a cache like mentioned in :ref:`caching-pattern`.
+assuming you have set up a cache like mentioned in :doc:`caching`.
 
 Here is an example cache function.  It generates the cache key from a
 specific prefix (actually a format string) and the current path of the
@@ -96,8 +96,8 @@ Here the code::
             return decorated_function
         return decorator
 
-Notice that this assumes an instantiated `cache` object is available, see
-:ref:`caching-pattern` for more information.
+Notice that this assumes an instantiated ``cache`` object is available, see
+:doc:`caching`.
 
 
 Templating Decorator

docs/patterns/wtforms.rst

@@ -9,7 +9,7 @@ forms, you might want to give it a try.
 
 When you are working with WTForms you have to define your forms as classes
 first.  I recommend breaking up the application into multiple modules
-(:ref:`larger-applications`) for that and adding a separate module for the
+(:doc:`packages`) for that and adding a separate module for the
 forms.
 
 .. admonition:: Getting the most out of WTForms with an Extension
@@ -55,7 +55,7 @@ In the view function, the usage of this form looks like this::
         return render_template('register.html', form=form)
 
 Notice we're implying that the view is using SQLAlchemy here
-(:ref:`sqlalchemy-pattern`), but that's not a requirement, of course.  Adapt
+(:doc:`sqlalchemy`), but that's not a requirement, of course.  Adapt
 the code as necessary.
 
 Things to remember: