hi,

I've found a bug with the detailed pages that is causing some confusion... (Version: 2.1.0)

Try this to replicate the problem. Make sure you've got several links in each category so that the pages will span on the detailed pages.

1. Add a link to one category - we'll call it the main one.
2. "Copy" that link to another category.
3. View the "main category" where your link is.
4. Click to view the detailed page for that link.
5. Press the spanning pages links to move onto the next link in the "main category".

Problem (at least on my setup) - when you press on the spanning page links it moves you to the next link in the "secondary" category instead of the main one!?

Logic tells me it should be moving onto the next link in the main category instead.

Gotta be a bug!?

Can anyone solve this one? GT?

Regan.

Hi,

As far as I am aware you do not have a 'main' category with Links SQL - all the categories that the link is in are treated equally. This, I agree is a problem in quite a lot of places and in my opinion it would be good to be able to choose a category for the link to be in and then have a separate field for the related categories (as was the case with the mod for Links2). However, I'm not sure whether this is possible as the categories are stored in a separate table.

I don't think that there is an easy way to fix this problem on the detailed pages. Generally LinksSQL seems to have been written for the case where each link is in one category and the ability to add them to several categories is an add on. It is also a big problem in the modification of links which are in more than one category as has been discussed before.

Laura.
The UK High Street

oh no, you're joking.

I thought they were just "mirrors" of the first link and changes to one changed them all.

That's going to cause me some headaches...

r.

Sorry - don't panic - that's not the problem!

The problem is that once the link owner has modified the link it only appears in one category - even if it was originally in several. I think there is a fix for this somewhere in the forum but it looked quite complicated, so at the moment I can't allow any of my links to be modified by the owners which is slightly annoying.

Sorry to scare you unnecessarily!

Laura.
The UK High Street

Hi Laura,

I just tested this on my installation (Version: 2.1.0) and it works fine. If I modify a link that's in duplicate categories it just modifies them all.

Glad I haven't got that problem too!

I'm guessing with the spanning pages problem that it's just grabbing the "last" link with that id from the table instead of grabbing the first when building the detailed page. Hopefully it's an easy fix!?

Thanks,

Regan.

Modifying them through admin is not a problem. The problem only occurs when using modify.cgi - i.e. allowing a user to modify their own link.

The UK High Street

Not a bug -- it's inevitable if your Detailed pages are static. Static pages cannot possibly know which category you entered from.

A good way to reduce the confusion is for each Detailed page to include a list of categories which contain the link (ref: http://www.gossamer-threads.com/...orum.cgi?post=152224 ). The user may then choose to return to the original category or go to one of the others.

Can you explain why not?

Surely it's just a matter of selecting the "first" category id that the link is in (since they're in order), instead of the last one which it seems to be doing?

Here's a select I just did from the lsql_CatLinks table. When building the detailed page, if the "next previous" links used the first match found, then it would correctly link to the main category it's in, instead of suddenly jumping back and forward between the first and some other secondary category.

Wouldn't it?

+--------+------------+
| LinkID | CategoryID |
+--------+------------+
| 128 | 2 |
| 128 | 13 |
+--------+------------+

What I want it to do is "always" default to the first category it was entered into, not select the one you're currently browsing through. At this stage the detailed page previous and next links are linking to the "last" category it was added to. I think you might have thought I wanted the static pages to know which category you "entered" from, which I don't - you're right that's impossible. (have just edited this post and added that after re-reading your msg).

So I guess my question is, how can I make the next and previous links, link to the first category a link was entered into instead of the last?

cheers,

regan.

Ok, I see what you mean. But I still don't think it is a bug. Your directory model assumes that the first entry for a LinkID in the CatLinks table is a principal category, and all the others are secondary. But LSQL makes no such assumption -- all the CatLinks records have equal rank, and I don't think there is any reason to suppose that the original order is guaranteed.

Is this a better way to state your plugin requirement?
"How can I make the next and previous links, link to the first category a link was entered into instead of the last -- and ensure that the first record for a LinkID in the CatLinks table will always be the first?"

ByTheWay -- it all happens in Build.pm, sub build_detailed, about line 475. After selecting the category IDs, they are (apparently) sorted by build_sort_order_category (you could test it by changing your build_sort_order_category, then seeing if that made a difference to the next and previous links).

Yip, exactly what I'm after!



Cool, thanks! I'll have a play around with it on my test site and see if I can figure it out.

Thanks YoYoYoYo!

Regan.

I think what you really need to do is ask GT nicely if they will deal with the multiple-category defects in the next release.

For example ...
An admin setting for your directory model: primary/secondary categories or equal-rank categories (primary categories could be flagged in a new CatLinks column).
The primary/secondary model could have next-previous links in Detailed pages. The other model would not, as it would make no sense anyway.
Links copied from a primary category should be editable only by an editor with privileges in the primary category -- and if deleted, would be deleted from the secondary categories also.
Links copied from an equal-rank category should be editable by any editor of the categories (right now, they can't be edited at all), as the model is by nature collaborative.

That would be a perfect solution!

Especially to work in with the "upcoming" shopping cart they're also developing.

Will drop them a note with reference to this thread.

Cheers,
Regan.

I really don't know what happened to my last reply - it is nothing like the reply I actually wrote, most of the message didn't appear. I'll try and have another go at replying!

I don't think that this problem has an easy solution. This is my very messy attempt to try and explain the problem:

Consider if you have only 2 categories: 'fruits' and 'vegetables'.

In fruits you have 3 links: apples, tomatoes and oranges.

In vegetables you have 2 links: tomatoes and carrots - the 'main' category for tomatoes is vegetables.

Then if you start from the detail page for apples, the 'next' link will take you to the detail page for tomatoes which will then take you to carrots (because the main category for tomatoes is different from that of apples).

The only way that I can see of getting round this is to use dynamic detail pages and pass in the category that you want to scroll through as an extra variable.

Hope this makes sense.

Laura.


Edit: Having reread the rest of this thread again I'm not sure that this helps - perhaps the example above is what you want to happen? Anyway, its helped me to think about how to get it working on my site!
The UK High Street