1038878 - Refactor Document View to Allow for Realistic Preview

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Wiki pages, defect)

Description

[David Walsh :davidwalsh]

What did you do?
================
The preview functionality on MDN is too primitive at the moment.  Any preview, using a macro that references environment properties, bombs because the endpoint for all previews is "/{lang}/docs/preview-wiki-content".

What happened?
==============
(Not this)

What should have happened?
==========================
Ideally we could do "/{lang}/docs/path/to/doc$preview", posting the content to said address and using the document view to run the content through the same processing as a normal document.

Is there anything else we should know?
======================================
This issue is due to the environment var problem:  https://bugzilla.mozilla.org/show_bug.cgi?id=1034598

Comment 1

[David Walsh :davidwalsh]

There are a few issues to consider:

1.  We need to keep the document view as fast and efficient as possible as it's the most used view on the site.

2.  "/{lang}/docs/new" doesn't have a real "path" yet, so we'll need to figure out how to display that preview.  Same for new translations.

Comment 2

[Jannis Leidel [:jezdez]]

So what I've found so far isn't encouraging, my plan was simple:

1. add a new "is_preview" field to the revision model
2. modify the revision form to have an optional "preview" button that posts to the same endpoint like the save button
3. modify the document edit view to check for the existence of the preview button in the POST data and conditionally set the saved revision's is_preview flag to True
4. redirect to the document view with a special "?preview=<pk>" GET parameter that forces the document view to fetch the revision to show using the given primary key id
5. show a "save" button on the document page that when clicked submits a form
6. add a new view called "save_preview" that receives the POST data of a document's preview safe button and checks if the current user is the creator of the preview revision
7. if yes, set the is_preview flag of the revision to False, call make_current on its document and redirect back to the main document page

This has the potential to leave lots of outdated preview revisions, so I would also add a cronjob that clears out all preview revisions after 1 or 2 weeks, just to make sure we don't have senseless stuff in the database. That fact should be noted on the document view when showing a preview revision.

This plan is generally possible, but specifically first requires some refactoring of the aforementioned views.

Comment 3

[luke.crouch]

Nice spelunking :jezdez. The overall plan seems like a good refactor - possible, reasonable, and challenging. :)

In the past we've also discussed having a "published" status for revisions for certain documents. I.e., revisions to some docs aren't shown unless/until a staffer/editor approves them. I only mention it here because the function will be very similar at the db level.

Re: outdated preview revisions, we should also check the "based_on" field of revisions to make sure there isn't a unique constraint? In case user A starts a preview with based_on: 123 and user B also starts a preview with based_on: 123.

Comment 4

[James Bennett [:ubernostrum]]

A way to get around the conflict issue, and maybe a cleaner way to implement this, would be to have Wikipedia-style user sandboxes. That is, when you're working on something, we could save copies of it to a URL that's under your user page, which lets you work without fear of conflicting with someone else's stuff.

That would solve the problem of where to store previews, and possibly could grow into a full-fledged feature when someone wants to do major editing work, to pull an article's current content into their user namespace, then ship it back over to the main MDN namespace when done.

Comment 5

[Luke Crouch [:groovecoder]]

I like that too. In fact, I just suggested someone do this when they asked how to test drastic changes to a high-profile page. (Apps center I think).

Comment 6

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.