Troubleshooting Portals

Branding is appearing twice

The portal method output type determines how the data is returned in the portal. If the portal leverages tabs, then the method using the view containing the tab architecture should set the output type to Default Branding. The methods associated with the tab views should be set to AJAX Popup/No Branding.

The portal is slow to load

Slow loading portals or timeouts can occur if portal queries are inefficient or trying to pull too much data at once. To start, ensure that all portal queries are using standard query bases whenever possible and have limited use of custom SQL. 

Breaking up large queries into multiple queries can also help load the portal if a large amount of data is needed. 

Consider if the information can be broken up across different tabs so that queries are only pulled when necessary. Also, check that queries are linked only to their appropriate methods. There is no need to link a query to a method if the data is not used when the method is called. 

Additionally, check that exports aren't duplicated 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. 

Try to see if information needs to be displayed immediately upon page load, or if a user could take an action to get the information. 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? 

Unsupported Method error

This error typically happens during one of these circumstances:

• No method was ever created with the action.
• There is a naming mismatch between the cmd being called and the cmd of the method. 

When starting to build a portal with pop-ups or tabs where additional methods with actions are needed, this error can occur if you have built the URL in the view to go to the new pop-up or tab, but have yet to create a method. Creating the method with the determined cmd will resolve the error. 

If you have already created the method but are still seeing the error, check the cmd called in the URL against the action of the method. In this example, the portal method is directory_detail, but the cmd in the URL is directory_details. 

Custom SQL snippet is not saving

If you are using a parameter in your portal, such as 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 Edit Parameters.

Tabs are not highlighting, or prefer a different color

To start, you'll want to ensure that in the JavaScript for your tabs, you are setting the class to active rather than selected or other type of class.

Additionally, you can use Custom CSS Rules to change the color, hover color, size, etc. The subtabs class in the rule is active, as it should be.

Records can still access a view that they shouldn't see

If the portal uses either multiple views or tabs, it is important to include a redirect method for each associated method.

In this example, you'll see that there is a method with an action for each tab, as well as a corresponding method with the same action for the redirect. 

The 'Tab: Home' method has an action of 'home' and an output type of 'AJAX Popup/No Branding'. 

The 'Redirect: Require Form Home Tab' also has the action of home, but the output type is Redirect. This method ensures that when the record is accessing this tab, the portal checks whether they have access or if the record should be redirected. 

Data isn't displaying in the portal

The merge fields used in the portal view 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.

The export labels have been updated to match the merge fields exactly. 

If the merge fields and the query exports match, you'll want to check if 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 doesn't have access to the data in that query and, consequently, the data is not used in the view's merge fields. 

New exports were added to a query, only some of the exports are populating 

When returning a list in a portal, users will leverage Liquid looping syntax. This syntax requires a prefix in front of the merge fields. 

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 starting with for result in my_event.  my_event is the node used in the query. result is the prefix. When looping through the list of results in the my_event node, in order to output the data correctly, each merge field must include result. before the merge field name.

The prefix in Liquid looping can be determined by the user. You may see examples of for item in node_name or for applicant in node_name. Whatever prefix is decided, it must be used in front of each merge field while using Liquid looping.

When creating a portal that pulls information about a single record, as well as information about 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 is important to understand when to use a node and when not to. 

A node is only necessary when pulling a list of results. In this example, there is 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. 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. 

The parameter name is application. result.id is the value that will be passed to the pop-up query. The first troubleshooting step is to ensure that a value is included. You can check using your browser's developer tools. When using Chrome, press Command + Option + C (Mac) or Control + Shift + C (Windows, Linux, Chrome OS).

Clicking on Kat's record, we can see in the Network tab that application=c63763f4-f83f-4d7c-8b7a-938540ce5299. This means that a value for application is being sent into the pop-up query.

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

application is indeed the parameter and is used in the custom SQL snippet.

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. 

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). 

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.