multisyde/CONTRIBUTING.md at main · inpsyde/multisyde · GitHub
Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
138 lines (98 loc) · 5.17 KB

CONTRIBUTING.md

File metadata and controls

138 lines (98 loc) · 5.17 KB
Raw

Contributing to MultiSyde

Thanks for your interest in contributing to MultiSyde!

This plugin explores improvements for the WordPress Multisite experience, especially around usability, visibility, and admin workflows. Whether you're here to fix a bug, suggest an enhancement, or build something new — you're welcome!

Table of Contents

Getting Started

Before contributing, it's a good idea to familiarize yourself with:

  • How WordPress Multisite works.
  • The purpose of each feature module in the plugin.

You can explore the plugin’s features in the modules/ directory or by visiting the Feature Overview.

Development Setup

We recommend using the WordPress Environment for local development.

Quick Start

git clone git@github.com:inpsyde/multisyde.git
cd multisyde
composer install
npm install -g @wordpress/env
wp-env start

Your environment will be available at http://localhost:8888
(Default credentials: Username: admin, Password: password)

Database credentials:

  • User: root
  • Password: password

Code Standards

composer run cs
composer run phpstan

Creating a Pull Request

  1. Fork the repository on GitHub.
  2. Create a new branch: 
    git checkout -b feature/my-contribution
  3. Make your changes and commit them with meaningful messages.
  4. Run code quality tools before submitting: 
    composer run qa
  5. Push your branch and open a pull request against the dev/main branch. The main branch is generated by CI from dev/main and must not be targeted or edited directly.

Please include in your PR:

  • A clear description of what your change does
  • Links to related issues or Trac tickets (if any)
  • Screenshots or screencasts for UI-related features
  • Notes on testing or impacts to existing functionality

Feature Structure

Example - LastUserLogin

Each feature is placed in its own directory under modules/ and follows a clear, modular structure to ensure ease of development, maintenance, and testing. Using LastUserLogin as an example:

1. Feature Class (Feature.php)

The Feature class:

  • Implements the LoadableFeature interface.
  • Hooks into WordPress' Network Admin screens (manage_users-network_columns, wp_login, etc.).
  • Defines constants (COLUMN_KEY, META_KEY) that uniquely identify the feature's logic and storage.
  • Handles:
    • Display of the custom column.
    • Recording login time via wp_login action.
    • Sortability by login date in the user table.
    • Conditional rendering based on user permissions.

2. Module README (README.md)

The module includes a dedicated README.md file that:

  • Describes the purpose and functionality of the feature.
  • Outlines how it works and key implementation details.
  • Includes screenshots and practical use cases.
  • Credits the original developer, if applicable.

3. Optional Metadata Files

Additional files may be included:

  • About.php: Provides metadata for the presenter or integration with feature discovery.
  • CHANGELOG.md: Documents changes specific to the feature across versions.

Reporting Issues

If you run into bugs or want to suggest an improvement:

  • Open a GitHub issue
  • Clearly describe what’s happening and what you expected
  • Include any error messages, reproduction steps, or environment details

Code of Conduct

We follow the WordPress Community Code of Conduct. Be respectful and inclusive in all your interactions.

Releasing

Releases are built and published by the Release workflow. Nothing is published by pushing a tag.

  1. On dev/main, bump Version: in multisyde.php, plus Stable tag and the changelog in readme.txt, and merge.
  2. Run Release from dev/main with that version as VERSION. DRY_RUN is on by default: the run builds main, runs Plugin Check on the built package, tags it, and uploads the would-be SVN trunk as an artifact without committing to WordPress.org. Review it, then run Release again with DRY_RUN off to publish. The GitHub release is created only by that publishing run.

A failing Plugin Check on the built package stops the release before anything is tagged. VERSION must be MAJOR.MINOR.PATCH. Every run, including a dry run, tags the built main with VERSION. A later run reuses that tag only while dev/main is unchanged; otherwise delete the tag first.

Thanks for helping improve MultiSyde! ❤️ — The Syde Team