diff --git a/guides/source/action_text_overview.md b/guides/source/action_text_overview.md index 2950a87d3b446..6d398ffa49231 100644 --- a/guides/source/action_text_overview.md +++ b/guides/source/action_text_overview.md @@ -65,7 +65,7 @@ After the installation is complete, a Rails app using Webpacker should have the Additionally, this `actiontext.scss` file should be imported into your stylesheet pack. - ``` + ```scss // application.scss @import "./actiontext.scss"; ``` diff --git a/guides/source/asset_pipeline.md b/guides/source/asset_pipeline.md index f189b773d7dbb..b1914c1e8c3b5 100644 --- a/guides/source/asset_pipeline.md +++ b/guides/source/asset_pipeline.md @@ -898,7 +898,7 @@ You can also set this value through an [environment variable](https://en.wikipedia.org/wiki/Environment_variable) to make running a staging copy of your site easier: -``` +```ruby config.action_controller.asset_host = ENV['CDN_HOST'] ``` @@ -1013,7 +1013,7 @@ the cache will store the object before invalidating the cache. The `max-age` value is set to seconds with a maximum possible value of `31536000` which is one year. You can do this in your Rails application by setting -``` +```ruby config.public_file_server.headers = { 'Cache-Control' => 'public, max-age=31536000' } diff --git a/guides/source/autoloading_and_reloading_constants.md b/guides/source/autoloading_and_reloading_constants.md index 332f3b4eb3108..57c404b7e19d3 100644 --- a/guides/source/autoloading_and_reloading_constants.md +++ b/guides/source/autoloading_and_reloading_constants.md @@ -172,7 +172,7 @@ Let's see other situations that involve stale class or module objects. Check this Rails console session: -``` +```ruby > joe = User.new > reload! > alice = User.new @@ -198,7 +198,7 @@ Bottom line: **do not cache reloadable classes or modules**. Applications can safely autoload constants during boot using a reloader callback: -``` +```ruby Rails.application.reloader.to_prepare do $PAYMENT_GATEWAY = Rails.env.production? ? RealGateway : MockedGateway end diff --git a/guides/source/configuring.md b/guides/source/configuring.md index 34b941b182b11..cd43e9bd91859 100644 --- a/guides/source/configuring.md +++ b/guides/source/configuring.md @@ -1381,7 +1381,7 @@ You can find more information in the [Unicorn readme](https://bogomips.org/unico Once you've configured the application server, you must proxy requests to it by configuring your web server appropriately. For example your NGINX config may include: -``` +```nginx upstream application_server { server 0.0.0.0:8080; } diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md index d70a2893fc61b..04b6684595298 100644 --- a/guides/source/debugging_rails_applications.md +++ b/guides/source/debugging_rails_applications.md @@ -331,7 +331,7 @@ application server, and you will be placed at the debugger's prompt `(byebug)`. Before the prompt, the code around the line that is about to be run will be displayed and the current line will be marked by '=>', like this: -``` +```ruby [1, 10] in /PathTo/project/app/controllers/articles_controller.rb 3: 4: # GET /articles diff --git a/guides/source/engines.md b/guides/source/engines.md index c8313f1a5d264..bd1fc3b4a6518 100644 --- a/guides/source/engines.md +++ b/guides/source/engines.md @@ -1338,7 +1338,7 @@ were inside the engine: You can also specify these assets as dependencies of other assets using Asset Pipeline require statements in processed files: -``` +```css /* *= require blorgh/style */ diff --git a/guides/source/generators.md b/guides/source/generators.md index db6503b03df06..8368cd111f7b9 100644 --- a/guides/source/generators.md +++ b/guides/source/generators.md @@ -468,7 +468,7 @@ Adding Command Line Arguments ----------------------------- Rails generators can be easily modified to accept custom command line arguments. This functionality comes from [Thor](https://www.rubydoc.info/github/erikhuda/thor/master/Thor/Base/ClassMethods#class_option-instance_method): -``` +```ruby class_option :scope, type: :string, default: 'read_products' ``` diff --git a/guides/source/layouts_and_rendering.md b/guides/source/layouts_and_rendering.md index 6ec5613e3fcab..62e8b9a73ad8b 100644 --- a/guides/source/layouts_and_rendering.md +++ b/guides/source/layouts_and_rendering.md @@ -754,7 +754,7 @@ head :bad_request This would produce the following header: -``` +```http HTTP/1.1 400 Bad Request Connection: close Date: Sun, 24 Jan 2010 12:15:53 GMT @@ -773,7 +773,7 @@ head :created, location: photo_path(@photo) Which would produce: -``` +```http HTTP/1.1 201 Created Connection: close Date: Sun, 24 Jan 2010 12:16:44 GMT diff --git a/guides/source/security.md b/guides/source/security.md index 3a3bad270e4d7..9c9972b57d8e0 100644 --- a/guides/source/security.md +++ b/guides/source/security.md @@ -734,7 +734,7 @@ This JavaScript code will simply display an alert box. The next examples do exac These examples don't do any harm so far, so let's see how an attacker can steal the user's cookie (and thus hijack the user's session). In JavaScript you can use the `document.cookie` property to read and write the document's cookie. JavaScript enforces the same origin policy, that means a script from one domain cannot access cookies of another domain. The `document.cookie` property holds the cookie of the originating web server. However, you can read and write this property, if you embed the code directly in the HTML document (as it happens with XSS). Inject this anywhere in your web application to see your own cookie on the result page: -``` +```html ``` @@ -798,7 +798,7 @@ As a second step, _it is good practice to escape all output of the application_, Network traffic is mostly based on the limited Western alphabet, so new character encodings, such as Unicode, emerged, to transmit characters in other languages. But, this is also a threat to web applications, as malicious code can be hidden in different encodings that the web browser might be able to process, but the web application might not. Here is an attack vector in UTF-8 encoding: -``` +```html ``` @@ -811,7 +811,7 @@ _In order to understand today's attacks on web applications, it's best to take a The following is an excerpt from the [Js.Yamanner@m](http://www.symantec.com/security_response/writeup.jsp?docid=2006-061211-4111-99&tabid=1) Yahoo! Mail [worm](http://groovin.net/stuff/yammer.txt). It appeared on June 11, 2006 and was the first webmail interface worm: -``` +```html