Changed "by a admin" to "by an admin"

Fix typo ("An" before a word starting with a consonant)

I was tasked to create a product that would be out-of-the-box available to our users, so I added the attributes in a data migration but I had a hard time finding any resource that describes adding options via code and had to dig through Oscar's code on GitHub to figure this out. People would benefit from an addition like this, at least save time from digging through code to figure this out.

Added usecase for oscar_fork_app command with dot path for forking to project_root dir. 
Added in #1717

Added a reference link of usecase fork_app management command.

I found some docs changes in my git stash that seemed useful. We removed
support for support when removing Django 1.6 support, so we can remove
mention of South.

This fix was supplied in #1686.

Fixes #1686.

I also updated the handling migration section of the general upgrading
doc to use native migrations lingo instead of South's.

This commit removes a few long deprecated bits in the docs and in
code. It also updates the
release notes to include those removals, and highlights what has been
deprecated in 0.8. And it fixes a Sphinx warning when building the docs.

Had to rename to new method name and re-add a link.

Registering receivers is a tricky business pre-Django 1.7 as they get
registered at the same time when models get registered, but require the
sending model to already be in the app cache. It's surprising we don't
see more issues!

Recommendations:
* Avoid calls to get_model in modules that get called during app init at
  all cost
* Don't use get_model in your own code. Just import directly.
* Switch to Django 1.7 :)

This commit probably fixes the issue in #1205. But get_model calls to
fetch the category, product image and stock record will all fail,
because receivers listen to their signals.

This commit also moves the catalogue receiver into it's own receivers
module, because that's how we do it elsewhere. That won't make a
difference to the issues though.

A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.

Copy-paste fail.

As it came up on the mailing list again, I've clarified a few more
scenarios of what needs to be done with migrations when upgrading.

This includes two examples for product attributes.

Also fixes two "document not referenced" warnings.

Fixes #794.

The recently introduced management command makes customising easier, and
the docs have been updated accordingly. The how-tos could still do with
updating to the new command, but at least the main docs are current.

These days, to override a mixin it is only required to override the
OrderPlacementMixin; overriding the app and view is not necessary. It is
just a generic case of overriding a core class. A dedicated how-to is
thus unnecessary.

As overriding a core class is the general goal of any advanced
customisation, it has been merged into the customisation section, which
has been given an overhaul as well.

The section regarding modifying apps will be re-added as part of a
higher-level "the Oscar application tree" kind of document.

It's such a core concept, it deserves a dedicated document. Moved some
of the "why" from the how-to into it as well.

It's getting easier and easier to customise parts of Oscar; the
customisation section can do with a rewrite because of it. Added to my
to-do list.

The function essentially does two things:
1. it applies a prefix - the first argument - to the given urls. In no
   instance a prefix was given
2. it calls url() for simple tuple or list elements in the given iterable.
   Cases where such a tuple or list was passed to patterns have been
   replaced by direct calls to url()

2 allowed for both calls to url() and simple tuples to be listed in
get_urls() and similar places. This allowed for unnecessary variation.
Always calling url() makes the url lists look less noisy and more uniform,
allowing the reader to focus on the actual differences of the urls instead
of superfluities.

django.conf.urls.patterns will also undergo deprecation starting from
Django 1.8. This commit anticipates that change.

https://docs.djangoproject.com/en/dev/releases/1.8/#django-conf-urls-patterns

The new recipe has a working example on customizing the behaviour Oscar
does when a customer places a successful order.

This is pretty much what I use for bikepartsmarket.com. If this gets
some more eyeballs, it might mature enough to move into Oscar core.

Fixes #1266

Just crossing items off my bucket list.

It's a nice app to handle non-blocking email sending.

Two links needed to be corrected.

The customisation section required some changes as it's not often
necessary to override the root application instance to change URLs or
views of subapps.

Those documents lived in ref/, but really aren't reference documents.
Topics/ is a more appropriate place for them.

With details of new prices/availability structure.

* Better wordings for the individual steps
* Mentioned necessary copying of migrations directory
* Fixed wrong prerequisites in examples
* Glossary typo fixed

The mailing list raised the issue of having to include the models.py to
replace a Form. The docs weren't clear, so I've taken the opportunity
to:

* merge 'INSTALLED_APPS' section and 'models.py & admin.py'.
* change misc wordings and add clarifications

It's a great idea, but confusing when empty. Replaced by links to
how_to_customise_models which contains some explanations.

Attempt at making it clearer what needs to be done for what kind of
customisation. Created a new topic that lines out the prepatory
steps that need to be taken, and moved duplicate information from the
how-tos into the new topic.