Editing Pages

Editing CMS Pages

We strongly recommend that only university staff with a strong grasp on HTML be given access to create and edit CMS pages. This is an advanced feature with no training wheels. Treat it accordingly!

There are very few aspects to a CMS Page: name, url slug, body, and visibility settings. Let's cover the easy ones first:

• Name: This will be displayed in the public-facing AlumnIQ navigation as the label for the link.

• URL Slug: This is the portion of the url that you can control. It is the ... in https://you.alumniq.com/page/...

• Body: This is where you enter the raw HTML and CSS that you want included on the page. Here are a few details that will help you design to fit into the provided space:

  • We currently use Bootstrap 3.4.0 and its CSS is included in the public-facing skin for you.

  • The primary page layout is done using CSS Grid. The region that you will be filling is a <section> tag with id="main-content" and class="container".

  • We encourage you not to import your entire university CSS file for any reason. If you need to style something, add only the necessary selectors and be specific to select with enough specificity not to affect other areas of the page.

  • The only limitation on content length is what can fit into the provided database column. It currently allows for up to 16mb of content per page.

    • If your page is 16mb, we need to have a talk! That's not ok!

That just leaves visibility settings...

Visibility settings

Screen shot of page visibility settings, illustrating the options described below

There are a variety of Visibilty Settings for pages. You can make them visible only to constituents who are logged in, logged out, matched (xid), or unmatched, or a member/excluded on a Content Access Control List (ACL).

Each setting has an opposite to enable you to optionally create if/else logic: If logged in, show a page of logged in resources; else if logged out, show a page of public resources. If you want to select "both" for a restriction, don't apply that restriction at all.

There are a few logical constraints that you should be familiar with to help you setup your visibility settings:

1. In order for us to verify that a person is matched or unmatched they must be logged in, thus using a matched/unmatched restriction implies the logged in restriction.

2. In order for us to verify that a person is included or excluded on an ACL they must be matched, thus using an ACL restriction implies both logged in and matched.

ACL's for content management must be lists with the Content Access Control purpose selected.

Lastly, whenever you restrict access to a page beyond "always visible" a redirect url becomes required. If someone tries to access a page that they don't have permission to view, we'll redirect them to the supplied URL. You may enter any valid URL.

One more thing...

While page-level visibility settings are pretty great, we know it would be a hassle to create and maintain several copies of one page customized for different audiences. That's why we built some custom logic that you can add to your HTML to hide and show different areas of the page according to who's viewing it. All of the visibility settings from above are also available as inline logic.

Here's how it works. You've already got some HTML. Maybe a list: <ul><li></li></ul> or a <div></div>. We've defined some custom attributes that you can add to your tags to hide or show them as appropriate. They are:

• iq_logged_in

• iq_not_logged_in

• iq_has_xid

• iq_no_xid

• iq_acl="listId"

• iq_not_acl="listId"

So for example, if I wanted a list item only visible to users who are logged in and matched, it might look like this:

You are logged in and matched.

Note that I only had to include the iq_has_xid attribute. Just as with page-level visibility settings, the more specific settings imply the less specific settings (see Visibility Settings above).

Also be careful to note: These are not additional HTML tags. <iq_has_xid> will not accomplish anything. You must add them as attributes to your standard HTML.

Using Access Control Lists

This is the most powerful, but potentially the most confusing feature of the CMS.

Just like event registration, you can create a custom list based on whatever list filters you like, or upload a list, to use as your ACL. If you select the Content ACL purpose, it will be available as an ACL here.

You may also put more than one ACL list id into the attribute value (a minimum of one is required to use the attribute). For example, if I wanted to have a <div> that was only visible to people who are either on list id 42 or list id 24, this would work:

Inline Help

We've also added inline-help on the edit page screen.

Screen shot of inline help available above the body entry area on the edit page screen

The inline help offers a quick reference of the available attributes, because we realize that they aren't exactly super memorable. You can click the little "+" icon next to each one to inject it at your cursor position.

The second tab in the help is a Guide. It is an abbreviated form of this documentation, describing what each attribute does.

And lastly, there is a tab labeled Available ACLs, which lists --you guessed it-- available ACLs. These are lists with the Content Access Control purpose selected.