Symphony.

Let's be honest, naming of extensions is currently a huge mess in the Symphony ecosystem. Extension names are very inconsistent, and it's not always clear right away what an extension is actually doing, or if another extension already fulfills the same or a very similar functionality (start reading here for a brief background story).

So I suggest a new naming convention for extensions that follows two principles:

• Don't use fancy names, make clear what the extension is doing.
• If other extensions provide similar or additional functionality, use a common prefix so it's easier to group these extensions together (also easier for developers to test their extensions and make sure they are compatible with other extensions, for example, make sure people can combine different methods of spam protection without breaking something).

Example (the original discussion was about event filters for spam protection):

• Spam Protection: Hash Validation
• Spam Protection: Blacklist
• Spam Protection: Honeypot
• etc.

Instead of:

• Can Of Spam
• Stop Forum Spam

Other examples:

• Editor: TinyMCE
• Editor: CKEditor
• Editor: MarkItUp!
• Editor: EpicEditor
• etc.

Instead of:

• Rich Text (TinyMCE) Text Formatter
• CKEditor
• Sym MarkItUp

More examples:

• Caching: Output
• Caching: Datasource
• Caching: ...
• UI: ...
• Field: ...
• Payment: ...

Instead of:

• CacheLite
• Cacheable Datasource
• Far Future Cache Controller
• ...

Makes complete sense.

Yep. Except I don't really know how the transition should be made for complicated extensions (providing events, datasources, fields, DB tables etc.).

Yep. Except I don't really know how the transition should be made for complicated extensions (providing events, datasources, fields, DB tables etc.).

The naming shouldn't necessarily be based on what an extension provides from a technical point of view (an "Editor"-type extension for example can act as a textformatter or just as a UI ontop of textformatters like Markdown, "Spam protection"-type extensions usually provide filters and events, etc.)

It's just a convention, not a requirement. Some extensions won't fit in, that's ok.

We could recommend a list with some prefixes and their related contents.

Extensions documentations could also be improved. More examples, more screenshots etc.

Nick Dunn's extensions usually have very good documentations! It's a lot easier for someone to decide to use it and to implement it.

Sometimes you have to install an extension to completely understand what it does!

The problem we will find here is that some extension developers may not want to change them. Also, some extensions are named by the service they provide, i.e. Stop Forum Spam, Askimet Spam Filtering etc etc. What should we do in this instance?

Although I agree with this point in principal (I asked the same question about a year ago), we've got to remember that there are now better 'types' to choose from. We could make a start by assigning better types to extensions. Also, the types list is not exhaustible, and can be added to to a point.

Also, remember that the XML meta schema is very new, and open to updates by the community at large to add new nodes, like for instance tagging extensions so that they can be better searchable by keywords on symphonyextensions.com. Maybe it would be better to allow more than one type, and make them more of a tag?

You can add more than one type in the meta schema from what I've seen.

There is a types parent node and as many type children nodes as required

Like so:

<types> <type>Interface</type> <type>Workflow</type> </types>

More info here

I was trying to think about how this relates to extension types, too.

Anyway, this type of convention makes sense to me. I'm just wondering if the type could be used instead.

I quite like some of the more esoteric names of extensions, and I don't think they always needs to be plain and boringly descriptive. Assigning multiple types works. The schema suggests a list, but in reality you can add whatever you like. The list on the Symphony Extensions site is here (a list of all types across all extensions):

http://symphonyextensions.com/api/extensions/types/

There's a little work involved in sanitising these (we have Event and Events) but I've started asking developers to fix these.

Personally, I think changing extension names the proposed way is a step into the wrong direction: types shouldn't be part of the name. We already have these poorly named extension prefixing the name with "Field" or "Textformatter". This kind of scheme only works for the simple extensions - as soon as they are tackling more complex tasks it won't work: extensions are allowed to provide fields and data sources and events and event filters - and not or :)

In my eyes, developers should give their extensions fitting names (without restrictions), tagged with the proper types (these need to be coordinated, not the names)..

Also, some extensions are named by the service they provide, i.e. Stop Forum Spam, Askimet Spam Filtering etc etc. What should we do in this instance?

"Can Of Spam" and "Akismet Spam Filtering" also stop forum spam. What exactly does "Stop Forum Spam" differently? Don't answer, I just asked to make clear what's wrong with the naming here.

In my eyes, developers should give their extensions fitting names (without restrictions), tagged with the proper types (these need to be coordinated, not the names).

One of my main intentions behind prefixing the names is that it would be easier to group extensions together. Spam protection extensions for example would be listed together in the backend (because of the alphabetic sort order), so it's easier to see which extensions you use in a specific Symphony setup for spam protection.

I'm just wondering if the type could be used instead.

Thought about that, too. Problem is, allowing multiple types doesn't allow for a simple sorting and grouping in the backend.

I will answer...

Stop Forum Spam is a web service not an action, so in actual fact there isn't anything wrong with it's name.

Ok, makes more sense now...