The navmenu disappears for cats and tags, isn't UAM concerned

Could you login as admin and see if then everything is there? If yes it’s related to some permission issue.

Hi,

Thanks

Yes I have done this checks, with my admin login.
It is not a permissions problem due to user group permissions.
I think that it is linked to the type of display which is filtered somewhere for all users : Archive, category, tag, author etc…

In this case and the nav-menu templates doesn’t run for category and tags links.

I have three ways in solving problem :

1- May be a plugin, but which one. : So I am looking for plugins which can generate these locks : “somebody had this issue because of parameters of…”

2- Another solution is to inactivate these (all) plugins, I am annoyed to have to do so, because they manage some accesses and I don’t want to set all the site opened to anybody. But I can do so if I maintain UAM (explanation in note) to hide everything to anybody else than admin or author.

3- Try to find in all code where treatments are done on these type of data, for now I found nothing.

I am going to try solution 2.

Best regards

Trebly
_________________________________________________________________
Note about the way I uses UAM :
It solved a problem for which I had posted into the general support forum.
The status of post makes that it is impossible with WP to test the navigation by the use of category and keyword when articles are not published.
So I have defined a group with UAM which hides the posts (most of them during site test) to anybody else than author and admin.
When I will unset these group for a post it becomes published and accessible to anybody.

Hi,

Bug is found.

All need work may be one hundred hours.

The question is tricky.

Nowhere it is (or as been) said that we can find into the last step of the query building the code : in (WP_Query::get_posts)
do_action_ref_array( 'pre_get_posts', array( &$this ) );
which allows any plugin to change the whole query parameters.

The plugin “Add Tags And Category To Page and Post Types” destroys the query for menu when the display of posts is based on category or tag selection (reported into plugin support)

The plugin replace into the query parameters of a menu :

["post_type"]=>  string(13) "nav_menu_item"
by
  ["post_type"]=>
  array(3) {
    [0]=>
    string(4) "page"
    [1]=>
    string(4) "w4pl"
    [2]=>
    string(4) "post"
  }

which leads to no item selected and no menu display.

Because I had simultaneously three crossed bugs, I missed the test of un-activation of any plugins for the anomaly (not already searched as bug).

So, it is after a detailed check of the code (one hundred hours without any other help than Codex) that I discovered the instruction into WP_Query::get_posts
[code]do_action_ref_array( 'pre_get_posts', array( &$this ) );[/code]
which allows any plugin to change anything into the parameters of the request without any control.
The I checked plugins code systematically and found the solution.

Best regards

Trebly

Note about solving process :

– the “get_posts” with three types and purpose with same name is in fact a “get_WP_object” then this is tricky for anybody.

– Farther the search is not immediate because do_action can execute a filter (it is normal but not immediate) the I had searched for “regex:/add_action.*?pre_get_posts/” and found nothing wrong.

– Nobody could tell me that the query can had any external alteration with
[code]do_action_ref_array( 'pre_get_posts', array( &$this ) );[/code]

This lead me, thinking that there were no direct relation with a plugin to go step by step, following data from
1- nav_men_template
2- nav_menu
3 -post – gest_posts
4- WP_Query :: get-posts()

I finally found the instruction which was breaking the menu query process.

I don’t mark myself as resolved because this is an example of difficulties met to find some types of bugs linked with plugins (90 for me), and the question can, at second level of process solving, generate some thoughts or actions

This thread was misplaced accidentally, I should be moved (if possible) to “general debugging”