It would be helpful if you provided information on how exactly this was fixed and what macros need (if anything) to do in order to be enabled.

This is finally implemented, and will soon ship in OnDemand, and in Confluence 5.3.

Some notes about the complexity of this work are recorded here.

I hope that helps with the waiting!

Concur with David. Not understanding the complexity of this; similar apps utilize the internal ID or the tinylink in order to maintain referential integrity and not affected by page names.

A simpler intermediate solution might simply be to allow users to specify a page ID or Tinylink instead of the page name

This is a big issue. One of the major advantages of a wiki is that you can change page names and have links update--the fact that this breaks in so many macros makes it impossible to trust that you can safely change names.

BTW, an additional macro that doesn't update is page-info.

see http://developer.atlassian.com/jira/browse/SUBS-6 (subsection macro)

• some macros, but not all, don't 'refactor' links inside those macros, or show incoming/outgoing links
  • These do:div, panel, lozenge, clickable, section, column, info, tip, warning
  • These don't:sub-section, expand, mail-form,roundrect

• Delegating to macros to 'refactor' themselves seems architecturally more powerful, but if left up to individual macro developers I fear will, in practice, result in most macro developers not implementing refactoring, or implementing it differently. If this approach is taken, please provide simple API calls for the macros to call in order to parse the parameters and do the page edits so bugs in this process can be dealt with en-mass by atlassian rather than by plugin/macro developers. These methods can be overridded for the more complicated cases.

To be clear, some additional very related use cases from CONF-6980

• Refactoring of the edit-include and similar user macros
• {{ {edit-include:test:page}

  }}

  • It doesn't seem to me that user macro developers will be able to respond to a 'reffactor mode' request using velocity script, thus the refactoring must be done on the confluence application side, not the macro side.

• which parameters to refactor, and how to refactor complex parameters need to still be specified for each macro, even for user macros
  • i.e. for the reporting plugin (and others) that use scope and supply chains require special refactoring:
    • {{ {content-reporter:scope=spacekey:pagename > children}

      }}

  • i.e. user macros, such as edit-include early versions, that separate spacekey and spacename, require special refactoring
    • {{ {edit-include:pagename|spacekey}

      }}

Suggested solution:

• create a sophisticated 'refactor event' for macros on page move/rename, which the core plugins and major community and commerical plugins will use
• create a simple interface 'agreement' for the user macros and 'simple plugins', perhaps as follows:
  • support the simple "spacekey:pagename" or "pagename' syntax
  • declare certain parameter names that will be fixed by the external refactoring engine, such as: 'page=' 'pages=' 'root=' 'scope=' 'parent=', and any unamed parameters that contain a single ':' (i.e. spacekey:pagename) and link to a valid existing page , or no : but the name corresponds to a page in the current space.

Nonetheless, what I describe might be the exceptions and even small steps towards what Charles describes above woudl be helpful.

e.g.

breaks when 'A Page' is renamed.