Some limit of posts in category

Hi!

Seems I’ve found a bug.
When I save the post order it inserts only 4 rows and doesn’t save the osers to table ‘nr_reorder_post_rel’

Continue searching…
Update soon.

As I see (line ~364), you UPDATE this table and posts that was added AFTER you have sorted once are NOT in this list.

So if I had 4 posts in the category – it just update 4 rows even if you already add a few new posts.

____________________________

Also I saw “savePost_callBack” function, but why you create it?
Seems it should prevent such things… continue for searching.

What would I do:
– remove savepost callback
– admin reorder page: load all posts from selected taxonomy
– on saving: remove all rows for this tax, upload new rows with all posts

Maybe I’m wrong?
Please, reply.

THanks.

I’ve found why it’s not adding to the table (line ~209).
I’ve got non-hierarchical taxonomy. And that’s why it’s not working, even with the line:

add_filter('reorder_post_within_categories_and_tags', '__return__true');

You use it only for outputting on settings page and didn’t use in if statement:
if ($taxonomie->hierarchical == 1 && is_array($orderedSettingOptions) && in_array($taxonomie->name, $orderedSettingOptions)) {

I’ve just comment “$taxonomie->hierarchical == 1” and seems works fine.
Please, reply a few questions:

1) Why you don’t like non-hierarchical, what is the issue with them, maybe just remove this option at all?
2) What do you think about straight scanning of posts on ReOrder page instead of callbacks?

Thanks!

thanks for spotting this issue.

I’ve just comment “$taxonomie->hierarchical == 1” and seems works fine.

can you do a PR on the github repo, or give me the line number where you made the change?

1) Why you don’t like non-hierarchical, what is the issue with them, maybe just remove this option at all?

you would need to ask the original author of this pluign, who abandoned it. I have been maintaining it as it is quite useful. someone requested support for non-hierarchical taxonomies and till now we had not come across this issue. So nothing personal as such.

2) What do you think about straight scanning of posts on ReOrder page instead of callbacks?

no sure what you mean. anyhow, I have it on my bucket list to re-code this plugin and get rid of the custom table in the db, use a WP std approach to solving the manual re-order, while at the same time solving other restrictions of the current solution.

Hi @aurovrata,

As I already wrote – it’s line 209.
Do you mean @aurelien is a real author? Does he read this forum or I need to contact him other way?

My second question is:

The plugin works this way: add callback after post save/delete and add post_id and taxonomy_id’s to external table.

Than when you sort them on ReOrder page it takes all posts from selected category, but we working only with posts that was added to external table. So if you add posts BEFORE plugin install it won’t work.

What I recommend to do and want to rewrite the plugin:
Remove all callbacks and just get all posts on ReOrder page and simply INSERT them ALL to this table. Of course before INSERT you need to DELETE rows from the table WHERE tax_id = current one.

Does this explanation make it cleaner?
Thanks.

As I already wrote – it’s line 209.

indeed, must have missed that.

Do you mean @aurelien is a real author? Does he read this forum or I need to contact him other way?

he is the original author, but has not been seen on the forum for several years now. I also tried to reach him on his professional email without any success.

The plugin works this way: add callback after post save/delete and add post_id and taxonomy_id’s to external table.

the plugin hooks filters and actions, that is correct. That’s how all plugin run in WordPress.

Remove all callbacks and just get all posts on ReOrder page and simply INSERT them ALL to this table.

No, I don’t agree for several reasons,

• hooks are the std way to code plugins in the WordPress framework for the simple reason that they allows multiple plugins to interact and process the same process flow. Unilaterally loading posts into the table using custom sql does not allow other developers the ability to add possible additional functionality in the future.
• writing custom sql is prone to break in the future should WordPress core evolve the underlying structure of the DB. Using WordPress std functions shields your code from such changes as much as possible.
• the re-coding of this plugin should really go in the opposite direction, do away with the custom table and bring everything back into the fold of WP core functionality, for the very reasons highlighted above.

Did you actually read my post on the re-coding thoughts I exchanged with another user of this plugin? I think not. I would appreciate it you did first, before any further discussion.