Portal Settings
A Portal is the entity that can be considered the Application, defining the look & feel and the hostname where it can be accessed.
Last updated
A Portal is the entity that can be considered the Application, defining the look & feel and the hostname where it can be accessed.
Last updated
As mentioned in , a Project can have multiple Portals. But must have at least one, so when creating any project, a Default portal is automatically created for you.
In this Summary block, you can see the following information:
Name and type of the Portal: "Default" and Website;
Home page: the starting point of the portal, defined by a specific Navigation Point which is linked to a specific Flowchart; [click] to change to a different item, or [Ctrl+Click] to locate in tree;
Design Template: the selected design template that defines how the portal will look; [click] to change the selected Template or to change the specific Template Configuration
Default Language; [click] to change the Language Settings;
Timezone setting; [click] to change;
SMTP Mail Sending Server Setting; [click] to change; You will get a list of available SMTP Servers to use for sending mail - these SMTP Server Profiles need to be setup in Workspace or DevOps Portal.
Staging information: date+time last published and the configured hostnames; [click] to change;
Live information: date+time last published and the configured hostnames; [click] to change;
Basic Portal Settings is where you can change the Name of the Portal to something more meaningful than Default.
The Home page is the Navigation item that points to the flowchart that has to be executed when a user first accesses the portal (by hostname). The Home-Navigation Item and the Home Flowchart are automatically created and set as starting point for any new created project. You do have to add at least some nodes to the Home flow (at creation it only gets a start-node).
Read this forumpost for information about the accessibility of the Home page navigation item.
The Design Template is the definition for how your application will look. It defines the base setup for all your pages in the project, generating the necessary HTML that browsers need to present the results to the user. The Design Template defines certain standard "containers" - blocks where standard elements like the Menu's go, what the main container is where all your own Interaction Templates will be put, the standard styling for all elements, fonts and colors.
Any WEM Design Template may support and provide specific setting-properties which you can provide custom values for in the Design Template Settings overlay.
If the available collection of Design Templates does not fit your needs, there are possibilities to get your own Custom Design Template. A WEM Design Template is a complex collection of files and definitions that have to be put together correctly. If you want to manage your own Design Templates, you need to have profound knowledge of LESS, CSS, HTML at least - but there are WEM Partners who can assist if you do not have this knowledge available.
For licensed customers with proper experience, WEM provides a specific tool to create and synchronize your own WEM Master Templates: WMT Design Tool
WEM supports multiple languages. On the Project level you can define which languages you want to be enabled. Thereafter, on each Portal you indicate which of those languages is the Default language. Just select one from the available languages, or click the gear-button next to it to add more. You will see an example of the formatting for numbers, dates and times that the selected language will use when presenting these types of fields.
Then, you select an option for the strategy: should the default language always be used, do you want to follow the user's browser-settings regarding the language, or do you want to let the user actively select the language? For the latter scenario, a dropdown with all available languages (as set on project level) will be displayed in the top-row of each page.
There are other options available to allow the user change a language, or you can even allow users select a language and store it into a preferences profile. You can manage (check and set) the selected language using the appropriate process-nodes.
There are three ways to determine the time zone for end-users:
Working with the WEM Modeler is free of charge, you can create an account and start getting to learn WEM and all its features without costs (just your time). You can also start your project in Preview, to test how it will work out for end-users.
When you want to publish your project to Staging or Live, to make your application available to your targeted end-users, you will need a License Key. This License Key is obtainable via WEM Partners or WEM HQ when an official business license has been agreed upon. Click here for the Main WEM License options, and fill in the form on that page to contact WEM for detailed options and prices.
Hostnames are the addresses by which your application (Portal) can be accessed. Read some info about hostnames.
There is a specific post on the WEM Forum about this feature, as well as a specific documentation page.
This information is important, so please read and understand it to be able to configure hostnames correctly. In the Hostname Configuration page, the documentation is also linked, so you can access it easily when you need it the most.
On the Hostname Configuration, you can see the option [Force https]. If you enable this option, the portal will force each request to run with https (secure, encrypted using SSL/TLS). We do suggest to use this option, but you do need to activate this setting yourself.
For the option [Force https] to work, there needs to be a valid SSL certificate in place for the hostname of the portal. When the hostname is part of the wem.io domain (*.staging.wem.io or *.live.wem.io), it works immediately because those hostnames are automatically covered by our wildcard certificates. But if you use a custom hostname, it is recommended that you first take care of the CNAME DNS setting (as described in the forum post), then go to MyWEM Support and use the [Request SSL Certificate] button to start a request for SSL certificate for your hostname. WEM uses the free LetsEncrypt Certificates, and after initial setup, this certificate will automatically renew each 3 months.
Portals can run under multiple hostnames: they are just different addresses pointing to the same application. This is useful when you want to develop and publish early using the wem.io hostnames, and only when you are ready and have a custom hostname properly set up, add that hostname and start using the new hostname. Another practical use for multiple hostnames, is to provide one application to several different user-groups and make small differentials based on the hostname that the user uses, with the WEM Environment Function Hostname().
In the Add Hostname dialog we added some useful links to information about DNS and related info.
Sometimes an applications runs into an unexpected situation. For several of these situations you want to specify what needs to happen. You can do this by specifying a particular flowchart to which the application should jump when one of these unexpected situations occur. That may be simply displaying a more user-friendly error message, but could also result in executing some workflow/application functionality.
There are 3 possible Error Handlers for which you can define your own specific flow:
Page Not Found: This can happen when a user tries to access a path that does not exist (for example a miss-typed address in the browser), no navigation item with a backing flowchart can be started > then the standard Page Not Found error will be displayed. OR if the portal has not yet been published and someone tries to access the hostname. This event can be caught and by selecting your own flowchart you can provide your own page and message, or redirect the user to the starting page.
Session Expired: This can happen when a user has been active in your application, but then decides to start doing other things, keeping the browser and the application open. Web Applications are typically "disconnected" applications, and sessions are kept alive by sending messages back-and-forth (request from user to server, response from server back to user). When at some point - after the Session Timeout Value has been reached - the server does not receive another follow-up request from the user, the session is regarded as no longer active and will be discarded and disconnected by the server to free up resources for other requests. This may also be regarded as a Security Risk (if users leave their browsers open and computer active and unlocked, other people may dive in). We have a forum post about the Session Timeout Setting, read about it here. In conclusion, when this situation occurs, you can catch this using the Session Expired error handler. For example by redirect the user to the login page, or show a friendly message as to why the application is no longer active.
Unauthorized:
Some elements in WEM have the property [Visible When] / [Allow Access When], for example on navigation items and files. When an item that a user is trying to access, is not visible or available, the Unauthorized situation is triggered, and you can use this custom error handler to determine what should happen (for example, send a mail to administrator to let it be known that unauthorized access was triggered - or just show your own friendly message). This Unauthorized flow can also be used manually in your flows, when you do your own custom check on access.
Whenever a value in these Project- or Portal-Settings has been changed, you need to publish the project, in order to get the changes available in the Staging and Live runtimes.
The Publish Process will be described further down... Publishing Process
Using the "hamburger menu", you get access to the Portal Context Menu, to change all settings.
Click on the "colour palette" icon to open the list of available Design Templates. WEM provides a range of predefined Design Templates. Each of them has some (or many) additional settings to change to your needs. The[Customizable Main]Design Template is the template with the most options you can set and modify yourself (within limits) and is becoming the most-used template of all.
Use a specific time zone: With this option, you can select one specific time zone from the available list of IANA Standard Time zones; then all times in the application are based on that time zone, and localization to end-users time zone is not useful.
Derive from client IP: This option is the default when new projects are created. With this option selected, the runtime environment will lookup the end-user's time zone based on the IP-address, using a global lookup table with known registered IP-address ranges and their known time zones. You can use the UTC time zone (and related functions) to store specific date+time values, and choose to display them as local time to the end-user based on their time zone. This approach should be used when displaying date+time values for events that are not location-bound (like an online meeting, but not for a local concert at a certain venue - that time is linked to that location specifically).
Use time zone from device: This is only available in Native Mobile Apps and can get the known time zone from the device. With this option you can also work with specific times translated to the user's local time zone.
