techsmurfy

Yes, this is what I understood from our conversation. Perhaps the description is not so well written? I’m not a native English speaker…

No, your english is excellent. Let me rephrase it: we were aiming to let the user choose which way they want their categories to be sorted; by lowest ID or by lowest key ID in the array. In your description, you say “if the post has multiple categories, the plugin will use the category with the lowest ID”. BUT If the user does NOT tick the “Sort Categories” option on the right, then the plugin will NOT use the category with the lowest ID. It will just use the lowest key ID in the array, as it was being done until recently. In order for the description to be true, the user HAS to tick the Sort Categories.

I’m just trying to make sure this is what you wanted, cause I thought that it would be working the other way round; that the plugin would sort categories and pick the one with the lowest ID, UNLESS the user would tick the ‘Sort Categories’ option, where it would pick the first in the array, as previously.

In short, if it stays like this, I’m only suggesting that the part of the description where you say “if the post has multiple categories, the plugin will use the category with the lowest ID” would be moved under the ‘Sort Categories’ option to make more sense.

Kudos, from Greece 🙂

Hello @aldolat

I’m terribly sorry for being late to reply/debug, I was so busy this week I could not lift a finger :/

I’m testing your update right now. It seems to me that end results are inverted? As soon as I tick the new “Sort categories” option, I get posts with the lowest ID, if I leave it default (unticked), I get posts with the lowest key ID in the array. If that was indeed the intention, and not the other way around, then the description probably confused me.

But despite this little confusion, bottom line is that it works! Did I ever tell you how awesome you are?

This is just great 🙂

It works, as far as I know. Indeed, now wordpress main category concurs with PiS displayed category!

But, hold on a sec 🙂
I do believe that your former way of how PiS gets the categories is wiser (albeit, more difficult for users to understand). Why? Because it’s easier for a user to change it, using a plugin.

Indeed, categories are (were) displayed alphabetically, which means, in your example, that PiS will use Category A as its main category (despite what WordPress does). BUT, with any plugin that changes the display order, I can easily set Category B to display first with a simple drag & drop. And PiS sees that and picks Category B now (while WordPress still picks the same cat).
note: of course, that applies for all posts, and all locations where a categories list is displayed, unfortunately; you can’t do that on a per post basis
This means that with your former way, the user has, at least, the option, if he chooses to, to change the display order of categories, unlike the latter way, where I am not familiar with any way to change a category’s ID without screwing everything up (of course you can manually move all posts to another category, but that’s another story).

All in all,
lowest key ID in the array
Pros: more flexibility
Cons: may confuse users, may differentiate from what wordpress does

lowest ID
Pros: concurs with wordpress, easier to understand
Cons: users can’t mess with category prioritization at all (not in any automatic way at least)

Which is why, in my previous post, I suggested to add an (advanced) option for a user to choose the way that PiS selects the post’s main category. If I had to choose one of the two for a default, yeah, probably the lowest ID would be my choice so not to confuse users, but an extra array sorting option would be a welcome addition.

• This reply was modified 9 years, 1 month ago by techsmurfy.

(To clarify; by reading the description above, I misunderstood that the function, except for the main category, would ignore all the current post’s characteristics, NOT the widget’s filled-in parameters for the query. Hence my confusion when it happened.)

As a follow up, I have to confirm that the issue doesn’t seem to be coming from another plugin. I deactivated all plugins, even switched theme to default, and I’m still getting the same warning. Which is weird, cause as I said, I can swear it was working at some point :/

Yes, you’re right, there is an ‘unable to symlink’ warning on top of my queries… :/

I’m on shared hosting, running Linux. I don’t think there’s anything unusual, but I am using over 20 plugins. Maybe one of them does use db.php? I thought it’d be Fastest Cache, but no, I deactivated it and still getting the same error.

If I find the cause I’ll let you know. If I don’t… well, could this have to do with server configuration?