|
| 1 | +# WP-Framework Structure |
| 2 | + |
| 3 | +This document outlines the structure, purpose, and usage of the WP-Framework within a WP Scaffold project. |
| 4 | + |
| 5 | +## Table of Contents |
| 6 | +- [Introduction](#introduction) |
| 7 | +- [Purpose and Benefits](#purpose-and-benefits) |
| 8 | +- [Framework Components](#framework-components) |
| 9 | +- [Versioning](#versioning) |
| 10 | +- [Integration with WP Scaffold](#integration-with-wordpress-scaffold) |
| 11 | +- [Extending the Framework](#extending-the-framework) |
| 12 | +- [Best Practices](#best-practices) |
| 13 | +- [Troubleshooting](#troubleshooting) |
| 14 | + |
| 15 | +## Introduction |
| 16 | + |
| 17 | +WP-Framework is a Composer package that extracts the most reusable parts of the WP Scaffold into a standalone, versioned dependency. Rather than being a component within the scaffold, it serves as the foundation that the scaffold builds upon, providing a centralized home for shared logic that was previously duplicated across projects. |
| 18 | + |
| 19 | +The framework follows modern PHP practices and is designed to work seamlessly with WordPress while providing additional structure and organization that the core WordPress codebase doesn't inherently provide. By moving this shared functionality into a separate package, the scaffold becomes leaner and more maintainable, while ensuring consistency across projects. |
| 20 | + |
| 21 | +## Purpose and Benefits |
| 22 | + |
| 23 | +### Core Purpose |
| 24 | + |
| 25 | +The WP-Framework was created to address specific challenges in maintaining and updating the WP Scaffold: |
| 26 | + |
| 27 | +1. **Centralize Shared Logic**: Provide a single source of truth for functionality that was previously duplicated across projects |
| 28 | +2. **Simplify Maintenance**: Make it easier to maintain and improve shared code without requiring manual updates to multiple projects |
| 29 | +3. **Ensure Consistency**: Standardize approaches to common WordPress development tasks across all projects |
| 30 | +4. **Enable Versioned Updates**: Allow projects to receive improvements through controlled, versioned updates |
| 31 | +5. **Reduce Technical Debt**: Prevent divergence of implementations across different projects over time |
| 32 | + |
| 33 | +### Key Benefits |
| 34 | + |
| 35 | +Using the WP-Framework in your WP Scaffold project offers several advantages: |
| 36 | + |
| 37 | +- **Easier Updates**: Improvements to shared functionality can be rolled out across multiple projects via Composer updates |
| 38 | +- **Reduced Boilerplate**: Common WordPress patterns are abstracted into reusable components |
| 39 | +- **Leaner Scaffold**: The scaffold itself becomes more focused and maintainable |
| 40 | +- **Improved Architecture**: Clear separation of concerns and dependency management |
| 41 | +- **Consistent Structure**: Standardized approach helps team members move between projects more easily |
| 42 | +- **Modular Design**: The 90% foundation that most projects need, while still allowing customization where necessary |
| 43 | +- **Stable Foundation**: Strict semantic versioning ensures updates won't unexpectedly break existing projects |
| 44 | + |
| 45 | +## Framework Components |
| 46 | + |
| 47 | +The WP-Framework extracts the most reusable parts of the WP Scaffold into a centralized package. These components represent the shared functionality that many WordPress projects need: |
| 48 | + |
| 49 | +### Module Loader |
| 50 | + |
| 51 | +The module loader is a core part of the framework that makes it easy to register and configure classes: |
| 52 | + |
| 53 | +- **Class Registration**: Simplified registration of classes with WordPress hooks |
| 54 | +- **Dependency Management**: Handles dependencies between components |
| 55 | +- **Initialization**: Controls the order and timing of component initialization |
| 56 | + |
| 57 | +### Abstract Classes and Base Implementations |
| 58 | + |
| 59 | +The framework provides abstract classes and base implementations for common WordPress patterns: |
| 60 | + |
| 61 | +- **Post Type Registration**: Base classes for creating custom post types |
| 62 | +- **Taxonomy Registration**: Base classes for creating custom taxonomies |
| 63 | +- **Admin Pages**: Base implementations for admin interfaces |
| 64 | +- **Meta Boxes**: Reusable patterns for meta box creation |
| 65 | +- **REST API Endpoints**: Base classes for creating REST API endpoints |
| 66 | +- **Asset Management**: Traits like `GetAssetInfo` for simplified asset handling |
| 67 | + |
| 68 | +## Versioning |
| 69 | + |
| 70 | +The WP-Framework follows strict [Semantic Versioning (SemVer)](https://semver.org/) to ensure stability and backwards compatibility. This strict versioning approach is a cornerstone of the framework's design, providing confidence that updates won't unexpectedly break existing projects. |
| 71 | + |
| 72 | +### Version Format |
| 73 | + |
| 74 | +Versions follow the format: `MAJOR.MINOR.PATCH` |
| 75 | + |
| 76 | +- **MAJOR (X.0.0)**: Incremented for incompatible API changes that may require code modifications |
| 77 | +- **MINOR (x.Y.0)**: Incremented for backward-compatible functionality additions |
| 78 | +- **PATCH (x.y.Z)**: Incremented for backward-compatible bug fixes and minor improvements |
| 79 | + |
| 80 | +### Compatibility Guarantees |
| 81 | + |
| 82 | +- **PATCH Updates**: Always safe to apply, contain only bug fixes and minor improvements |
| 83 | +- **MINOR Updates**: Safe to apply, add new features without breaking existing code |
| 84 | +- **MAJOR Updates**: May include breaking changes, but these will be clearly communicated in advance |
| 85 | + |
| 86 | +This versioning approach ensures that projects won't suddenly break due to a framework update. You can confidently upgrade within the same major version, knowing there will be no unexpected changes. |
| 87 | + |
| 88 | +### Deprecation Policy |
| 89 | + |
| 90 | +Before removing or significantly changing functionality: |
| 91 | + |
| 92 | +1. The feature is marked as deprecated in a minor release |
| 93 | +2. Deprecation notices are added to the documentation and codebase |
| 94 | +3. The feature continues to work for at least one major version cycle |
| 95 | +4. The feature is removed only in a major version update |
| 96 | + |
| 97 | +This policy gives developers ample time to adapt their code to any upcoming changes. |
| 98 | + |
| 99 | +## Integration with WP Scaffold |
| 100 | + |
| 101 | +The WP-Framework was introduced to the WP Scaffold in PR #268 as a significant architectural improvement. Rather than being embedded within the scaffold, it's now included as a Composer dependency. |
| 102 | + |
| 103 | +### Changes to the Scaffold |
| 104 | + |
| 105 | +The WP Scaffold has been updated to: |
| 106 | + |
| 107 | +1. **Require WP-Framework**: The framework is now included as a Composer dependency |
| 108 | +2. **Remove Duplicated Code**: Much of the shared functionality has been removed from the scaffold and is now provided by the framework |
| 109 | +3. **Leverage Framework Components**: The scaffold now builds upon the foundation provided by the framework |
| 110 | + |
| 111 | +This change makes the scaffold lighter and more focused while ensuring projects can still benefit from improvements made over time. |
| 112 | + |
| 113 | +### Installation and Updates |
| 114 | + |
| 115 | +For new projects using the scaffold, the WP-Framework is automatically included via Composer: |
| 116 | + |
| 117 | +```json |
| 118 | +{ |
| 119 | + "require": { |
| 120 | + "10up/wp-framework": "^1.0" |
| 121 | + } |
| 122 | +} |
| 123 | +``` |
| 124 | + |
| 125 | +For existing projects, updating to use the framework is completely optional. If updating would cause undue delays or waste engineering time, it's perfectly fine to leave things as they are. However, if you're planning a significant update or refactor, it might be worth considering the new approach to take advantage of future improvements. |
| 126 | + |
| 127 | +### Usage in Scaffold Components |
| 128 | + |
| 129 | +Scaffold components can use the framework by: |
| 130 | + |
| 131 | +1. Extending framework base classes |
| 132 | +2. Using framework utilities and helpers |
| 133 | + |
| 134 | +## Best Practices |
| 135 | + |
| 136 | +The WP-Framework is designed to provide a solid 90% foundation for most WordPress projects while still allowing flexibility for project-specific needs. When working with the framework, consider these best practices: |
| 137 | + |
| 138 | +### For New Projects |
| 139 | + |
| 140 | +- **Embrace the Framework**: Take advantage of the framework's components and patterns |
| 141 | +- **Follow Versioning**: Use semantic versioning in your `composer.json` to control updates |
| 142 | +- **Extend, Don't Modify**: Extend framework classes rather than modifying core framework files |
| 143 | +- **Leverage Composer**: Use Composer for dependency management and updates |
| 144 | +- **Stay Current**: Regularly update to the latest minor and patch versions for improvements and bug fixes |
| 145 | + |
| 146 | +### For Existing Projects |
| 147 | + |
| 148 | +- **Optional Migration**: Updating to use the framework is completely optional |
| 149 | +- **Consider ROI**: Evaluate whether migrating to the framework makes sense for your project timeline and resources |
| 150 | +- **Incremental Adoption**: Consider adopting the framework during significant updates or refactors |
| 151 | +- **Maintain Compatibility**: If updating, ensure your custom code remains compatible with the framework |
| 152 | + |
| 153 | +### General Guidelines |
| 154 | + |
| 155 | +- **Customize Where Needed**: The framework provides a 90% foundation, but you can still customize the remaining 10% |
| 156 | +- **Respect Versioning**: Pay attention to major version changes which may contain breaking changes |
| 157 | +- **Contribute Improvements**: If you develop enhancements that could benefit others, consider contributing them back |
| 158 | +- **Document Extensions**: Document any custom extensions or modifications to the framework |
| 159 | + |
| 160 | +## Troubleshooting |
| 161 | + |
| 162 | +Here are solutions to common issues you might encounter when working with the WP-Framework: |
| 163 | + |
| 164 | +### Composer Dependency Issues |
| 165 | + |
| 166 | +If you're having trouble with the framework as a Composer dependency: |
| 167 | + |
| 168 | +1. **Version Constraints**: Ensure your `composer.json` has the correct version constraint (e.g., `"10up/wp-framework": "^1.0"`) |
| 169 | +2. **Composer Cache**: Try clearing the Composer cache with `composer clear-cache` |
| 170 | +3. **Composer Update**: Run `composer update` to ensure you have the latest compatible version |
| 171 | +4. **Composer Diagnostics**: Use `composer why 10up/wp-framework` to see why the package is being included |
| 172 | + |
| 173 | +### Migration Challenges |
| 174 | + |
| 175 | +When migrating an existing project to use the framework: |
| 176 | + |
| 177 | +1. **Namespace Conflicts**: Check for namespace conflicts between your code and the framework |
| 178 | +2. **Duplicate Functionality**: Identify and remove code that duplicates framework functionality |
| 179 | +3. **Dependency Injection**: Adapt your code to use the framework's dependency injection patterns |
| 180 | +4. **Incremental Approach**: Consider migrating one component at a time rather than all at once |
| 181 | + |
| 182 | +### Version Compatibility |
| 183 | + |
| 184 | +If you encounter version compatibility issues: |
| 185 | + |
| 186 | +1. **Semver Understanding**: Remember that only major version changes (e.g., 1.x to 2.x) might contain breaking changes |
| 187 | +2. **Changelog Review**: Always review the changelog before upgrading to a new major version |
| 188 | +3. **Deprecation Notices**: Pay attention to deprecation notices in your logs to prepare for future changes |
| 189 | +4. **Testing Environment**: Test framework updates in a development environment before applying to production |
| 190 | + |
| 191 | +### Custom Extensions |
| 192 | + |
| 193 | +If you're extending the framework and encountering issues: |
| 194 | + |
| 195 | +1. **Extension Points**: Make sure you're using the intended extension points rather than modifying core files |
| 196 | +2. **Hook Priority**: Check that your hooks have the correct priority if they're not executing as expected |
| 197 | +3. **Inheritance**: When extending framework classes, ensure you're calling parent methods when required |
| 198 | +4. **Documentation**: Consult the framework documentation for the recommended approach to customization |
| 199 | + |
| 200 | +--- |
| 201 | + |
| 202 | +For more detailed information about specific framework components, refer to the corresponding documentation files in this directory. |
0 commit comments