Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.8, 0.9
-
None
Description
With the introduction of the locationmap it can be unclear which sitemap pipeline is handling a request. Prior to the locationmap, exceptions would tell us where in the sitemap we were working. However, this can sometimes get lost in the interaction with the locationmap.
This makes it very difficult to debug some locationmap problems. For example, I recently had a situation in which the locationmap was being queried for "project.foo". In this hint the "project." part was being added by the sitemaps, but the error reported was not showing where. I knew this meant some match was intercepting the request before my plugin sitemap got hold of it, but the error messages would not tell me which. I had to trace the process manually, which took an age. In the end it was a catchall match in the raw.xmap
If the LM logs could report where the request is coming from, I would have known in seconds what the problem was, rather than hours. We need a log entry something like:
"Examining Locationmap for "project.foo" on behald of /raw.xmap (line XYZ)"
This makes it very difficult to debug some locationmap problems. For example, I recently had a situation in which the locationmap was being queried for "project.foo". In this hint the "project." part was being added by the sitemaps, but the error reported was not showing where. I knew this meant some match was intercepting the request before my plugin sitemap got hold of it, but the error messages would not tell me which. I had to trace the process manually, which took an age. In the end it was a catchall match in the raw.xmap
If the LM logs could report where the request is coming from, I would have known in seconds what the problem was, rather than hours. We need a log entry something like:
"Examining Locationmap for "project.foo" on behald of /raw.xmap (line XYZ)"