Thank you for your interest in contributing to BinktermPHP! This document provides guidelines and instructions for contributing to the project.
- Getting Started
- Development Setup
- Code Conventions
- Making Changes
- Database Migrations
- Version Management
- Testing
- Submitting Changes
- Changelog Updates
If you're considering getting involved, check out HELP_WANTED.md for an overview of the areas where contribution would have the most impact — from FTN protocol work and DOS door integration to WebDoors game development and UI themes.
BinktermPHP is a modern web interface and mailer tool for FidoNet message packets using the binkp protocol. Before contributing, please familiarize yourself with:
- FidoNet Technology Network (FTN) basics
- The binkp protocol
- PHP development best practices
- PostgreSQL database operations
- PHP 8.2 or higher
- PostgreSQL database
- Composer for dependency management
- Git for version control
-
Clone the repository:
git clone https://github.com/awehttam/binkterm-php.git cd binkterm-php -
Install dependencies:
composer install
-
Set up your database and configuration files
-
Create a feature branch:
git checkout -b feature/your-feature-name
Important: Never push directly to the main branch. All changes must go through pull requests for review.
- Variables and functions: camelCase (e.g.,
$userName,getUserData()) - Classes and components: PascalCase (e.g.,
MessageHandler,BinkpConfig) - Constants: UPPER_SNAKE_CASE (e.g.,
MAX_CONNECTIONS)
- Use 4 spaces for indentation (no tabs)
- Be consistent with existing code formatting
src/- Main source codetemplates/- Twig HTML templatespublic_html/- Web site files and static assetstests/- Test and debugging scriptsconfig/- Configuration filesschema/- Database migration scriptsvendor/- Third-party libraries (managed by Composer, do not modify)
- Never modify the vendor directory - it's managed by Composer
- Use AJAX requests for web interface queries
- Keep feature parity between netmail and echomail when appropriate
- Write secure code - avoid SQL injection, XSS, command injection, and other OWASP Top 10 vulnerabilities
- Check existing issues and pull requests to avoid duplicate work
- For new features, consider opening an issue first to discuss the approach
- Understand the existing architecture and patterns in the codebase
- Follow the existing code style and conventions
- Write clear, self-documenting code with meaningful variable names
- Add comments only where the logic isn't self-evident
- Keep functions focused and reasonably sized
- Avoid premature optimization - prioritize clarity
Always validate and sanitize:
- User input
- External API data
- Database queries (use prepared statements)
- File paths and operations
Never:
- Trust user input without validation
- Expose sensitive configuration data
- Use dynamic SQL queries without parameterization
- Store passwords in plain text
All database schema changes must be done through migration scripts:
-
Create a new migration file in
schema/following the naming convention:v<VERSION>_<description>.sqlExample:
v1.5.0_add_user_preferences.sql -
Write idempotent migrations when possible (safe to run multiple times)
-
Test migrations on a clean database to ensure they work from scratch
-
Version Bump Required: When changing the database version through a migration, you must update:
src/Version.php- Update the VERSION constantcomposer.json- Update the version field
- Use transactions where appropriate
- Include rollback procedures in comments
- Test with realistic data volumes
- Document any manual steps required
BinktermPHP uses semantic versioning (MAJOR.MINOR.PATCH):
- MAJOR: Breaking changes
- MINOR: New features, backwards compatible
- PATCH: Bug fixes, backwards compatible
When releasing a new version:
-
Update
src/Version.php:private const VERSION = '1.4.3';
-
Update
composer.json:"version": "1.4.3"
-
Commit and tag:
git add src/Version.php composer.json git commit -m "Bump version to 1.4.3" git tag -a v1.4.3 -m "Release version 1.4.3"
Note: Contributors typically don't need to worry about version bumps - maintainers handle this during release preparation.
- Test your changes in a development environment
- Verify both success and error cases
- Test edge cases and boundary conditions
- Check for regressions in existing functionality
Use the scripts in the tests/ directory for debugging and troubleshooting:
- Test message handling
- Verify packet processing
- Validate kludge line generation
- Check address parsing
- Netmail: Message composition, replies, addressing
- Echomail: Area subscriptions, message posting, threading
- Binkp: Connection handling, polling, packet transfer
- Web Interface: Form submissions, AJAX requests, user interactions
- Character Encoding: CP437 and UTF-8 handling
- Date Parsing: FidoNet timestamp formats
Write clear, descriptive commit messages:
Fix parameter order in system config save handler
Corrected the parameter mapping in BinkpController::updateConfig()
to properly align form data with the setSystemConfig() method
signature. Previously, fields were shifted causing address to save
as name, sysop as address, etc.
Format:
- First line: Brief summary (50-72 characters)
- Blank line
- Detailed description if needed
- Reference related issues:
Fixes #123orRelated to #456
Important: All changes must be submitted via pull request. Do not push directly to the main branch.
-
Update your branch with the latest main:
git checkout main git pull git checkout your-feature-branch git rebase main
-
Push your feature branch to the repository:
git push origin your-feature-branch
-
Submit a Pull Request on GitHub:
- Navigate to the repository on GitHub
- Click "Pull requests" → "New pull request"
- Select your feature branch
- Use a clear, descriptive title
- Describe what changes you made and why
- Reference any related issues (e.g., "Fixes #123")
- Include screenshots for UI changes
- List any breaking changes
-
Wait for review:
- Maintainers will review your pull request
- Be open to suggestions and constructive criticism
- Make requested changes in new commits
- Push updates to your feature branch (they'll appear in the PR automatically)
-
After approval:
- Maintainers will merge your PR into main
- You can then delete your feature branch
Before submitting, ensure:
- Code follows project conventions
- No sensitive data or credentials committed
- Changes tested locally
- Documentation updated if needed
- Database migrations created if schema changed
- Changelog updated for significant changes
- No new security vulnerabilities introduced
- Code is properly formatted and commented
- Open an issue for bugs or feature requests
- Join discussions in existing issues
- Check the project wiki for additional documentation
- Review existing code for examples and patterns
- Be respectful and constructive
- Welcome newcomers and help them learn
- Focus on what's best for the project
- Accept constructive criticism gracefully
By contributing to BinktermPHP, you agree that your contributions will be licensed under the same license as the project.
Thank you for contributing to BinktermPHP! Your efforts help keep FidoNet alive and thriving in the modern era.