• Members 17 posts
    Aug. 25, 2013, 7:47 a.m.

    Does Misago have the capabilities to serve as an addon forum application for an existing python application? If so then how would one go about merging them together. Thanks!

  • Aug. 25, 2013, 10:09 a.m.

    Integration with existing projects with glue scriptsis not supported and will never be.

    In future Misago will provide API gateway that will enable other apps to fetch certain data from forums in order to display it page and tell it to automatically create discussion threads for articles.

  • Members 3 posts
    Sept. 1, 2013, 2:51 a.m.

    I don't see a reason why this should not be possible ... Even askbot cannot fully integrate with another websites. We are still waiting for an app that will do this job well ...

  • Sept. 1, 2013, 3:16 a.m.

    Then consider this problem: You have saloon and truck. How are you going to merge them into one car without heavy modifications in both of them?

    The reason why "nobody" big does this "well" is simply because there is no way to do it "well" (as in elegantly and efficiently). You either limit featureset delivering only one thing (say, forums and posts) that integrates well because it has no expectations towards sessions/permissions/users system, or complete solution that delivers package of closely tied features coming from many domains (users, permissions, sessions) that makes it extremely hard to replace parts of system with parts from other system.

  • Members 3 posts
    Sept. 1, 2013, 4 a.m.

    Thank you for the reply, I understand now. I just really liked this forum and would love to integrate it with my website. BTW, take a look at this website www.biostars.org/ they made a very nice integration between a Forum, Q&A, Planet and some other things all in django. It's probably more simple that this forum but also a good bunch of code.

    Congratulations for this forum, I think I will install it as a standalone and try to integrate using an iframe ... Ugly solution but at least I will provide a good forum for my users.

    Best Regards and good luck with the refactoring!

  • Sept. 1, 2013, 4:36 p.m.

    I've gave their code a skim and from what I see they are not really integrating with other stuff. Instead they are using their own content framework to act as either Q&A or Forum based on active tab of their site.

  • Members 3 posts
    Sept. 1, 2013, 5:36 p.m.

    www.biostars.org/ is all Q&A actually.

    About the integration, I made my own forum a while back. It's full featured, it has the same features as misago anyway and I can tell there are ways to ease the integration.

    Since Django 1.5 you can implement your own custom user model. You can also create an abstract model to integrate on existent user apps.
    ie: misago user model would become:

    class MisagoUser(models.Model):
        avatar_type = ...
        avatar_image = ...
        class Meta:
            abstract = True

    Then, it can be extended:

    class User(AbstractBaseUser, PermissionsMixin, MisagoUser):
        username = ...
        username_slug = ...
        email = ...
        email_hash = ...
        password = ...
        password_date = ...
        USERNAME_FIELD = 'username'
        REQUIRED_FIELDS = ['email', ]

    So, it would be possible make use of the misago.user app (login, register, etc) or else extend the model and use your own user app.

    Also, named urls can use prefixes to avoid collisions with other apps, ie: misago:login.

    urlpatterns = patterns('',
        url(r'^forum/', include('misago.urls', namespace="misago", app_name="misago")),
        # Uncomment the next line to enable the admin:
        url(r'^admin/', include(admin.site.urls)),

    @rafalp told me about the idea of switching to django's sessions. I'm not sure if misago's permissions and django's permissions can coexists, or misago's permissions would have to be dropped. There might be other issues Im not aware of.

  • Sept. 1, 2013, 7:29 p.m.

    Currently only thing I can surely say about rolling in django.auth is that I don't mind it as long as user accounts behavior remains same as it is now. This probably will mean duplication of user groups/permissions functionality as Misago takes different approach to user permissions than Django, but if others don't mind that, then all right. Misago models already enforce custom app prefix ("misago_") which means Misago models won't conflict with other apps models.

    Other things are matters that are not for discussion like dropping Misago admin for Django one for Misago models or dropping Jinja as templating engine. Also off table is fragmentation of Misago reuseable apps that can be used alone. Disabling some features by removing their misago.* entries from INSTALLED_APPS may be possible, but is not goal. Same can be said about adding only picked few apps from misago to your project. Adding misago.forums to your INSTALLED_APPS will not work and it is not my design goal to make it work.

    Only problems I see that would need solving are:

    1. Template engine conflicts - Misago uses Django_Jinja for templates
    2. Storing templates - Misago stores templates outside of apps to make them easy to discover for those interested in customizing them, but this may make templates collide with other apps
    3. Static files conflicts
    4. Context processors conflicts
    5. Middlewares conflicts

    However Misago is still in development, it's not complete, it's being changed frequently, integrating Misago with other Django projects will have to wait for feature complete stage before I'll be willing to get serious about it.

    For now, I've changed roadmap a little by adding milestone for code refactoring to make it compliant with Django way for laying app, use django.auth and django.sessions as well as make misago-native settings easier to merge into exisiting django projects:


  • Oct. 18, 2013, 9:17 p.m.

    I've tought about this a lot recently and I am convinced that this is not an healthy usecase for Misago. It's simply too complex to integrate with existing projects without forcing major amount of work to be put in both project and Misago's codebase in order to make them work together.

    What I am considering instead is making it easier to use existing Django apps as extensions for Misago. So if you want to add, say, galleries to Misago, you pick existing Django app, throw it in, modify templates to fit your design/link to new features and enable django admin to be able to admin your newly installed app.

    Once you have learn'ed how Misago is setup and how it differs from Django, Misago itself could become "higher-level" foundation for building sites around Misago forums.

  • Members 2 posts
    Dec. 15, 2013, 2:02 p.m.

    This post is hidden. You cannot see its contents.

    Hidden by rafalp on Dec. 15, 2013, 2:03 p.m..

  • Dec. 23, 2013, 11:29 p.m.

    Hey, let's actually turn this into dev discussion. :smile:

  • Dec. 24, 2013, 12:08 a.m.

    To sum up current situation: Many folks showing interest in Misago do it because Misago is Django-powered. They then realize Misago cuts itself from Django ecosystem and find that turn-off for them.

    I admit that decision to turn back on Django world was mistake. Over time Django has grown impressive collection of ready apps around it and it would be awesome if it was possible to use them in process of building your site.

    This is currently impossible as Misago is violating Django "contract", however during next code cleanup steps will be taken to change that.

    I'm still disliking Django Admin and Django permissions, but they are de facto standard 3rd party app developers expect to be present when they are developing their apps. So while Misago will keep its own Admin component and permissions framework, Auth component will be build upon Django's one and User model will be 100% compatible with Django Admin, Groups and Permissions, so when you decide to use 3rd party apps, all dependencies will already be here for you. Just turn on Django admin and make sure it's using different admin link than Misago one.

    Only "gotcha" I could think of here would be adding fields and features to Misago user model. If you edit model itself, you will break Misago's migrations so you will probably want to roll in custom extra profiles with 1:1 relation to this model + signals to keep stuff in sync.

    In addition, Misago uses Jinja2 for its templates, which allows for different approach to adding features to templates. Those features will need to be implemented again as django tags or filters for those who will want to stick to Django templates in their apps.

    Also implementation of some things will change in the spirit of "get outta ma way", so they shouldn't get in your way and surprise you when you are writing your site.

    Naturally, working as stand-alone app still remains important use-case for Misago, so language-agnostic integration layer is still planned for those who want to integrate with solutions from outside of Django or even Python world.

  • Members 9 posts
    Jan. 2, 2014, 1:23 p.m.


    2-5. can easily solved by using basic namespacing everywhere.
    For templates, you should put everything under templates/misago/ rather than templates/ directly. Same works with static, just put every static files under static/misago/.
    You can find this in Django documentation at "Template namespacing" note.
    For context_processors, I don't see how is that a problem? As I see right now, context_processors.py is under misago directory, so it's namespaced. Same for 5 I guess?

  • Jan. 2, 2014, 5:03 p.m.

    Thanks for taking minute to take the voice in this thread, @Walkman

    My concern back when I was writing that lied in fact that Misago defines massive amount of variables via context processors, but looking at this file now, plenty of those variables will go away when Misago apps are dropped and Django counterparts are used in their stead, and other variables are not that generic to be likely to collide with 3rd party apps.

    As for templates and statics, currently I'm convinced I'll put them all into same misago/ directory that will hold Django apps used by project. Then some magic in default config will register those directories automagically on django boot.

    And yes, while originaly I've disliked idea for namespacing them for making dir tree too deep, that's simplest and nicest solution for the problem, so it will go in.

    Preffered approach to customising Misago looks will be adding your own template/static dir to config before misago ones, and creating custom version of tiles that template loader/static collector will use instead of default ones.

  • Members 9 posts
    Jan. 2, 2014, 5:15 p.m.

    Oh, I misunderstood the problem, sorry. In the case you worry about collision with 3rd party apps, you can still use poor man's namespacing system: prefix context variables with misago_ :smile:

  • Feb. 12, 2014, 6:31 p.m.

    I've decided to bite it in Misago 0.6 and here's what I've done so far:

    • dropped Jinja 2 templates for sake of Django templates
    • moved templates to 'misago/' dir
    • moved links under 'misago:' namespace
    • moved default assets to 'misago/' dir
    • added 'shared_403_error_handler' and 'shared_404_error_handler' decorators that can be used by project defining its own error handlers but still wishing for 403/404 errors raised by forum links to be handled by Misago

    Other things on todo are dropping Misago sessions/messages for sake of Django ones, and making Misago auth component based on Django's auth framework. The goal is to minimalise number of places Misago may conflict with Django apps or other projects. Django admin will also be supported for those who want to use it to admin their apps, but Misago will keep its own admin panel.

  • Members 9 posts
    March 15, 2014, 11:50 p.m.

    I'm just curious; how are you doing with this? Will it land in the next release?

  • March 16, 2014, 11:19 a.m.

    Yep, all those things will land in 0.6 release which is big cleanup of existing codebase.

    When's 0.6 going to happen? Not sooner than Django 1.7. 0.6 will change a lot about models so I would like to have one annoying update (data & south deprecation) instead of two.