Hi Guys,

I imagine that this is not a bug but perhaps something that's a bit quirky on my side, but I am getting some weird results:

The strange thing is that running the development server through django the page renders fine (with the Filter and Action menus above the content), but when they run on the production server this happens.

Any ideas?

Thanks

Adam

Hello,

It's really an amazing work how you transformed the admin area with bootstrap, thank you so much for sharing your great work. But the javascript calendar and clock icons are not inject when using bootstrap with my admin area. but when i disable bootstrap they appear here is the code:

 Today | 

I'm using Python 2.7.3 and Django 1.7.1 in a python virtual environment, i already run the command "python manage.py collectstatic" inside the virtual environment shell. it moved all static files to the static directory of my site, and no files are missing according to the browser debugging logs.

so is the problem because of an incompatibility with the version of Django or python I'm using or is it a missing feature in your integration.

Thank yous o much for your support and your very good work.

Fieldsets are shifted and the following fieldset is centered. My code looks like this:

fieldsets = (
    ('Address', {
        'fields': (
            'name',
            'owner',
            ('street', 'street_number'),
            ('zip', 'city')
        )
    }),
    ('Contact', {
        'fields': (
            'email',
            'website',
            'phone',
            'mobile_phone'
        )
    })
)

And the result looks like:

I am using Bootstrap 3 and Django 1.6.5.

Since the start of my new job, I have had problems keeping the pace up to that of the fantastic contributors to my project (https://github.com/riccardo-forina/django-admin-bootstrapped).

As you can see, there are some long standing issues that should be addressed, plus some other trivial ones and PRs that must be analysed.

I'm looking for somebody that can help in these tasks. Of course, chosen people will get moderator rights to this repository. I can also consider moving the project to its own home, effectively detaching it from my home.

Any candidate? I'd like to directly call @jmagnusson, @nsmgr8 and @kwbock as the top 3 contributors to the project.

Hi, this is my first pull request ever... I added a language selector dropdown in the admin menu, after user and before the logs. Code is inside a block. It might not be robust enough, useless in particular for those who don't need i18n support. Anyway let me know if you have some comments or suggestions.

Using: Python 3.4.1 Django 1.6.6 django-admin-bootstrapped 1.6.8

Test foo.models.py:

from django.db import models

class A(models.Model):
    title = models.CharField(max_length=100)
    notes = models.TextField(null=True)

    def __str__(self):
        return self.title

class ABRelation(models.Model):
    position = models.PositiveSmallIntegerField()
    a = models.ForeignKey(A)
    b = models.ForeignKey("B")

    class Meta:
        ordering = ("position",)

class B(models.Model):
    title = models.CharField(max_length=100)
    a = models.ManyToManyField(A, through=ABRelation)

    def __str__(self):
        return self.title

Test foo.admin.py:

from django.contrib import admin
from foo.models import A, B, ABRelation
from django_admin_bootstrapped.admin.models import SortableInline

class AAdmin(admin.ModelAdmin):
    model = A
    list_display = ("pk", "title")
    fields = ("title",)

class ABRelationInlineAdmin(SortableInline, admin.StackedInline):
    model = ABRelation
    list_display = ("pk", "title")
    readonly_fields = ("a_title", "a_notes")
    fieldsets = (
                (None, {
                        "fields" : ("position", "a")
                }),
                ("More info", {
                        "classes" : ("collapse",),
                        "fields" : ("a_title", "a_notes")
                })
    )

    def a_title(self, obj):
        return obj.a.title

    def a_notes(self, obj):
        return obj.a.notes


class BAdmin(admin.ModelAdmin):
    model = B
    list_display = ("pk", "title")
    fields = ("title",)
    inlines = (ABRelationInlineAdmin,)

admin.site.register(A, AAdmin)
admin.site.register(B, BAdmin)

To reproduce:

1. Open change/create view for B model.
2. Collapse first StackedInline #1 (ab relation).
3. Expand first StackedInline, "More info" flickers of a moment - it gets expanded, then goes to collapsed state.

Repead 3-2-3-2.. until eye caches that in fact "More info" with "A title" is expanded, visible for a spit second. The more fields are in fieldset, the more it's noticeable.

Same with Kubuntu 14.04 Firefox 31 and Windows 7 (VirtualBox) Chrome, IE10, Opera, ...

Currently, if messages.warning(), messages.critical() are added manually in view (for example in SomeAdmin.change_view()) they are all rendered inside:

<div class="alert alert-info">

So, warning and critical messages appear just like "successfully saved" info messages. They are hard to notice.

I am aware that <li class="warning"> could be used to style manually, but still, they are in same peaceful blue "alert-info" div...

AdminSite have some new properties to be able to with ease be able to change site header, title etc by just subclassing AdminSite and hook it to the urlconf. That should be implemented to allow to function with Django 1.7 release.

• index_title
• site_header
• site_title

I noticed that you have a test directory and tests are mentioned are mentioned in setup.db. Perhaps you could benefit from automated integration tests? Once you set up a free Travis CI account linked to your GitHub, those would happen automatically once you push anything not labeled with [ci skip] and if any tests fail, you'll get an e-mail. Also, you'll be getting your pull requests tested the same way and you can test for multiple Django/Python versions easily.

It happens when integrating with django-cms 2.4.2 and django-admin-bootstrapped 0.4.1, it breaks all cms admin interface:

Invalid filter: 'moderator_choices' Request Method: GET Request URL: http://localhost:8000/en/admin/cms/page/ Django Version: 1.4.3 Exception Type: TemplateSyntaxError Exception Value:

Invalid filter: 'moderator_choices'

The failing template:

In template /home/ubuntu/devenv/local/lib/python2.7/site-packages/django_admin_bootstrapped/templates/admin/cms/page/menu_item.html, error at line 55

54 {% if CMS_MODERATOR %}

First let me say great job on your work here. I am using this for the second time on a project and I look forward to using the bootstrap3 version.

I am just wondering why the model admin form inputs don't have the boostrap3 form-control class applied to them and just default so squarish looking fields? Is there a specific reason, because it makes them look inconsistent from the rest of the admin.

/cingles/viv/lib/python3.5/site-packages/django_admin_bootstrapped/templates/registration/logged_out.html, error at line 2

1 | {% extends "admin/base_site.html" %} -- | -- {% load url from future %}{% load i18n %}   {% block breadcrumbs %} {% endblock %}   {% block content %}  

{% trans "Thanks for spending some quality time with the Web site today." %}

{% trans 'Log in again' %}

Request Method: | GET -- | -- http://127.0.0.1:8000/admin/logout/ 1.11.4 TemplateSyntaxError 'future' is not a registered tag library. Must be one of: admin_list admin_modify admin_static admin_urls bootstrapped_goodies_tags cache i18n l10n log static staticfiles tz

For me the list view looks like this in a mobile browser (django-admin-bootstrapped 2.5.7, Django 1.8, Chrome 59):

The table is not properly sized to fit the width of the window.

First, thanks for all the hard work that went into this library. I've used it on several projects and really enjoy it.

Today, I'm using it on a project that is Django 1.11.4. I found that the section for including templates to the change form was not working. After much confusion, I found that in Django 1.11 the render_to_string method (used here) now requires a dict instead of Context() / RequestContext().

I added some logging and eventually saw the error: TypeError: context must be a dict rather than RequestContext.

I found these two key sources discussing the matter:

• https://code.djangoproject.com/ticket/27722
• https://docs.djangoproject.com/en/1.11/releases/1.11/#django-template-backends-django-template-render-prohibits-non-dict-context

To resolve the issue, I forked and created a PR. Only after all this effort did I see that this library was capped at Django 1.9 and I haven't tested its complete compatibility with Django 1.10 or 1.11 but it seems to be working well for me now. I wanted to post up this issue in case others were looking around as well.