Track change of the scaffolding file names, removing 'pyramid_' prefix.

1 files changed, 3 insertions, 3 deletions

diff --git a/docs/tutorials/wiki/basiclayout.rst b/docs/tutorials/wiki/basiclayout.rst
index 311352f5b..897775428 100644
--- a/docs/tutorials/wiki/basiclayout.rst
+++ b/docs/tutorials/wiki/basiclayout.rst
@@ -2,7 +2,7 @@
 Basic Layout
 ============
 
-The starter files generated by the ``pyramid_zodb`` scaffold are basic, but
+The starter files generated by the ``zodb`` scaffold are basic, but
 they provide a good orientation for the high-level patterns common to most
 :term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` based) projects.
 
@@ -69,7 +69,7 @@ hierarchically in a :term:`resource tree`.  This tree is consulted by
 tree represents the site structure, but it *also* represents the
 :term:`domain model` of the application, because each resource is a node
 stored persistently in a :term:`ZODB` database.  The ``models.py`` file is
-where the ``pyramid_zodb`` scaffold put the classes that implement our
+where the ``zodb`` scaffold put the classes that implement our
 resource objects, each of which happens also to be a domain model object.
 
 Here is the source for ``models.py``:
@@ -144,7 +144,7 @@ Let's try to understand the components in this module:
 
 #. *Lines 5-6*.  We define a :term:`view callable` named ``my_view``, which
    we decorated in the step above.  This view callable is a *function* we
-   write generated by the ``pyramid_zodb`` scaffold that is given a
+   write generated by the ``zodb`` scaffold that is given a
    ``request`` and which returns a dictionary.  The ``mytemplate.pt``
    :term:`renderer` named by the asset specification in the step above will
    convert this dictionary to a :term:`response` on our behalf.