Has some imperfect styling that increases the entire nav area's height, this'll fix it:

li form.trac-logout { display: inline-block !important; }
li form.trac-logout button {
	height: auto;
}

If a user is using "DjangoProject Login", Trac should link to https://www.djangoproject.com/accounts/password_change/ somewhere.

When presented with a Trac error, code.djangoproject.com says "To that end, you could create a ticket." (see screenshot) with a link to Django's Trac ticket tracker. After using the link to report code.djangoproject.com tickets (see https://code.djangoproject.com/ticket/24216) I was told I should instead use https://github.com/django/code.djangoproject.com/issues. I think it would be helpful to update this message to reflect the preferred ticket tracker.

Recaptcha module does not include "Send" button. Experienced on Firefox.

I think it's quite common type of problems for any framework / program. Can't find it, the only remaining option is to use broad "Uncategorized".

The change from django/djangoproject.com#272 was never reflected here.

I think the CSS files need to be copied from djangoproject.com but I'm not sure how to do that.

I was trying to see the list of previous versions of the page https://code.djangoproject.com/wiki/CommitterTips but there is no link to this list anywhere on the page. The only way I could follow its history was to use the highly non-obvious "last modified" link to get to the diff of the last change, and proceed from there by manually editing the version number in the URL.

In the timeline page, the element to choose the date hides other content, see image below and imagine a changeset that occupies the full line (I didn't find an example today).

See https://code.djangoproject.com/ticket/24096#comment:6
issue #22 may be related.
(couldn't get the image to upload for some reason... this one is from a different ticket, url updated)

When using a quote in a ticket's description:

Doing something
> Like this for example

It results in the quote being doubly outlined, like so (see https://code.djangoproject.com/ticket/25166#ticket for a live example):

I found out this option on https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/
In other contexts, the login displays a popup with username and password, and no clear way to login using github.

These days you can enable a dark theme on Firefox. In addition to inverting most of the browser's chrome so that it's black, dark themes also invert the input elements on every page so that by default you're writing white text on a black background. (I find this to be nuts, but the theory is that the input elements are drawn by the OS, and should match the theme — fine, whatever.)

Anyway, this works fine much of the time, but lots of sites assume a light theme or have never tested a dark theme. Among such sites is code.djangoproject.com. On this website, if you have a dark themed browser and you type into the input box you get white text on a white background. Why? Because somewhere in the CSS the background of inputs and text areas is set to white. This overrides the dark theme, which would normally make the background black.

That can be OK, but code.djangoproject.com doesn't set the color of the text in these elements, so you get the default from the theme, which is also white. The result: White text (from the theme) on a white background (from the CSS).

The solution is either:

1. Remove the background color from the CSS so that the theme can do its normal thing, or
2. Explicitly set the color of the text in input elements and textareas.

I tried to sort this out, but couldn't find the rule in the scss file. Weird. Anyway, hopefully this is a super easy one, if I've explained it properly.

On pages with the #dev-warning, #outdated-warning, .doc-floating-warning, etc. fixed bar at top, some JS is being used to fix positioning after load so fragment links (foo#section) align you properly (so the heading isn't obscured by the fixed bar at top), but... it's not very reliable, and requires JS.

Example pages that should have this yellow or red bar at top:
https://docs.djangoproject.com/en/dev/releases/1.7/#app-registry-consistency
https://docs.djangoproject.com/en/1.7/releases/1.7/#app-registry-consistency

You can compensate for such top bars without JS, with CSS alone kinda like this:
.section > span[id]:first-child { padding-top: 38px; }

Clicking 'logout' is ineffective - if you click 'DjangoProject Login' afterwards then you are logged straight back in again without being asked for any username or password.

I am using Chrome 46.0.2490.86m (64-bit) on Windows.

After I submit changes (with external link added) to wiki article, I get "Trac Error", with two red blocks – the first one is empty, the second one stands "Submission rejected as potential spam; SpamBayes determined spam probability of 99.31%".

Cross-posting this issue from #24005 in Trac.

The text selection colour is too light. Please darken it up a bit.

After logging in with github, the navigation looks like this:

It used to say "logged in as xxx" and the "DjangoProject login" link was not there.

Maybe that's related to the recent Trac update?

In the main page of section "code", the main text has a font that seems to be different from the website.

In the chrome, the computed font in the main text is

font-family: sans-serif;

but the computed font in the sidebar is

font-family: Roboto, Corbel, Avenir, 'Lucida Grande', 'Lucida Sans', sans-serif;

Hello!

I tried to login to code.django.com with my GitHub account. After authorizing django, I get redirected to https://code.djangoproject.com/github/oauth?code=[...]&state=[...] which redirects me to the same location again, and again, and aga—.

Direct link to login (if you want to test if it works or not): https://code.djangoproject.com/github/login

I cannot reproduce it on Chrome. Only on my firefox profile.

Firefox Profile

Your user agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Other HTTP headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: fr,en;q=0.8,en-GB;q=0.7,en-US;q=0.5,tr;q=0.3,de;q=0.2
Host: next.duckduckgo.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
COOKIE: 5=2; aj=m; ad=en_US
DNT: 1
UPGRADE-INSECURE-REQUESTS: 1

Chromium Profile

Your user agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
Other HTTP headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Host: duckduckgo.com
Referer: https://duckduckgo.com/
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
UPGRADE-INSECURE-REQUESTS: 1

Note: I "disable" (target URL is put instead of previous URL) HTTP referrers if the target base domain is different from the previous one.

Edit: it looks like the referrers are causing this infinite loop. Disabling this module fixes it. But this issue shouldn't occur—still.

The idea is to add something to tickethacks.js which translates the "Has patch", "Needs documentation", etc. flags to a prominently displayed paragraph that explains how to move the ticket forward.

For example, "Has patch=Yes" and the rest "no" would say, "To move this ticket forward, a community member needs to review the patch using the patch review checklist and either mark the ticket as "Ready for checkin" if everything looks good, or leave comments for improvement and mark the ticket as "Patch needs improvement".

I'll be happy to provide further guidance on this for anyone interested in tackling the implementation.

Hello,

I can't access trac website. I got the following error:

Traceback (most recent call last):
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/api.py", line 514, in send_error
    data, 'text/html')
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/chrome.py", line 968, in render_template
    message = Markup(req.session.pop('chrome.%s.%d'
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/api.py", line 316, in __getattr__
    value = self.callbacks[name](self)
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/main.py", line 268, in _get_session
    return Session(self.env, req)
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/session.py", line 206, in __init__
    self.get_session(sid)
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/session.py", line 235, in get_session
    self.bake_cookie()
  File "/home/www/trac/venv/local/lib/python2.7/site-packages/trac/web/session.py", line 214, in bake_cookie
    assert self.sid, 'Session ID not set'
AssertionError: Session ID not set

But I can access it in private mode

Thanks,

Originally reported here

I am using Firefox 35 on Fedora 20.

Every time I log in by clicking "GitHub Login" near the top of all code.djangoproject.com pages Trac reports an internal error and I am presented with the error page attached. If I navigate away from this error page I am actually logged in, so this error doesn't stop me from using the site as a logged in user. You can see in the screenshot it says "logged in as jdufresne".

I do use various Firefox add-ons, so perhaps that may be an issue? Beyond typical web developer add-ons, my add-ons can manipulate cookies and HTTP referer. I do have cookies enabled for .djangoproject.com and .github.com so I don't think that is it.

I have reproduced this on multiple boxes that share the same Firefox profile and OS.

I was able to move it back to its original location in a quick devtools session:

I can probably add this quick modification to scss/trachacks.scss.

In ticket change history I saw time difference displayed like "Opened 109 minutes ago". I think the better practice is to round it to hours, for example "Opened 2 hours ago". I see it used on many sites and in my opinion it's more human readable and friendly.

Hi,

Django's documentation is staggering. I really like the "You are here" path in the right sidebar in order to navigate more easily.

In effect, they function as breadcrumbs. For me, it would be more clear if we included those as a breadcrumb path in a small font size just below or to the right of the page heading.

On Mac OS X Yosemite, both on Chrome (39) and Safari, the font looks ragged:

Django's CONTRIBUTING guide currently points to the New Ticket page: https://code.djangoproject.com/newticket

If you're not logged in, this won't work:

If you click the "do so" link, you get a login that makes it look like you need to create a new account:

Hmm... Now how do I create an account? If I click cancel, by the way, I go here:

OK, no good. At this point, I commenced clicking around the site for a while. I finally ended up at https://code.djangoproject.com/. While that is a separate subdomain, it looks on the project page like only one of many pages. On this page, there is a link that says "log in with a Github account." Finally, I clicked this link, logged in, and went back to file my bug.

I think my confusion (and perhaps many others') could be mitigated by:

1. Adding a "login with Github link" to the new ticket page, and/or adding a "create a Django Project account" link. According to the DRY principle, this suggests:
2. Adding a unified login page to which both https://code.djangoproject.com/ and the default "not logged in" pages will point to. This login page will have all the options, so that none of them get forgotten or need to be maintained separately.
3. Possibly making a "log in" button more prominent on the Django Project site. This is a bigger design decision though.
4. Give the "Authorization required." page links to login/registration options.

In the main page of section "code", the horizontal line contains a shadow. In the rest of the website (e.g. here), they don't.

Gmail is flagging Trac notifications from code.djangoproject.com as spam, with a link to https://support.google.com/mail/answer/81126?hl=en-GB#authentication.

Here are the email headers. Would it be possible to create an SPF record for the IP address sending the emails?

Delivered-To: alasdair@...
Received: by 10.194.190.44 with SMTP id gn12csp2126929wjc;
        Tue, 28 Apr 2015 07:52:23 -0700 (PDT)
X-Received: by 10.140.235.68 with SMTP id g65mr1217528qhc.96.1430232742966;
        Tue, 28 Apr 2015 07:52:22 -0700 (PDT)
Return-Path: <[email protected]>
Received: from djangoproject.com ([2001:4802:7801:102:be76:4eff:fe20:789f])
        by mx.google.com with ESMTP id d74si18594161qhc.132.2015.04.28.07.52.22
        for <alasdair@...>;
        Tue, 28 Apr 2015 07:52:22 -0700 (PDT)
Received-SPF: none (google.com: [email protected] does not designate permitted sender hosts) client-ip=2001:4802:7801:102:be76:4eff:fe20:789f;
Authentication-Results: mx.google.com;
       spf=none (google.com: [email protected] does not designate permitted sender hosts) [email protected]
Received: from djangoproject.com (ip6-localhost [127.0.0.1])
    by djangoproject.com (Postfix) with ESMTP id 870826A304;
    Tue, 28 Apr 2015 14:50:58 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: "Django" <[email protected]>
X-Trac-Version: 1.0.5
Precedence: bulk
Cc: [email protected]
Auto-Submitted: auto-generated
X-Mailer: Trac 1.0.5, by Edgewall Software
X-Trac-Project: Django
Date: Tue, 28 Apr 2015 14:50:58 -0000
Reply-To: [email protected]
X-URL: https://code.djangoproject.com/
Subject: Re: [Django] #24714: Use more specific assertions than assertEqual
 in tests
X-Trac-Ticket-URL: https://code.djangoproject.com/ticket/24714#comment:8
Message-ID: <[email protected]>
References: <[email protected]>
X-Trac-Ticket-ID: 24714
In-Reply-To: <[email protected]>

There used to be a "core developer" badge in the comments of tickets but it seems to have disapeared.

It seems it might have been caused by Trac's update where it now shows the user's full name ("Baptiste Mispelon") instead of their GitHub username ("bmispelon") like it did before.

The javascript hack that added the badge relied on being able to extract the username and therefore doesn't work anymore.

The information on https://code.djangoproject.com/wiki#Djangoreleaseprocess is out of date. Please could somebody with WIKI_ADMIN privileges update it?

• 1.9 is the current stable branch
• 1.8 is now the LTS branch, not LTS and stable. Note typo of repeated 'branch branch' as well.
• 1.7 is no longer supported.

Perhaps it would be better for this wiki page to link to somewhere else, e.g. https://www.djangoproject.com/download/#supported-versions, so that it doesn't need to be updated for each release.

Crossposting: #23997

I mostly like the new design. There is one thing though that I'd consider a bug: the Trac forms.

• There font size in the filters is way too small.
• This description field is overlapping with the side menu
  
  
  

Hello

I'm new to django and the community, if this ticket is opened in the wrong place, please point me to the right one. Thanks in advance.

I just started browsing the tickets in https://code.djangoproject.com and noticed that it is not possible to mark an item as valid for more than one version of django.

I also found that when a ticket applies to more than 1 version, it is marked as the lowest version it applies to.

Don't know if this has been discussed before, but I think it would be useful to have the ability to mark a ticket as valid for more than one version, this would so that when a search is performed, all the relevant tickets for the version you are looking for show up.

I for instance am using version 1.8.1 already, but found one of the tickets that was marked as 1.7, even though it also applies to 1.8 and master. Would have saved me some time if it was marked 1.8.

Cheers

Is code.djangoproject.com responsive?

It seems that Trac had a new maintenance release: http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.0#MaintenanceRelease

Should we upgrade?

On the code section, the main content (left side), contains an extra bordered box.

This is pushing the text to the right, which is not consistent with the rest of the website and is removing some space to text.

It would be useful to add something like a banner notification to Trac for people who don't have an email address in https://code.djangoproject.com/prefs to try to cut down on the number of people who file a ticket and then never follow due to lack of notification.

If you try to add yourself to the CC of a ticket, it'll sometimes be marked as spam.

Hi,

I like the new layout very much.

A small improvement could be to highlight the current page in the top menu.

For example, we could use light green as a color for the active page if we are on that page or a subpage. If we want the effect to differ from the mouse-over effect, we could add an underline to the mouse-over.

It is a small detail that helps people figuring out where they are.

I tried to use the Github login and the DjangoProject login. Both resulted in the error:
"Error: Forbidden
WIKI_VIEW privileges are required to perform this operation. You don't have the required permissions."

Often description is quite big, contains code snippets, so every time after clicking "Preview" we need to resize height manually and find edited part again.

See https://code.djangoproject.com/wiki/DjangoFellows/BerkerPeksag for the actual page.

body, th, tr font-size is currently set at medium, which results in 16px and a table so wide that it doesn't fit on a 13'' monitor...

Also, the table overlaps the bottom part of the "Useful links" section.

I think the margin on the left is 2 times too big, is it just me? Anyone else seeing this too?

Upgrading to v2 didn't seem to work yet, in fact - it's so broken that I can't comment on the ticket on the Trac!

Here's the SS:

Once i start typing in the "Comment" box and the preview appears, the "Pull Requests:" section of the summary box disappears.

Thought i was going crazy. Is this intentional?

This happens when you do:

{{{#!diff
... diff goes here ...
}}}

I have a solution for design problems on mobile phones. You need to add
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=1.0, minimum-scale=1.0, maximum-scale=1.0">
to a head tag of your base site.