Skip to content

Renamed Post to BlogPost #1691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 19 additions & 20 deletions en/css/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ djangogirls

Time to write some CSS! Open up the `blog/static/css/blog.css` file in your code editor.

We won't be going too deep into customizing and learning about CSS here. There is a recommendation for a free CSS course at the end of this page if you would like to learn more.
We won't be going too deep into customizing and learning about CSS here. There is a recommendation for a free CSS course at the end of this page if you would like to learn more.

But let's do at least a little. Maybe we could change the color of our headers?
To understand colors, computers use special codes. These codes start with `#` followed by 6 letters (A–F) and numbers (0–9). For example, the code for blue is `#0000FF`. You can find the color codes for many colors here: http://www.colorpicker.com/. You may also use [predefined colors](http://www.w3schools.com/colors/colors_names.asp), such as `red` and `green`.
Expand Down Expand Up @@ -128,11 +128,11 @@ Your file should now look like this:
<h1><a href="/">Django Girls Blog</a></h1>
</div>

{% for post in posts %}
{% for blogpost in blogposts %}
<div>
<p>published: {{ post.published_date }}</p>
<h2><a href="">{{ post.title }}</a></h2>
<p>{{ post.text|linebreaksbr }}</p>
<p>published: {{ blogpost.published_date }}</p>
<h2><a href="">{{ blogpost.title }}</a></h2>
<p>{{ blogpost.text|linebreaksbr }}</p>
</div>
{% endfor %}
</body>
Expand Down Expand Up @@ -180,7 +180,7 @@ h1 a, h2 a {
Great!


As mentioned above, CSS has a concept of classes. These allow you to name a part of the HTML code and apply styles only to this part, without affecting other parts. This can be super helpful! Maybe you have two divs that are doing something different (like your header and your post). A class can help you make them look different.
As mentioned above, CSS has a concept of classes. These allow you to name a part of the HTML code and apply styles only to this part, without affecting other parts. This can be super helpful! Maybe you have two divs that are doing something different (like your header and your blog post). A class can help you make them look different.

Go ahead and name some parts of the HTML code. Add a class called `page-header` to your `div` that contains your header, like this:

Expand All @@ -191,14 +191,14 @@ Go ahead and name some parts of the HTML code. Add a class called `page-header`
</div>
```

And now add a class `post` to your `div` containing a blog post.
And now add a class `blogpost` to your `div` containing a blog post.

{% filename %}blog/templates/blog/post_list.html{% endfilename %}
```html
<div class="post">
<p>published: {{ post.published_date }}</p>
<h2><a href="">{{ post.title }}</a></h2>
<p>{{ post.text|linebreaksbr }}</p>
<p>published: {{ blogpost.published_date }}</p>
<h2><a href="">{{ blogpost.title }}</a></h2>
<p>{{ blogpost.text|linebreaksbr }}</p>
</div>
```

Expand Down Expand Up @@ -254,15 +254,15 @@ h1, h2, h3, h4 {
}
```

Then surround the HTML code which displays the posts with declarations of classes. Replace this:
Then surround the HTML code which displays the blog posts with declarations of classes. Replace this:

{% filename %}blog/templates/blog/post_list.html{% endfilename %}
```html
{% for post in posts %}
{% for blogpost in blogposts %}
<div class="post">
<p>published: {{ post.published_date }}</p>
<h2><a href="">{{ post.title }}</a></h2>
<p>{{ post.text|linebreaksbr }}</p>
<p>published: {{ blogpost.published_date }}</p>
<h2><a href="">{{ blogpost.title }}</a></h2>
<p>{{ blogpost.text|linebreaksbr }}</p>
</div>
{% endfor %}
```
Expand All @@ -274,13 +274,13 @@ in the `blog/templates/blog/post_list.html` with this:
<div class="content container">
<div class="row">
<div class="col-md-8">
{% for post in posts %}
{% for blogpost in blogposts %}
<div class="post">
<div class="date">
<p>published: {{ post.published_date }}</p>
<p>published: {{ blogpost.published_date }}</p>
</div>
<h2><a href="">{{ post.title }}</a></h2>
<p>{{ post.text|linebreaksbr }}</p>
<h2><a href="">{{ blogpost.title }}</a></h2>
<p>{{ blogpost.text|linebreaksbr }}</p>
</div>
{% endfor %}
</div>
Expand All @@ -300,4 +300,3 @@ Don't be afraid to tinker with this CSS a little bit and try to change some thin
We really recommend taking the free online courses "Basic HTML & HTML5" and "Basic CSS" on [freeCodeCamp](https://learn.freecodecamp.org/). They can help you learn all about making your websites prettier with HTML and CSS.

Ready for the next chapter?! :)

8 changes: 4 additions & 4 deletions en/deploy/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ Linux and MacOS treat files with a name that starts with `.` (such as `.gitignor
and the normal `ls` command won't show these files.
Instead use `ls -a` to see the `.gitignore` file.

> **Note** One of the files you specified in your `.gitignore` file is `db.sqlite3`. That file is your local database, where all of your users and posts are stored. We'll follow standard web programming practice, meaning that we'll use separate databases for your local testing site and your live website on PythonAnywhere. The PythonAnywhere database could be SQLite, like your development machine, but usually you will use one called MySQL which can deal with a lot more site visitors than SQLite. Either way, by ignoring your SQLite database for the GitHub copy, it means that all of the posts and superuser you created so far are going to only be available locally, and you'll have to create new ones on production. You should think of your local database as a good playground where you can test different things and not be afraid that you're going to delete your real posts from your blog.
> **Note** One of the files you specified in your `.gitignore` file is `db.sqlite3`. That file is your local database, where all of your users and blog posts are stored. We'll follow standard web programming practice, meaning that we'll use separate databases for your local testing site and your live website on PythonAnywhere. The PythonAnywhere database could be SQLite, like your development machine, but usually you will use one called MySQL which can deal with a lot more site visitors than SQLite. Either way, by ignoring your SQLite database for the GitHub copy, it means that all of the blog posts and superuser you created so far are going to only be available locally, and you'll have to create new ones on production. You should think of your local database as a good playground where you can test different things and not be afraid that you're going to delete your real posts from your blog.

It's a good idea to use a `git status` command before `git add` or whenever you find yourself unsure of what has changed. This will help prevent any surprises from happening, such as wrong files being added or committed. The `git status` command returns information about any untracked/modified/staged files, the branch status, and much more. The output should be similar to the following:

Expand Down Expand Up @@ -199,7 +199,7 @@ As you watch that running, you'll be able to see what it's doing:

On PythonAnywhere all those steps are automated, but they're the same steps you would have to go through with any other server provider.

The main thing to notice right now is that your database on PythonAnywhere is actually totally separate from your database on your own computer, so it can have different posts and admin accounts. As a result, just as we did on your own computer, we need to initialize the admin account with `createsuperuser`. PythonAnywhere has automatically activated your virtualenv for you, so all you need to do is run:
The main thing to notice right now is that your database on PythonAnywhere is actually totally separate from your database on your own computer, so it can have different blog posts and admin accounts. As a result, just as we did on your own computer, we need to initialize the admin account with `createsuperuser`. PythonAnywhere has automatically activated your virtualenv for you, so all you need to do is run:

{% filename %}PythonAnywhere command-line{% endfilename %}
```
Expand Down Expand Up @@ -250,9 +250,9 @@ And remember, your coach is here to help!

# Check out your site!

The default page for your site should say "It worked!", just like it does on your local computer. Try adding `/admin/` to the end of the URL, and you'll be taken to the admin site. Log in with the username and password, and you'll see you can add new Posts on the server -- remember, the posts from your local test database were not sent to your live blog.
The default page for your site should say "It worked!", just like it does on your local computer. Try adding `/admin/` to the end of the URL, and you'll be taken to the admin site. Log in with the username and password, and you'll see you can add new BlogPosts on the server -- remember, the blog posts from your local test database were not sent to your live blog.

Once you have a few posts created, you can go back to your local setup (not PythonAnywhere). From here you should work on your local setup to make changes. This is a common workflow in web development – make changes locally, push those changes to GitHub, and pull your changes down to your live Web server. This allows you to work and experiment without breaking your live Web site. Pretty cool, huh?
Once you have a few blog posts created, you can go back to your local setup (not PythonAnywhere). From here you should work on your local setup to make changes. This is a common workflow in web development – make changes locally, push those changes to GitHub, and pull your changes down to your live Web server. This allows you to work and experiment without breaking your live Web site. Pretty cool, huh?


Give yourself a *HUGE* pat on the back! Server deployments are one of the trickiest parts of web development and it often takes people several days before they get them working. But you've got your site live, on the real Internet!
10 changes: 5 additions & 5 deletions en/django_admin/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,14 +7,14 @@ Let's open the `blog/admin.py` file in the code editor and replace its contents
{% filename %}blog/admin.py{% endfilename %}
```python
from django.contrib import admin
from .models import Post
from .models import BlogPost

admin.site.register(Post)
admin.site.register(BlogPost)
```

As you can see, we import (include) the Post model defined in the previous chapter. To make our model visible on the admin page, we need to register the model with `admin.site.register(Post)`.
As you can see, we import (include) the BlogPost model defined in the previous chapter. To make our model visible on the admin page, we need to register the model with `admin.site.register(BlogPost)`.

OK, time to look at our Post model. Remember to run `python manage.py runserver` in the console to run the web server. Go to your browser and type the address http://127.0.0.1:8000/admin/. You will see a login page like this:
OK, time to look at our BlogPost model. Remember to run `python manage.py runserver` in the console to run the web server. Go to your browser and type the address http://127.0.0.1:8000/admin/. You will see a login page like this:

![Login page](images/login_page2.png)

Expand Down Expand Up @@ -46,7 +46,7 @@ Return to your browser. Log in with the superuser's credentials you chose; you s

![Django admin](images/django_admin3.png)

Go to Posts and experiment a little bit with it. Add five or six blog posts. Don't worry about the content –- it's only visible to you on your local computer -- you can copy-paste some text from this tutorial to save time. :)
Go to BlogPosts and experiment a little bit with it. Add five or six blog posts. Don't worry about the content –- it's only visible to you on your local computer -- you can copy-paste some text from this tutorial to save time. :)

Make sure that at least two or three posts (but not all) have the publish date set. It will be helpful later.

Expand Down
Loading