fossasia/WPFAevent

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

Description The calendar checks are currently implemented as a standalone PHP script and executed through a dedicated GitHub Actions workflow. They should be integrated into the existing PHPUnit unit test suite instead. Tasks Delete .github/workflows/calendar-test.yml and remove the dedicated calendar-test workflow. Move tests/calendar-test.php into tests/unit/. Convert the standalone assertions into proper PHPUnit test methods and extend WP_UnitTestCase as appropriate. Rename the test file/class according to the naming conventions documented in tests/README.md. Ensure the calendar tests are discovered and executed by the existing composer test / PHPUnit test suite. Remove standalone CLI-specific test scaffolding and assertions where they are no longer needed because the WordPress PHPUnit environment provides the required functionality. Keep coverage for calendar ICS generation, Google Calendar URL generation, timezone formatting, timed/all-day events, and invalid/missing event

Description Currently, newly created templates do not include a footer section. We already have a reusable footer component located at public/partials/footer.php. We need to integrate this partial into the template rendering logic so that whenever a user creates or views a template, both the header and the footer appear automatically. This will unify the layout and significantly improve the overall User Experience (UX). Expected Behavior When a template is rendered, the partials/footer.php file should be included at the bottom of the page. The layout should be consistent with how headers are currently implemented. Technical Tasks Locate the main template rendering view/controller. Include the partials/footer.php file at the end of the template layout. Verify that the footer renders correctly without breaking existing CSS/layouts. Ensure the footer displays properly across different user-created templates. Additional Context The footer partial is already built and located in th

Description While investigating a recent commit, it was noted that git diff --check flagged trailing spaces in PHP files that should have been caught automatically by PHP_CodeSniffer (phpcs). Currently, developers have to manually run check commands or rely on Git to catch these spacing issues, which adds friction to the review workflow. We need to investigate why our phpcs configuration is failing to detect trailing whitespaces and fix it to automate this check. Expected Behavior Running phpcs should flag any trailing whitespaces in PHP files and block the build/CI pipeline if they are present. Actual Behavior phpcs passes successfully even when PHP files contain trailing spaces, forcing manual verification via git diff --check. Steps to Resolve Check the phpcs.xml configuration file to see which coding standard is being enforced. Verify if the Generic.Files.LineEndings or Squiz.WhiteSpace.SuperfluousWhitespace sniff is included and properly configured. Ensure that the trailing white

Problem Description Currently, the main admin class inside admin/class-wpfaevent-admin.php handles multiple distinct structural tasks: registering global admin notices, enqueuing styles/scripts, processing settings pages, and managing custom post type (CPT) Meta Boxes (rendering inputs, processing schema arrays, verifying individual nonces, and updating post meta data). As the plugin evolves, bundling all CPT meta box logic directly inside this single file causes visual clutter, introduces code duplication, and scales poorly when introducing new metadata properties. Proposed Solution To maintain high readability and decouple our system architecture, we should extract the Meta Box presentation and data lifecycle routines away from the master admin file. Instead of adding more files to the root admin/ root directory, we should create a dedicated subdirectory inside admin/partials/ specifically for Meta Box handlers. Expected Structural Update Create a new subdirectory: admin/partials/me