← General Information

Make File Explanation

The yourfi-make.json file lives in your site_repo/development folder. The package.json makes a call to this file to provide the data necessary when first setting up a site on staging environments.

Many aspects of this file can be automated using gulp commands. See this page for more information on make file automation that can be done.

Once you have pushed a site to UAT, and changed the “allowScaffold” value to “false” in Postman, this file doesn’t need to be updated. However, you may still wish to do this for sites that will have multilingual copies made, because that will make it faster to scaffold the other language site.

Institution

  • domains - These are the domains that your site will live on. If these domains are not listed the CMS will not work and you will not be able to login. The project coordinator for the site should have set up the DNS for the preferred UAT site name, so use that for each value. For example: "domains": ["firstbank.dev.banno.com", "firstbank.banno.com", "firstbank-uat.banno.com", "firstbank-stag.banno.com"]
  • databaseName - Name of the database that will live on mongo. This should reflect the bank’s domain, and should be a unique value. For example, www_yourfi_com. If you try to use a database name that already exists with another site, at best you will get an error when trying to scaffold. At worst, you could overwrite the other site.
  • name - Name of the FI.
  • themeId - unique identifier of site to be used after site is scaffolded. Rule of thumb is to give this the same name as the zip.
  • bannoInstitutionId - another identifier used after scaffold. Project Coordinator on a project is the one that typically requests this setup. The Aggregation team will provide this on a trello card on this board. If this field is left empty, or includes typos or other errors, you will get an error when trying to scaffold the site, so make sure it is correct.
  • features - Options that a site could have. The starting repo for builds has these all listed out by default and ones that aren’t being used should be removed during initial setup. We can always add or subtract features by updating the institution info via Postman.
    • “PAGES” - The list of pages that the site has. This should be included in all sites.
    • “ASSETS” - The images, PDFs, etc. that are uploaded to the CMS by the client. This should be included in all sites.
    • “FORMS” - The section of the CMS that allows you to view the list of available foms and all submissions to them. This should be included in all sites for now - the form builder is in process, so we may not eventually need to include this.
    • “TREASURY” - The treasury rate manager within the CMS. This should be included in all sites.
    • “MENU_BUILDER” - The ability to add / remove menus in a site, and edit pages within those menus. This should be included in all sites.
    • “MEMBERS_ONLY” - Indicates whether the site has the members only component (should be noted on the trello card). For more information on installing this component, see this page.
    • “LOCATION_MANAGER” - Allows the client to manage ATM and branch locations via the CMS. This will almost always be included, though some sites may elect not to use it.
    • “HISTORY” - Allows users to see a history of information, such as what user logged in and when, information about what files were uploaded / deleted and when, and what pages were edited / created / deleted and when. This should be included in all sites.
    • “SENTINEL” - Indicates whether or not the client purchased Banno Monitor. This should be listed on the trello card. If this value is included, "showSentinel":true should also be listed for every page on the site.

Config

  • cashGrain - id of CashGrain feed. Almost never used anymore, not sure if we even have an example.

  • atm

    • defaultLocation - Address of bank. Use the address of the main branch, which should be included in the Institution ID creation card if you can’t find it anywhere else. Set the “name” value to the name of the bank, just like the “name” value noted above. The client will be able to change these values in the CMS later if needed.
    • defaultRadius - How far around the banks address search results should be; this is a value from the drop down found on the atm locator subpage. Acceptable values are 5, 10, 15, 20, 25, 50 (the default), 100, 250, and 500. The client will be able to change this value in the CMS later if needed.
    • textForLocationInput - Text that shows up as the placeholder for the input. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • showAtmOnFirstLoad - Shows all the ATM pins on the first load of the page. If set to false or null, the “ATMs” checkbox on the page will be unchecked initially. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • descriptionInList - Shows the description of the location inside the location list table. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • descriptionInMap - Shows the description of the location inside a tooltip in the map, when a specific pin is clicked. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • imageInList - Shows an image of the location if one is entered, inside the location list. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • imageInMap - Shows an image of the location if one is entered, inside a tooltip in the map when a specific pin is clicked. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • scrollWheel - If set to true, the map will zoom in if you scroll while mousing over it. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • branchLabel - Change the label for the Branches checkbox. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • atmLabel - Change the label for the main ATMs checkbox. This value can be edited later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.
    • googleMapsKey - The project coordinator will need to get this information from the client, and should provide it to you on the trello card for the site. If not provided when you initially build the site, you or the PC can add it in later via the admin settings > ATM locator settings in the CMS.

  • banno - bannoAPIToken provided by the backend team. This is provided when work on the ATM Trello card is completed. If you have it, you will need to put it in with the following format: "banno": { "bannoApiToken": "abcd-1234-etc" }. If it’s not provided, it can be added in later via the admin settings > ATM locator settings in the CMS by the PC, developer, etc.

  • stock - List stock markets to list out when using banno:stock tag. Not often used anymore.

  • weather - Zipcode to use with banno:weather. You can overwrite this value within the banno tag. Not often used anymore.

  • categories - Array of categories that a site should use. They should be in double quotes and comma-separated. Sites must have at least one category, or you will get an error when scaffolding.

  • history - Turns on the History feature for a site. You can leave it set to null.

  • page - Turns on the Pages feature for a site. You can leave it set to null.

  • showSharedContentFeature - Turns on ability to use Shared Content feature. This should be set to true by default, and will usually always be left that way.

  • useTinyMCE - Uses the Platform CMS, set to true by default and should not be made false unless talking to supervisor.

  • optimalBlue - You can leave this value set to null.

  • loginIpRange - You can leave this value set to null.

  • numberOfSearchResults - Allows you to customize the number of search results that appear on the Search Results page. It is 20 by default, and you can leave it set to null in most cases. If you are changing it, make sure to set the value as a number, NOT a string - meaning, enter only a number with no quotes.

  • allowReScaffold - In Postman, this is the value you will change to block anyone else from scaffolding another site over top of yours. In the make.json, you will want to leave this value set to true, because otherwise you won’t be able to scaffold your new site. Note that if the value is set to null in Postman, it is read the same as “true” and will allow overwrites, so make sure to change your site to “false” in Postman once you’re done with scaffolding and making changes.

Pages

Includes the list of all pages in the site. Each page should have at least the below values, but can include others. You will be automatically generating these based on the values put into the menu, and inserting them into this section manually, but there will be some pages that should also be created by default like the homepage, search results, and 404 page. You will want to leave those pages in the list when you insert your custom pages.

To generate pages, you can run gulp make-everything, and pages will be created into multiple files. The default-pages.json file will exist there by default and includes things like the homepage, search results, and 404. These pages should also already be included in your make.json. The file custom-pages.json will be created from the information provided within your menus. This file can be copied in its entirety and placed within your make.json, alongside the other pages like the homepage, calculators, search results, etc. Lastly, all-pages.json is a combination of both the default-pages.json file and the custom-pages.json file.

You can also run gulp make-custom-pages if you would like to only retrieve a list of custom pages for the site.

Generating list of pages from HTML

To automatically generate the list of pages, first you will need to set up your menus on the site. Anything with a banno:menu tag will be searched for this information. Here is an example page setup within a menu:

<li class="menu-internal" role="menuitem">
  <a data-template="products" data-showsentinel="true" data-duplicate="false" href="personal/checking">Checking</a>
</li>

Page Values Within Menu

  • data-template - Should include the name of the mustache file that the page uses.
  • data-showsentinel - Boolean. Indicates whether the page should show the Banno Monitor badge in the footer. If the site purchased Banno Monitor, you will need to set this value to true for all pages, because will default to false and the badge will be hidden.
  • data-duplicate - Indicates whether the page is used more than once within a menu, or in a different menu further down the page. For example, if the privacy policy link is included in the main nav as well as the footer nav, you can set it to false for the first occurrence, and any other occurrences should be set to true. When set to true, you can entirely exclude the data-template and data-showsentinel values. If the page is listed multiple times without being noted as a duplicate, the automatic generator will create the page twice, which will in turn lead to errors with pages having non-unique URLs.
  • href - The HREF for a page. Note that the leading forward slash is missing–if it is included, you will end up with two slashes on your created pages within the CMS. For example, href="personal-services/checking" is correct, while href="/personal-services/checking" is wrong.

Explanation of JSON values for each page

The following explains the list of values that you will see for each page, and what they mean.

Required values

  • category - References one of the categories in the array from above. Can be left empty (as two double quotes, "") if the page is uncategorized.
  • url - relative url of page, should include category + ‘/’ + title. Should NOT have a leading ‘/’. For example, "url":"personal-banking/personal-checking".
  • templateId - references name of mustache template the page should be created with. This ID should match one of the templates in the “template” section described below.
  • title - Page title as found in sitemap in the design files. Note that for ADA, all page titles should be unique. (“Personal Checking” and “Business Checking”, for example, rather than “Checking” as the title for both. ADA scanners do not take page categories into account.)
  • showSentinel - Boolean. Tells page if it should show Banno Monitor badge or not.

Optional values

You can remove the sections for optional values entirely if they are not needed. All of this will be able to be edited in the CMS, but you may wish to add some of it prior to scaffolding your site to save time.

  • content - optional way to populate content.
    • name - content area name that you are wanting to fill out. These should be unique on a page.
    • content - HTML content for designated area. If your HTML includes quotes in some way, you will either need to use single quotes (because the content is wrapped in double quotes), or use a backslash \ to escape the quote. For example: "content":"<div class=\"big\">Text goes here<div>"
    • shareId - Indicates the ID number of the shared content group that this content area uses.
  • titleTag - The SEO title tag for the site. If you don’t want to have the title of a page be “Personal Checking”, you can instead set this value to be “Personal Checking”, and that will show up instead. Be sure to also include anything else you want included in the title tag, to match the other pages on the site - for example, the FI’s name.

Values you may see in Postman, but will not usually need to add when scaffolding

  • description - The meta description for the page. This is usually added by the client or PC when putting in content for the site.
  • keywords - The meta keywords for the page. This is usually added by the client or PC when putting in content for the site.
  • personalizedUrl - If the client changes the URL for the page, the update will be listed here.
  • accessibleBy - If only specific users are able to access a page, they will be listed here. Accessible by all by default.
  • headerCode - Any code inserted into the <head> of the page by the CMS.
  • footerCode - Any code inserted above the closing </body> tag of the page by the CMS.
  • indexedInSearch - Boolean. Indicates whether the page should be indexed within the site search component.

Templates

The list of available templates that a site has. After running gulp make-everything for a custom site, the templates will be listed within a file called templates.json. For a showcase site, after running gulp make-everything, you will also need to run gulp make-templates. All the necessary templates will then beincluded within site-specific-templates.json. You can use your chosen text editor’s prettify function to format the code better, and then copy and paste the list of templates into the template section of the make.json. This automation can also be utilized after scaffolding, if you’ve created a new template and want to get its list of content areas quickly. In that case, you’ll just need to run whatever command to create the template json file, find your new template and copy its conetent areas, and paste them into postman.

  • templateId - References name of mustache template the page should be created with. Should be unique.
  • title - Defines the title of the template.
  • description - The description of the template. For example, “Basic subpage with column on left side.”
  • imageLocation - The template thumbnail image, in format "imageLocation":"/assets/templates/filename.png". You can find the available images within the templates > images folder. For very unique templates, you may want to create your own, but the files included will usually cover all your needs.
  • contentAreaNames - The list of content area names for the template. Each content area name should be unique. Listed in double quotes and separated by commas.
  • devOnly - Boolean. If set to true, the client will not be able to see this template when they go to make a new page in the CMS. It is only visible to developers, project coordinators, and designers.

The list of menus included within the site. This will usually include at least two menus - the main menu and the footer menu, but you can add on as many as you need for things like a top list of links within the header or a social media list. These menus will be created within the CMS, and can be edited there as well.

To automatically generate the menus, you should have already edited your menus within your HTML as described above in the Pages section. You can then run gulp make-everything to generate all files including your menus.json file, or you can run gulp make-menus to only generate a new menu file.

Explanation of values

Highest level (the overall definitions for the menu)

Nearly all values for the menu pieces are repeated for each level.

  • id - For showcases, this will automatically be set up and hooked into the HTML for you. For custom sites, this can be left off, and one will be generated once you create the menu which you will hook up manually. You will then need to go into the CMS for the site, select the Menu option in the left sidebar, and click on the menu bar that you need. In the URL when you’re viewing the menu of the CMS, you can copy and paste the ID that it gives you and put it in the HTML for your banno tag. For example, a URL of https://uat.banno.com/a/cms/0000/menus/12bbe400-9ce8-11e9-838e-0242de20af2b means that the menu’s ID is 12bbe400-9ce8-11e9-838e-0242de20af2b, and therefore your banno menu tag should be edited to look like this: <banno:menu menu-id="12bbe400-9ce8-11e9-838e-0242de20af2b"></banno:menu>
  • label - The label that will show within the CMS to denote which menu it is. Try to keep these short, yet descriptive.
  • newWindow - Does not apply here. Can be left false.
  • menuType - Can be left “root” as default.
  • value - Can be left null.
  • anchor - Can be left null.
  • children - Includes the list of categories (and within that, the groups and/or pages.)

First level (the categories)

Values defined here will show up as the first items within the menu bar. These are generally things like categories, and sometimes occasional links that don’t have a dropdown. For example, on Sonora Bank, the items Personal, Commercial, Loans, Digital, Insurance, and About are all first-level menu items.

  • label - Indicates what the category or item should show as.
  • newWindow - Can be left false if this is a category or group. If it’s a page, and the client wants the page to open in a new window, this can be changed to true. You will also be able to change this within the CMS once the site is scaffolded.
  • menuType - Possible values are “category” (to note that it’s a category listed for the site), “group” (to note that it’s a sub-category of pages, sometimes also used for pieces of text like a routing number), and “internal” or “external” (for page links - internal denotes a page within the site, and external denotes an external link to another site).
  • value - If this is a page, the URL will go here. Make sure not to include a leading forward slash. This should match what you wrote in the nav section for data-href exactly.
  • anchor - If this is a page, and the page contains an anchor tag that should automatically be jumped to, that can go here.
  • children - Includes the list of groups and/or pages within the category.

Second level (the groups and/or pages)

Values defined here will show up as dropdowns of their parent categories. For example, on Sonora Bank, hovering over Personal shows you the second-level items in a dropdown. As a second example, on 1st United Credit Union, all dropdowns also include groups. Hovering over the Checking & Savings category reveals two groups, one called Products and the other called Resources, that each have their own sub-list of pages.

  • label - Indicates what the page or group should show as within the menu. If it’s a page, this can be different from the page’s title, if needed.
  • newWindow - If it’s a link, this indicates whether it should open within a new window or tab. This can be changed within the CMS once the site is scaffolded. If it’s a group, you can leave this as false.
  • menuType - Possible values are “group”, “internal”, or “external”, described above. In theory you could also have a value of “category” here, but it’s not common and probably not best practice to list a category within another category. That’s what we use groups for.
  • value - If this is a page, the URL will go here. Make sure not to include a leading forward slash. This should match what you wrote in the nav section for data-href exactly.
  • anchor - If this is a page, and the page contains an anchor tag that should automatically be jumped to, that can go here.
  • children - If this item is a group, any subpages within that group will be included here.

Third level (subpages within groups)

This is usually as far as our nesting goes. It is incredibly rare for a site to have more levels of links than this, because it’s just bad UX.

  • label - Indicates what the page or group should show as within the menu. If it’s a page, this can be different from the page’s title, if needed.
  • newWindow - If it’s a link, this indicates whether it should open within a new window or tab. This can be changed within the CMS once the site is scaffolded. If it’s a group, you can leave this as false.
  • menuType - Possible values are “group”, “internal”, or “external”, described above.
  • value - If this is a page, the URL will go here. Make sure not to include a leading forward slash. This should match what you wrote in the nav section for data-href exactly.
  • anchor - If this is a page, and the page contains an anchor tag that should automatically be jumped to, that can go here.
  • children - As noted, this will likely not include anything since going below this is bad UX.

Shared Content Groups

This section includes the list of shared content groups for the site. There should already be one created by default, for the calculator banner image. That can be left as-is. The shareId for the calculator banner image content group will also be automatically set within each of the calculator pages. You usually won’t need to create shared content groups before scaffolding, but here is the explanation of values.

  • id - The unique ID for the shared content group. If it’s being used on a page, it will be included within the page’s “shareId” attribute.
  • title - The title of the shared content group. These should be unique and descriptive, yet short because there is limited space within the menu.
  • description - A short description of the shared content group.
  • latestContent - The content within the group. You won’t usually need to add anything to this before scaffolding the site.

Disclaimers

When clicking on a link that goes to an external website, one of these disclaimers will pop up. You will note that each disclaimer includes the text [Financial Institution] - make sure to select each instance of this and replace with your FI’s name. You can do this quickly by selecting the text and then pressing command D until all instances are selected, and fill in your FI’s name.

Once you scaffold, each disclaimer will also receive a unique ID. If any links within content have disclaimers, they will be given the attribute data-disclaimer-id with that ID inside the value. That is how the CMS determines whether or not to show a disclaimer for a link, and which disclaimer to show.

  • message - The information that shows up within the body of the disclaimer modal. Most of this text can be left as-is by default, just make sure to add in the FI’s name as described above.
  • title - The title of the disclaimer, which will also show as a header within the disclaimer modal. Keep this short and descriptive. You can leave the default values as they are.

Forms

A list of all the forms available on the site. We have generic forms for things like the Accessibility Feedback form, the email collection form (there are multiple versions: one for showcase, one for custom sites with full name and email fields, and one with first name, last name, and email fields), and on showcase sites only, the contact us form and warm lead form.

If you have any custom forms for a site, and the jira card for that custom form is up to at least UAT on the board, you can also include it here and it will automatically be included in your site’s list of forms once you scaffold. Here is the explanation of each attribute.

  • id - The ID of the form. In the HTML for your form, you will have noted the ID and name on the form tag, and the input type=“hidden” below the form tag also has a value–all 3 of these should match. And that value is what you use for the form ID here in the JSON.
  • name - The name of the form that will show in the CMS. Try to keep it short and unique, yet descriptive.
  • formType - The value that the form is set up under in the backend. There are two ways to set this up, the second way is usually easier because there’s less guesswork with the name. If your form is not set up in the backend yet as described above, you will not be able to do this.
    • To find this value prior to scaffolding (trickier option), go to this page within GitHub and find your site. Within the folder for your site, there will be a list of subfolders for each unique form that has been built. The value of your formType field will be “sitefoldername-nameofformwithinscala”. For example, for 1st United CU’s form, it would be “firstunitedservicescreditunion-contactus”.
    • You can also set up the form after scaffolding the site. Within the CMS for your site, click Settings in the left column, then Admin Settings, then in the new window it takes you to, select “Form Setup” in the top bar. The “formType” value is simply selected from a dropdown. Find the section for the forms in your site (if you’re unsure what this is, go to this link and find the folder with your site’s name), and then within that choose the correct one for the form you’re building.
  • emailTo - This can contain a list of the site’s users to whom an email will be sent once a form is submitted. You can leave this blank when scaffolding the site, and the PC will add in these users later.
  • unread - Indicates the number of unread form submissions. This can be left as 0.
  • captcha - Boolean. Indicates whether the form uses captcha. If the client purchased captcha for any or all of their forms, it should be noted on the trello card. The one exception is email collection forms - captcha is not usually included on these, even if it has been purchased and is included on the other forms for the site.

Feeds

Refers to RSS feeds that the site may be using. This is not used much if at all anymore, so it will be left blank 99% of the time. If you have questions, reach out in the #org-content-dev room on slack and someone can find you an example!