Jump to content

Module naming bug


Recommended Posts

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

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
 Share

  • Recently Browsing   0 members

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