Module naming bug

[Pieter Beulque]

Hello,

I'm not sure if this is a known bug or not.

I found a bug within the naming conventions of a ProcessWire-module. I am aware of the prefixes commonly used like Process and Fieldtype. However, when building a module that doesn't fit within any of the predefined categories, you are allowed to just work at root level 'ModuleName.module'. Correct me if I'm wrong.

At work, we prefix our own modules with the company abbreviation (WWWP - Short for We Work We Play). With my previous module, a Process-type module, there was no problem. It was named ProcessWWWPInstaller (like the conventions say it should be named).

However, I'm now building a hook-module so I don't think there's any prefix that I should use. I named my module WWWPMailer, and ProcessWire throws an error (showing WWWPMailer in an error field in /admin/module/). Everything still works but it doesn't look professional towards clients. Renaming my module WeWorkWePlayMailer.module works, and sorts it in the admin under 'We'.

Is there anything to do about the plugin naming conventions?

[ryan]

The first part of a module name is considered a grouping and must consist of 1 upper letter followed by 1 or more lowercase letters. Then the module name after should do the same-1 upper+1 or more lower. You can also use digits in the second part. Example: ProcessField or MarkupPagerNav, or any existing module name.

You can make up your own grouping if you want to, though if your module clearly fits in an existing grouping, it's better to use that (especially for ones that go in the directory). For your modules I would suggest "Wwwp", "We" or Weworkweplay as your grouping, i.e. WwwpInstaller, WeInstaller, WeworkweplayInstaller. 

[Pieter Beulque]

Ryan, thank you. I figured out the naming scheme, but I'm thinking in this case it might be better checking for known prefixes (Process, Markup, …) and bundle all others under a section called 'Other'?

Because, in this case, there is no way to account for a good sectioning. Naming my module 'WeWorkWePlayMailer' won't throw an error but groups it under 'We'. That's stupid. 'WwwpMailer' groups it under 'Wwwp', which is okay but an abbreviation should be all caps…

In my opinion, it'd be better to have an 'Other'-section, allowing developers to group their modules using a property in getModuleInfo();

I might be biased.

[WillyC]

names my.modulos other i do.not want

but

u.can name other

if u like.

 this does

try u.will

class OtherWWWWPInstallamos extends WireData implements Module {  

   __/\o/\__

 } 

That's stupid. 'WwwpMailer' groups it under 'Wwwp', which is okay but an abbreviation should be all caps…
 

for your brand.the group is not !

for group ! is.the group for

u must.unthink what.u  hav thought

[Pieter Beulque]

Willy, you are right that I could indeed prefix my own modules with 'Other' if I really want to have them grouped together. I did not consider that before