I’ve worked with changing the classes of modules on the fly during my work on this module.
In order to change the class of a module or some modules:

MM.getModules().withClass(/*Your module name or list of names*/).enumerate(module => {
    ref = document.getElementById(module.data.identifier);
    if(ref === null){
        Log.log("Module does not exist")
    }else{
        ref.classList.add("Your new class")
        // Or if you want to get rid of a class
        ref.classList.remove("Your old class")
    }
})

The way that this system would have to work could not reduce API calls. Duplicating the module would simply send two calls instead of one. As I understand it, a large rework of how magic mirror works at a much baser level than what this module does would be necessary to change that.
It would be possible to have one module shown in different places by assigning it multiple names, but I don’t see how that would really be useful.

Ok, I’ve implemented persistent pages. In order to access them right now, you need to be in the development branch since I don’t have the time to do extensive testing.

I’m not exactly sure what you mean when you say “not have on module configured and shown multiple times via different names”. You do not want to have the same module shown multiple times on the same page?
If the module was shown multiple times by this module, then all the instances would have the same config and I don’t see how that would help with rate-limited APIs.
Could you clarify?

Yea. I’m trying my best not to change base functionality so any sort of bells and whistles like this will have to be manually activated.

Persistent properties such as those could be achieved through a temp file so definitely something that could be implemented.
My reading week is over so I don’t have as much time to do development now, but I’ll get it done in some free time.

Changes that edit the way users must set up their config.js file have been made to this module. The position prop is no longer necessary to have inside the module config and the way to exclusions are handled has changed. For more information, look at the updated readme in the development branch of the GitHub page.
These changes will be merged into the master branch in a couple of days which will cause errors if your config is not updated.

@Banandze,
I’ll take a look at it. It is very possible that I made a mistake while refactoring and module precedence has been swapped.

@Banandze,
I’m going to address the issue with the switching only working four times before shutting down. First, are you using pm2 to manage you mirror? If that is the case, try just starting it from a terminal instance so it does not automatically restart if it crashes.
When I said “Is there any output to the console”, what I meant is, in the terminal window where you started magic mirror, is there any text that prints out when the issues start? Also, in your electron instance, in the top menu, when you click on view then toggle developer tools, it will bring up a window with a console in it. If there is anything in red there I would like to see it.
What I am assuming is happening is that magic mirror itself is running out of resources and causing the issues.

I am not quite certain what you mean by:
“I put first one upper in config file and wrote “top_left” for both modules but they are shown in wrong way”
Are you saying that you want one module to appear above another, but it is instead appearing below? If that is the case then I will need to see your config again to know exactly what you mean and attempt to fix the problem.

As an update, it is now possible to have your pages automatically rotate on a certain interval. Refer to usage and configuration in the Readme.

Hey @rudibarani,
Yea, that was completely on me. The new version should fix the issue. There was a really obvious bug that was stopping the PAGE_SELECT system from working. If it still does not work, make sure that the payload that is being sent is actually just the string name of the page and not an object.

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?