not working even if there is one and only one 004777.md, albeit in one of the sub-directories, if not directly in the current directory.
The previous and current shorthand ref functionality is the same… it has nothing to do with page context. It links to the file with that name wherever it is in the content tree. The new ambiguity detection is consistent with that: it will refuse to resolve a ref if there is a duplicate anywhere in the content tree.
If you want to link to the match within the branch of the tree you are in, you can use a relative path (or an absolute path if you prefer)
I read, and I would have thought that that should work because the second GetPage is from the context of /post page object. So why should the same named file in the parallel /quote subdir cause ambiguity?
I understand that part. Leaving ref and relref shortcodes aside, I am curious why the second GetPage method in the first post would give that ambiguity error.
That behavior never existed, and would require actual search, or more complicated indexing logic. I’m not sure @bep is down for that. That’s between you guys and him. I’ve been told my pull requests are no longer welcome.
I wouldn’t compare those shortcodes with the Page version GetPage. The shortcodes are analogous to .Site.GetPage i.e. the “search” happens from the .Site context.
On the other hand the .GetPage on the /post Page object in that first example should “look” only in the context of that object. It should not complain about ambiguity if a same named file is in a Page context outside the current one.
Based on the PR I was following, it was just the expected delay as your PR was thorough and extensive, changed a lot of code and tests and the response to the PR looked positive (ref).
So unless that conversation about not accepting your PRs happened between you guys in private, I have no idea where that came from.
Leaving those politics aside, I’m just saying that doesn’t look quite right about that current Page version GetPage behavior.
Not true. Dude, I know the code. As I keep saying, the refs are interpreted identically for all methods, ref, relref, Site.GetPage and Page.GetPage, with the one exception that Site.GetPage does not support page-relative paths simply because it has no page context. ref and relref do have an implicit Page context.
On the other hand the .GetPage on the /post Page object in that first example should “look” only in the context of that object. It should not complain about ambiguity if a same named file is in a Page context outside the current one.
You’re asking for additional functionality, not a restoration of functionality that ever existed. The point of Page context in my changes was to support relative paths, not relative search. But sure, your idea would be consistent. Like I said, that’s between you and @bep.
But if Page’s .GetPage has the context, why is it looking out that context? As you say, it would be consistent for that to not give that false ambiguity error even if that’s counted as a “feature request”.
oh well, at the very least, I can work on making the docs reflect what the code is doing.
Internally they use the same code. Got ahead and try it.