Don't.
Stick with ordinary update processes which are currently used by most companies to update client or server-side software.
It's up to the users to trigger the update process when they need to update. It's even more true for a website, for several reasons (some of the reasons apply as well for client-side software):
- Security: as a user, I don't want someone I don't trust to update my website at any moment without asking my permission,
- Privacy: if your updates are accessing the database, how can the users be sure that their data will not be used maliciously by your company?
- Performance: if most of my users are connected from 2 PM to 9 PM, and there are no or few connections between 3 AM and 5 AM, I want the updates to take place in the middle of the night, not when all the visitors are using my website. What if you're triggering the update at 4 PM?
- Risk management: what if during an update, my website goes down? What if I notice it only after a week, and I find that it's your update that you've done without any permission which caused that? Would you compensate the financial loss?
- Compatibility: what if I've done some changes or added some plugins which are not compatible with your updates?
So either don't do it, or be ready to be sued and to see your customers leaving you.
imagine that we want to add a module to these sites
What if the user don't need this module? Fewer code server-side means fewer security holes. If the user doesn't need an additional feature, there are no reasons to force him to have this feature enabled on his website.
There is an exception: hosted solutions with unified codebase. Consider the following cases:
Case 1:
- Third-level domain name (mywebsite.example.com) or an optional redirect from a second-level domain name,
- Hosted solution,
- No server-side scripting,
- No external plugins (i.e. plugins which are not already hosted),
- No direct access to source or data (for example it is not possible to access the data of the database directly, nor to do backups and save them locally), etc.
- Inability to migrate the website to another hosting,
- Customization limited to the options in a configuration panel,
- Forced advertisement embedded in the pages of the website (optionally removed if you pay).
Case 2:
- Second-level domain name (mywebsite.com) or third-level domain name (depending on price),
- Hosted solution,
- Maybe server-side scripting,
- Maybe external plugins,
- Ability to make SQL queries and/or backup data locally,
- Ability to download everything you need to migrate the website to another hosting,
- Ability to customize the website by uploading additional content (stylesheets, images, etc.),
- Maybe forced advertisement embedded in the pages of the website (optionally removed if you pay).
What makes the difference?
- In the first case, we have a generic solution which tries to fit all the needs. If your needs are different, go away, our website is not for you. We own the service, so either you agree to use it as is, or you search for another one.
- In the second case, we have a generic core you can use to build something which fits your needs. Now, you own the website.
Behind the scenes, it may have a huge impact on the architecture of the solution:
- In the case of a generic solution, there are no files hosted separately for every website. If there is a CSS file for a specific template, this file is hosted once. For every of the thousands of "websites". If there is a PHP file containing a class which is used by every website, there is only one PHP file per server.
- In the case of a generic core, on the other hand, there may be no unified hosting (even if it might be an option, but, well, when I build my own website hosted on my own server, I don't host JQuery, but use Google CDN instead, so it's the same thing). This allows a customer to change a specific file without affecting other customers.
You see that in the first case, per-user updates just don't work, and cannot be implemented. As a service provider, you can only update everyone at once, since everyone share the same files. You cannot ask users permission or let the specific user schedule the update. But in this hosting situation, the users are expected to be updated passively, so it's ok.
