# Web applications

A web application or web app displays the content created in content and channels to create your personalized digital channel. All the development, design, and navigation flow is carried out in the web application.

A web app can be in one of these three states:

  • Enabled: Default status of newly created web applications and those that are enabled for use.
  • Pending changes: There are pending changes in the web application. An administrator can verify the changes and publish the web application.
  • Disabled: The web application cannot be accessed.

# Create a Web Application

To create a new web app, follow these steps:

  1. In the side menu, click on channels.
  2. Click on + new application.
  3. Type the name and host (main path of the web application).
  4. If necessary, select which realm it belongs to.
  5. Click create.

Once created, the web application is automatically enabled and the system takes you to the summary screen.

Attention

In the web apps index, you will only see those apps in which you have a role and are part of the team.

# Review and joint publication

On the review and joint publication screen, you can see all the pending changes to be published in your web app. To view the changes, click on the view button.

# Joint Publication

To make a joint publication in your web application, follow these steps:

  1. In the side menu, click channels.
  2. Click on your web application.
  3. In the summary screen you can see the pending changes to be published. Click on the publish button to preview and select the changes.
  4. Select the changes you want to publish.
  5. Click on the publish button.

Tip

If you click publish on a particular article (e.g. publish a page), the Review and Publish window will open with this article selected to see the pending changes.

When you create a web application with Modyo, your users can search your web apps and all their content using the search function. This can be done using the /search URL or by accessing the dedicated search page.

To enable or disable the search functionality, follow these steps:

  1. In the side menu, click channels.
  2. Click on your web application.
  3. Click on general.
  4. In the privacy section, enable or disable the enable search box, as required.
  5. Click save.

# Search template

You can control the appearance and search functionality in your web app using the template search.

This template is available by default in the templates section and contains all the Liquid code needed to carry out queries in your web app. By default, when making a query, the records are displayed in list form, with their title, description and a link to their address. You can modify the template to suit your needs.

To access this template:

  1. In the side menu, click channels.
  2. Select your web application.
  3. Click templates in the side menu.
  4. In the views section, in the right column, and under the search category, click show.

To access the search template, append search or search.json to the URL of your web app.

For example:

  • test.modyo.com/mySite/search
  • test.modyo.com/mySite/search.json

# Search.json

You can also use “search.json” to integrate the search engine in a more personalized way.

To access this API, add “search.json” to the URL of your web app along with your query. For example: test.modyo.com/mysite/search. json?query=MyQuery

Customize your queries as follows:

Parameter Description
query Make queries to the search API. This search engine performs queries on all published pages of your web app and on all public entries in the spaces linked to the web app.
per_page Divide the total number of records by the number of pages selected.
page Select the specific page you want to consult, in case there are multiple pages of records to query.
multi=true Allows you to search in all the web applications in the account that have the search function enabled.

# Web Application Settings

In the application configuration section, you can customize your web app so that your visitors, customers, developers, and administrators view your web app differently. As well as to optimize the SEO of your application.

# General

In this section you can configure:

  • Name of the application: This field is used as the default title for the SEO of your web app.
  • Description

Warning

Changes to the name and description are immediately reflected in Modyo. The update in the search results will be seen once the search engines complete their reindexing process.

  • Application logo: Image shown at the top left.
  • Application language: The language in which your web app is available. The options are: Spanish, English, and Portuguese.
  • Time zone: The timezone in which the date and time fields are displayed in the app. This setting affects all sections, including pages, navigation and templates, as well as Liquid's calls to the web application data.

Attention

The time in content is managed in the general (opens new window) section of the account settings.

  • Google Tag Manager ID: Add a Google Tag Manager identifier to insert scripts for tracking and measuring events.

By default, new Modyo themes include snippets to automatically inject Google Tag Manager scripts into tags <head>and<body>of web applications.

To access these snippets:

  1. In the side menu, click on channels.
  2. Select your web application.
  3. Click on templates in the side menu
  4. In the column on the right side, click on snippets and go to the general section. You can embed them in the head snippet and in the home and base views.

To create custom snippets:

For the head:

  1. Use this code:
{% if site.tag_manager_id != '' %}

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','{{site.tag_manager_id}}');</script>
<!-- End Google Tag Manager -->

{% endif %}
  1. Embed the snippet in the head of the web app using {% snippet "gtm-head" %}, replacing “gtm-head” with the name you gave the snippet.

For the body

  1. Use this code:
{% if site.tag_manager_id != '' %}

<!-- Google Tag Manager (noscript) -->
<noscript>
<iframe src="https://www.googletagmanager.com/ns.html?id={{ site.tag_manager_id }}" height="0" width="0"
style="display:none;visibility:hidden">
</iframe>
</noscript>
<!-- End Google Tag Manager (noscript) -->

{% endif %}
  1. Embed the snippet inside the body tags of the home and base views using {% snippet "gtm-body" %}, replacing “gtm-body” with the name you gave the snippet.

With this configuration complete, when there is a value associated with the ID field of Google Tag Manager, the scripts will be automatically injected. This will allow you to create events in Google Tag Manager to record the actions of your users.

  • Favicon: Image that appears on the side of the address bar.
  • Apple icon: Image that you see on mobile devices when using the site as an application.
  • Delete: Permanently deletes a site and all its elements.

Danger

Erasing is irreversible, you must be completely sure when executing this action.

When you press the delete button, the system will ask you to enter the textual name of the site you want to delete to confirm the action. Once confirmed, you won't be able to access the site or its elements again.

Visualization

  • Favicon: Image displayed next to the address bar.
  • Apple icon: An image that is displayed on iOS mobile devices when you mark the application as a favorite.

Privacy

  • Audience: All visitors can view the web app and its content without having to log in.
  • Private: Only users who are logged in to Modyo can view the web app.
  • Show home to public visitors: The home page of the web app is shown to all visitors, even those who are not logged in. When navigating to any other page, registration or login is required.
  • Redirect to home when a URL is not found: By default, the web application shows a 404 error when the user accesses a non-existent URL. If you check this option, the user will be redirected to the home page of the web app instead of to the 404.
  • Enable search: Activates search function in the web app.
  • Enable search across multiple applications

Tip

If you enable search in your web app and use the multi=true parameter from another web app, you can also search in your current app.

Danger Zone

Danger

Use caution when modifying these options, as they can affect access to your web application and your users' experience.

  • Change host: This action modifies the visibility and accessibility of the application. Making a host change can impact the visibility and availability of the web application.
  • Change realm: Shows the application's realm. When you change the realm, you lose all the privacy settings in your web apps, pages, and browsing.
  • Change status: Changes the status of the application, the options are:
    • Enabled: Editable and visible to the public. This is the default state of a web app.
    • Editable: Modifiable but not visible to the public. Requires login to access. Robots.txt, PWAs, and the manifest are disabled in this state.
    • Disabled: Not editable or visible. In this state, it's not accessible or visible to users.
  • Delete app: Initiates the asynchronous removal of the application and all of its elements, such as pages and widgets.

Danger

Deleting a web application is irreversible.

When you press the delete button, the system asks you to enter the textual name of the application to confirm the action. Once confirmed, you can't access the application or its elements.

# SEO

SEO (Search Engine Optimization) is essential for search engine positioning. Users rely on good SEO settings to find your application.

You can configure:

  • Tagline: Description for search engines, below the name of the web application.
  • Automatically update the sitemap.xml file for me: Allows Modyo to create and maintain the sitemap.xml automatically. Disable this option to use a custom site map.
  • Sitemap: This XML file allows search engines to index site content.
  • Custom sitemap.xml file: File that allows search engines to index the content of the web app.
  • Automatically update the robots.xml file for me: Allows Modyo to automatically create and maintain robots.txt. Disable this option to provide personalized instructions to web app crawlers.
  • Custom robots.txt file: File that tells web crawlers what parts of the application they may or may not index.

Tip

The robots.txt and sitemap.xml files are only visible with custom domains. Otherwise, they are found only at the platform level, have default values and cannot be customized.

  • Custom meta tags: Allows you to configure meta tags for all pages and their default values. Click + new meta tag to create a new one.
  • Replicate metatag on pages: When creating a new meta tag, select this option to spread the meta tag and its value across all pages of the web app. You must save the changes to meta tags and publish all the modified pages for the new meta tags to take effect.

Attention

Only administrators of the application can add meta tags. Developers can add and remove meta tags page by page.

# On-page vs. off-page SEO

Also known as on-site and off-site SEO, these terms refer to actions you can do on and off a web page to improve visibility in search engines. For better positioning, we recommend using both strategies together.

# On-Page SEO

To improve on-page SEO:

  • Use keywords in the SEO section of the platform and on your pages.
  • Include keywords in the URL.
  • Add relevant links to other sections of your application.
# Off-Page SEO

To improve off-page SEO:

  • Promote content on social networks and other distribution channels.
  • Encourage alliances and collaborations with authoritative media on the subject.

# PWA

Modyo allows you to implement progressive web apps (PWA) on your digital channels under development. To do this, you have two options:

# Manifest

The manifest indicates how you want a browser to display your digital channel. To activate the manifest:

  1. In the side menu, click on channels.
  2. Select your web application.
  3. Click on application settings.
  4. Click on PWA.
  5. Check the Enable PWA Manifest box.
  6. In the modal, fill in the fields.
  7. Click generate.
  8. Click save in the modal.
  9. Click save.

When you activate the manifest, this route is created:

https://[domain]/[site-name]/manifest.json

It is necessary to implement the manifest on each page of the PWA through Templates, in the head snippet.

Attention

If you do not customize the content of the PWA manifest and add the route in templates, the manifest will be created blank and will have no effect.

# Service worker

Activate the Service Worker so that your digital channel can cache data, work offline and provide an improved experience for your users, even with an unstable connection.

To enable the service worker, follow these steps:

  1. In the side menu, click on channels.
  2. Select your web application.
  3. Click on application settings.
  4. Check the Enable Primary Service Worker box.
  5. Click save.

Once activated and saved, the following route is created:

https://[domain]/[site-name]/serviceworker.js

To modify the service worker, follow these steps:

  1. In the side menu, click on channels.
  2. Select your web application.
  3. Click on templates in the side menu.
  4. Click on the snippets tab in the right column.
  5. In the service worker section, select the file you want to modify.
  6. Click save.
  7. Click publish.

Attention

You need to customize and save the service worker code to integrate these functions into your web app.

Attention

If you turn off the service worker, your web application will continue to work, with basic functions and without the benefits of the service worker.

# Domains

In the domains section, you can view and modify the public location of your web application.

Attention

It's essential to inform all members of the platform about any changes you make to this section.

Check the box to make changes. The variables you can modify are:

  • Host: Location of the web application on the server.
  • Primary domain: Main address of the web application.
  • Alternative domain: Secondary address to redirect in case the primary one fails.

Attention

These domains are reserved by Modyo. They are not available as custom domains:

  • education.modyo.com
  • elearning.modyo.com
  • training.modyo.com
  • capacitacion.modyo.com
  • support.modyo.com
  • soporte.modyo.com
  • developers.modyo.com
  • desarrolladores.modyo.com
  • www.modyo.com
  • en.modyo.com
  • pt.modyo.com
  • global.modyo.com

:: :warning Attention These hosts are reserved by Modyo. They are not available as hosts for your web apps:

  • 404
  • 422
  • 500
  • activate
  • admin
  • api
  • auth
  • callback
  • code_generators
  • crossdomain
  • dist
  • login
  • logout
  • mailing
  • panel
  • password
  • profile
  • rails
  • realms
  • robots
  • session
  • signup
  • sitemap
  • status
  • uploads
  • users
  • welcome
  • widgets
:::

# Stages

Using stages in your web application allows you to implement a continuous integration and deployment (CI/CD) approach to add new functionality without affecting what's already published.

The main advantages of having different stages in your web apps are:

  • Focused development: Develop at the current stage without modifying the published web app.
  • Flexible customization: Create and use local variables, widgets, and templates to customize the experience or visualize changes.
  • Easy integration: When you finish the changes in one stage, you can integrate them into another.

Warning

  • A web app can have a maximum of four stages.
  • The changes you make to a stage are only reflected in that stage.
  • Stages are only available for web applications.
  • Custom PWAs and redirections are disabled in stages. They can only be used in the main stage.
  • The team members section is separate on each stage main. Add members to enable team review.
  • You can have the same members with different roles and permissions for each stage.

# Add a new stage

To add a new stage to your web app, follow these steps:

  1. In the side menu, click on channels.
  2. Select your web application.
  3. Click on application settings.
  4. Click on stages.
  5. Click on + new stage.
  6. Select the source stage and name your new stage.
  7. Click create.

Tip

In the summary section of your web application you can see the details of the current stage. You can also click on the name of your web app to display a list of its stages and navigate between them.

# Synchronize a stage

Attention

The platform does not allow you to synchronize changes that have not yet been published. Make sure you don't have any pending changes to publish before starting the synchronization.

To synchronize a stage follow these steps:

  1. In the side menu, click on channels.
  2. Click on the name of your web application and select the stage you want to synchronize.
  3. In the summary view, click synchronize.
  4. In the synchronizations view, select the stage you want to synchronize to. In this view you can see all the elements with differences between the selected stages. Click on view for more details on the changes.
  5. Check the boxes for the items you want to synchronize.
  6. Click on synchronize

Attention

The elements of a stage associated with a segment are not synchronized. You must repeat the process manually in the new stage, once the synchronization is complete.

# Delete a stage

To delete a stage, follow these steps:

  1. In the side menu, click on channels.
  2. Click on the name of your web application and select the stage you want to delete.
  3. Click on application settings.
  4. Click on General.
  5. In the dangerous zone section, click delete stage.
  6. Enter the name of your stage.
  7. Click delete.

Warning

Once you confirm the deletion, Modyo starts an asynchronous process, and you won't be able to access the stage again.

Deleting a stage deletes all the elements associated with that stage in the web application, including pages and widgets. In addition, the configuration of equipment, roles and other relevant aspects related to the stage are eliminated.

# Team Review

Team Review is a tool that allows you to control the process of publishing content in Modyo.

By activating Team Review using the Enable Team Review box, you establish that each item must go through different stages of review before it can be published.

Once you've enabled team review, you can take the following actions:

  • Define the number of approvals necessary for an item to be published.
  • Restrict the selection of reviewers - Only the submitter for review can select who should review the content and only those reviewers can approve the content.
  • Force review - By activating this option, at least one of the users designated as reviewers must approve the item before publication.
  • Require all - When this option is selected, you require that all users designated as reviewers approve the item before it can be published.

# Team Members

To efficiently organize and manage the work in Modyo, you can select the team members who will participate in the development of each site, giving them access to writing, reviewing and/or publishing tasks.

When creating a site, the administrator can manually assign users and the default roles that enable each of the functions.

# Add a new member

To add a new member to your site, follow these steps:

  1. From the Modyo Platform main menu, open the Channels section.
  2. Select your site.
  3. Expand Site Settings.
  4. Click on Team Members.
  5. Press the + Add Member button.
  6. Search for and select the user you want to add to the site and choose a role for that user.
  7. Click Add.

# Modify a role

To modify an administrator's role, follow these steps:

  1. Click on the administrator's name.
  2. In the modal that opens, select the new role.
  3. Press Update to confirm the change.

The available roles are:

  • Viewer: This user can view entries, view differences between versions, and leave comments. They can also access the synchronization view and view the changes that are pending synchronization. This role is not authorized to take any action that constitutes a change to the platform.
  • Developer: This user is in charge of structural resource development. They can create, modify, and submit pages, widgets, menus, and templates for review. All actions taken by a Developer must go through a review process before publication. This role does not have permissions to publish, delete, or rollback to previous versions of the resources, nor to modify the configuration of the site. There is a variant of this role called Developer CLI, which in addition to the permissions of a Developer, allows updating widgets from external applications, such as the [modyo-cli](/en/platform/channels/widgets.html#modyo -cli).
  • Developer CLI: Can create, modify and submit pages, widgets, the menu and templates for review. In addition, they can push widgets from external applications.
  • Reviewer: This role allows for the correction, approval or discarding of the work done by the Developers. It can create, modify, submit for review, and approve pages, widgets, menus, and templates. It can also publish when the review conditions are met. It cannot edit the site settings.
  • Admin: The Site Administrator has the same privileges as the previous roles and has the ability to configure the entire site. This includes the creation, modification, submission for review and approval of pages, widgets, menus and templates. In addition, they can publish without requiring team review validation.

# Delete an administrator

To remove an administrator from the site, follow these steps:

  1. Check the box next to the administrator's name.
  2. Click on the Delete button at the bottom of the list, at the bottom left of the screen.

# Custom Redirects

Modyo has a custom redirect system that will allow you to take a URL from your site and automatically redirect it via a 301 or 302 code to another section of the site.

In this view you will find a table with all the redirects that currently exist on the site. You can search by path or description.

To create a new redirect, click on the New button in the upper right corner of the view. Fill in the fields URL of Source and URL of destination and redirection code, and then save the changes.

Attention

The redirect table is the second to last in precedence, so if there is a URL on the site that points to a page or a default view, you'll see that view instead of being redirected through the custom redirection table.

In addition to creating redirects one by one, you can import a CSV file with up to 1000 redirects.

Warning

The required columns to import redirects are origin y destination.

You can select a 301 or 302 response code for all elements without having to add an additional column.

If you're importing a redirect with a source that's already registered, you won't be able to start the import process. Adjust your CSV file by deleting the row with the existing source, or delete the record of custom redirects from the site where you're trying to import the source.

The hierarchy of locations on Modyo sites follows this order:

  1. Default views (Home, search)
  2. Pages
  3. Custom Redirects
  4. Site 404 error settings

Conditions for a redirect

For a redirect to be successful, the source path cannot exist or must be unpublished. If the source is a published page with subpages, you must unpublish the subpages before you unpublish the main page.

# Security Headers

Enable this module for your site to configure HTTP security headers. Please note that this action cannot be undone. Once enabled, you'll have full control over the headers you want to use.

# HTTP Strict Transport Security (HSTS)

Tells the browser that it can only access the site using HTTPS.

  • Duration: Sets the time that the browser accesses the site via HTTPS only.
  • Preload: Includes the preload policy. For more information, see HSTS Preload List Submission (opens new window).
  • Include subdomains: Applies the HSTS rule to all subdomains on the site.

# Referrer-Policy

The header Referer contains information from the previous web page from which it is linking, with the header Referer-Policy you can control how much information should be included in the header Referer.

  • no-referrer: Does not send referrer information.
  • no-referrer-when-downgrade: Does not send referrer information to a less secure destination.
  • origin: Sends only the source domain, removes the paths and query string.
  • origin-when-cross-origin: Sends referrer information for requests from the same source. Deletes the routes and query string for other destinations.
  • same-origin: Sends referrer information for same origin requests only.
  • strict-origin: Sends the origin domain only for same security level requests, and doesn't send referrer information to less secure destinations.
  • strict-origin-when-cross-origin: Sends referrer a requests information from the same source. Sends the source only if the security level is the same, and does not send referrer information to less secure destinations.
  • unsafe-url: Always sends referrer information.

# X-Frame-Options

Indicates whether your site can be included in a frame, iframe, embed, or object.

  • DENY: The site cannot be displayed in a frame.
  • SAMEORIGIN: The site can be displayed in frames with the same domain.

# X-Content-Type-Options

Indicates that MIME types announced in the header Content-Type must be followed to avoid MIME type sniffing.

# Content-Security-Policy (CSP)

Controls what resources the browser can load on the site to mitigate data injection attacks and cross site scripting. The default value allows you to load resources from anywhere, so it's important to design a content security policy that's right for your site.

Freely specifies your content security policy in the text area. For a complete guide on how to write your policy, see Content Security Policy (CSP) from Mozilla Developer Network. (opens new window)

Warning

A very strict value can interfere with some features like Google tag manager, PWA, Widgets and Asset Manager.

A production-ready policy must ensure that all resources, such as images and style sheets, are loaded from reliable sources and requires that all scripts be secure and reliable for the application. For example, a strict policy for the minimal template would look like this:

default-src 'self'; img-src 'self' https://cloud.modyocdn.com; font-src 'self' https://cloud.modyocdn.com http://cdn.materialdesignicons.com; style-src 'self' http://cdn.materialdesignicons.com; script-src 'self'

The policy must include a default-src 'self' directive, which serves as a fallback for any other type of resource. You should also include script-src and style-src directives to avoid evaluating inline style and script tags.

  • Nonce: A CSP nonce will be added automatically by the server to the script-src and style-src directives if present.

If you have the nonce present in your policy, you can add the script and style tags to the allowed list in your templates using the csp_nonce variable.

<script nonce="{{csp_nonce}}">
  alert("everything will be ok");
</script>

These tools can help you design a strong security policy:

# Permissions-Policy

Allows or denies the use of browser features and APIs for the site; for example, you can restrict privacy-sensitive APIs such as the camera or microphone and the automatic playback of videos.

For a full list of browser-compatible features, see the MDN Feature Policy (opens new window).

# Cross Origin Embedder Policy (COEP)

Configures the insertion of cross-source resources into the document. For example, if your document has a COEP header with a value of Require-Corp or Credentialless, you can only access certain functions, such as SharedArrayBuffer or Performance.now () objects, with unrestricted timers.

For more information, see the MDN Cross-Origin-Embedder-Policy (opens new window).

# Cross Origin Opener Policy (COOP)

Allows you to ensure that a top-level document doesn't share a browsing context group with cross-source documents.

COOP isolates the processing of your document, so potential attackers won't be able to access your global object if they open it in a popup, preventing a set of cross-origin attacks.

For more information, review the MDN Cross-Origin-Opener-Policy (opens new window).

# Cross Origin Resource Policy

Conveys the desire to block cross-origin/cross-site requests without cors to the specified resource by the browser.

For more information, see the MDN Cross-Origin-Resource-Policy (opens new window).

# Site Variables

Modyo has global variables that you can use on multiple sites. However, you can also create specific variables for a particular site or overwrite the value of an existing global variable, with a value specific to the particular site.

Using variables allows you to reuse HTML, JS, CSS, or text code across different sites, widgets, or templates. If you have code that is repeated in several parts of your account, you can assign that value to a variable to simplify your processes and if you edit the value of the variable, the change will be reflected everywhere the variable is in use.

Tip

In global variables, you can use plain text, HTML, JavaScript, and CSS. However, it's important to note that you can't use Liquid code inside these variables. It is also important to remember that the content of global variables has a maximum limit of 65,535 characters.

To get the value of the variable anywhere that accepts Liquid markup, use:{{vars.Name}}

# Create a variable in sites

To create a variable in sites, follow these steps:

  1. From the main side menu, click Channels.
  2. Select your Site.
  3. Under Site Settings, click Site Variables. Here you can see the list of all global variables and site variables, their general information and a button to copy their code into Liquid markup.
  4. Click on + New Variable.
  5. Complete the Name and Value fields of the variable.
  6. Click save.

Attention

When using variables, Modyo follows a hierarchy of preference, where variables defined at the lowest level have priority. The variables defined in the widget will take precedence over the variables defined on the site, and in turn, the variables defined on the site will take precedence over the variables defined at the account level.

Therefore, it's important to use caution when defining variables in widgets or on the site, especially if you use the same name as the variables defined at the account level.