Hey @Banandze,
I have added a lockstring so that modules cannot show themselves which was causing the issue where the weather module showed itself. Pull the new changes to fix that issue.
The issue with the module not showing on the weather page I cannot replicate, but it is most likely due to the position being set to left which is not a valid position in Magic Mirror. Refer to this this for a list of positions.
I am also unable to replicate the problem where the page switching does not work. When it fails to switch, is there any output to the console?

One small thing before I actually get into the meat of the issue. It is not necessary to specify the number of pages for MMM-page-indicator since it is overridden by the page selector.

While I was developing the new page system, I forgot about the very important issue of capitalization. Basically what was happening is that it was trying to switch to pages that did not exist. If you pull the update, everything should work fine.

Ah good. I’m glad that the changes I’m making are improving the module.
Thank you for the kind words.

So the exclusions array takes a list of selectors. Those selectors could be the name of a module (Like MMM-Cursor) or they could be the prop name. Here’s some sample code:
This is the inside the module array:

{
    module: "MMM-page-indicator",
    name: "noHide",
    position: "bottom_center"
},

And then this is the exclusions:

[
    "noHide",
]

This one works because the name noHide is a selector.

You could also just use the name of the module:

[
    "MMM-Cursor",
]

because it is also just a selector.

The pages config also works off of selectors in the same way. noHide is a selector that you assign with the name prop while MMM-page-indicator is a selector that is assigned via the fact that it is the name of the module.

Ok, changes have been made and now the module is much more resilient.
The second method for setting up pages has become pretty powerful now, but that came with it becoming more complicated. I would suggest reading the readme section carefully before trying to implement it.
If you have any question, I am more than happy to clarify and edit the readme.

I copied your config and it actually allowed me to catch a couple of bugs that I will be working to fix over the next few days. The main one that you are having trouble with stems from the fact that multiple modules with the same name are being used. I don’t know why I didn’t think about that during development, but it causes problems now. I’m going to fix that up and I’ll post again when it’s done. It’s a bit of a large change, however, so it probably won’t be done for at least 24 hours.

Ok, the new commit includes the changes. Just git pull and then the new method should be available.

It shouldn’t be necessary to have quotes around everything. Does it error when you just use this?

{
    module: “weatherforecast”,
    position: “bottom_center”,
    pages: {main: “bottom_right”},
    config: {
        locationID: “REMOVED”,
        appid: “REMOVED”
    }
},

Also, I have implemented the method for setting up pages as I described above alongside the other method. The readme will be updated with full instructions on how it works. I will commit the changes to the repository soon.

I’ve only looked at this a couple of time, but if you wanted to spend some time on getting a module running, it’s possible that this could be a jumping off point.

Hey Robiv8,
First, I will address a couple of things.

All lines must also be marked with “” signs:
To be clear, it is not necessary to put quotes around page names or props. For example:
"pages": {"main": "top_right", "fun": "top_left"} is exactly the same as
pages: {main: "top_right", fun: "top_left"}
I just believe that it is more clear for everything to be specified as strings.

Even more if you did not need to provide the entire modules and each line with extra signs:
Could you elaborate a little bit about what this means? What do you mean when you say each line with extra signs?

What would be great if you had a main config and for each additional page its own config which is then read out:

I’m still very much open to developing this further and possibly adding more ways to create pages.
I think I get the idea that when you have many modules it can be hard to keep track of what modules have been put on what pages and where, but I am unclear on what exactly you are suggesting.

One idea that I had during development was to have a pages section in the config.js like this:

address: "localhost",
port: 8081,
ipWhitelist: ["127.0.0.1", "::ffff:127.0.0.1", "::1"],
modules: [
    ...
],
pages: {
    "main": {
        "calendar": "top_left",
        "MMM-Bob-Ross": "bottom_left",
        "clock": "top_right",
        "weatherforecast": "bottom_right",
        "newsfeed": "bottom_center"
    },
    "fun": {
        "clock": "top_left",
        "MMM-Lunartic": "bottom_right",
        "MMM-Astronauts": "bottom_left",
        "MMM-Reddit": "top_right"
    }
}

In order to condense the page config down when there are just too many modules to handle. Something like this would be very easy to implement.
Is this along the lines of what you were suggesting?