Error submitting module to directory

[gRegor]

Answered Below

Short version: the git repository must have the .module.php file (and .info.php or .config.php files if used) in the top directory. It is OK to put any other files in sub-directories.

ProcessWire will create the /modules/ModuleName directory during install and put all files in there, so there's no need to have folder ModuleName in your repository.

---
Original post:

I am trying to submit https://github.com/gRegorLove/ProcessWire-IndieAuth I get these errors on the first step:

Quote

 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.

The module has the static getModuleInfo() function. My folder structure does put the files in a directory of the same name (ProcessIndieAuth), but I've not had issues with submitting modules like that in the past (Webmention -- granted, it's been several year ago now). Must I "flatten" the files by not having them in the sub-directory? I tried searching the forums and the documentation but couldn't find a definitive answer.

Edited July 8, 2022 by gRegor
add answer

[Robin S]

Probably the first step of "Add module"...

...should be updated to include any rules about how the repo needs to be organised. @ryan

But most modules that I've seen abide by the following principles, so that's probably a good way to go:

1. Name the repo the same as the module, in your case "ProcessIndieAuth".

2. Put the module files and readme in the top level of the repo. Includes or assets could go in subfolders when needed.

[gRegor]

Ah, I hadn't considered it might be the repo name being different than the class. I might try that first.

If flattening is required, I do wonder how to best organize modules like Webmention, which is actually a set of two Process classes, an InputField class, and FieldType class.

[teppo]

6 hours ago, gRegor said:

If flattening is required, I do wonder how to best organize modules like Webmention, which is actually a set of two Process classes, an InputField class, and FieldType class.

One option is to put them in a single directory. Some may see this as being less elegant, of course. Personally I don't mind, and have done that on multiple occasions ?

That being said, I would assume the modules directory to be fine with it as long as there's a module file and/or separate info file for the main module in the root directory, with any "additional modules" in their own subdirectories. Though this is largely guesswork, as I'm not familiar with the way the GitHub parser in modules directory actually works.

I've seen quite a few cases where the repository name doesn't match the module name (or has a prefix, such as processwire-[module name]) so I'd be surprised if that's the issue.

[gRegor]

I heard back from Ryan via email:

Quote

I think that extra directory must be the issue. At least that's the only difference I can find between your modules and others. Only the .module.php file (and .info.php or .config.php files if used) would need to be there, and it's fine if you want to place your other files in directories. When ProcessWire unzips a module, it creates a directory with that module name and places all of the unzipped files in it. So it expects that the files in the archive root directory include the module file. Otherwise users of the module may end up with a /site/modules/ModuleName/ModuleName/ directory, which is fine, but not ideal.