This article includes common portal issues, how to diagnose them, and how to fix them.

Duplicate branding

A portal method’s output type determines how the data is returned in the portal. This is often set to Default Branding, which renders the portal method’s view as an HTML web page styled with your branding.

If your portal has tabs, you might see duplicate branding content in the tabs.

To fix this:

1. In the portal, select the method for the tab in which you see duplicate branding.

2. Select Edit.

3. Set Output Type to AJAX Popup/No Branding.

   

4. Select Save.

z

📖 Further reading: The Portal method output type

Portal loads slowly

Slowly loading portals or timeouts can occur if portal queries are inefficient or trying to pull too much data at once.

To avoid query slowdowns:

• Portal queries should using standard Configurable Joins query bases

• Avoid custom SQL

• Break up large queries into multiple, smaller queries

• Run queries only when necessary by separating portal content into multiple tabs

• Don’t link a query to a method if the method doesn’t use the query’s data

• Don’t duplicate exports across queries when they're not needed.

  • For example, if a method is linked to two queries and you need the pull the rank 1 GRE score, including it in just one of the linked queries will suffice.

• Does data need to be displayed immediately upon page load, or  can user action request the information manually, as needed?

  • For instance, if you want to display a list of checklist items for a list of applicants in the portal user's department, does the user need to see the checklist items immediately when they log into the portal? Or could the checklist information be in a pop-up where the data is only pulled when the user wants more information about a specific applicant?

    

Table view widget issues

📖 Further reading: Table view widget

No queries appear in the Query list

When using a table view widget, only queries with a node will be available for selection.

1. Go the query to be used in the table view widget.

2. Click Edit Parameters.

3. Add a value for the Output Node.

   

4. Return to the portal view and select the query.

No results shown (Error 500)

Error 500 issues are usually caused by the following:

• Table view widgets in portal views must have a query selected from the list:

  
  
  

• The query used must contain a sort:

  

Unsupported method

This error typically happens because:

• A portal was created with one or more views, but no methods

• An action was called, but no method with that action exists

• There is a naming mismatch between the action being called and the action of the method

If your portal does not have any methods and you see this error, make sure there is at least one method associated with a view and has a blank action.

This error can occur if the URL in the view goes to to the new pop-up or tab, but you have not yet created a method. Creating the method with the determined action usually resolves the error.

If it persists, check the cmd called in the URL for typos relative to the Action of the method. In this example, the portal method is directory_detail, but the cmd in the URL is directory_details:

Must declare scalar variable

If you are using a parameter in your portal, for example, passing the ID of the record clicked into the query to return data in a pop-up, or sending in a filter selection, then the parameter must be declared in the Edit Parameters menu.

To fix this issue, in the query in which you receive the error:

1. Select Edit Parameters.

2. In the Parameters field, enter the parameter. For example, <param id="major" type="uniqueidentifier"/>.
   

3. Select Save.

Tabs are not highlighting

• Check the JavaScript in your tabs: are you setting the class to “active", rather than “selected", or other types of class?

  

• Use Custom CSS Rules to change the color, hover color, size, etc. The subtabs class in the rule is active, as it should be.

  

User can access a view they shouldn't see

Make sure your redirects follow conventions in the Portal Redirects article. That is, if you have multiple views, you should have one redirect method per view method.

For example, in this portal with two separate views (and no tabs), you'll see that there is a method with an action for each view, as well as a corresponding method with the same action for the redirect.

In a portal that uses tabs, you only need a single redirect method. In this case, the redirect query must have a parameter called tab that captures the current tab and redirects based on it.

Merge fields are blank

The merge fields used in Static Content parts must match exactly with the query exports.

For example, in the query, if the export label is first but in the view the merge field is first_name, then the data will not display.

If you’ve confirmed the merge fields and the query exports match, check whether the query is linked to the appropriate method.

When a portal method runs, it only has access to data in queries linked to that method.

If the volunteer information query is not linked, then the portal method does not have access to the data in that query, and the data is not used in the view's merge fields.

Liquid looping merge fields are blank

Liquid looping syntax requires a prefix in front of the merge fields. If you recently added a merge field and it’s blank, make sure the prefix is present.

In this example, the location merge fields are missing the result prefix shown in the other merge fields. In this scenario, the summary and date information does populate, but the city and region do not.

In the source code, the Liquid looping syntax starts with for result in my_event.  

my_event is the node used in the query. result is the prefix.

For Slate to loop through the list of results in the my_event node, each merge field must include result.<field_name>, where <field_name> is the name of the merge field.

The prefix in Liquid looping can be determined by the user. You may see examples that use for item in node_name or for applicant in node_name.

Whatever prefix you decide to use, it must be used in front of each merge field while using Liquid looping.

When to use nodes

If your portal retrieves information about a single record and a list of records (for example, an alumni interviewing portal that displays data about the alumni record logged in as well as the list of interviewees assigned to them), it’s important to understand when to use a node and when not to.

A node is only necessary when pulling in a list of results.

In the following example, we have a query for a list of possible interviewees and a query for a list of possible events. These queries have nodes because there could be 0-n results. There is also a query for volunteer information about the volunteer logged into the portal. This query does not have a node, as it is only returning a single row of data.

Pop-up doesn't load any data

In order for data to appear in a pop-up, a parameter must be used in the URL for the pop-up.

📖 Further reading: Portal pop-ups

For example, the portal may pass in an applicant's ID as the value for the id or record parameter. The name of the parameter used in the URL must match the parameter used in the query that returns the data in the pop-up. Additionally, the portal must have access to the merge field that populates the value.

In this example,

• The parameter name is application

• result.id is the value that will be passed to the pop-up query

Check for a value

The first thing to use your browser’s developer tools to check is whether a value is included.

In Chrome, press Command + Option + C (Mac) or Control + Shift + C (Windows, Linux, Chrome OS).

Selecting a record in Slate, we then select the Network tab. Here, we can see application=c63763f4-f83f-4d7c-8b7a-938540ce5299. This confirms that a value for application is being sent into the pop-up query.

Next, we check the parameter in the pop-up query. If it is not application, then the query will not be able to accept the value.

To check this value:

1. Go the query used in the pop-up.

2. Select Edit Parameters.

3. Confirm the following:

   • Ensure the param id in the Parameters field matches the parameter used in the URL.

   • Ensure that you set a type.

   • Check that the filter then uses the same parameter.
     

4. Select Save.

Opening the GUID filter for the query, we see that application is indeed the parameter and is used in the filter.

Ensure query uses nodes only where applicable

If data is still not appearing in the pop-up, make sure that the query is only using a node where applicable.

In this example, two queries are being used in the pop-up. The first query, which pulls details about the applicant clicked, does not have a node, because there will only be one record in query results. The second query, which returns the checklist items for the applicant, does have a node, as an applicant might have multiple checklist items.

Portal XML

XML, also known as eXtensible Markup Language, is designed to store data while HTML displays the data. In a portal, users can see their HTML using the Source Code in the view widgets. To view the XML, users can go to the portal and append &output=xml (or ?output=xmlif the portal URL does not have any additional parameters).

1. Go the portal.

2. Open developer tools, and go to the Network tab.

3. Right click on the URL, and select Open in new tab.

4. Append the URL in the new tab with output=xml.

The XML displays information about the user logged in, as well as the data from the portal queries for that method.

Only users with the Administrator (All Access) permission will be able to view the XML.

Using XML can help users troubleshoot the names of the merge fields, identify what nodes are used, etc. While it is not necessary to understand XML or be familiar with browser developer tools to build a portal, some familiarity can be useful when troubleshooting.