@pat59
Or just remove “updatenotification” module from config. Trust me, it would be better.

Dear community,
Recently I got a message from CalendarLabs, who is providing ical of MM’s default config.js.sample. They had some problem from too many/frequent request from MM (because it is included in config.js.sample)

Around three thousand MagicMirror systems are making a huge amount of requests, impacting our service (similar to DDoS). Some IPs even send more than 20 requests per minute.

Also, Most of them using an old version of the ics URL, which will be phased out from 30th July.

So, all the subscribers should get their unique URL for their applications(so that they won’t get blocked for exceeding the limits of 36 requests per day for holiday calendars).

Also, they should visit the ical page after creating a free login, if they want to get notified when they exceed the limit or there is any update related to the ics they are using (the subscriber ID get associated with the logged-in users when it is within same user session)

Any ics subscriber exceeding the request limit will receive notifications on their calendar from 30th July.

Not to request too many times/frequently. It consumes others’ resources.
I think 30 mins or a few hours is enough to reveal updates. Really do you guys need real-time updates?(Especially for holiday? it will not be changed in a day. :D )

@mmmmh
useDisplay: false,

It is a good try, Although most checklists are meaningless rather than useless. There are also wrong checks. (For example, MMM-ModuleMonkeyPatch doesn’t have node_modules directory. It doesn’t have node_helper.js at all.)

However, I would like to praise it because it is a good-looking list. It’s a good attempt.

In any case, dependency checking is information ordinary users cannot deal with even if they know it. Unless he is a developer, there is nothing he can do with that information.

Rather than performing a dependency check, it would be better to reveal the last update date or the number of unresolved issues to guess the module’s activation level or popularity.

Or, if you are going to parse package.json anyway, I think it could be used to organise installation methods, etc.

MMM-CalendarExt3

New MagicMirror module for calendar view. (successor of MMM-CalendarExt2)

Screenshot

Concept

My previous module, MMM-CalendarExt2, was always notorious for its difficulty to use. I need a more easy and light one. So I rewrite this from scratch newly.

Features

What’s different with CX2.

• Only focusing on how it shows; Parsing is delegated to original MagicMirror module calendar. (It means the calendar module is REQUIRED to use this module.)
• Only week and month views. I found that people are rarely interested in other views on CX2. So I drop out different views.
• Respect to original MM’s hide/show mechanism. Now you can hide/show this module easily with other scheduler or control modules. (By the way, Look at this module also. - MMM-Scenes)
• No dependency on the 3rd party modules (e.g. momentJS or Luxon, etc.). This is built with pure JS and CSS only.

Main Features

• week view or month view
• locale-aware calendar
• customizing events: filtering, sorting, transforming
• multi-instance available. You don’t need to copy and rename the module. Just add one more configuration in your config.js.

DETAILS : https://github.com/MMRIZE/MMM-CalendarExt3

MMM-Scenes2

“Life is a theatre set in which there are but few practicable entrances.”

― Victor Hugo, Les Misérables

MagicMirror module to change screen scenes by time and order with ANIMATION EFFECT.

Demo

Click To Play
Click it to see the DEMO.
Its configuration file is in /examples/config.js.example

Successor of MMM-Scenes

Since MM 2.25, a new feature, animateCSS is introduced into the MagicMirror.

By this update, my previous MMM-Scenes will be obsoleted. So I remade a new module for MM 2.25

• The update can provide more effects now. ( without my effort. :D )
• I guess custom animation is rarely used, and this update would cover most use-cases. So I decided to drop it.
• I redesigned the structure more simply and intuitively. (role is introduced.)

Concept

The scenario of the MM screen comprises a series of scenes. Each module has its role in its appearance scenes to enter and exit by design.

When a scene begins, all modules whose roles end will be expelled, and all modules with the parts in that scene will be admitted.

As described in the scenario, your MM screen will play a drama with modules.

Features

• control show/hide modules by assigning role names to the module’s class
• various animations for modules exit/enter
• control scenes by notification and WebURL endpoints.
• Loop control
• custom indicators

https://github.com/MMRIZE/MMM-Scenes2

I suggest you and the community expand package.json to regularise the details of the module. (recommended but optional)
For example;

{
  "name": "mmm-something",
  "version": "1.0.0",
  ...
  "mm" : {
    "communityId" : "johndoe",
    "community" : "MagicMirror forum",
    "screenshot" : "https://somewhere.com/screenshot.png",
    "install" : "https://github.com/johndoe/mmm-something/README.md#installation",
    "update" : "...",
    "email" : "johndoe@somewhere",
    "required: {
      "mm" : "2.25",
      "node" : "18.0"
    },
    "notice" : [
      "This will not work in Windows.",
      "Pre-dependency required. Please readme."
    ]
  }
}

The fields are my imagination. Maybe the community can reach an agreement on rules.

I don’t care if it is not updated or not as long as it works.
However, we can call some unmaintained-anymore modules legacy. Maybe a tag legacy to some old modules be a good way to distinguish. By contrast, the other side might be modern.

If possible, I wish for more features/rules for common "modern" modules. These could help automate the management of modules.

• Installer command/script/instruction
  Some modules may need additional manual pre-requisition or dependency jobs (e.g. getting auth), but most of the modules would be possible to prepare simple scripts for installation. (in package.json and specific installer folder). If so, we can provide an auto-install/update feature to MM.

• Basic default configuration example file.
  If possible, a default config example would be a help for the newbie, and with that content, auto-configuration would be possible in the installation stage.
  Of course, there might be private-information or API-Key issues…

• Using .env to store private/secure information. (Or private.json something…)
  To separate normal configuration from sophisticated private data (e.g., API Key, Account, password, etc.) , using .env may be the option. It could be composed through an installation script if needed.

I wish we could have something like a plugins market or bundle store of other applications.

@sifuhall
Maybe like this;

Some test words are censored and removed already, so you cannot see them in title (and in description). (test words are “FBI”, “in data”, ‘man’, “to”)

Anyway, it is a tiny modification of the original Mich’s default module. So real monetized reward is not fair (at least, I think)
You can get it here;
https://github.com/MMRIZE/MMM-anotherNewsFeed

But if you want more than the little modification, anyway contact me.

@JohnGalt
To be honest, I always install MM on various env, manually by myself. Never with his script. So my experience will not be helpful.
Anyway,
Even in windows (I installed MM many times on Windows) it is always same.

1. Install git-bash
2. Install nvm-for-windows, then install node js through it.
3. Make a working directory for MM on git-bash terminal.
4. Clone repository of MM on that directory with git command.
5. Edit some path in package.json for Windows.
6. execute npm install.
7. Make config.js, custom.css
8. For fonts and bundle, install them.

Well, For me it’s not difficult at all but I recommend @sdetweil ‘s script for beginners. As far as I know, it will work on all Windows version.