Repository: phoenixframework/phoenix
Pull request #3910 (2020-06-20 16:22:32)

Fix typos in guides


Patch:
diff --git a/guides/contexts.md b/guides/contexts.md
index fab91ca11..0201e9fbc 100644
--- a/guides/contexts.md
+++ b/guides/contexts.md
@@ -996,7 +996,7 @@ And it works! We now have two isolated contexts responsible for user accounts an
 
 ## Adding CMS functions
 
-Just like we extended our `Accounts` context with new application-specific functions like `Accounts.authenticate_by_email_password/2`, let's extend our generated `CMS` context with new functionality. For any CMS system, the ability to track how many times a page has been viewed is essential for popularity ranks. While we could try to use the existing `CMS.update_page` function, along the lines of `CMS.update_page(user, page, %{views: page.views + 1})`, this would not only be prone to race conditions, but it would also require the caller to know too much about our CMS system. To see why the race condition exists, let's walk through the possible execution of events:
+Just like we extended our `Accounts` context with new application-specific functions like `Accounts.authenticate_by_email_password/2`, let's extend our generated `CMS` context with new functionality. For any CMS system, the ability to track how many times a page has been viewed is essential for popularity ranks. While we could try to use the existing `CMS.update_page` function, along the lines of `CMS.update_page(page, %{views: page.views + 1})`, this would not only be prone to race conditions, but it would also require the caller to know too much about our CMS system. To see why the race condition exists, let's walk through the possible execution of events:
 
 Intuitively, you would assume the following events:
 
diff --git a/guides/controllers.md b/guides/controllers.md
index a6f4bff9d..7a7e0cc30 100644
--- a/guides/controllers.md
+++ b/guides/controllers.md
@@ -427,7 +427,7 @@ The flash functionality is handy when mixed with redirects. Perhaps you want to
   end
 ```
 
-Now if you reload the Welcome page, you will be redirect and the flash messages will be shown once more.
+Now if you reload the Welcome page, you will be redirected and the flash messages will be shown once more.
 
 Besides `put_flash/3` and `get_flash/2`, the `Phoenix.Controller` module has another useful function worth knowing about. `clear_flash/1` takes only `conn` and removes any flash messages which might be stored in the session.
 
diff --git a/guides/ecto.md b/guides/ecto.md
index c2dd6dfae..f9b1adf76 100644
--- a/guides/ecto.md
+++ b/guides/ecto.md
@@ -454,7 +454,7 @@ This will set up all the correct dependencies and configuration for us automatic
 
 If we have an existing application, all we need to do is switch adapters and make some small configuration changes.
 
-To switch adapters, we need to remove the Postgrex dependency and add a new one for Mariaex instead.
+To switch adapters, we need to remove the Postgrex dependency and add a new one for Myxql instead.
 
 Let's open up our `mix.exs` file and do that now.
 
diff --git a/guides/realtime/channels.md b/guides/realtime/channels.md
index a6296f1ae..982b5666d 100644
--- a/guides/realtime/channels.md
+++ b/guides/realtime/channels.md
@@ -156,7 +156,7 @@ The `Phoenix.Socket.Message` module defines a struct with the following keys whi
 PubSub consists of the `Phoenix.PubSub` module and a variety of modules for different adapters and their `GenServer`s.
 These modules contain functions which are the nuts and bolts of organizing Channel communication - subscribing to topics, unsubscribing from topics, and broadcasting messages on a topic.
 PubSub is used internally by Phoenix.
-It's also useful in application development in any case where you want to notify interested processes of an event; for instance, letting all connected [live views](https://github.com/phoenixframework/phoenix_live_view) know that a new comment has been added to a post.
+It's also useful in application development in any case where you want to notify interested processes of an event; for instance, letting all connected [live views](https://github.com/phoenixframework/phoenix_live_view) to know that a new comment has been added to a post.
 
 The PubSub system takes care of getting messages from one node to another so that they can be sent to all subscribers across the cluster.
 By default, this is done using [Phoenix.PubSub.PG2](https://hexdocs.pm/phoenix_pubsub/Phoenix.PubSub.PG2.html), which uses native BEAM messaging.
@@ -439,7 +439,7 @@ socket.connect()
 
 Now that we are connected, we can join channels with a topic:
 
-```elixir
+```javascript
 let channel = socket.channel("topic:subtopic", {})
 channel.join()
   .receive("ok", resp => { console.log("Joined successfully", resp) })
diff --git a/guides/views.md b/guides/views.md
index 6e45c4968..14023537f 100644
--- a/guides/views.md
+++ b/guides/views.md
@@ -122,7 +122,7 @@ iex(1)> Phoenix.View.render(HelloWeb.PageView, "test.html", message: "Hello from
 {:safe, ["This is the message: ", "Hello from IEx!"]}
 ```
 
-As we can see, we're calling `render/3` with the individual view responsible for our test template, the name of our test template, and an empty map representing any assigns we might have wanted to pass in. The return value is a tuple beginning with the atom `:safe` and the resultant io list of the interpolated template. "Safe" here means that Phoenix has escaped the contents of our rendered template to avoid XSS injection attacks.
+As we can see, we're calling `render/3` with the individual view responsible for our test template, the name of our test template, and a set of assigns we might have wanted to pass in. The return value is a tuple beginning with the atom `:safe` and the resultant io list of the interpolated template. "Safe" here means that Phoenix has escaped the contents of our rendered template to avoid XSS injection attacks.
 
 Let's test out the HTML escaping, just for fun:
 
@@ -247,7 +247,7 @@ And the `render/2` matching `"show.json"`:
 
 This works because both "index.json" and "show.json" builds themselves on top of an internal "page.json" clause.
 
-The `render_many/3` function takes the data we want to respond with (`pages`), a view, and a string to pattern match on the `render/2` function defined on view. It will map over each item in `pages`, and call `PageView.render("page.json", %{page: page})`. `render_one/3` follows, the same signature, ultimately using the `render/2` matching `page.json` to specify what each `page` looks like. 
+The `render_many/3` function takes the data we want to respond with (`pages`), a view, and a string to pattern match on the `render/2` function defined on view. It will map over each item in `pages`, and call `PageView.render("page.json", %{page: page})`. `render_one/3` follows, the same signature, ultimately using the `render/2` matching `page.json` to specify what each `page` looks like.
 
 It's useful to build our views like this so they can be composable. Imagine a situation where our `Page` has a `has_many` relationship with `Author`, and depending on the request, we may want to send back `author` data with the `page`. We can easily accomplish this with a new `render/2`:
 


Test patch:
diff --git a/guides/testing/testing.md b/guides/testing/testing.md
index 3604d5460..b1a681e45 100644
--- a/guides/testing/testing.md
+++ b/guides/testing/testing.md
@@ -68,7 +68,7 @@ Our test files simply define modules. At the top of each module, you will find a
 use HelloWeb.ConnCase
 ```
 
-If you were to write an Elixir library, outside of Phoenix, instead of `use HelloWeb.ConnCase`, you would write `use ExUnit.Case` instead. However, Phoenix already ships with a bunch of functionality for testing controllers and `HelloWeb.ConnCase` builds on top of `ExUnit.Case` to bring these functionalities in. We will explore the `HelloWeb.ConnCase` module soon.
+If you were to write an Elixir library, outside of Phoenix, instead of `use HelloWeb.ConnCase` you would write `use ExUnit.Case`. However, Phoenix already ships with a bunch of functionality for testing controllers and `HelloWeb.ConnCase` builds on top of `ExUnit.Case` to bring these functionalities in. We will explore the `HelloWeb.ConnCase` module soon.
 
 Then we define each test using the `test/3` macro. The `test/3` macro receives three arguments: the test name, the testing context that we are pattern matching on, and the contents of the test. In this test, we access the root page of our application by a "GET" HTTP request on the path "/" with the `get/2` macro. Then we **assert** that the rendered page contains the string "Welcome to Phoenix!".
 
@@ -113,7 +113,7 @@ There is a lot to unpack here.
 
 The second line says this is a case template. This is a ExUnit feature that allows developers to replace the built-in `use ExUnit.Case` by their own case. This line is pretty much what allows us to write `use HelloWeb.ConnCase` at the top of our controller tests.
 
-Now that we have made this module a case template, when can define callbacks that are invoked on certain occasions. The `using` callback defines code to be injected on every module that calls `use HelloWeb.ConnCase`. In this case, we import [`Plug.Conn`](https://hexdocs.pm/plug/Plug.Conn.html), so all of the connection helpers available in controllers are also available in tests, and then imports [`Phoenix.ConnTest`](https://hexdocs.pm/phoenix/Phoenix.ConnTest.html). You can consult these modules to learn all functionality available.
+Now that we have made this module a case template, we can define callbacks that are invoked on certain occasions. The `using` callback defines code to be injected on every module that calls `use HelloWeb.ConnCase`. In this case, we import [`Plug.Conn`](https://hexdocs.pm/plug/Plug.Conn.html), so all of the connection helpers available in controllers are also available in tests, and then imports [`Phoenix.ConnTest`](https://hexdocs.pm/phoenix/Phoenix.ConnTest.html). You can consult these modules to learn all functionality available.
 
 Then it aliases the module with all path helpers, so we can easily generate URLs in our tests. Finally, it sets the `@endpoint` module attribute with the name of our endpoint.
 
@@ -528,7 +528,7 @@ Remember to update your repository by running migrations:
 
 Now let's follow the directions and add the new resources route to our `lib/hello_web/router.ex` file and run the migrations.
 
-When we run `mix test` again, we see that we now have twenty tests!
+When we run `mix test` again, we see that we now have nineteen tests!
 
 ```console
 $ mix test
diff --git a/guides/testing/testing_contexts.md b/guides/testing/testing_contexts.md
index 5f76ccbfe..c89f1affd 100644
--- a/guides/testing/testing_contexts.md
+++ b/guides/testing/testing_contexts.md
@@ -66,13 +66,13 @@ As the top of the file we import `Hello.DataCase`, which as we will see soon, it
 
 Next we define an alias, so we can refer to `Hello.Blog` simply as `Blog`.
 
-Then we start a `describe "posts"` block. A `describe` block is a feature in ExUnit that allows us to group similar tests. The reason why we have grouped all post related tests together is because contexts in Phoenix are capable of grouping multiple schemas together. For example, if you ran this command:
+Then we start a `describe "posts"` block. A `describe` block is a feature in ExUnit that allows us to group similar tests. The reason why we have grouped all post related tests together is because contexts in Phoenix are capable of grouping multiple schemas together. For example, if we ran this command:
 
 ```console
 $ mix phx.gen.html Blog Comment comments post_id:references:posts body:text
 ```
 
-We will would get a bunch of new functions in the `Hello.Blog` context plus a whole new `describe "comments"` block in our test file.
+We will get a bunch of new functions in the `Hello.Blog` context plus a whole new `describe "comments"` block in our test file.
 
 The tests defined for our context are very straight-forward. They call the functions in our context and assert on their results. As you can see, some of those tests even create entries in the database:
 
@@ -158,7 +158,7 @@ defmodule Hello.Blog.PostTest do
   alias Hello.Blog.Post
 
   test "title must be at least two characters long" do
-    changeset = Post.changeset(%User{}, %{title: "I"})
+    changeset = Post.changeset(%Post{}, %{title: "I"})
     assert %{title: ["should be at least 2 character(s)"]} = errors_on(changeset)
   end
 end
diff --git a/guides/testing/testing_controllers.md b/guides/testing/testing_controllers.md
index d3e813582..eedaf0d8b 100644
--- a/guides/testing/testing_controllers.md
+++ b/guides/testing/testing_controllers.md
@@ -238,7 +238,7 @@ You may have noticed that this time the scaffold controller has generated fewer
 resources "/articles", ArticleController, except: [:new, :edit]
 ```
 
-`new` and `edit` are only necessary for HTML because they basically exist to assist users in creating and updating resources. Besides having less actions, we will the controller and view tests and implementations for JSON are drastically different from the HTML ones.
+`new` and `edit` are only necessary for HTML because they basically exist to assist users in creating and updating resources. Besides having less actions, we will notice the controller and view tests and implementations for JSON are drastically different from the HTML ones.
 
 The only thing that is pretty much the same between HTML and JSON is the contexts and the schema, which, once you think about it, it makes total sense. After all, your business logic should remain the same, regardless if you are exposing it as HTML or JSON.
 
@@ -386,7 +386,7 @@ The `action_fallback` can be extremely useful to reduce boilerplate when designi
 
 ### The `delete` action
 
-Finally, the last action we will stidy is the `delete` action for JSON. Its implementation looks like this:
+Finally, the last action we will study is the `delete` action for JSON. Its implementation looks like this:
 
 ```elixir
 def delete(conn, %{"id" => id}) do