refactor or remove old docs (pallets#4748)

Author: davidism

docs/advanced_foreword.rst

@@ -394,13 +394,11 @@ The following configuration values are used internally by Flask:
 Configuring from Python Files
 -----------------------------
 
-Configuration becomes more useful if you can store it in a separate file,
-ideally located outside the actual application package. This makes
-packaging and distributing your application possible via various package
-handling tools (:doc:`/patterns/distribute`) and finally modifying the
-configuration file afterwards.
+Configuration becomes more useful if you can store it in a separate file, ideally
+located outside the actual application package. You can deploy your application, then
+separately configure it for the specific deployment.
 
-So a common pattern is this::
+A common pattern is this::
 
     app = Flask(__name__)
     app.config.from_object('yourapplication.default_settings')
@@ -692,10 +690,8 @@ your configuration files.  However here a list of good recommendations:
     code at all.  If you are working often on different projects you can
     even create your own script for sourcing that activates a virtualenv
     and exports the development configuration for you.
--   Use a tool like `fabric`_ in production to push code and
-    configurations separately to the production server(s).  For some
-    details about how to do that, head over to the
-    :doc:`/patterns/fabric` pattern.
+-   Use a tool like `fabric`_ to push code and configuration separately
+    to the production server(s).
 
 .. _fabric: https://www.fabfile.org/
 

docs/config.rst

@@ -130,9 +130,25 @@ being present.  You can easily use your own templating language, but an
 extension could still depend on Jinja itself.
 
 
-Micro with Dependencies
+What does "micro" mean?
 -----------------------
 
+“Micro” does not mean that your whole web application has to fit into a single
+Python file (although it certainly can), nor does it mean that Flask is lacking
+in functionality. The "micro" in microframework means Flask aims to keep the
+core simple but extensible. Flask won't make many decisions for you, such as
+what database to use. Those decisions that it does make, such as what
+templating engine to use, are easy to change.  Everything else is up to you, so
+that Flask can be everything you need and nothing you don't.
+
+By default, Flask does not include a database abstraction layer, form
+validation or anything else where different libraries already exist that can
+handle that. Instead, Flask supports extensions to add such functionality to
+your application as if it was implemented in Flask itself. Numerous extensions
+provide database integration, form validation, upload handling, various open
+authentication technologies, and more. Flask may be "micro", but it's ready for
+production use on a variety of needs.
+
 Why does Flask call itself a microframework and yet it depends on two
 libraries (namely Werkzeug and Jinja2).  Why shouldn't it?  If we look
 over to the Ruby side of web development there we have a protocol very
@@ -201,5 +217,12 @@ requirements and Flask could not meet those if it would force any of this
 into the core.  The majority of web applications will need a template
 engine in some sort.  However not every application needs a SQL database.
 
+As your codebase grows, you are free to make the design decisions appropriate
+for your project.  Flask will continue to provide a very simple glue layer to
+the best that Python has to offer.  You can implement advanced patterns in
+SQLAlchemy or another database tool, introduce non-relational data persistence
+as appropriate, and take advantage of framework-agnostic tools built for WSGI,
+the Python web interface.
+
 The idea of Flask is to build a good foundation for all applications.
 Everything else is up to you or extensions.