CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Extensions (Moderators: mathieu, totten, kasiawaka) »
  • Best practice to backport a feature using extension?
Pages: [1]

Author Topic: Best practice to backport a feature using extension?  (Read 1293 times)

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Best practice to backport a feature using extension?
March 07, 2013, 06:42:22 am
Hi,

I'm working on an extension to make use of the phone prefix in civicrm_country. I created a new api country.get that will end up in the core.

So so far, I add my api/v3/Country.php and all good.

However, what will happen once the Country api is in the core is that my extension will override the one from the core. At one point or another, the version in the core will be more advanced than the one in the extension, so enabling the extension will downgrade this api.

How to be sure I install the api in the extension only if it isn't in the core already (eg be sure to backport, but not override?)

This is a problem I have had not only with a new api but as well with changing something on a template or modifying a method in a class in the core for instance.

Any suggestion more than welcome.
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

nicolas

  • I post occasionally
  • **
  • Posts: 92
  • Karma: 6
    • cividesk
  • CiviCRM version: 4.4 LTS
  • CMS version: Standalone (yep)
  • MySQL version: 5.1
  • PHP version: 5.3
Re: Best practice to backport a feature using extension?
March 10, 2013, 12:58:04 pm
Xav - that's a good one, and I have another closely related that I will post on right after answering.

Probably the best way to deal with that is that when core is brought up to date, you need to release a new version of your extension that does not include the overridden core elements. Of course, set the compatibility flag accordingly for this new version of your extension. I do not know if the extension upgrader does indeed check the compatibility flag in the xml file, but if it did then it would be a fully automated solution.
cividesk -- CiviCRM delivered ... your way!

totten

  • Administrator
  • Ask me questions
  • *****
  • Posts: 695
  • Karma: 64
Re: Best practice to backport a feature using extension?
March 10, 2013, 08:26:05 pm
I like nicolas's recommendation -- releasing different builds targeted at different platforms is a good approach.

Regarding the compatibility flags -- Civi 4.2 and 4.3 use the compatibility flags for in-app distribution. (The list of downloads is filtered by compatibility.) However, if you manually install the extension code, then the flags are ignored/irrelevant.

If you really want to bundle the backported APIs and produce a single build, it should be possible to manipulate the relative priority of API files. For example, you could put the backported file in "$myextension/backport/api/v3/Country.php" and then modify hook_civicrm_config to add "__DIR__/backport" to the include-path. When adding the directory, you can make a choice to put it at the start or the end of the include-path.

It's moments like this when I wish we had a dependency-management system (like composer). You could put the backports in one package ("com.example.apibackports") then declare it as a dependency for your new extension. (And others could depend on it, too.) However, we haven't integrated a dependency-manager, so that's not an option yet.

xavier

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4453
  • Karma: 161
    • Tech To The People
  • CiviCRM version: yes probably
  • CMS version: drupal
Re: Best practice to backport a feature using extension?
March 11, 2013, 08:25:32 am
Hi,

How would it work with minor versions? eg what is the missing feature is introduced in 4.3.2?

When 4.3.2 is released, should we release a new extension compatible 4.3 without the backport? what happens to those in 4.3.1? It fails and we tell them to upgrade?

X+
-Hackathon and data journalism about the European parliament 24-26 jan. Watch out the result

nicolas

  • I post occasionally
  • **
  • Posts: 92
  • Karma: 6
    • cividesk
  • CiviCRM version: 4.4 LTS
  • CMS version: Standalone (yep)
  • MySQL version: 5.1
  • PHP version: 5.3
Re: Best practice to backport a feature using extension?
March 12, 2013, 10:51:25 am
I an sure the extensions installer can accept minor version numbers in the compatibility flag - but totten can confirm.
cividesk -- CiviCRM delivered ... your way!

totten

  • Administrator
  • Ask me questions
  • *****
  • Posts: 695
  • Karma: 64
Re: Best practice to backport a feature using extension?
March 13, 2013, 12:39:24 am
I'm afraid Xavier's right -- the compatibility flag doesn't work with point releases. It's a limitation in the data-model and matching algorithm used in civicrm.org's Drupal database, so if someone fixed that then we could provide everyone with better matching -- without requiring any patches or changes to Civi installations.

Tactically, if you're concerned about point-releases, it's probably better to try the 'backport/api/v3/County.php' approach. The design has risks of conflicts (e.g. if two modules extensions both try to backport the same API, then they may backport different versions, and the winner of the conflict would be arbitrary/non-deterministic), but the risks scale with the size of our extension-base. At our current size, the odds of conflicts seem low. And -- hopefully -- we'll be able to incorporate a real dependency manager before the risk becomes problematic.
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Discussion »
  • Extensions (Moderators: mathieu, totten, kasiawaka) »
  • Best practice to backport a feature using extension?

This forum was archived on 2017-11-26.