Thread

This question may be related to a resolved thread.

According to my understanding of the previous thread, this should be resolved. However, having just downloaded and updated my client’s site with the latest build (20100430), this issue is still cropping up.

For the record, it’s on my second MSM site using reverse_related_entries and ordering by a custom field, in this case: orderby=“athlete_lname”.

This is the bug that won’t quit.  Try this- in system/modules/weblog/mod.weblog.php around line 648, we need to add into the $str_sort array- see that line I’ve added below?  That take care of the problem?

if ( isset($cfields[$order]))
{
    $order = 'field_id_'.$cfields[$order]; 
    $set = 'y';
    $str_sort[] = 'field_id_'.$cfields[$order]; 
    break;
}

Just tried it. The only result is the following error:

Notice: Undefined index: field_id_95 in /system/modules/weblog/mod.weblog.php on line 652

Words fail to express how dumb that code was.  Le sigh.  Try this instead- tested and works.

$str_sort[] = $order;

Got rid of the error, but still no change regarding ordering.

Hrm- can you link me to a sample page?  It’s not going to order perfectly by number (because it’s not sorting it as a number)- but based on the field name, I’m thinking they don’t start out numerically.

Correct, it’s an alphabetical problem. The athletes should be ordered by last name: http://www.seniorclassaward.com/ciaa/mensbasketball/

Here’s a link with only the relevant code on it: http://www.seniorclassaward.com/ciaa/seasons/test/

Odd- and I’m not replicating (I put the first 3 names in, which are wrong on the link- they came out properly).

Let’s reduce a bit more so I can see what’s happening.  Can you put up a test template with just this code on it:

{exp:weblog:entries weblog="default_site" limit="5"}
<h3>{title}</h3>

<p>{reverse_related_entries orderby="athlete_lname"}<br />
{title} - {entry_id}</p>

<h6>{athlete_lname}</h6>
<p>{/reverse_related_entries}</p>

<p>{/exp:weblog:entries}

Well- you will likely need to change the weblog parameter.  And- is the link to a single entry page?  In other words- are all of the athletes related back to mensbasketball url_title?

What do you mean you put the first 3 names in?

Test template is at the same URL as before: http://www.seniorclassaward.com/ciaa/seasons/test/
I had to modify the code to take account of my entry statuses:

{exp:weblog:entries weblog="seasons" limit="5" show_expired="yes" status="Winner"}
<h3>{title}</h3>

<p>{reverse_related_entries weblog="athletes" orderby="athlete_lname" status="Finalist"}<br />
{title} - {entry_id}</p>

<h6>{athlete_lname}</h6>
<p>{/reverse_related_entries}</p>

<p>{/exp:weblog:entries}

It’s not a single entry page. It’s an embedded template, but the embedded code was all that was in the test link I made (I hard coded in the entry id in that example to make it work).

I just figured it out!
My 2nd MSM site is using the same custom fields as the other MSM site. So changing athlete_lname to athlete_lname2 made it start working. The instructions that I used to set up the MSM site seemed to indicate that having custom fields with the same field name would work (since I duplicated the weblog parameters from the first site).

Thanks for your help. I guess I’ll go through and change my field names now.

What do you mean you put the first 3 names in?

I just meant- I entered your data into my test site to run the last tests- just in case there was something about the names themselves affecting things.

But- ‘yay’ that you’ve figured it out.  Though now I need to ponder if it’s still a bug.  That seems weird to me (though it explains why I couldn’t replicate).  I’m not entirely sure why it’s happening and I don’t like that it is.

I’ll poke a bit more and if it does turn up buggy, get a fix in.  Seems buggy from here, but I need to take a closer look.

Yes it does still seem like a bug. If you’d like me to provide you any more information, I’d be happy to help.

Hi, shinka -

I know it’s been a long time.  I wanted to let you know that the development team is still working on this, and we will get back to you.

Thank you for your patience.

Sounds good. The renaming of the custom field to differentiate it from the other custom field of the same name seems to be a good workaround at this point.