I'm trying this module and find that even though filters are properly set, no block shows up. I enabled the block and gave all users view permissions, but nothing happens.

Comments

njivy’s picture

Component: User interface » Code
Assigned: Unassigned » njivy
Priority: Normal » Critical

Yeah, I get the same result now. I recently hacked this module together, and my simple tests worked okay. But when I try it again, it does not work.

The filter function must be tricky in order to pass its results to the block function. This is an inherent limitation of Drupal, because the filter knows nothing about the node ID--it only knows the md5sum of the text. The block knows nothing about the md5sum--it knows the node ID. So I need to figure out a more reliable way to pass information from the filter to the block. I had assumed some URL conventions in the current module version, but my assumptions were incorrect. For example, the node ID is not always contained in the URL.

I need to re-think this architecture. I'll respond here when I have done so.

Ideas and suggestions are greatly welcomed. :]

njivy’s picture

I committed a new version based on the recommendations of the drupal-devel mailing list. There was a big discussion here about providing context to filters. The outcome was a decision to do contextual "filtering" with the view operator of the nodeapi hook. The nodeapi hook was refactored so it occurs after the filters run.

I have experienced no problems with relatedlinks.module, except for the small quirk that the block may not update until the node is viewed a second time. This may happen if the block is rendered before the node is viewed the first time after it is updated or created. The results are cached, however, so after the first node view it should be fine.

njivy’s picture

Uh, yeah. I forgot to close my < em >. Oops.

Anonymous’s picture