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.