aboutsummaryrefslogtreecommitdiffstats
path: root/docs/source/pluginwriter
diff options
context:
space:
mode:
Diffstat (limited to 'docs/source/pluginwriter')
-rw-r--r--docs/source/pluginwriter/api.rst8
-rw-r--r--docs/source/pluginwriter/authhooks.rst4
-rw-r--r--docs/source/pluginwriter/database.rst8
-rw-r--r--docs/source/pluginwriter/hooks.rst2
-rw-r--r--docs/source/pluginwriter/tests.rst8
5 files changed, 15 insertions, 15 deletions
diff --git a/docs/source/pluginwriter/api.rst b/docs/source/pluginwriter/api.rst
index a220eac1..03761a38 100644
--- a/docs/source/pluginwriter/api.rst
+++ b/docs/source/pluginwriter/api.rst
@@ -83,7 +83,7 @@ can use a shortcut to get your plugin's config section::
>>> floobie_dir = floobie_config['floobie_dir']
A tip: you have access to the `%(here)s` variable in your config,
-which is the directory that the user's mediagoblin config is running
+which is the directory that the user's MediaGoblin config is running
out of. So for example, your plugin may need a "floobie" directory to
store floobs in. You could give them a reasonable default that makes
use of the default `user_dev` location, but allow users to override
@@ -92,7 +92,7 @@ it, like so::
[plugin_spec]
floobie_dir = string(default="%(here)s/user_dev/floobs/")
-Note, this is relative to the user's mediagoblin config directory,
+Note, this is relative to the user's MediaGoblin config directory,
*not* your plugin directory!
@@ -178,7 +178,7 @@ Adding static resources
-----------------------
It's possible to add static resources for your plugin. Say your
-plugin needs some special javascript and images... how to provide
+plugin needs some special JavaScript and images... how to provide
them? Then how to access them? MediaGoblin has a way!
@@ -230,7 +230,7 @@ the MediaGoblin repository.
WTForms hooks
+++++++++++++
-We haven't totally settled on a way to tranform wtforms form objects,
+We haven't totally settled on a way to transform wtforms form objects,
but here's one way. In your view::
from mediagoblin.foo.forms import SomeForm
diff --git a/docs/source/pluginwriter/authhooks.rst b/docs/source/pluginwriter/authhooks.rst
index 9721d729..66d9b9da 100644
--- a/docs/source/pluginwriter/authhooks.rst
+++ b/docs/source/pluginwriter/authhooks.rst
@@ -44,7 +44,7 @@ This hook is called in ``mediagoblin.auth.views`` in both the ``login`` and
if :ref:`basic_auth-chapter` is not enabled, the user will be redirected to the
correct login and registration views for your plugin.
-The code assumes that it can generate a valid url given
+The code assumes that it can generate a valid URL given
``mediagoblin.plugins.{{ your_plugin_here }}.login`` and
``mediagoblin.plugins.{{ your_plugin_here }}.register``. This is only needed if
you will not be using the ``login`` and ``register`` views in
@@ -82,5 +82,5 @@ the ``stored_hash`` and return either ``True`` or ``False``.
This hook is called in ``mediagoblin.auth.tools.check_login_simple``. It is
called if a user is not found and should do something that takes the same amount
-of time as your ``check_password`` function. This is to help prevent timining
+of time as your ``check_password`` function. This is to help prevent timing
attacks.
diff --git a/docs/source/pluginwriter/database.rst b/docs/source/pluginwriter/database.rst
index c0698a24..90c2cee3 100644
--- a/docs/source/pluginwriter/database.rst
+++ b/docs/source/pluginwriter/database.rst
@@ -24,7 +24,7 @@ Accessing Existing Data
=======================
If your plugin wants to access existing data, this is quite
-straight forward. Just import the appropiate models and use
+straight forward. Just import the appropriate models and use
the full power of SQLAlchemy. Take a look at the (upcoming)
database section in the Developer's Chapter.
@@ -134,13 +134,13 @@ plugin's models.py and then run::
./bin/gmg alembic --with-plugins revision \
--head REVISION_HERE \
--autogenerate \
- -m "YOUR_PLUGIN_NAME: Change explaination here."
+ -m "YOUR_PLUGIN_NAME: Change explanation here."
Once again, this will dump the migration into the wrong place, so move
to your plugin's migrations directory. Open the file, adjust
accordingly, and read carefully! Now you should also test your
-migration with some real data. Be sure to test it both on sqlite
-*AND* on postgresql!
+migration with some real data. Be sure to test it both on SQLite
+*AND* on PostgreSQL!
One last *very critical* note: you must never, never modify core
tables with your plugin. To do that is to put you and all your users
diff --git a/docs/source/pluginwriter/hooks.rst b/docs/source/pluginwriter/hooks.rst
index 4aa062e8..66fe3b4d 100644
--- a/docs/source/pluginwriter/hooks.rst
+++ b/docs/source/pluginwriter/hooks.rst
@@ -28,7 +28,7 @@ What hooks are available?
This hook is used by ``add_media_to_collection``
in ``mediagoblin.user_pages.lib``.
It gets a ``CollectionItem`` as its argument.
-It's the newly created item just before getting commited.
+It's the newly created item just before getting committed.
So the item can be modified by the hook, if needed.
Changing the session regarding this item is currently
undefined behaviour, as the SQL Session might contain other
diff --git a/docs/source/pluginwriter/tests.rst b/docs/source/pluginwriter/tests.rst
index fe99688f..560a8899 100644
--- a/docs/source/pluginwriter/tests.rst
+++ b/docs/source/pluginwriter/tests.rst
@@ -19,7 +19,7 @@ Here's a brief guide to writing unit tests for plugins. However, it
isn't really ideal. It also hasn't been well tested... yes, there's
some irony there :)
-Some notes: we're using py.test and webtest for unit testing stuff.
+Some notes: we're using py.test and WebTest for unit testing stuff.
Keep that in mind.
My suggestion is to mime the behavior of `mediagoblin/tests/` and put
@@ -44,7 +44,7 @@ In any test module in your tests directory you can then do::
# real code goes here
pass
-And you'll get a mediagoblin application wrapped in webtest passed in
+And you'll get a MediaGoblin application wrapped in WebTest passed in
to your environment.
If your plugin needs to define multiple configuration setups, you can
@@ -52,8 +52,8 @@ actually set up multiple fixtures very easily for this. You can just
set up multiple fixtures with different names that point to different
configs and pass them in as that named argument.
-To run the tests, from mediagoblin's directory (make sure that your
-plugin has been added to your mediagoblin checkout's virtualenv!) do::
+To run the tests, from MediaGoblin's directory (make sure that your
+plugin has been added to your MediaGoblin checkout's virtualenv!) do::
./runtests.sh /path/to/myplugin/tests/