Hello, Does anyone know a trick (or something I shouldve read, but did not read) about how to get acces to $node objects in hook_filter? My filters do not alter anything in that object, but the filters /do/ need some parameters in that object. As far as I can see, _filter only receives a 'stupid' text-chunk, but I cannot beleive that we designed it that stupid and never pass more information to he filters. Its just that I cannot find the wheres, hows and whens. Bèr -- [ End user Drupal services and hosting | Sympal.nl ] Written while listening to Smokes Quantity by Boards of Canada on Twoism
As far as I can see, _filter only receives a 'stupid' text-chunk, but I cannot beleive that we designed it that stupid and never pass more information to he filters. Its just that I cannot find the wheres, hows and whens.
thats how it works. there have been long debates about this in the past. see http://www.acko.net/blog/drupal-filter-formats and http://drupal.org/node/11225 lets be a bit more *positive* and refrain from calling designs 'stupid'.
Op zaterdag 15 juli 2006 14:25, schreef Moshe Weitzman:
thats how it works. there have been long debates about this in the past. see http://www.acko.net/blog/drupal-filter-formats and http://drupal.org/node/11225
lets be a bit more *positive* and refrain from calling designs 'stupid'.
I am not calling the design stupid. I meant that the functions aer stupid. Stupid in a way that they are 'ignorant' of their 'position' etc. So I am not calling a person stupid. Nor the design not even the implementation. A better phrasing would have been: «functions that (get to) know too little» Ber
On Sat, 15 Jul 2006, [iso-8859-1] B�r Kessels wrote:
Does anyone know a trick (or something I shouldve read, but did not read) about how to get acces to $node objects in hook_filter?
My filters do not alter anything in that object, but the filters /do/ need some parameters in that object.
As far as I can see, _filter only receives a 'stupid' text-chunk, but I cannot beleive that we designed it that stupid and never pass more information to he filters. Its just that I cannot find the wheres, hows and whens.
I tried to get a patch in, which would pass the node along. But filters are not only used for node text. They are used for the site mission, node add page help texts and such. The answer to this question then was that I should use nodeapi view to do node based filtering. This is what I do. Gabor
Op zondag 16 juli 2006 12:35, schreef Gabor Hojtsy:
The answer to this question then was that I should use nodeapi view to do node based filtering. This is what I do.
This is what I do now too. Bèr -mission/footer/blocks as nodes in microcontent- Kessels
Hi, Gabor Hojtsy wrote:
On Sat, 15 Jul 2006, [iso-8859-1] B�r Kessels wrote:
Does anyone know a trick (or something I shouldve read, but did not read) about how to get acces to $node objects in hook_filter?
My filters do not alter anything in that object, but the filters /do/ need some parameters in that object.
As far as I can see, _filter only receives a 'stupid' text-chunk, but I cannot beleive that we designed it that stupid and never pass more information to he filters. Its just that I cannot find the wheres, hows and whens.
I tried to get a patch in, which would pass the node along. But filters are not only used for node text. They are used for the site mission, node add page help texts and such.
The answer to this question then was that I should use nodeapi view to do node based filtering. This is what I do.
I took a look at this patch, and I concluded that the passing of other information needed to more generic. So not so much just being able to pass a node. One thing that I would like to see is targeted filters so that you can have a filter which will only be applied to nodes, and other filters which will be applied to other types of data which is being filtered. I was actually looking to using the filtering for the E-Commerce emails, but it was just too node centric. Doing this then you can set up to allow the passing of an array of parameters which could then used by the filter. In the case of the php filter you could extract() the array and use all the parameters as local values. Also it means that filters could be targeted, ie. can be used for nodes or any other type of data, or global like what there is now, and not care what the data is. Also this will change the filter_tips and only show filters which are applicable to the type of data that is being filtered. I plan on doing this one day when I have time. It will make the filtering system a lot more powerful. Gordon.
Op zondag 16 juli 2006 14:20, schreef Gordon Heydon:
One thing that I would like to see is targeted filters so that you can have a filter which will only be applied to nodes, and other filters which will be applied to other types of data which is being filtered.
I think it needs not be this complex. instead of function hook_filter($op, $delta = 0, $format = -1, $text = '') { } we need function hook_filter($op, $delta = 0, $format = -1, $text = '', $object = NULL) { } Where $object is either the $comment, $node, $term, $user or any other object. Or nothing at all (in case of just a piece of text). This is by far the simplest solution I see. It does require a bit of logic on your side, when implementing the hook, but it cannot be that hard to test, e.g. for $node->nid (if exists, you are filtering a node). Am I missing something obvious why this cannot work? If not, I will gladly turn this into a patch. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Written while listening to Slowmotion Girl by Laid Back on Keep Smiling
Hi, Bèr Kessels wrote:
Op zondag 16 juli 2006 14:20, schreef Gordon Heydon:
One thing that I would like to see is targeted filters so that you can have a filter which will only be applied to nodes, and other filters which will be applied to other types of data which is being filtered.
I think it needs not be this complex. instead of function hook_filter($op, $delta = 0, $format = -1, $text = '') { } we need function hook_filter($op, $delta = 0, $format = -1, $text = '', $object = NULL) { }
Where $object is either the $comment, $node, $term, $user or any other object. Or nothing at all (in case of just a piece of text).
This is by far the simplest solution I see.
It does require a bit of logic on your side, when implementing the hook, but it cannot be that hard to test, e.g. for $node->nid (if exists, you are filtering a node).
Am I missing something obvious why this cannot work? If not, I will gladly turn this into a patch.
This would work to a certain extent, but then there is the user interface. The system is going to be telling the user that they can filter on these different things that are just not going to work on an object that is not a node. The global filters will be fine (in that they don't care what the object is) but the filters that require a node are going to publish in the filter tips that are not going to be done. Which would be confusing for the user. I know my implementation is a little more complex, but it does add context sensitivity to the mix and be better for the user, and not so ambiguous for the developer. Gordon.
participants (4)
-
Bèr Kessels -
Gabor Hojtsy -
Gordon Heydon -
Moshe Weitzman