Documentation for macros show wrong names

[radistmorse]

Description

If you go e.g. here https://json.nlohmann.me/api/macros/nlohmann_define_derived_type/ you'll see that all the NLOHMANN_DEFINE_DERIVED_TYPE... macros names in the left column are replaced with NLOHMANN_DEFINE_DERIVED_TYPE_INTRUSIVE. This is also happening to the other NLOHMANN_DEFINE_... macros. Apparently, mkdocs doesn't support several different nav links to the same page.

Reproduction steps

1. open https://json.nlohmann.me/api/macros/nlohmann_define_derived_type/
2. See the wrong nav links

Expected vs. actual results

Expected: correct macros names, Actual: incorrect

Minimal code example

No response

Error messages

No response

Compiler and operating system

Library version

Validation

• The bug also occurs if the latest version from the develop branch is used.
• I can successfully compile and run the unit tests.

[nikhilreddydev]

Hello @radistmorse @nlohmann
I was able to reproduce the issue.
I think mkdocs is using the first label associated with the .md file

For below configuration

We are getting below output

I am trying to understand what should be the potential solution
should we make different sections in same file and use those as links?

Please let me know your thoughts 🙂

[nlohmann]

This seems to be the effect of mkdocs/mkdocs#3428 which was decided not to fix. The workaround (create separate pages and include the original page) is ugly and error-prone.

I found a better way: create a single link with all titles, so instead of

- 'NLOHMANN_JSON_VERSION_MAJOR': api/macros/nlohmann_json_version_major.md
- 'NLOHMANN_JSON_VERSION_MINOR': api/macros/nlohmann_json_version_major.md
- 'NLOHMANN_JSON_VERSION_PATCH': api/macros/nlohmann_json_version_major.md

I can do this

- 'NLOHMANN_JSON_VERSION_MAJOR, NLOHMANN_JSON_VERSION_MINOR, NLOHMANN_JSON_VERSION_PATCH': api/macros/nlohmann_json_version_major.md

which seems to work as expected:

I will fix this as part of #4560 which already touches a lot of documentation...

[nlohmann]

I fixed the issue (found a few other duplicate keys) in #4560 and added a check to the documentation linter such that this issue should never occur again in the future.