I have flatpage attached to multiple sites. Its admin preview chooses
arbitrary site, which is quite obvious after debugging up to lines 35-36 of
django.contrib.contenttypes.views.shortcut().
What would be the best way of fixing this problem?
I see that the shortcut() function takes a request object, so I could just extract host from there, but I prefer to not patch the live server.
I haven't looked at catching admin url yet, so maybe someone can suggest some nice solution?
In my opinion, this could be considered a bug in Django, and at least a partial fix would be to check if the current SITE_ID is one of the sites related to the object, and if so use that one instead of an arbitrary one. You could file a ticket with a patch.
To fix it without patching Django, you might look into overriding the admin edit-form template for the flatpages model so that you can put the URL you want into that link instead of the default one that goes to the shortcut view. I haven't looked into it enough to know how clean that would be.
Another option might be to monkeypatch the Flatpage model with a get_absolute_url method that actually returns a complete absolute url, including the domain, based on Site.objects.get_current().domain.
Related
Just learning django here, going through their website's tutorial.
When they take you through their admin panel, it's like, wow, all I have to do is define a model and django will give me a cool web page like this?
But that doesn't seem to be the case--it seems as if all that cool automatic functionality is only inside the admin panel. It seems that, if you want to have a cool add/change form, for instance, a form that looks and acts like the one in the admin panel, you're going to have to do all the layout and cool features by hand.
Am I wrong about this? Is there some way to make something that looks and works exactly like the admin's "change record" panel, but at your own url?
You are right, but I guess your expectations might be wrong.
Django's automatic admin site is one of the things that makes it very powerful. For example if you're building a large site, normally you'd also have to spend a lot of time to create a admin site, I mean A LOT! So Django provides a useful admin site automatically and it does a good job, which is great.
On the other hand your actual site is always going to be different so Django doesn't provide you the similar "automatic" ways as you expect. But it provides you the same building blocks, like ModelForms, ClassBasesView etc.. And of course, you have to put them together. But it's so much easier and faster to build sites with those blocks then doing it by yourself.
That being said, if you really like how admin site is looking and behaving then you can copy and use them on your main site, which will still require you to do some work.
(Couldn't comment, lacking reps)
I have a lot of apps running on my site and I was wanting to make all the views accept a certain kwarg without having to go in and edit them all manually? Is there a way to do this?
I suppose I should add it into the django base view class somewhere, but I am unsure exactly where to add it to in that?
Any ideas?
EDIT:
What I am trying to do is have translations set in my db under a certain model and then have the site default text areas be displayed in a certain language based on the url...
/eng/some/url
/esp/some/url
those two urls would display different languages, but I have to capture the variable and put it into each and every view which is quite cumbersome
Django already has some i18n support in urls, check it out. You need to activate django.middleware.locale.LocaleMiddleware by adding it to your settings.MIDDLEWARE_CLASSES and to tune your urlconf a bit by wrapping your urls with i18n_patterns.
The complete example is given in the docs, I see no sense copying it here.
I have just deployed a django site, and upon changing the value my DEBUG variable to 'False' causes my admin page links to change from active links to simple text.
An attempt to go directly to what I know should be the URL causes a 'TemplateDoesNotExist'.
I am sure it's not a permissions issue with Apache, I feel it is something to do with my admin configuration though I have no idea what.
I figured it out. Here is a reference for anyone else who might find themselves with this problem.
I was using what must be a deprecated method of defining my Admin models - I put them all in models.py, instead of creating a separate admin.py file for each application.
When learning django, there are plenty of tutorials floating around that recommend or give examples that use this method. Apparently this is no longer a good idea (at least not as of Django 1.4). It could probably be wrangled into working with some template hacking, but it is is probably cleaner and definitely simpler to just follow the latest conventions and create the admin.py file.
I thought I was saving time by just cramming it all into one file "for now" but without some of the magical debug-only template loading, this solution failed.
Hope this saves someone some frustration!
I know this question's been already solved.
But in my case, coming from django 1.7 to a server that runs django 1.6, I had to add
admin.auto_discover()
to my urls.py.
Well, I had added this line to the end of urls.py and django admin was all characters !
Moving it to top up the file, above definition of urlpatterns, fixed the issue.
Hope this helps :)
I am writing a Django application and using the built-in ORM. I would like to create functionality to provide a form but the template for that form needs to be built on admin side of the application and can change over time.
For instance, initially they have a form that asks for first name, last name but later if they decide to add birthday field admin should be able to go to this template page add birthrate as new field and on client side, users start seeing it. Is there anything already in place that can be used? I was thinking of using something like this but decided to check here and see if there is something better available.
Is it this what your are looking for?
I have never heard about any library for that, because you have pretty much different approaches to handle that!, but check the link, he is explaining better those approaches.
A company I'm looking at claims to have made the website for an airline and a furniture store using Django, but when I look at the sites, there is no indication what the underlying web technology is. How can you tell?
This is quite an old question, but I don't see any canonical answers. As the other answers have noted though, there's no sure-fire way to know, and if someone wanted to hide the fact that they're using Django, they can. That said, you can always do a little detective-work and determine with some confidence whether it uses Django or not. If that's your goal, here are some strong indicators you can look out for:
Admin Panel
First and foremost, check if the site has a /admin/ page. If it does, and it gives that familiar Django admin login page, you're 99% sure (unless someone went through a lot of trouble to make it look like Django).
Forms
There are a number of things you can look out for in forms:
Form fields with id attributes starting with id_
Check for a hidden field with the name csrfmiddlewaretoken
If the site has a formset, check for -TOTAL-FORMS and -DELETE hidden inputs.
Cookies
If the site uses the contrib.auth package for authentication, you will probably see a cookie called sessionid being set when you log in.
Forms will also probably set a cookie called csrftoken.
Trailing Slashes
Trailing slashes after URLs, and/or redirecting you to the page with a trailing slash if you try to go to one without it. This is Django's default behavior, and to my knowledge not extremely common in other frameworks. Note, though, that it can be easily deactivated in Django.
Error Pages
Failing all this, or still not being convinced, you can try to force error pages, and try to learn something from that. Go to an unmapped URL with a 404 page, and see if DEBUG still happens to be true (in which case you should probably notify the owner that they're not being very secure about their site).
You can try a few things, such as attempting to find error pages, and checking the default location of the administration panel that Django creates, but overall there's no way to determine what technologies a given site is using.
See also: https://stackoverflow.com/questions/563316/is-there-a-generic-way-to-see-what-is-a-website-running-on/563335#563335
Look for the csrf input box. This is present on any forms. But this can be turned off though not very recommended. Also if it's an old version of django this may not exist. But if it's there it's a strong indicator.
This is present on any page that have a post form. And it looks like this:
<input type='hidden' name='csrfmiddlewaretoken' value='3b3975ab79cec7ac3a2b9adaccff7572' />
Navigate to a page with a formset, and check if there are *-TOTAL_FORMS or *-DELETE hidden inputs.
That doesn't prove that they are using Django, but might be a clue that they are (with the mentioned model formsets).
Try to navigate to some 404 error page, or something of that sort. Chances are slim, but try to find a default django error page.
You can also try to login to www.website.com/admin and see if you get the default django admin page.
Other than that, if that didn't work, then you just can't.
There are no reliable indicators to my knowledge but you could check the /admin/ URL to see if you get the standard admin app or sometimes the feed-URLs use a common prefix compared to a common suffix (although this might not be an indicator at all but just a preference of the developers).
Trying to trigger a debug page (either via a 404 or using some broken input that might case an internal error) might also be a good way (although this acts more as a test of competency of the original developers and admin than anything else :-) )
Could you ask the airline and / or the furniture store? I'm guessing that you want to know if this company has good experience in django, I think it is reasonable to ask for references if you are considering working with them.
The other companies may be quite happy to discuss what technologies were used - some are and some aren't, but it's worth asking.