4

Say we have an extension with short-name "fancywidget" which is managed by Company A. The full name of the extension is com.a.fancywidget.

Now say Company A drops maintenance of it, and Company B steps up to take over. It's still the "fancywidget" extension, but under new ownership.

Is it safe to rename the extension to com.b.fancywidget? What are the implications (e.g. for the extension directory, pingback stats, etc.) of doing so?

  • Since both com.a.fancywidget and com.b.fancywidget will have namespace conflicts (hook function names), what reasons are there for developers to use the com.X prefix? – Chris Burgess Jun 9 '15 at 4:18
  • 1
    I've asked the same question. One response is that it's technically possible to avoid a conflict by setting a different <file> tag in each info.xml, although that kicks the can down the road. (Which module should change its <file>? Who identifies the conflicts?) Another response is that the long name gives some branding. Personally, I'd be +1 on deprecating long-names (eg require a standard prefix, "org.civicrm.", for all new extensions), but this might be a better conversation for the developer forum. – Tim Otten Jun 9 '15 at 9:55
6

There are several places which rely on the full name of the extension:

  • Extension directory: One must create a new record for the new extension key. Ownership, release-history, etc, will be different.
  • Pingback stats: The old and new name will have separate stats.
  • Upgrades (downloading new code): Upgrades issued in the new name won't be displayed as upgrades on existing installations (which expect the old name).
  • Upgrades (tracking/updating DB schema): The schema versions of the extensions are separate.
  • Managed entities: If the old and new extensions insert managed entities, there could be uniqueness conflicts. (The ManagedEntities manager does not impose a global uniqueness constraint, but some specific entities do enforce uniqueness -- eg you can't simultaneously register two payment-processor-types with the same name.)

My recommendation: Don't think of it as renaming an extension; think of it as publishing a new extension (and reusing code from the old extension). The new extension should be designed around the old one (eg using different names throughout and/or migrating data).

Speaking in the abstract without a specific extension, it's not simple to rename or replace a extension. However, for specific extensions, there may be mitigating factors:

  • (No) DB content: If the extension only adds runtime functionality (via hooks) and does not insert anything into the DB, then it will be easier to rename/replace. If the extension does insert into the DB (eg via hook_install, via Upgrader, or via managed-entities), then expect some tasks or complications.
  • Private vs public extension: If the extension wasn't released to the public, then you may be able to hack through conflicts (eg manually changing over DB references), and you probably won't care about the extensions directory, the pingback stats, or distributing upgrades.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.