docs(developer): a page for the browser variables, and links from where they are used
browser_info and browser_url_vars were only described inside the troubleshooting page, under Support Diagnostics. That is the right place to find them if you already know they exist and are looking for a log line; it is not where anyone looks when writing a hook, which is what they are mostly for. The new Developer Guide page carries the whole subject: which services receive the two tables, the column lists, the debug values per platform and the MPEINIT log lines, reading them from a hook with the exist() guard, and the reminder that they are client-supplied and so diagnostics rather than a security boundary. Troubleshooting keeps three stub headings - browser_info, browser_url_vars, reading-them-from-a-hook - pointing at the page, so the anchors that are already published keep resolving, and the detail is not maintained twice. Linked from the three places a hook author actually starts: the HOOK Scripts section of the MPE_TABLES page, the pre-edit hook guide (where the editor's inputs are listed), the two-rule-sets guide (post-edit hook), and the VA embed page, where embed=va is exactly the kind of thing a hook wants to branch on.
This commit is contained in:
1 parent
f08c2dff0e
commit
c7626b2797
7 files changed
+126
-83
No files matched your search
@@ -53,6 +53,8 @@ In the VA Report Designer, add a **Data-Driven Content** object and set the URL
|
||||
|
||||
## Debugging
|
||||
|
||||
A hook script can tell an embedded editor from a standalone one without any client-side inspection: `work.browser_info` carries the page URL and `referrer`, and `work.browser_url_vars` carries `embed=va`. See [Browser Variables](/developer-guide/browser-variables/).
|
||||
|
||||
The following snippet can be used in console to dump the values being provided to DC from VA:
|
||||
|
||||
```
|
||||
|
||||
Reference in new issue
Block a user