Bring menu item/reference selection into core and make a new Reference selector widget

Package targeted

Both

Description

I was hoping to implement this as a PR immediately, but it's become a little bigger than I had imagined so I think it's best we scope this out.

Currently, this Menu Item selector/editor is only available when the Pages plugin is installed:

However, I feel (and I seem to recall the other maintainers feeling the same) that this is a well useful tool that could be used in other areas, and as such should be brought into core. Ideally, I'd like to create a new FormWidget called "Reference" which brings up a (simplified) version of this selector and calls for all plugin references (the pages.menuitem.* events), allowing the user to select a reference for cross-linking, or providing an ability for a field to contain either a straight URL or a dynamic reference to a plugin item. This would make it similar to Wordpress' link picker:

Storage

There's two ways we could store these references:

• As a JSON or serialized object. Seems a bit "unclean" in my opinion, but would be much easier. Should be stored as an object to allow for URL changes on the target references. The object would need to be decoded/unserialized prior to use - for forms/models, we could do this automatically. For Twig, it might need a filter like we have for media items.
• Alternatively, we could store it as an "attachment" relation. Would require a database call to get the relations however, and Halcyon has no relation capability yet, so would require us to add - at a minimum - attach relation capabilities to Halcyon. Doing this would pave the way to allow us to eliminate another issue: people being unable to use fileupload widgets with Halcyon objects.

Reference FormWidget

The Reference form widget should, at a minimum, provide the following fields from the menu item editor above:

• Type
• Reference
• Allow nested items?
• Replace with children?

It should return a class representing the reference: ideally, this class should be able to determine if there's multiple references or not, and return URLs for each.

It may be prudent to allow the form widget to be configured to accept only one reference (therefore not allowing nested items), or accept multiple.

Other places to implement this

The same picker should be made available for the Rich Editor and Markdown Editor's link buttons. Currently, I believe, these both allow you to just pick a CMS page.

Will this change be backwards-compatible?

Yes, backwards compatibility would be maintained.

Ideally, we'll need to use new event names, but call the old event names for compatibility and merge the results. I propose the following:

• references.getTypes (replaces pages.menuitem.listTypes, gets the available reference types for the "Type" dropdown)
• references.getReferences (replaces pages.menuitem.getTypeInfo, gets the available references for a particular type)
• references.resolve (replaces pages.menuitem.resolveItem, resolves a reference object)

Start by tracing the existing Pages menu-item selector and the pages.menuitem.* events, then review how the proposed references.* events would preserve compatibility. The work is complete when a core Reference form widget supports the listed fields and reference resolution, with the same picker available to the Rich Editor and Markdown Editor link buttons.