Added the missing codeblock highlights in guides

Rubocop fix

guides/source/action_cable_overview.md

@@ -777,7 +777,7 @@ when using the same Redis server for multiple applications. See the [Redis Pub/S
 
 The Redis adapter also supports SSL/TLS connections. The required SSL/TLS parameters can be passed in `ssl_params` key in the configuration YAML file.
 
-```
+```yaml
 production:
   adapter: redis
   url: rediss://10.10.3.153:tls_port
@@ -916,8 +916,8 @@ run ActionCable.server
 
 Then to start the server:
 
-```
-bundle exec puma -p 28080 cable/config.ru
+```bash
+$ bundle exec puma -p 28080 cable/config.ru
 ```
 
 This starts a cable server on port 28080. To tell Rails to use this

guides/source/active_record_querying.md

@@ -2463,7 +2463,7 @@ Customer.where(id: 1).joins(:orders).explain
 
 may yield
 
-```
+```sql
 EXPLAIN SELECT `customers`.* FROM `customers` INNER JOIN `orders` ON `orders`.`customer_id` = `customers`.`id` WHERE `customers`.`id` = 1
 +----+-------------+------------+-------+---------------+
 | id | select_type | table      | type  | possible_keys |
@@ -2487,7 +2487,7 @@ Active Record performs a pretty printing that emulates that of the
 corresponding database shell. So, the same query running with the
 PostgreSQL adapter would yield instead
 
-```
+```sql
 EXPLAIN SELECT "customers".* FROM "customers" INNER JOIN "orders" ON "orders"."customer_id" = "customers"."id" WHERE "customers"."id" = $1 [["id", 1]]
                                   QUERY PLAN
 ------------------------------------------------------------------------------
@@ -2511,7 +2511,7 @@ Customer.where(id: 1).includes(:orders).explain
 
 may yield this for MySQL and MariaDB:
 
-```
+```sql
 EXPLAIN SELECT `customers`.* FROM `customers`  WHERE `customers`.`id` = 1
 +----+-------------+-----------+-------+---------------+
 | id | select_type | table     | type  | possible_keys |
@@ -2544,7 +2544,7 @@ EXPLAIN SELECT `orders`.* FROM `orders`  WHERE `orders`.`customer_id` IN (1)
 
 and may yield this for PostgreSQL:
 
-```
+```sql
   Customer Load (0.3ms)  SELECT "customers".* FROM "customers" WHERE "customers"."id" = $1  [["id", 1]]
   Order Load (0.3ms)  SELECT "orders".* FROM "orders" WHERE "orders"."customer_id" = $1  [["customer_id", 1]]
 => EXPLAIN SELECT "customers".* FROM "customers" WHERE "customers"."id" = $1 [["id", 1]]

guides/source/api_documentation_guidelines.md

@@ -179,7 +179,7 @@ When documenting the behavior for IRB, Ruby's interactive REPL, always prefix co
 
 For example,
 
-```
+```irb
 # Find the customer with primary key (id) 10.
 #   irb> customer = Customer.find(10)
 #   # => #<Customer id: 10, first_name: "Ryan">
@@ -189,7 +189,7 @@ For example,
 
 For command-line examples, always prefix the command with `$`, the output doesn't have to be prefixed with anything.
 
-```
+```bash
 # Run the following command:
 #   $ bin/rails new zomg
 #   ...

guides/source/autoloading_and_reloading_constants.md

@@ -603,8 +603,8 @@ When Rails boots, engine directories are added to the autoload paths, and from t
 
 For example, this application uses [Devise](https://github.com/heartcombo/devise):
 
-```
-% bin/rails runner 'pp ActiveSupport::Dependencies.autoload_paths'
+```bash
+$ bin/rails runner 'pp ActiveSupport::Dependencies.autoload_paths'
 [".../app/controllers",
  ".../app/controllers/concerns",
  ".../app/helpers",
@@ -632,8 +632,8 @@ Testing
 
 The task `zeitwerk:check` checks if the project tree follows the expected naming conventions and it is handy for manual checks. For example, if you're migrating from `classic` to `zeitwerk` mode, or if you're fixing something:
 
-```
-% bin/rails zeitwerk:check
+```bash
+$ bin/rails zeitwerk:check
 Hold on, I am eager loading the application.
 All is good!
 ```

guides/source/classic_to_zeitwerk_howto.md

@@ -88,8 +88,8 @@ How to Verify The Application Runs in `zeitwerk` Mode?
 
 To verify the application is running in `zeitwerk` mode, execute
 
-```
-bin/rails runner 'p Rails.autoloaders.zeitwerk_enabled?'
+```bash
+$ bin/rails runner 'p Rails.autoloaders.zeitwerk_enabled?'
 ```
 
 If that prints `true`, `zeitwerk` mode is enabled.
@@ -119,14 +119,14 @@ config.eager_load_paths << "#{Rails.root}/extras"
 
 Once `zeitwerk` mode is enabled and the configuration of eager load paths double-checked, please run:
 
-```
-bin/rails zeitwerk:check
+```bash
+$ bin/rails zeitwerk:check
 ```
 
 A successful check looks like this:
 
-```
-% bin/rails zeitwerk:check
+```bash
+$ bin/rails zeitwerk:check
 Hold on, I am eager loading the application.
 All is good!
 ```
@@ -141,8 +141,8 @@ If there's one constant reported, fix that particular one and run the task again
 
 Take for example:
 
-```
-% bin/rails zeitwerk:check
+```bash
+$ bin/rails zeitwerk:check
 Hold on, I am eager loading the application.
 expected file app/models/vat.rb to define constant Vat
 ```
@@ -177,8 +177,8 @@ With this option you have more control, because only files called exactly `vat.r
 
 With that in place, the check passes!
 
-```
-% bin/rails zeitwerk:check
+```bash
+$ bin/rails zeitwerk:check
 Hold on, I am eager loading the application.
 All is good!
 ```

guides/source/contributing_to_ruby_on_rails.md

@@ -530,7 +530,7 @@ You should add an entry **to the top** of the CHANGELOG of the framework you mod
 
 A CHANGELOG entry should summarize what was changed and should end with the author's name. You can use multiple lines if you need more space, and you can attach code examples indented with 4 spaces. If a change is related to a specific issue, you should attach the issue's number. Here is an example CHANGELOG entry:
 
-```
+```markdown
 *   Summary of a change that briefly describes what was changed. You can use multiple
     lines and wrap them at around 80 characters. Code examples are ok, too, if needed:
 
@@ -668,7 +668,7 @@ understanding why the change was made, so please take the time to write it.
 
 A good commit message looks like this:
 
-```
+```markdown
 Short summary (ideally 50 characters or less)
 
 More detailed description, if necessary. Each line should wrap at

guides/source/debugging_rails_applications.md

@@ -208,7 +208,7 @@ Adding extra logging like this makes it easy to search for unexpected or unusual
 
 When looking at database query output in logs, it may not be immediately clear why multiple database queries are triggered when a single method is called:
 
-```
+```irb
 irb(main):001:0> Article.pamplemousse
   Article Load (0.4ms)  SELECT "articles".* FROM "articles"
   Comment Load (0.2ms)  SELECT "comments".* FROM "comments" WHERE "comments"."article_id" = ?  [["article_id", 1]]
@@ -219,7 +219,7 @@ irb(main):001:0> Article.pamplemousse
 
 After running `ActiveRecord.verbose_query_logs = true` in the `bin/rails console` session to enable verbose query logs and running the method again, it becomes obvious what single line of code is generating all these discrete database calls:
 
-```
+```irb
 irb(main):003:0> Article.pamplemousse
   Article Load (0.2ms)  SELECT "articles".* FROM "articles"
   ↳ app/models/article.rb:5

guides/source/development_dependencies_install.md

@@ -100,7 +100,7 @@ If both `openssl@1.1` and `openssl@3` are installed, you will need to tell Ruby
 
 In your `.bash_profile` set the `PATH` and `RUBY_CONFIGURE_OPTS` to point to `openssl@1.1`:
 
-```
+```sh
 export PATH="/usr/local/opt/openssl@1.1/bin:$PATH"
 export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@1.1)"
 ```

guides/source/plugins.md

@@ -146,7 +146,7 @@ end
 
 To test that your method does what it says it does, run the unit tests with `bin/test` from your plugin directory.
 
-```
+```bash
 $ bin/test
 ...
 2 runs, 2 assertions, 0 failures, 0 errors, 0 skips