WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 6 months ago

#37915 assigned enhancement

Customize: allow terms to be created in nav menus

Reported by: celloexpressions Owned by: boonebgorges
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: needs-patch 2nd-opinion
Focuses: Cc:

Description

Follow up to #34923. When setting up initial site structure, in many cases it's as important to be able to create new terms to add to menus as the ability to create posts. For users, the distinction between terms and posts probably isn't immediately clear, so this functionality gap may be confusing.

There are several patches on #34923 that contain the needed framework here, but we need the ability to preview terms before we can add support for terms.

This depends on #37914. Milestoning for 4.7 now for tracking, but we're waiting for that ticket before we can proceed here.

Change History (12)

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 months ago

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


7 months ago

#3 @boonebgorges
7 months ago

  • Keywords 2nd-opinion added

Previously: https://core.trac.wordpress.org/ticket/34923#comment:46

Having thought a bit more about this, I agree with my former self (good job, former self!) that the most feasible strategy for the time being is a "shadow" taxonomy for each affected taxonomy. Very roughly, here's what I'm imagining:

if ( is_customize_preview() || this is customize.php ) {
    $menu_taxonomies = get_taxonomies( array( 'show_in_nav_menus' => true ), 'objects' );
    foreach ( $menu_taxonomies as $menu_tax_name => $menu_tax ) {
        $shadow_tax_name = '_draft_' . $menu_tax_name;

        $shadow_args = (array) $menu_tax;
        $shadow_args['public'] = false;
        $shadow_args['show_ui'] = false;
        $shadow_args['show_in_menu'] = false;
        $shadow_args['show_tagcloud'] = false;
        // etc

        register_taxonomy( $shadow_tax_name, $shadow_args['object_type'], $shadow_args );
    }
}

When customizing, save terms as '_draft_post_tag' etc, and when changes are saved, delete the draft terms and publish them as actual terms.

Does this strategy seem workable and sane to you? (Keeping in mind that "sane" is a relative term in this context.) Of the available options, it seems to me like the one with the smallest footprint and the least likelihood of interfering with (a) future improvements to the taxonomy system, and (b) the various ways in which taxonomy terms are used - and especially queried - in the wild.

#4 @boonebgorges
7 months ago

A very brief follow-up, before I forget: Third-party integration into the term creation/deletion process is likely to be a point of friction here, both in the short and long term. Imagine you have a plugin that does something like this:

add_action( 'create_term', function( $term_id, $tt_id, $taxonomy ) {
    if ( 'foo' === $taxonomy ) {
        do some stuff
    }
}, 10, 3 );

If draft terms are in a "shadow" taxonomy, then they won't be identified properly by this logic. This might cause bugs in some cases. On the other hand, if and when we have a term_status system, so that draft terms are actually created in the proper taxonomy, they *will* be identified as terms by this logic. And this might cause bugs of its own! There's probably no way to solve this without some change in expected behavior for plugins, and whatever we do, we should be sure to create documentation to explain the potential fallout to developers.

#5 @celloexpressions
7 months ago

If we do go with a shadow taxonomy in 4.7, one benefit is that we'll only need to do it for new terms added in menus, which would reduce the volume of drafted terms, at least. However, we'd have to register a _draft_ taxonomy for every show_in_nav_menus taxonomy, which could be a lot of taxonomies. The alternative is to create one draft taxonomy for each and store the actual taxonomy somewhere with each term, but that could also get messy.

It's sounding like we will need some sort of term_status approach eventually, as that will (likely?) create less breakage than using shadow taxonomies for every taxonomy when we scale to allowing any term and its meta to be previewed in the customizer. If we're okay with going that route, we could look at an implementation here for 4.7 and save #37914 for a future release and broader exploration of term_status.

https://github.com/xwp/wp-customize-terms could probably piggyback on the nav menus approach for now, with plugins not being able to hook in as described above.

#6 @boonebgorges
7 months ago

However, we'd have to register a _draft_ taxonomy for every show_in_nav_menus taxonomy, which could be a lot of taxonomies. The alternative is to create one draft taxonomy for each and store the actual taxonomy somewhere with each term, but that could also get messy.

Yes, it could potentially be a fairly large number of taxonomies. But storing everything in a single taxonomy seems problematic: taxonomies act differently from each other in ways that will affect the way the Customizer interacts with them (hierarchical comes to mind), and this will not be easy to model within a single draft taxonomy. And since the shadow taxonomies would only be registered when in the customizer view, it doesn't seem like too big a problem to have a large number of them.

I have been thinking some more about term_status and will leave some additional thoughts in the upcoming days on #37914. I don't know that it's feasible for 4.7, but I do think there's a place in core for it beyond the Customizer, and it's worth fleshing out how that'd work.

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 months ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


6 months ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


6 months ago

#10 @celloexpressions
6 months ago

  • Owner set to boonebgorges
  • Status changed from new to assigned

Assigning for a decision on whether this needs to be punted to a future release.

#11 @boonebgorges
6 months ago

  • Milestone changed from 4.7 to Future Release

Yes, I'm afraid this won't happen for 4.7. More to come after our upcoming meeting.

This ticket was mentioned in Slack in #core by boone. View the logs.


6 months ago

Note: See TracTickets for help on using tickets.