Forums | Mahara Community

Developers /
Migrating blocktype - Usage of "extracols" and "extrajoin


anonymous profile picture
Account deleted
Posts: 2

27 August 2013, 3:12

Hi All,I hope all is well.

I'm currently in the middle of migrating a plugin from Mahara 1.1 to Mahara 1.7. The plugin implements a blocktype. In the blocktype's lib.php is a function artefactchooser_element()

I pass on additional joins and additional columns into the $element array using key 'extrajoin' and 'extracols'.

In Mahara1.7 I noticed that these keys are no longer used. I'm just wondering what is the best way to work around this change?

I tried to look at the blog artefact (blocktype blogposts) code. As this use to use the 'extracol' and 'extrajoin' keys in older versions of Mahara. But I couldn't see how exactly this got around the issue I have.

All the best,
Jonathan

 

Aaron Wells's profile picture
Posts: 896

27 August 2013, 14:04

Hi Jonathan,

It looks like Francois removed those options in 2010 as part of a process of hardening Mahara against SQL injections. Here is the detail of the commit in which he removed extrajoin and extracols. It includes changes to blocktype blogposts, so perhaps it can give you some idea of how to handle the change in your code: https://reviews.mahara.org/gitweb?p=mahara.git;a=commit;h=2e2f34abf7787b89305d7b4895cdbdee835984cb

From that, it looks like the artefactchooser is indeed limited to only contents in the artefact table. There is still the "sort" and "extraselect" options available, but they don't accept raw SQL, instead they take a list of column names and value names.

It looks like in the case of the blog posts block, he simply removed the ability for the artefactchooser to indicate whether a particular blog post is a draft or not, thus removing the need for the extra columns and extra joins.

I'm not too familiar with this part of the Mahara codebase, so I can't advise you in too much detail. What are you trying to do with the artefact chooser?

Cheers,

Aaron

anonymous profile picture
Account deleted
Posts: 2

27 August 2013, 20:14

Hi Aaron,

Thanks for the information. I was actually trying to find the commit myself yesterday in the hope it would indicate a work around. But I couldn't access the repository as it kept mentioning something about an upgrade.

 

When I was looking at the blockposts block myself it looked as if the functionaility that used the extracol/extrajoin was removed.

 

What I'm trying to do is the following:

When the configuration form for the instance is called. It loads a list of posts(artefacts) the user can select to display in the block.  The lists of posts fails to load since the extra join/extracol parameters aren't getting used. I traced the code and noticed that the function build_artefactchooser_data() in lib/view.php is used to build the data.

I'm just struggling to find how to get around this change in the coding of this plugin.

Thanks again,

Jonathan

 

Aaron Wells's profile picture
Posts: 896

28 August 2013, 19:39

Hi Jonathan,Well, I think you've got these main options:

1. Add an artefact_chooser_get_element_data() function to your blocktype, and use this to fetch the additional data that you're currently fetching by calling extracol/extrajoin.

2. Make your own custom pieform element based off of lib/form/elements/artefactchooser.php , which supports the SQL queries you need, and use that instead. A plugin can provide its own custom Pieform elements, you just need to add your plugin's form directory to the 'configdirs' setting when declaring the pieform. See artefact/file/form/elements/filebrowser.php for the one example in the core code. Hm... for a block the configdir seems to be set for you, in BlockInstance->build_configure_form(), but it does include the "form" directory of your block's "artefactplugin" if it has one. Or you could submit a patch to core to provide an API for setting the configdirs for a block's config form. Which brings me to...

3. You could submit a patch to Mahara core, to alter the block plugin API in such a way that what you need to do is possible. I agree with Francois's change; it's a bad idea to be passing around raw SQL as function parameters, but if you could come up with some other way to filter/extend the list of artefacts that you need, I'd be glad to upstream it. Perhaps we could add an optional function that lets the block class itself provide the full list of artefacts used by the artefactchooser plugin? Unfortunately we're past the feature freeze for the Mahara 1.8 release, so this wouldn't be able to make it into core until Mahara 1.9, which is about 6 months off. Until then you'd have to ask people to patch their system manually when installing your plugin.

Cheers,

Aaron

4 results