onContentPrepare fix #111

New Issue

Closed

opened 2017-08-20 19:09:20 +00:00 by Llewellyn · 4 comments

Llewellyn commented

2017-08-20 19:09:20 +00:00

Owner

I would like to add onContentPrepare to each text area and text field loaded in a site view, there is already some code that does this

// Make sure the content prepare plugins fire on description.
$data->description = JHtml::_('content.prepare',$data->description);

on line 1514 in the Interpretation.php

But it seems to stop working, so now I would like to redo it like the way the article component implements this.

// Process the content plugins.
JPluginHelper::importPlugin('content');
$dispatcher->trigger('onContentPrepare', array ('com_content.article', &$item, &$item->params, $offset));

on line 187 in the view.html.php file of the article view.

Any ideas will be helpful!

I would like to add onContentPrepare to each text area and text field loaded in a site view, there is already some code that does this ``` // Make sure the content prepare plugins fire on description. $data->description = JHtml::_('content.prepare',$data->description); ``` [on line 1514](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php#L1514) in the Interpretation.php But it seems to stop working, so now I would like to redo it like the way the article component implements this. ``` // Process the content plugins. JPluginHelper::importPlugin('content'); $dispatcher->trigger('onContentPrepare', array ('com_content.article', &$item, &$item->params, $offset)); ``` [on line 187](https://github.com/joomla/joomla-cms/blob/staging/components/com_content/views/article/view.html.php#L187) in the view.html.php file of the article view. Any ideas will be helpful!

stutteringp0et commented

2017-12-04 01:26:48 +00:00

(Migrated from github.com)

Author

Owner

I do a lot of work with plugins.

The first option in the config array becomes the $context variable in plugin. This allows the plugin author to selectively apply their changes to only items that match a context. Normally, you'd set the valid component and view dot path and let the cards fall where they may - that is, if a plugin has a narrow $context - it might not show the plugin alterations. For context though, you can go any direction you want - broad, narrow - I saw one extension that used com_component.view.layout in its plugin context...

So, in order to do this the right way, the component name and view name must be available when this code is generated (as opposed to faking another context, which I've also seen developers do). Passing the item by reference allows the plugin to make changes - otherwise the plugin can look, but not touch. I'd pass the item params as well, although the plugin would have to know what it was looking for to use them.

I've issued a PR, it should be linked by now

I do a lot of work with plugins. The first option in the config array becomes the $context variable in plugin. This allows the plugin author to selectively apply their changes to only items that match a context. Normally, you'd set the valid component and view dot path and let the cards fall where they may - that is, if a plugin has a narrow $context - it might not show the plugin alterations. For context though, you can go any direction you want - broad, narrow - I saw one extension that used com_component.view.layout in its plugin context... So, in order to do this the right way, the component name and view name must be available when this code is generated (as opposed to faking another context, which I've also seen developers do). Passing the item by reference allows the plugin to make changes - otherwise the plugin can look, but not touch. I'd pass the item params as well, although the plugin would have to know what it was looking for to use them. I've issued a PR, it should be linked by now

stutteringp0et commented

2017-12-04 01:36:08 +00:00

(Migrated from github.com)

Author

Owner

Right, there is something that isn't working right - apparently ###view### isn't available at this point in e_Interpretation.php - so the closest context I can get is com_###component###

stutteringp0et commented

2017-12-04 01:44:13 +00:00

(Migrated from github.com)

Author

Owner

I'm adding some additional code to create a better $context based on the available fileContentStatic keys. So if you want to modify the code to include the view name, it will happen in this code automatically.

stutteringp0et commented

2017-12-04 01:53:51 +00:00

(Migrated from github.com)

Author

Owner

Nevermind about the context, I have it. Removing the additional logic to construct a context - I can get it from the model.