Module Directory: Issues submitting and updating module info

[d'Hinnisdaël]

I'm having trouble submitting new modules to the directory, as well as updating versions of existing modules.

What's the best way to debug this? Is there some person I could ping from the core team to help me look at this? Has anyone had similar problems?

Here's the concrete issues I'm facing:

• When trying to add the ImagePlaceholders module from this GitHub repo, it errors out with the message: "Unable to load module info from GitHub. Please make sure there is a getModuleInfo() function, a ModuleName.info.php file, or a ModuleName.info.json file". However, the module does have a .info.php file and is working fine locally and when installed via composer.
• Trying to add the DatetimeCarbonFormat module from this GitHub repo results in the same error. This one also works fine when installed and has a getModuleInfo method defined.
• An existing module, TemplateEngineLatte, seems to not get updated, even after successful refreshes. The version is stuck at 1.0.0, even though the GitHub repo has a recent 1.0.6 tag.

[bernhard]

I'd write Ryan a PM 🙂 

[ryan]

@d'Hinnisdaël I think the issue with the first 2 repos is that the repo name does not match the module name. When you add a module, all it asks for is the GitHub URL. So it loads github.com/daun/processwire-image-placeholders and assumes the "processwire-image-placeholders" is the module or class name. But the module name is actually "ImagePlaceholders". If you change the GitHub repo name/URL so that it matches the module name, i.e. github.com/daun/ImagePlaceholders then it should work. 

For the TemplateEngineLatte, the module info for that repo lists the version as 1.0.0. So you'd need to update that to 106 or better yet "1.0.6" (string). 

[bernhard]

Or let github update your version number automatically: 

 

[d'Hinnisdaël]

@ryan Thanks a lot! That's useful to know. Is this something that could be reconsidered or changed in the module directory? I've recently started prefixing module names with processwire- on GitHub for better context and discoverability and have found that to be a great way of organi`ing projects. This makes it a lot easier to e.g. enter "processwire" into the repo search input and filter down a list to only PW modules.

@bernhard Sweet — I'll definitely need to try that as well! It's super easy to forget simple steps like version bumps when creating releases. Better to automate this.

[ryan]

@d'Hinnisdaël I tried adding something that would make it ignore a leading "processwire-" on the repo name, so that something like "processwire-ImagePlaceholders" might potentially work, so long as the part after the processwire- prefix is still the correct module/class name. I don't have any repos to test that format with though, so I'm not positive if there might be more to it that I need to account for. Give it a try and please let me know if you find it still doesn't work. 

[d'Hinnisdaël]

@ryan Thanks! Could we convert kebab case to pascal case in general? That way we'd cover all use cases. I've tested the following snippet below and it's working great. Currently conforming names will be left untouched: PageEditLockFields, ProcessWireUpgrade, etc. Any kebab case names are converted to valid module names: processwire-template-engine-latte → TemplateEngineLatte.

function guessModuleNameFromRepo($repo) {
  $module = str_starts_with($repo, 'processwire-') ? substr($repo, 12) : $repo;
  $module = str_replace('-', '', ucwords($module, '-'));
  return $module;
}

[d'Hinnisdaël]

In the meantime, I've found a fix that kind of works: rename the repo to ImagePlaceholders, register the module in the registry, the rename it back to processwire-image-placeholders. Since GitHub will indefinitely redirect any requests to the new name, this should be somewhat future-proof, but very hacky and not my preferred solution here 🙂