You probably already know that many pages in Rock are designed so that a single page can be used to display any number of items.

For instance:

• Just one page is used to display all person profiles - whose profile is shown is determined by the ID number in the URL.
• One page can be used to display all groups in group finder- you'll notice again that the GroupId is provided in the URL.
• A single page is usually used to display all connection opportunity signups- this is the page where your visitor or member can create a new connection request. You're probably seeing the pattern, but all of those signups can run from a single page because the OpportunityId is given to the page in a page parameter again (that is, from the URL).

Sometimes you may want to add additional information to one of these pages, based on the specific record you're looking at. The question is, "how we as Rock Admins can use the information provided in the Page Parameters?"

One Example:

Let's say you've added an attribute to your Connection Opportunities - something like "Footer" to display some text below the signup form. That might be an HTML, Memo or Text attribute field, so that whenever you edit or create a connection opportunity it asks you to provide that value. Let's say the key for this attribute is "Footer":

Once that's set up and you've added the values you want for each opportunity, you might head over to your Connection Signup page and add an HTML block below the Connection Opportunity Signup page:

The Temptation:

Now, you've been hanging around the community for awhile so you know about the power of Entity Commands. Your first impulse might therefore be to reach for an Entity Command like
{% connectionopportunity id:'{{ PageParameter.OpportunityId }}' %} to get a usable entity stored in a Lava- that way whenever the page is loaded, your Lava can be just as dynamic to the current item being shown as the other blocks on the page.

But Entity Commands, while powerful, can also be "heavy" to run- each entity command can require multiple queries to be made to the database. We want to help you keep your Rock instance running as quickly as possible, so where there's a less-costly way to achieve the same thing, it's a great idea to do so.

One Alternative: Page Context

HTML blocks have a great capability of letting you specify what kind of entity is being displayed on the page, then they'll give you direct and easy access to the entity.

So here are the steps for you to take advantage of that in this case:

1. Go to your HTML Block's settings, and scroll all the way to the bottom where you'll see "Entity Type" under the header "Context". Set the value to "Connection Opportunity", then click Save.
   
2. Now, go to your Page Settings by clicking the    cog button on the admin toolbar by hovering your mouse at the bottom of the page. Go over to the Advanced Settings tab and you'll see that a new header has been added: Context Parameters.
   There's a single setting asking you to tell the page how to tell which Connection Opportunity you're going to care about when this page is loaded. Looking at the URL again (or sometimes the Page Route), you can see that the parameter is called OpportunityId. So type that into the Parameter Name and click Save.
   

That's all it takes! Now your HTML block has been provided with the Connection Opportunity entity identified in the URL, using
{{ Context.ConnectionOpportunity }}

For example, we can use any of the following in our HTML block:

• Thanks for signing up for the {{ Context.ConnectionOpportunity.Name }} ministry!
  • Result: Thanks for signing up for the Children's ministry!
• Remember, this is a {{ Context.ConnectionOpportunity | Attribute:'Role' | Downcase }} type of role.
  • Result: Remember, this is a behind the scenes type of role

Or, since we're assuming in our example that you've added an attribute called simply "Footer", use this to display the footer for each opportunity:

<div class="alert alert-info">{{ Context.ConnectionOpportunity | Attribute:'Footer' | NewlineToBr }}</div>

There you go- we've got dynamic content looked up from the entity identified in the URL, with no entity commands needed! Rock on!