CMS Unloaded 12 6 8


Good afternoon, please help. When I log in via IP address, the CMS works successfully. And when I log in through the domain, after logging in (the login page loads successfully) there’s this white, unloaded window

What could be the reason?


When I log in directly (not through the domain), the chanels simply do not load

25.02.2025 14:09:11 WARN http-nio-8080-exec-14 [AggregationValve.logPossibleWaste:586] POSSIBLE WASTE DETECTED in request ‘Request{ method=‘OPTIONS’, scheme=‘https’, host=‘mysitedomain’, requestURI=’/_rp/cafebabe-cafe-babe-cafe-babecafebabe./channels/site-en-preview’, queryString=‘null’}’ : Component ‘/hst:hst/hst:configurations/site-en/hst:workspace/hst:containers/pagenotfound/main’ gets rendered but never adds anything to the response. Its renderer ‘classpath:vbox.ftl’ is never flushed to a parent component. This might be waste you are not aware of. If it is on purpose, for example because the component does only some processing that does not involve direct response contribution, you can mark the component with ‘hst:suppresswastemessage = true’.

This is the log I see when I try to open chanels

Hi,
The warning about possible waste is not an error, has nothing to do with the white screen.

It probably has to do with platform virtual host configuration.

If you access the CMS at mytestdomain123123123.com, you should let the HST delivery tier know that with a node at `/hst:platform/hst-hosts/[group]/com/mytestdomain123123123

See Configure Virtual Hosts in an Environment

HTH
Jeroen

Good afternoon, thank you for helping me, forgive me, maybe I’m asking stupid questions, I just want to understand Hippo CMS better, I’m a junior in this business. Here is my hosts.yaml

definitions:
  config:
    /hst:hst/hst:hosts/dev-localhost:
      .meta:residual-child-node-category: content
      jcr:primaryType: hst:virtualhostgroup
      hst:cmslocation: http://localhost:8080/cms
      hst:defaultport: 8080
      /localhost:
        .meta:residual-child-node-category: content
        jcr:primaryType: hst:virtualhost
        hst:cacheable: false
        /hst:root:
          .meta:residual-child-node-category: content
          jcr:primaryType: hst:mount
          hst:homepage: root
          hst:mountpoint: /hst:hst/hst:sites/site-en
          /en:
            .meta:residual-child-node-category: content
            jcr:primaryType: hst:mount
            hst:mountpoint: /hst:hst/hst:sites/site-en
            hst:locale: en_EN
            /crestservices:
              .meta:residual-child-node-category: content
              jcr:primaryType: hst:mount
              hst:alias: restservices
              hst:cacheable: tene
              hst:ismapped: false
              hst:namedpipeline: JaxrsRestPlainPipeline
              hst:type: live
            /restservices:
              .meta:residual-child-node-category: content
              jcr:primaryType: hst:mount
              hst:alias: restservices
              hst:cacheable: false
              hst:ismapped: false
              hst:namedpipeline: JaxrsRestPlainPipeline
              hst:type: live
            /api:
              .meta:residual-child-node-category: content
              jcr:primaryType: hst:mount
              hst:alias: api
              hst:ismapped: false
              hst:namedpipeline: RestApiPipeline
              hst:types: [rest]
          /restservices:
            .meta:residual-child-node-category: content
            jcr:primaryType: hst:mount
            hst:alias: restservices
            hst:ismapped: false
            hst:namedpipeline: JaxrsRestPlainPipeline
            hst:type: live
            hst:cacheable: false
    /hst:hst/hst:hosts:
      hst:defaultcontextpath: ''
      hst:cacheable: true

hosts are not listed here, but they are in /cms/console in the hosts section, how does it work? Shouldn’t I include them in hosts.yaml?

/hst:hst/hst:hosts:
  hst:defaultcontextpath: ''
  hst:cacheable: true

Hi,
The yaml files are for bootstrapping those nodes into the repository, meaning on deployment these will be processed and the nodes they represent will be created.

So if you want nodes to be present on every deployed environment, bootstrapping is a good idea. Otherwise you need to reconfigure manually on every env through cms/console.

I guess for HST hosts, most projects do have bootstrapping.

Note that there’s /hst:hst/hst:hosts for the delivery tier itself and /hst:platform/hst-hosts/ for the current case.

Cheers, Jeroen

Ow wait you’re on 12.6.8, the remark on /hst:platform/hst-hosts/ doesn’t apply

For your case it’s simpler, set hst:cmslocation=https://mytestdomain123123123.com/cms on your “mytestdomain” host group

1 Like