Administration¶
Pages¶
Pages are individual entire pages of markup content. They are require Title
, Path
, and Content
to be acceptable in the system. Note that Pages are implemented using a fall through system of URL routing so a user cannot override an existing defined Django URL on accident with a Page.
Fields and Descriptions
- Title:
Title of the Page. Will also be used as the
<title></title>
attribute in the markup.- Keywords:
HTML META keywords for search engines
- Description:
HTML META description for search engines
- Path:
Relative URL path where the page will reside, excluding the initial slash. Example:
about/psf/somepage/
- Content:
The actual content of the page.
- Markup Type:
Type of markup contained in the Content field. Options are: HTML, plain text, ReStructured Text, and Markdown
- Is Published:
Controls whether or not the page is visible on the site.
- Template Name:
By default Pages use the template
templates/pages/default.html
to use a different template enter the template path here.
Note
Pages are automatically purged from Fastly.com upon save.
Boxes¶
Boxes are re-usable bits of HTML markup that are used throughout the site. Things like sidebar info and specific areas of areas of pages with a richer design (i.e. landing pages) that would be cumbersome to edit as one large content textarea.
Note
There are special boxes that are automatically rebuilt using templates, see Supernavs.
Downloads and Releases¶
The downloads
app stores all of the structured data regarding Python releases. Each Release
object has associated ReleaseFile
objects that contain information on the various download formats Python.org
supports.
If the version you are creating should be considered the “latest” release for the major version in question (Python 2.x.x, 3.x.x, etc)
then check the ‘Is this the latest release’ checkbox. When the Release
is saved, the previous version will be automatically
demoted for you and the new version will be used prominently on the site. For example the download buttons and supernav links.
Note
If you make a mistake here, no worries you can just check the box and save on ANY version and promote it to being the latest release.
To create a release you simply need to fill in the appropriate information. Currently if a Release
has an associated Release Page
the system redirects to that to accommodate legacy content, but if the Content
field is filled they are taken to the Release Detail page which shows the content and lists all of the associated downloadable files.
Release Files have a checkbox named ‘Download button’ that determines which binary/source package download link to display for a given OS. This information is used by the OS detection JS on the site so pick the package in most widespread use. On Source distributions be sure to check the ‘Download button’ for the .tgz version for widest compatibility.
Jobs¶
The jobs application is used to display Python jobs on the site. The data items should be fairly self explanatory. There are a couple of things to keep in mind. Logged in users of the site can submit jobs for review.
- Status:
Jobs enter the system in ‘review’ status after the submitter has entered them. Only jobs in the ‘approved’ state are displayed on the site.
- Featured:
Featured jobs are displayed more prominently on the landing page.
- Comments:
Users who have submitted a job and admin reviewers can make comments on a job. Emails will be sent to the other party in order to foster communication about job description and data.
Sponsors¶
The Sponsors app is a place to store PSF Sponsors and Sponsorships. This is the most complex app in the project due to the multiple possibilities on how to configure a sponsorship and, to support this, the app has a lot of models that are grouped by context. Here’s a list of the group of models and what do they represent:
- sponsorship.py:
The Sponsorship model and all the related information to configure a new sponsorship application like programs, packages and benefits;
- benefits.py:
List models that are used to configure benefits. Here you’ll find models that forces a benefit to have an asset or controls it maximum quantity;
- assets.py:
Models that are used to configure the type of assets that a benefit can have;
- sponsors.py:
Has the Sponsor model and all related information such as their contacts and benefits;
- notifications.py:
Any type of sponsor notification that’s configurable via admin;
- contract.py:
The Contract model which is used to generate the final contract document and other support models;
Events¶
TODO
Companies¶
TODO
Success Stories¶
TODO