Calendar: Evolve post overlay into a Quick Edit modal for enhanced inline editing

[GaryJones]

Summary

This issue proposes transforming the calendar's current post overlay (small popup positioned near the calendar cell) into a proper centered modal dialog. This would enable more comprehensive inline editing capabilities, including proper support for hierarchical taxonomies, while solving the performance and usability issues documented in #756.

Background

Issue #756 identified that the current "editable fields" system has significant problems:

1. Hierarchical taxonomies don't work properly: The wp_dropdown_categories() single-select dropdown can't represent multiple categories, and would silently remove all but one if it saved successfully
2. Performance issues: Loading the full category tree for every post on the calendar causes page bloat
3. Limited space: The current overlay (250-350px wide, positioned absolutely near the cell) constrains what can be displayed

PR #757 addressed this by making hierarchical taxonomies non-editable, which is the right immediate fix. However, there's an opportunity to solve this more comprehensively.

The Proposal: Modal Quick Edit

Replace the current small overlay with a centered modal dialog that:

• Uses a backdrop overlay (blurred/dimmed background) following standard modal UX patterns
• Has adequate space for multiple editable fields including hierarchical taxonomy checkboxes
• Loads content via AJAX to avoid upfront performance cost
• Follows WordPress patterns using @wordpress/components Modal (already a dependency)

This would create a "Quick Edit" experience similar to the Posts list table, but tailored for the calendar context.

Current State

┌──────────────────────────────────────────────────┐
│  Calendar                                        │
│  ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┐    │
│  │ Mon │ Tue │ Wed │ Thu │ Fri │ Sat │ Sun │    │
│  ├─────┼─────┼─────┼─────┼─────┼─────┼─────┤    │
│  │     │ ┌──────────────┐                  │    │
│  │     │ │ Post Title   │ ← Small overlay  │    │
│  │     │ │ Author: Joe  │   (250-350px)    │    │
│  │     │ │ Tags: foo    │   positioned     │    │
│  │     │ │ [Edit|Trash] │   near cell      │    │
│  │     │ └──────────────┘                  │    │
│  └─────┴─────┴─────┴─────┴─────┴─────┴─────┘    │
└──────────────────────────────────────────────────┘

Proposed State

┌──────────────────────────────────────────────────┐
│  Calendar (dimmed/blurred backdrop)              │
│  ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┐    │
│  │▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│    │
│  ├─────┴─────┴──┬──────────────────┬────────┤    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│   Quick Edit     │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│                  │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  Post Title      │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  Author: [▾]     │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  Categories:     │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  ☑ News          │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  ☐ Opinion       │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  ☑ Featured      │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│  Tags: [____]    │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│                  │▒▒▒▒▒▒▒▒│    │
│  │▒▒▒▒▒▒▒▒▒▒▒▒▒▒│ [Save] [Cancel]  │▒▒▒▒▒▒▒▒│    │
│  ├──────────────┴──────────────────┴────────┤    │
│  │▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│▒▒▒▒▒│    │
│  └─────┴─────┴─────┴─────┴─────┴─────┴─────┘    │
└──────────────────────────────────────────────────┘

What This Enables

1. Proper hierarchical taxonomy editing: Room for checkbox trees with indentation, similar to the classic editor category metabox
2. Multiple editable fields simultaneously: Author, status, date, multiple taxonomies visible at once
3. Scrollable regions: Each taxonomy section can scroll independently if needed
4. Familiar UX: Users understand modals - they're used throughout WordPress (media library, block inserter)
5. Performance: AJAX-loaded content means no upfront cost; only load full taxonomy trees when user clicks

Technical Approach

Existing Infrastructure

Edit Flow already has the building blocks:

• React components in modules/calendar/lib/react/
• @wordpress/components (v30.9.0) including Modal component
• @wordpress/data for state management
• AJAX save infrastructure in calendar.js for metadata updates
• wp_terms_checklist() available server-side for hierarchical taxonomies

Implementation Phases

Phase 1: Modal Shell

• Convert existing overlay trigger to open a React Modal component
• Render existing post information inside the modal
• Maintain current Edit/Trash/Preview actions
• No functional changes, just UI restructure

Phase 2: AJAX Content Loading

• Load modal content via AJAX when opened (POST ID → modal HTML)
• Add loading state/spinner
• This solves the performance issue - only fetch taxonomy trees on demand

Phase 3: Hierarchical Taxonomy Editing

• Re-enable hierarchical taxonomies as editable
• Use wp_terms_checklist() to render proper checkbox trees
• Extend AJAX save to handle multiple term IDs
• Add proper capability checks

Phase 4: Enhanced Fields (Optional)

• Consider additional editable fields: author dropdown, publication date, post status
• Evaluate based on user feedback from earlier phases

Considerations

Scope Management

Once a proper modal exists, there will be requests for more fields (custom fields, featured image, excerpt). Need to define boundaries - this is "Quick Edit", not "Full Edit". The Edit button handles complex operations.

Mobile/Tablet UX

Modals work well on desktop but need responsive design. The @wordpress/components Modal supports isFullScreen prop for smaller viewports.

Accessibility

Modals require:

• Focus trapping (Modal component handles this)
• Escape-to-close (Modal component handles this)
• ARIA labels (need to ensure proper implementation)
• Screen reader announcements

The @wordpress/components Modal is designed with accessibility in mind, but we need to ensure proper implementation.

Performance Trade-offs

• Pro: No upfront category tree loading; AJAX loads on demand
• Con: Each modal open requires a round-trip
• Mitigation: Could cache modal content in JS after first load for same post

Relationship to Other Issues

• Calendar: Make hierarchical taxonomies non-editable to solve performance and usability problems #756: This proposal provides a path to properly fix the hierarchical taxonomy editing that Calendar: Make hierarchical taxonomies non-editable to solve performance and usability problems #756 identified as broken
• Calendar: Remove 'taxonomy hierarchical' from editable fields for performance and usability #757: The immediate fix (making hierarchical taxonomies non-editable) should ship first; this is a follow-up enhancement
• Calendar: Object cache not cleared #505: The original caching issue that led to Calendar: Make hierarchical taxonomies non-editable to solve performance and usability problems #756's investigation

Questions for Discussion

1. Should the modal replace the overlay entirely, or should the small overlay remain for "view only" with a "Quick Edit" button opening the modal?
2. What fields should be editable in the initial implementation? Just taxonomies, or also author/status/date?
3. Should we support keyboard navigation between posts (arrow keys to next/prev post while modal is open)?

---

Related: #756, #757, #505
🤖 Generated with Claude Code

[jerclarke]

Wow that's a lot. Seems like a nice feature if it worked properly, though I can't help thinking, is it worth it? Having to duplicate all of "Quick Edit" seems a bit out of scope for a plugin like this, especially a plugin with a history of going unmaintained for months/years.

I'd just rely on switching to the post editor. Yeah it's not the fastest, but it is rock solid and avoids having to account for all kinds of interactions like "what if someone else is editing" and "what happens to our dialog-based editor when core changes the admin".

Maybe I'm biased because I don't use the calendar myself, so the convenience isn't important to me compared to the lack of bugs reported by my users 😅