Re: [mezzanine-users] Possible toinstall Django Reversion for Mezzanine? And 2 questiosn about built-in threaded comments.

[Stephen McDonald]

Hi Tom, answers inline below:

On Wed, Oct 17, 2012 at 1:01 AM, Tom Neville <tom.n...@distilled.co.uk> wrote:

Hi,

A few quick question re Mezzanine - we think it's the right solution for us (we're currently using Django for three different products and Mezzanine seems perfect for replacing our Wordpress setup).

1. Reversion: Mezzanine doesn't have version history built in. We have installed Reversion on other Django projects before, would it be as easy to install it on mezzanine setup and use as it was with our standard django set ups?
   

Give it a try - if you hit any issues let us know. Reports toward the end of this thread suggest it works: https://groups.google.com/group/mezzanine-users/browse_thread/thread/e2faf72164fef143?hl=en#

 

2. Comments: Mezzanine homepage has "Disqus integration, or built-in threaded comments" - I can't find any information on the built in threaded comments - what are they like? Can anyone point me towards some info on them? We'd rather use this than Disqus.

These are enabled by default. Again just give it a try. You can also see an example on the demo site: http://mezzanine.jupo.org/blog/

 

1. Comment reply notifications: do users who post comments with using built in threaded comments get notified by email if people reply to their comments or if other comments are posted?

Not at the moment. There was a pull request that added this feature (I can't find it at the moment) but off the top of my head it was rejected because the implementation had some issues. 

--
Stephen McDonald
http://jupo.org

[C Heathcott]

I'll preface by admitting that my experiments with django-reversion are not comprehensive, and that I'm new to Mezzanine in general.  However, I've created a versioned page app that simply subclasses Mezzanine's Page/RichText and Reversion's VersionAdmin, and I'm able to see/edit/revert among the changes in the history list of such objects.  I still need to investigate what admin template modifications are needed to enable recovery of deleted objects, but otherwise this is a quick and easy way to get versioning.

Now, I've also tried directly hacking on Mezzanine's Pages app by using Reversion's VersionAdmin as a mixin with PageAdmin.  This approach also successfully enables versioning for any objects that subclass Mezzanine's Page.  However, this approach causes the admin to stop using Mezzanine's templates.  I've not yet had time to investigate further, but within the next couple days I'll provide more details and hopefully a solution to this issue.

[C Heathcott]

Reversion's VersionAdmin abstract admin class defines a variable "change_list_template," which defaults to "reversion/change_list.html."  So, in order to use Reversion's VersionAdmin as a mixin with Mezzanine's PageAdmin while still using Mezzanine's change_list.html template, I defined/overwrote "change_list_template" in Mezzanine's PageAdmin and assigned as "admin/pages/page/change_list.html."  So, versioning now works as expected on Mezzanine's built in Pages.  I still need to add a button for recovering deleted objects to Mezzanine's change_list.html template, but that's a minor issue.  Of course, more thorough testing needs to be done, but from these preliminary experiments it seems that Reversion is relatively easy to integrate with Mezzanine.

[Stephen McDonald]

Thanks a lot Chris for taking the time to work this out and report back.

If we need to make a couple of tweaks in Mezzanine to support this, perhaps a few spots where we check for reversion in INSTALLED_APPS and do things slightly differently, then I'd be more than happy to merge those in if you want to set up a pull request.

[C Heathcott]

What do you think about doing something like this in pages/admin.py:

if "reversion" in settings.INSTALLED_APPS:
    class VersionedPageAdmin(PageAdmin, VersionAdmin):
        """
        Versioned admin class for the ``Page`` model
        and all subclasses of ``Page``.
        """
        change_list_template = "admin/pages/page/change_list.html"
       
    admin.site.register(Page, VersionedPageAdmin)
    admin.site.register(RichTextPage, VersionedPageAdmin)
else:
    admin.site.register(Page, PageAdmin)
    admin.site.register(RichTextPage, PageAdmin)

[Christian Bahls - gmail.com]

Wow that would be a welcome addition for mezzanine for our ngo :)

Christian

[Stephen McDonald]

Looks good Chris.

I think there might be some other parts in the code base that depend on the name PageAdmin, so it'll probably be better to do something like:

    class VersionedPageAdmin: # etc

    if "reversion" in settings.INSTALLED_APPS:

        PageAdmin = VersionedPageAdmin

    admin.site.register(Page, PageAdmin)
    admin.site.register(RichTextPage, PageAdmin)

Assuming that actually works, everything that uses PageAdmin will pick up the reversion stuff.

[C Heathcott]

Reassigning PageAdmin to VersionedPageAdmin is a problem since VersionedPageAdmin, as I defined it above, extends PageAdmin.

I could define VersionedPageAdmin without extending PageAdmin, though that would not be DRY since VersionedPageAdmin would need to define all the same methods as PageAdmin.

Perhaps all the functionality of PageAdmin should be abstracted out into a third class that both PageAdmin and VersionedPageAdmin can extend?

As an aside, BlogPostAdmin, will need to be handled separately anyway since it doesn't extend PageAdmin.

[Stephen McDonald]

Perhaps this logic needs to sit around the DisplayableAdmin class? Off the top of my head pages and the blog use that.

[Ahmad Khayyat]

On Wednesday, October 24, 2012 4:00:01 PM UTC-4, Stephen McDonald wrote:

 

Perhaps this logic needs to sit around the DisplayableAdmin class? Off the top of my head pages and the blog use that.

Did anything come out of this?

[Christian Bahls - gmail.com]

Similar question from here :)

Christian

[Paul Whipp]

Old thread but I've just implemented this and successfully deployed it to a commercial site.

In short, I redefined the PageAdmin class as DefaultPageAdmin and then assigned either that or a specialised VersionedPageAdmin to PageAdmin depending upon whether or not django-reversion is loaded. I also conditionally included the reversion middleware so that front end editing creates versions too.

The modified admin file can be seen here and the modified project template settings file here. Unfortunately, I don't think I can put this up for Stephen as a pull request because my fork is of kniyl's model translation stuff. Nevertheless, applying these changes should be pretty straightforward if you need them.

I've not modified the template to include the 'restore deleted pages' option because there are complications regarding the restoration of pages where the 'parent' page has been deleted that I've not yet had to address. If necessary I'd probably just set it up to restore the latest version of any deleted parents when restoring.