Layout created in Xibo V4 are not visible in layout list

Hi everyone,

I recently installed the new version of Xibo and have run into an issue while trying to create a new layout. After configuring and saving the layout, it does not appear in my available layouts list.I have created many to try, buut none is visible in layout list, the list is always empty

But when I go to Administration → Settings → Display and click on default layout, all the created layout are present in the dropdown

Xibo version 4.0.7
Windows Server 2019

Bellow are the scrennshoots

Hi @royken

Please try to click on “Clear Filters”

If not, there must be a problem in the database setting.

Wow, today I’ve the same problem!

Layouts and media tables are empty. No filters, and “All folders” checked.

That’s strange. This is an old v3.3.3 installation where everything worked fine until now.
I updated to 3.3.11, same thing.
I’m logged in as Admin. Simple Docker installation.

@dan @alex Is there somewhere I can check? Do you want debug logs?

Try in templates. We’ve seen it where users on v2 or v3 were actually running the whole system by scheduling templates. If they are templates, then removing the template tag should resolve it.

I had 2 templates with “template” tags. I’ve removed the “template” tags from the templates but it’s still the same issue.

Any other ideas?

If they are actually templates then you don’t want to remove the tag - only if they’re actually layouts.

If nothing is showing then you need to run through report fault wizard, gather logs and examine them to see what the problem is.

The other thing to check is that you’ve not put the user you’re logged in as in DooH mode. It’s in the logged in user preferences. Make sure it’s not set to DooH.

As I can no longer see the layouts and media, I can’t control the tags.

I’ve looked at the debug logs, but nothing seems wrong.

My connected user is in Standard mode (not DooH). I’ve tried with another Admin user.

I’ll see if I can access the database to control the layout tags.



Ok, this is a problem with ngnix reverse proxy.
When I access without reverse proxy, works.