Extension Module Development: Acquiring the http path of the extesnsion

[awasson]

Hi All,

Hopefully this is a quick one.

I've got an extension in development that needs to link to an internal link; something like:
http://www.example.com/somepath-to-extensions/this-particular-extension/export_to_excel.php?report_year=2014

The only thing I can be certain of is the name of the script it will run: export_to_excel.php?report_year=2014

Any thoughts on acquiring the http path to the extensions directory?

Thanks,
Andrew

[totten]

You can use CRM_Core_Resources::singleton()->getUrl('org.my.extension', 'my/file/name.php'). (Similarly, if you need the local file-path to an extension, use getPath().)

You may want to consider registering a new page instead (e.g. "civix generate:page ExportToExcel civicrm/myextension/export" or hook_civicrm_xmlMenu). There are two main issues with pointing to a standalone script in an extension:

• If the .php needs access to Civi or to the CMS, it will need to bootstrap. That's very hard to do in a portable way because the extension directory is allowed to go anywhere in the filesystem.
• If a reference to the URL needs to be communicated/stored externally, then it becomes part of the public interface that should get documented for sysadmins. It's easier to document/support a page that is registered through an XML file.

Note: By defualt, pages produced by "civix generate:page" output HTML. But you can short-circuit it and output non-HTML, e.g.

Code: [Select]

  function run() {
    header('Content-type: application/foo');
    echo $excelEncoder->encodeRows($myData);
    CRM_Utils_System::civiExit();
  }


[awasson]

Perfect! Thanks Totten.

I think I'll experiment a bit and follow your suggestion about registering a new page. The script is just a processor that outputs a report in excel format so it doesn't need anything from civi but it might be the cleanest way. It's worth a try anyway. Thanks for suggesting that.

Cheers,
Andrew

[xavier]

Another reason to follow the page approach is that on some installations (quite common on nginx drupal setup) only the registered entry points are allowed to run .php, and you have to explicitly add on your nginx config you want the update.php or whatever.php to be allowed to run.

I still thing it's a good security measure, but a bit of a PITA to debug when random feature doesn't work because they use their own .php

X+

[awasson]

On reflection (and a little tinkering with my code), I think the page approach will actually make this a simpler approach anyway, because the code is where it should be according to CiviCRM Extension Building 101 and as it turns out, in this case, it will be helpful to pull some data from Civi.

Cheers,
Andrew

[xavier]

btw, both mathieu and myself wrote and extension to do excel stuff, if your need is generic enough, might be worthwhile to modify one of these to add the feature instead of starting a new one?

X+

[awasson]

Thanks xavier,

The extension I'm working on is used to track an organization's member's continuing learning credits and only needs to export a report that is specific to it so I'm not sure that I can leverage the one you've created but I'm sure it will be handy for others so I'll definitely have a look.

Andre

[JohnFF]

btw, both mathieu and myself wrote and extension to do excel stuff

Details!? This could be really useful for my team.