Attached is a screenshot of the current Delete confirmation page.
This is the page you see after clicking "Delete" on a media page.

The whole thing is kind of a stop gap solution, but for now I'd
like to suggest these changes:


-  "Save changes" on the input button should be changed because
   you're not saving changes. Something like "Delete permanently",
   which describes the action and mentions its severity.
-  Remove the "If you choose yes, the media entry will be deleted
   permanently." and "Confirm" text.
-  Replace the two radio buttons by a single checkbox that says "I
   am sure I want to delete this"
-  Add a thumbnail like we do on the Edit page. This changes the
   process to:
-  User clicks Delete
-  User arrives at Delete confirmation page
-  User is asked if he is sure and has to check the box to say
   "Yes, I am sure"
-  User finishes the process by clicking "Delete permanently"

Right now the Create Account page has these labels/forms and
descriptions:

**Username***This is the name other users will identify you with.**Password***Try
to use a strong password!
**Confirm password***Type it again here to make sure there are no spelling mistakes.**Email address***Your
email will never be published.

I think these are still my placeholders.


-  Some of these could go (especially the one under "Username" I
   think)
-  Some of them should be changed to something more
   useful/descriptive. Which ones though, and what should they be
   changed to?
-  There are probably several other form pages that could use
   descriptions, but we should open additional bugs for those (like
   this one:
   `http://bugs.foocorp.net/issues/467 <http://bugs.foocorp.net/issues/467>`_)

I unwittingly triggered an extra MongoDB version dependency because
I was running MongoDB v1.2.2 on omgmg (bad Caleb, bad!). The
symptom is as follows:


-  media items show up on root.html, but the link to
   /u/this-is-my-slug gave 404 errors. However, the
   /u/objectid\_string link worked. That is, until later Elrond found
   one for which the slug link 404'ed and the objectID link 500'ed. I
   don't have the traceback.

Chris investigated, figured out the problem was probably a MongoDB
version issue, cleaned up the mess by upgrading MongoDB, and
narrowed the issue down to older MongoDBs not being able to drop
indexes...or something like that. The exact cause remains unknown,
but what is known is that there is another MongoDB version
dependency lurking in the inky shadows somewhere between v1.2.2 and
v1.8.3.

If the dependency is met by v1.3 then the docs are correct.
Otherwise the docs are incorrect.

We could narrow down the version dependency in two ways:


1. Actively by stepping through MongoDB releases on one machine
   from v1.2.2 until the ambiguously defined issue is resolved.
2. Passively by keeping an eye out for this error in IRC, and
   asking users to report their MongoDB versions here before
   updating.

I'm happy to do `#1 </issues/1>`_ using the old omgmg envball and
Chris's 404 test (below). Meanwhile please consider #2.

test -
`http://omgmg.dyndns.org:6543/u/isylja/m/spielkind-2/ <http://omgmg.dyndns.org:6543/u/isylja/m/spielkind-2/>`_
gives 404 error. First MongoDB version without the 404 error meets
the "dependency." That's the best I can think of for now.