Contributing

Ettic plugins are GPL-licensed and built in the open. Bug reports, well-scoped feature ideas, and clean pull requests are all welcome.

Reporting issues

Bug reports

Open an issue on the relevant plugin repository:

• MagicAuth: github.com/nolderoos/magicauth/issues
• OpenTrust: github.com/nolderoos/opentrust/issues

Useful bug reports include:

• Plugin version, WordPress version, PHP version.
• Active theme and any other plugins that might interact (auth plugins, caching, security plugins).
• Steps to reproduce, expected behaviour, actual behaviour.
• Any relevant log output, screenshots, or browser console errors.

Feature requests

Open an issue and tag it as a feature request, or start a GitHub Discussion if you'd like to talk through the shape first. Be concrete about the problem you're trying to solve, not just the implementation you have in mind. Small, self-contained features land faster than large reworks.

Documentation issues

Typos, inaccuracies, and gaps in these docs go to github.com/nolderoos/ettic-docs/issues. PRs are welcome too.

Pull requests

Before you start

For anything beyond a small fix, open an issue first so we can sanity-check direction. It's much easier to align on approach before code than to ask for a rewrite at review time.

Fork and branch

1. Fork the plugin repository.
2. Create a topic branch from main: feat/short-description or fix/short-description.
3. Keep the change focused. One concern per PR.

Coding standards

PHP code follows the WordPress Coding Standards (WPCS). The plugin repos ship with PHPCS configuration, so:

composer install
composer run lint        # phpcs against WPCS
composer run lint:fix    # phpcbf auto-fix what it can

JavaScript and CSS follow the conventions already in the file you're editing. We don't ship a JS bundler in either plugin, so keep dependencies minimal and avoid build-step regressions.

Tests

PHP changes that touch logic should ship with a PHPUnit test:

composer install
composer run test

UI tweaks don't need automated tests but do need a manual smoke run. Note in the PR description what you tested (WP version, PHP version, browser).

Commit messages

• Short imperative subject (under ~70 chars), like Fix throttle reset under sustained burst.
• Body explains the why, not just the what.
• One logical change per commit when reasonable. Squash trivial fixups before opening the PR.

What we look for in review

• A clear description of the problem and the fix.
• No unrelated drive-by refactors.
• No new dependencies without justification. We keep the dependency surface tight on purpose.
• Backwards-compatible defaults. If the change alters behaviour for existing installs, call it out and gate it behind a filter or option where possible.
• Security-sensitive code paths (authentication, capability checks, output escaping, SQL, file handling, REST routes) get extra scrutiny.

Translations

We're happy to merge .po / .pot updates and new locale files in languages/. Once a plugin lands on the WordPress.org plugin directory, translation will move to translate.wordpress.org and contributions there are the canonical path.

Licensing

Ettic plugins are licensed GPL-2.0-or-later. By submitting a pull request, you agree your contribution is offered under the same licence and that you have the right to submit it.

We don't require a CLA.