getRelated: automatically listing related Resources for Revolution

getRelated is a snippet for MODX Revolution that automatically finds related pages based on fields you specify.

You can install it via the Package Manager.

It has been developed by Mark Hamstra for Vierkante Meter.

Documentation: http://rtfm.modx.com/display/ADDON/getRelated
Bugs & Features: https://github.com/Mark-H/getRelated/issues [ed. note: markh last edited this post 11 years, 7 months ago.]

Nice addition!

I`ve tried to use it in child resource as (I need to find all the "sister" resources):
[[getRelated? &parents=`Parent_title`]]
Received error message
BTW maybe it`s better to use Parent ID instead of Parent title?
When I use:

and then

I receive equal results which mean this doesn`t work.

Uncached call makes a lot of trouble.

Idea is nice but lack of examples and bugs are crucial...

I`ve tried to use it in child resource as (I need to find all the "sister" resources):

It's better to use getResources for something like that, or Wayfinder. getRelated is to automatically get resources that are related in terms of content, not in terms of their location in the tree structure.

Either of the both snippet calls would work to get all siblings, see their respective docs for more info on other properties to use.

Received error message

Would be helpful to see your snippet call and know what error message you got to help with that

BTW maybe it`s better to use Parent ID instead of Parent title?

Not sure what you're talking about here. If you mean the &parents parameter, that accepts parent IDs only.

When I use:

[[getRelated? &fieldSortDir=`desc`]]

and then

[[getRelated? &fieldSortDir=`asc`]]

I receive equal results which mean this doesn`t work.

No, you misunderstood/misread the fieldSortDir property.

Let me quote the docs to explain that:

fieldSortDir Sort direction for the fieldSort property desc

Okay, so it tells it's for the fieldSort property. Let's see what that is..

fieldSort Resource field to sort by, used in conjunction with the fieldSample property createdon

Aha, so the fieldSort property is used with fieldSample. Let's see..

fieldSample Number of resources to use in comparing based on resource fields. Can have a huge impact on performance so if you\'re experiencing long load times, try decreasing this number. 125

Aha! So now we know that fieldSample is used to control the number of resources that are used in the comparison. That defaults to 125 resources that are already somewhat related based on words used in the fields specified, and using fieldSort and fieldSortDir we can influence where we get the sample from.

The default behavior is to get 125 related resources for comparison, sorted based on the createdon field, latest first. In order words, the 125 most recent resources that are somewhat related. Those 125 resources are then processed with an algorithm which results in a ranking for every one of those resources, which is then being output sorted on the rank.

To sum up: fieldSortDir influences the sample only, not the output.
As this is a snippet to generated a list of related pages, it makes no sense to add a sort property to change the sort to anything but the rank it was assigned.

The only time you *may* see any effect with the fieldSortDir property is when you have an insane amount of resources where the total related resources based on words used exceed the maximum sample size and other results are discarded.

Uncached call makes a lot of trouble.

There is absolutely no reason to call this uncached. A lot of processing is done, and the result of that will never change before a resource is changed and the cache cleared. That said - if there are serious issues other than performance which is obvious, please come forward with more details.

Idea is nice but lack of examples and bugs are crucial...

I've had a more in-depth explanation of how it works (explaining the sample & processing done more) planned, but the minimum call is really all 99% of the users need. I'll just open up the docs and see if there's anything more is missing that really needs to be there, but if there's things that are really missing in your opinion please let me know.

Also, I still have to see a bug report and I think you misunderstood the idea behind this addon I've done quite extensive testing on various sites and it looks quite solid to me (tho I am biased, of course).


Anyhow - thanks for taking the time to try it out and reporting back. While I may have torn apart pretty much all you said, I really appreciate you taking the time to get back to this topic to share your thoughts.

Updated the docs with a section on performance, how it works and hopefully clarified the properties more: http://rtfm.modx.com/display/ADDON/getRelated

Quote from: markh at Oct 16, 2011, 01:37 PM

getRelated is to automatically get resources that are related in terms of content, not in terms of their location in the tree structure.

Now I got it! Thanks! At the beginning I was thinking about getRelated as a lightweight getResource...
So the example of using it which comes to my mind is, as an real life example, to find related products of current product. Please correct me if I`m wrong.
Thank you for spending so much time to make such comprehensive explanation...

Yes, if products are entered as resources you could use getRelated to output related products based on a category TV, its title, a description etc.

Templates are not working, what am I doing wrong?

Getting the default tpl. Can change the core file, but prefer to do it with a chunk..!

SOLVED..

TPL name can not have the default name!

Dunno if it's a bug or a standard MODx thing, but giving the tpl chunk a different name fixed it.

Great, you found a bug in a piece of code I use in a lot of my addons. Guess I'll have go through them all now Thanks for the report.

It should *fall back* to the file placed templates, but the way it's looking in the code right now is that it first attempts the filed based template, and after that the actual chunk. While no problem in dev, that's the opposite of how it'd be expected for usage. Your chunks have the same name as the files which causes the collision.

I've fixed it and pushed a new version out (1.0.1-pl2) that fixes it, so you should be able to update from package manager. (Not sure if / how long that is cached tho)