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)

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 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/ gives 404 error. First MongoDB version without the 404 error meets the "dependency." That's the best I can think of for now.