Jump to content

Private module used in private repos for multiple sites?


Recommended Posts

I am trying to figure out the best way to handle developing a module for multiple private ProcessWire sites. The key issue being: when I update the module, how can I elegantly get the changes in the sites that use it. It would be nice to not have to copy/ftp the files from site to site, or entangle them in git history (maybe as a sub module?)

The ProcessWire modules directory has a nice upgrade module which can elegantly notify/click+upgrade publicly hosted repos. But this would be private code hosted on a private repo. I assume this would preclude it from being hosted there?

Can someone point me to a solution for this, or perhaps brainstorm any possibilities.

  • Like 1
Link to comment
Share on other sites

You can change the module service url in your config.php file.

$config->moduleServiceURL = 'http://modules.processwire.com/export-json/';
$config->moduleServiceKey = (__NAMESPACE__ ? 'pw300' : 'pw280');

Format of the complete url: {moduleServiceURL}/{moduleClassName}/?apikey={moduleServiceKey}

Example: http://modules.processwire.com/export-json/MarkupCookieConsent/?apikey=pw300

If you provide this service (json format) for your module by your own you could hook in ProcessModule::execute

if ($input->get->update) {
    $this->addHookBefore('ProcessModule::execute', function($e) {
        $moduleClassName = $this->wire('sanitizer')->name($this->wire('input')->get->update);
        if ($moduleClassName != 'MySuperPrivateModule') return;

        // change service url here
        $this->wire('config')->moduleServiceURL = 'http://example.com/export-json/';

Another solution: Symlink your module if all sites using this module are hosted on the same server.

  • Like 7
Link to comment
Share on other sites

@kixe Thank you for responding. Perhaps we need a broader understanding of what is involved?

  1. The module we are developing is client-specific, and is not really applicable to the broader community, so registering at modules.processwire.com doesn't seem to make sense. 
  2. So it seems we would need to create a private module feed to keep these modules up to date across sites? Is there documentation on that, or is there an alternative that will scrape the module code of a private repo to generate it?
  3. Your first solution regarding changing the moduleServiceUrl to this private feed, would that unhook the site from modules.processwire.com for core updates and free-use plugins?

Thank you again for replying and helping us work through this.

Link to comment
Share on other sites

@chcs, as you probably know the ProcessWireUpgrade module doesn't keep modules up-to-date by itself. You still have to log into each site, visit the Upgrades process page, look to see which modules need updating, and then perform the upgrade for each module that has an update available.

So it isn't really any faster than updating a module via "Add Module From URL", which you can do for a private repo as per the thread below:

That is for GitLab repos but I'm sure there's something similar possible for private GitHub repos.

For a single private module it doesn't seem like it would be worth the trouble to create another website to provide the custom updates feed.

  • Like 2
Link to comment
Share on other sites

So maybe the upgrades module should get an upgrade to support custom upgrade urls. Does not sound very complicated that when a module has a custom update url, the upgrades module takes this url instead of the default modules directory service?!

The "latest version" check would then of course not work, but it could show a link to the repo. And maybe the module could also add a link to a release info page. Would be great to have such a release log in a somewhat standardized way ?

Link to comment
Share on other sites

A couple of thoughts.

  1. How many private sites do you need to auto-update? If only a couple, is automation worth the effort?
  2. With automation, there's the potential of 'break one, break them all'. If there's a problem with your code, it will break all you n sites and you might not even know it
  3. How many times will you be updating the module, say, per month?
  4. Are all your sites on one server or on different servers?
  5. Are they running the same versions of L(W)AMP?

If you still want to pursue automation, other options you could pursue besides what has already been said.

  1. Custom feed with lazy or normal cron. Create an autoload module to periodically check for updates to your module. If updates found, fire code to update the module
  2. Mother ship + ProcessWire multi-instance:  Have only one of your sites to check for updates OR do it manually since you are the one updating the custom module so you will know if there is an update. If there is an update, in a loop, bootstrap into the other sites using PW multi-instance and update the respective modules. This will only work if the sites are on the same server. Updating a module in PW is not complicated; download a  zip file, unzip it, backup the old files, copy over the unzipped files. Done. You can use the $files API for this. Expounding on the mother ship idea, you could create a simple Process module with a button to click to execute the multi-instancing. I am not sure if you have access to $modules API when multi-instancing. If not, all you need is to call some code in the instanced sites to run the update.

Written in a hurry, hope it makes sense. 

Edited by kongondo
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...