-
Suggestion
-
Resolution: Duplicate
-
None
-
None
-
None
Currently, if you change a page name or move it to a new space, any refernences such as [page] or [space:page] or even [alias|page] are renamed, and I haven't tested it deeply, but I think
{include:page}are also renamed.
However, my own
{edit-include:page}is not renamed, so links are often broken. Also, the
{metadata-from:page|key}macros and many many others are not renamed.
Referncing a page is a common activity. I would like a 'weakly-typed' (or even strongly-typed if you want) page refernece parameter for all user macros, which supports page renaming.
Any named user macro parameter that is 'page' or 'pages' or 'target' or 'targets' or 'root' (and perhaps a few other common words) almost exclusively refer to a page (or perhaps a comma or semicolon delimited list of pages.) Therefor this sort of change would be almost certainly backwards compatible in most cases, and would also enforce people using these parameter names carefully in the future macros.
I propose if there is a named parameter of one of the above, the content of the parameter is treated as though it is a page reference, and it is updated when the page name changes. Also, if there is a unamed parameter which corresponds to the name of an existing page, it should also be treated as a page reference.
These references are also not counted in the 'incoming-links', and in most cases it would also be good to have the association between two pages that is made by a macro indexed in the incoming links table.
Thanks,
- duplicates
-
CONFSERVER-3649 Generic link tracking and refactoring support for macros
- Closed
- relates to
-
CONFSERVER-7952 Create a set of useful global macro parameters which macro developers can use without re-inventing
- Closed