Rename modules to extensions

[JDGrimes]

This is something that I've been thinking about, and I think that we should go ahead and do it. The sooner that a rename like this occurs, the easier it will be, and the longer we wait the harder it will get.

The reason that we call modules "modules" is because CubePoints had things called "modules". However, those weren't extensions, they were included with the plugin. And that is the way that the term module is generally used: it can describe a discrete set of features within a plugin (like Jetpack), but not generally add-on extensions for the plugin.

In short, people are familiar with the term extension, and its meaning is self-evident. The term module is less familiar, and requires special definition by us so that the user realized that modules are add-ons.

I was pondering not tackling this entirely in 2.4 only doing a rename in the UI, and renaming internal APIs later. However, I think that we ought to do both in 2.4, because we've introduced a considerable number of module-related functions. If we wait, and want to rename those functions, the old versions of all of them will have to be deprecated. So it seems like now is a good time to do this.

[JDGrimes]

I am thinking that for most preexisting APIs though, we should forego the rename for now. That will allow us to make more substantial changes to them later, in concert with the rename.

[JDGrimes]

I suppose that we might as well go ahead and update what we expect as the API header declared on remote extension servers to be x-wordpoints-extension-api and not x-wordpoints-module-api. We'll update the header served from .org as well.

[JDGrimes]

In addition to new code, I think that we should also consider renaming some of the most commonly used functions and actions, since these will cause the most pain when the old versions are eventually deprecated.

Specifically, I think we'd want to rename:

• Module Name and Module URI headers.
• WordPoints_Modules::register(), used to wrap the headers.
• 'wordpoints_modules_loaded action.
• wordpoints_modules_dir().
• Method to get an extension's version.
• wordpoints_modules_url().
• wordpoints_is_module_network_active().
• etc.

[JDGrimes]

When it comes to updating the docs to reflect this change, there's a variety of things that we'll need to do:

• [x] Update docs on .org
• [x] Change "/modules" to "/extensions".

[JDGrimes]

One downside of the term extension is that it usually refers to an actual plugin, whereas in this case it refers to a native extension for WordPoints. This will be confusing sometimes, if people write extensions as plugins as well.

In other words, people will know what an extension is, but they won't know what an extension for WordPoints actually is; they will likely think that it is a plugin. In reality though, I'm not sure that it makes that much difference, and actually it might be a good thing. Because essentially extensions are plugins, from the perspective of the end-user, they are just managed on a dedicated screen. It is only developers that really need to worry much about the difference, and even then it isn't so important.

It would probably improve UX if extensions could be installed via the plugins screen, instead of just giving a warning as we currently do.

[JDGrimes]

Two more things to consider renaming:

• Capabilities.
• Modules directory name.

[JDGrimes]

• Admin screen slug.

[JDGrimes]

I think that we can rename the modules directory without breaking anything, just by using the new name on new installs and adding back-compat for old installs. We can also attempt to rename the directory on update, and only enable the back-compat code if that fails.

However, then what do we do when the plugin is initially loaded before the update takes place? The back-compat code won't be triggered by the DB flag because the update won't have taken place yet. So the new directory name will be used, and no modules will be found there. Essentially, on that one load, no modules will be loaded. This could potentially cause problems.

I suppose that we could check the WordPoints database version in the legacy handling code, and trigger it in that special case where the update hadn't taken place yet.

[JDGrimes]

I think that most everything else will have to be tackled in future releases.

[JDGrimes]

One last thing that I'd like to do, that I might have forgotten to mention before, but had been thinking about, is renaming the modules app to extensions.