Upgrade Civix generated code

[seamuslee001]

@bjendres

@a-cormick-dockery @johntwyman

[bjendres]

@jaapjansma does this needlessly break compatibility with older CiviCRM versions?

Or even better: do you have a list of things to look out for or roll back to maintain compatibility? And if you do, may I add it to https://github.com/systopia/legacycode/blob/master/README.md?

[jaapjansma]

Yes it is two things.

1. In the ext.civix.php there is a line of code with

    if ($entry{0} == '.') {

which needs to be replaced to

    if ($entry[0] == '.') {

2. In the ext.civix.php the following lines

     if (is_array($template->template_dir)) {
        array_unshift($template->template_dir, $extDir);
      }
      else {
        $template->template_dir = array($extDir, $template->template_dir);
      }

Needs to be replaced with

     $template->addTemplateDir($extDir);

However a full Civix upgrade will make sure the extension works with the latest version of civicrm (and reduces boileplate code). The drawback is then it loses backwards compatibility. I have tested the lines above with an old CiviCRM installation 5.14 on php 7 and with CiviCRM 5.71 and PHP 8.

[bjendres]

Yes it is two things.

Ah, ok, understood. But it's not as easy as running a full civix updgrade and then manually changing a few things back, right @jaapjansma?

@seamuslee001 does the civix upgrade add/enable features or compatibility that are important enough to drop support for older CiviCRMs?

[jaapjansma]

Indeed I avoid running civix upgrades. My solution is manual changes to the code. (I am in a mode that I try to avoid using Civix whenever possible, it gives me too much headache and work)

[bjendres]

Indeed I avoid running civix upgrades. My solution is manual changes to the code. (I am in a mode that I try to avoid using Civix whenever possible, it gives me too much headache and work)

@seamuslee001 any reasons do that instead of the full civix upgrade?

[seamuslee001]

@bjendres I prefer doing civix upgrades because I find it makes my extensions easier to manage and its more the recommended approach. Also as jaap points out it does reduce a bunch of unneded boilerplate.

Also at JMA we tend to be more closer with keeping CiviCRM closer to supported versions for our clients so we don't generally worry about versions back to 5.14 and such. I think our oldest CiviCRM versions is like 5.65 or something like that for our client sites.

The polyfill here should mean that you get mixin support but the :void or the :string may mean you don't support older versions of PHP7 but they should work fine on PHP7.3 and up. I haven't tried this on older versions of CiviCRM but I would have thought it should be fine because you don't need smarty stuff

[eileenmcnaughton]

I don't actually use it but there is an OpenStreetMaps geocoder that ships with the geocoder extension - which is compatible with the latest CiviCRM / Smarty - so that could be an option for people who want to use up-to-date civi/Smarty/php

(ie I use the extension - but not that geocoder plugin)

[bjendres]

@bjendres I prefer doing civix upgrades because I find it makes my extensions easier to manage and its more the recommended approach. Also as jaap points out it does reduce a bunch of unneded boilerplate [...] we tend to be more closer with keeping CiviCRM closer to supported versions for our clients

I understand and agree, but... I think we explained our situation various times: some of our larger clients have dozens of complex extensions to adjust CiviCRM to some European or specific workflows, so a CiviCRM upgrade is a massive endeavour for them. That's why try to keep these extensions as compatible as possible to not unnecessarily add to that complexity.

[bjendres]

there is an OpenStreetMaps geocoder that ships with the geocoder extension

Interesting, I didn't know that.

[eileenmcnaughton]

I believe it works cos I get patches every now & then for it - although there is this open issue - might be a good sprint task for me to look at it

eileenmcnaughton/org.wikimedia.geocoder#61