Fixing guides validation errors.

railties/guides/source/action_view_overview.textile

@@ -126,7 +126,7 @@ Rails supports multiple template systems and uses a file extension to distinguis
 
 h5. ERB
 
-Within an ERB template Ruby code can be included using both +<% %>+ and +<%= %>+ tags. The +<% %>+ are used to execute Ruby code that does not return anything, such as conditions, loops or blocks, and the +<%= %>+ tags are used when you want output.
+Within an ERB template Ruby code can be included using both +&lt;% %&gt;+ and +&lt;%= %&gt;+ tags. The +&lt;% %&gt;+ are used to execute Ruby code that does not return anything, such as conditions, loops or blocks, and the +&lt;%= %&gt;+ tags are used when you want output.
 
 Consider the following loop for names:
 
@@ -137,14 +137,14 @@ Consider the following loop for names:
 <% end %>
 </erb>
 
-The loop is setup in regular embedding tags +<% %>+ and the name is written using the output embedding tag +<%= %>+. Note that this is not just a usage suggestion, for Regular output functions like print or puts won't work with ERB templates. So this would be wrong:
+The loop is setup in regular embedding tags +&lt;% %&gt;+ and the name is written using the output embedding tag +&lt;%= %&gt;+. Note that this is not just a usage suggestion, for Regular output functions like print or puts won't work with ERB templates. So this would be wrong:
 
 <erb>
 <%# WRONG %>
 Hi, Mr. <% puts "Frodo" %>
 </erb>
 
-To suppress leading and trailing whitespaces, you can use +<%-+ +-%>+ interchangeably with +<%+ and +%>+.
+To suppress leading and trailing whitespaces, you can use +&lt;%-+ +-%&gt;+ interchangeably with +&lt;%+ and +%&gt;+.
 
 h5. Builder
 

railties/guides/source/active_model_basics.textile

@@ -163,12 +163,14 @@ person.first_name_changed? #=> true
 </ruby>
 
 Track what was the previous value of the attribute.
+
 <ruby>
 #attr_name_was accessor
 person.first_name_was  #=> "First Name"
 </ruby>
 
 Track  both previous and current value of the changed attribute. Returns an array if changed else returns nil
+
 <ruby>
 #attr_name_change
 person.first_name_change #=> ["First Name", "First Name 1"]

railties/guides/source/active_record_querying.textile

@@ -132,7 +132,7 @@ SELECT * FROM clients ORDER BY clients.id DESC LIMIT 1
 
 <tt>Model.last</tt> returns +nil+ if no matching record is found. No exception will be raised.
 
-h5. +first!+
+h5(#first-1). +first!+
 
 <tt>Model.first!</tt> finds the first record. For example:
 
@@ -149,7 +149,7 @@ SELECT * FROM clients LIMIT 1
 
 <tt>Model.first!</tt> raises +RecordNotFound+ if no matching record is found.
 
-h5. +last!+
+h5(#last-1). +last!+
 
 <tt>Model.last!</tt> finds the last record. For example:
 

railties/guides/source/active_support_core_extensions.textile

@@ -190,7 +190,7 @@ WARNING: Fixnums and symbols have no singleton classes, +singleton_class+ raises
 
 NOTE: Defined in +active_support/core_ext/kernel/singleton_class.rb+.
 
-h4. +class_eval(*args, &block)+
+h4. +class_eval(*args, &block)+
 
 You can evaluate code in the context of any object's singleton class using +class_eval+:
 
@@ -2097,7 +2097,7 @@ NOTE: Defined in +active_support/core_ext/array/prepend_and_append.rb+.
 
 h4. Options Extraction
 
-When the last argument in a method call is a hash, except perhaps for a +&block+ argument, Ruby allows you to omit the brackets:
+When the last argument in a method call is a hash, except perhaps for a +&block+ argument, Ruby allows you to omit the brackets:
 
 <ruby>
 User.exists?(:email => params[:email])

railties/guides/source/ajax_on_rails.textile

@@ -67,7 +67,7 @@ link_to_remote "Add to cart",
 
 If the server returns 200, the output of the above example is equivalent to our first, simple one. However, in case of error, the element with the DOM id +error+ is updated rather than the +cart+ element.
 
-** *position* By default (i.e. when not specifying this option, like in the examples before) the response is injected into the element with the specified DOM id, replacing the original content of the element (if there was any). You might want to alter this behavior by keeping the original content - the only question is where to place the new content? This can specified by the +position+ parameter, with four possibilities:
+** *:position* By default (i.e. when not specifying this option, like in the examples before) the response is injected into the element with the specified DOM id, replacing the original content of the element (if there was any). You might want to alter this behavior by keeping the original content - the only question is where to place the new content? This can specified by the +position+ parameter, with four possibilities:
 *** +:before+ Inserts the response text just before the target element. More precisely, it creates a text node from the response and inserts it as the left sibling of the target element.
 *** +:after+ Similar behavior to +:before+, but in this case the response is inserted after the target element.
 *** +:top+ Inserts the text into the target element, before it's original content. If the target element was empty, this is equivalent with not specifying +:position+ at all.
@@ -123,7 +123,9 @@ link_to_remote "Add new item",
   :update => "item_list",
   404 => "alert('Item not found!')"
 </ruby>
+
 Let's see a typical example for the most frequent callbacks, +:success+, +:failure+ and +:complete+ in action:
+
 <ruby>
 link_to_remote "Add new item",
   :url => items_url,
@@ -133,7 +135,9 @@ link_to_remote "Add new item",
   :success => "display_item_added(request)",
   :failure => "display_error(request)"
 </ruby>
+
 ** *:type* If you want to fire a synchronous request for some obscure reason (blocking the browser while the request is processed and doesn't return a status code), you can use the +:type+ option with the value of +:synchronous+.
+
 * Finally, using the +html_options+ parameter you can add HTML attributes to the generated tag. It works like the same parameter of the +link_to+ helper. There are interesting side effects for the +href+ and +onclick+ parameters though:
 ** If you specify the +href+ parameter, the AJAX link will degrade gracefully, i.e. the link will point to the URL even if JavaScript is disabled in the client browser
 ** +link_to_remote+ gains it's AJAX behavior by specifying the remote call in the onclick handler of the link. If you supply +html_options[:onclick]+ you override the default behavior, so use this with care!

railties/guides/source/asset_pipeline.textile

@@ -62,11 +62,11 @@ This has several disadvantages:
 
 <ol>
   <li>
-    <strong>Not all caches will cache content with a query string</strong><br>
+    <strong>Not all caches will cache content with a query string</strong><br/>
     "Steve Souders recommends":http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/, "...avoiding a querystring for cacheable resources". He found that in these case 5-20% of requests will not be cached.
   </li>
   <li>
-    <strong>The file name can change between nodes in multi-server environments.</strong><br>
+    <strong>The file name can change between nodes in multi-server environments.</strong><br/>
     The query string in Rails is based on the modification time of the files. When assets are deployed to a cluster, there is no guarantee that the timestamps will be the same, resulting in different values being used depending on which server handles the request.
   </li>
 </ol>
@@ -91,7 +91,7 @@ This is not to say that assets can (or should) no longer be placed in +public+;
 
 When a scaffold or controller is generated for the application, Rails also generates a JavaScript file (or CoffeeScript file if the +coffee-rails+ gem is in the +Gemfile+) and a Cascading Style Sheet file (or SCSS file if +sass-rails+ is in the +Gemfile+) for that controller.
 
-For example, if a +ProjectsController+ is generated, there will be a new file at +app/assets/javascripts/projects.js.coffee+ and another at +app/assets/stylesheets/projects.css.scss+. You should put any JavaScript or CSS unique to a controller inside their respective asset files, as these files can then be loaded just for these controllers with lines such as +<%= javascript_include_tag params[:controller] %>+ or +<%= stylesheet_link_tag params[:controller] %>+.
+For example, if a +ProjectsController+ is generated, there will be a new file at +app/assets/javascripts/projects.js.coffee+ and another at +app/assets/stylesheets/projects.css.scss+. You should put any JavaScript or CSS unique to a controller inside their respective asset files, as these files can then be loaded just for these controllers with lines such as +&lt;%= javascript_include_tag params[:controller] %&gt;+ or +&lt;%= stylesheet_link_tag params[:controller] %&gt;+.
 
 NOTE: You will need a  "ExecJS":https://github.com/sstephenson/execjs#readme - supported runtime in order to use CoffeeScript. If you are using Mac OS X or Windows you have a JavaScript runtime installed in your operating system. Check "ExecJS":https://github.com/sstephenson/execjs#readme documentation to know all supported JavaScript runtimes.
 

railties/guides/source/form_helpers.textile

@@ -98,7 +98,7 @@ form_tag({:controller => "people", :action => "search"}, :method => "get", :clas
 
 h4. Helpers for Generating Form Elements
 
-Rails provides a series of helpers for generating form elements such as checkboxes, text fields, and radio buttons. These basic helpers, with names ending in "_tag" (such as +text_field_tag+ and +check_box_tag+), generate just a single +&lt;input&gt;+ element. The first parameter to these is always the name of the input. When the form is submitted, the name will be passed along with the form data, and will make its way to the +params+ hash in the controller with the value entered by the user for that field. For example, if the form contains +<%= text_field_tag(:query) %>+, then you would be able to get the value of this field in the controller with +params[:query]+.
+Rails provides a series of helpers for generating form elements such as checkboxes, text fields, and radio buttons. These basic helpers, with names ending in "_tag" (such as +text_field_tag+ and +check_box_tag+), generate just a single +&lt;input&gt;+ element. The first parameter to these is always the name of the input. When the form is submitted, the name will be passed along with the form data, and will make its way to the +params+ hash in the controller with the value entered by the user for that field. For example, if the form contains +&lt;%= text_field_tag(:query) %&gt;+, then you would be able to get the value of this field in the controller with +params[:query]+.
 
 When naming inputs, Rails uses certain conventions that make it possible to submit parameters with non-scalar values such as arrays or hashes, which will also be accessible in +params+. You can read more about them in "chapter 7 of this guide":#understanding-parameter-naming-conventions. For details on the precise usage of these helpers, please refer to the "API documentation":http://api.rubyonrails.org/classes/ActionView/Helpers/FormTagHelper.html.
 

railties/guides/source/generators.textile

@@ -1,4 +1,4 @@
-h2. Creating and Customizing Rails Generators & Templates
+h2. Creating and Customizing Rails Generators & Templates
 
 Rails generators are an essential tool if you plan to improve your workflow. With this guide you will learn how to create generators and customize existing ones.
 

railties/guides/source/initialization.textile

@@ -454,7 +454,7 @@ app = eval "Rack::Builder.new {( " + cfgfile + "\n )}.to_app",
     TOPLEVEL_BINDING, config
 </ruby>
 
-The <ruby>initialize</ruby> method will take the block here and execute it within an instance of +Rack::Builder+. This is where the majority of the initialization process of Rails happens. The chain of events that this simple line sets off will be the focus of a large majority of this guide. The +require+ line for +config/environment.rb+ in +config.ru+ is the first to run:
+The +initialize+ method will take the block here and execute it within an instance of +Rack::Builder+. This is where the majority of the initialization process of Rails happens. The chain of events that this simple line sets off will be the focus of a large majority of this guide. The +require+ line for +config/environment.rb+ in +config.ru+ is the first to run:
 
 <ruby>
 require ::File.expand_path('../config/environment',  __FILE__)
@@ -676,11 +676,11 @@ h4. Back to +railties/lib/rails/railtie.rb+
 
 Once the inflector files have been loaded, the +Rails::Railtie+ class is defined. This class includes a module called +Initializable+, which is actually +Rails::Initializable+. This module includes the +initializer+ method which is used later on for setting up initializers, amongst other methods.
 
-h4. +railties/lib/rails/initializable.rb+
+h4(#railties-lib-rails-initializable-rb-1). +railties/lib/rails/initializable.rb+
 
 When the module from this file (+Rails::Initializable+) is included, it extends the class it's included into with the +ClassMethods+ module inside of it. This module defines the +initializer+ method which is used to define initializers throughout all of the railties. This file completes the loading of +railties/lib/rails/railtie.rb+. Now we go back to +rails/engine.rb+.
 
-h4. +railties/lib/rails/engine.rb+
+h4(#railties-lib-rails-engine-rb-1). +railties/lib/rails/engine.rb+
 
 The next file required in +rails/engine.rb+ is +active_support/core_ext/module/delegation+ which is documented in the "Active Support Core Extensions Guide":http://guides.rubyonrails.org/active_support_core_extensions.html#method-delegation.
 

railties/guides/source/performance_testing.textile

@@ -207,15 +207,15 @@ GC Time measures the amount of time spent in GC for the performance test case.
 
 h5. Metric Availability
 
-h6. Benchmarking
+h6(#benchmarking-1). Benchmarking
 
 |_.Interpreter|_.Wall Time|_.Process Time|_.CPU Time|_.User Time|_.Memory|_.Objects|_.GC Runs|_.GC Time|
 |_.MRI        | yes       | yes          | yes      | no        | yes    | yes     | yes     | yes     |
 |_.REE        | yes       | yes          | yes      | no        | yes    | yes     | yes     | yes     |
 |_.Rubinius   | yes       | no           | no       | no        | yes    | yes     | yes     | yes     |
 |_.JRuby      | yes       | no           | no       | yes       | yes    | yes     | yes     | yes     |
 
-h6. Profiling
+h6(#profiling-1). Profiling
 
 |_.Interpreter|_.Wall Time|_.Process Time|_.CPU Time|_.User Time|_.Memory|_.Objects|_.GC Runs|_.GC Time|
 |_.MRI        | yes       | yes          | no       | no        | yes    | yes     | yes     | yes     |