fossasia/WPFAevent

Follow-up to #328 (fixes #325). Task: document the WordPress version dependency The fullscreen editor fix in admin/css/wpfaevent-admin.css targets block-editor internal class names: .edit-post-meta-boxes-main .edit-post-meta-boxes-main__liner .interface-interface-skeleton__content These are not a stable WordPress API and have been renamed in past releases. If they change again, the fullscreen bug from #325 will silently return. Extend the existing comment above these rules to say they were verified against WordPress 7.1, and link back to #325 so the reason for the rules is easy to trace. Acceptance criteria CSS comment mentions the WP version the selectors were verified on and references #325 No change in behaviour: fullscreen editor still works on the Event edit screen (Venue / Transportation / Hotel information) and the Speaker edit screen (Biography) Optional, not required for this issue Each rule is currently written once for .post-type-wpfa_event and once for .post-type-wpfa_s

Bug Description Event Name: Visiting /speakers/?event=ev-6b901f56 The event name is not displayed in the hero, other events appear in the filter bar but the active event name is not visible Social Link Hover on Profile: On individual speaker profiles, hovering over social media links (Twitter, LinkedIn, etc.) turns the text white on a white/transparent background, making it invisible. Steps to Reproduce Issue 1: Open /speakers/?event=ev-6b901f56. See that the event title is missing from the hero and no speakers load. Issue 2: Open any individual speaker page. Hover over the Twitter or LinkedIn button. See that the text disappears on hover. Expected Behavior /speakers/?event=<slug> should resolve the event, show the event name Speaker social links should retain high-contrast, legible text on hover. Actual Behavior Event name is not visible on/speakers/?event=.... Speaker social link text becomes invisible on hover. Screencast: Screencast.from.2026-09-20.06-

Bug Description When updating an event's Description or Hero Lead Text via the frontend Edit Event modal on /events/, the modal form saves successfully. However, when visiting the event's main single page, the updated Hero Lead Text and Description are not displayed. This happens because the AJAX handler saves these values to post_excerpt and the post meta key wpfa_event_lead_text, but the single event template controller only checks post_content and an incompatible meta key _event_lead_text (with an underscore prefix). Steps to Reproduce Log in to WordPress as an administrator. Go to the events listing page at /events/. Click the Edit Details button on any event card to open the Edit Event modal. Modify the text in the Description field and the Hero Lead Text field. Click Save Changes (modal confirms the update and closes). Open the event's main single page (permalink). Notice the hero section and about section still show the old text instead of the newly saved text. Expected Beha

Description: When clicking the Edit Details button on an event card at /events/, the Edit Event modal dialog overflows the browser viewport vertically. Because the modal has a long form containing over 12 fields but lacks a max-height constraint and internal scrolling, flexbox vertical centering causes the modal to stretch off-screen in both directions. The modal header is cut off behind the top edge/admin bar. Additionally, the scrollbar for the modal's internal content (the div that is roughly 25% of the page width) is not positioned alongside that div. Instead, it appears on the far right side of the screen, detached from the modal container it controls. Steps to Reproduce Log in to WordPress as an administrator. Navigate to the events listing page at /events/. Locate any event card and click the Edit Details button. Observe the Edit Event popup modal that appears on screen. Expected Behavior The modal dialog should fit comfortably within the browser viewport with reasonable m

Description The PR title lint workflow in .github/workflows/lint-pr-title.yml is not working as expected. The workflow previously mentioned the contributor in a PR comment when the PR title failed the Conventional Commits validation. Currently, the GitHub Actions logs correctly show the PR title linting error, but the expected contributor comment is not being posted. An invalid PR title also results in a ❌ status at the end of the PR. The workflow uses amannn/action-semantic-pull-request@v6 for validation and marocchino/sticky-pull-request-comment@v3 for the PR comment. Expected Behavior Detect an invalid PR title. Comment on the PR mentioning the contributor with the linting error. Provide an example of the correct Conventional Commits format. Remove the warning comment once the title is fixed. Task Investigate why the contributor comment is no longer being posted and fix the workflow so that the PR title linting and notification work as intended. Reference file https://github.co