Tag: PHP Composer

  • Git Submodule vs Composer Package for Testing Framework Integration

    Background and Decision Context

    When designing a “Separate Testing Framework Repository with Development Tools,” a key question emerged:

    Does this design work for a project where another developer, who already has their environment set up, can just get the PHPUnit part? (For experienced developers, this would be the interesting part.)

    This page explores two primary approaches to integrating a separate testing framework repository into WordPress plugin projects, with a focus on developer experience and flexibility.

    Comparison Overview

    FactorGit SubmodulesComposer Packages
    Setup ComplexityModerateHigher
    Developer ExperienceRequires Git knowledgeRequires Composer knowledge
    VersioningManual trackingAutomatic via semantic versioning
    Update Processgit submodule updatecomposer update
    Flexibility for Experienced DevsDirect access to filesAbstracted as a dependency
    Learning CurveGit commandsComposer + Package publishing

    Option A: Git Submodules

    What Are Git Submodules?

    Git submodules allow you to include one Git repository inside another as a subdirectory. This creates a link to a specific commit in the external repository rather than copying the code.

    Implementation Steps

    1. Create your testing framework repository:

      mkdir ~/sites/wp-phpunit-framework
      cd ~/sites/wp-phpunit-framework
      git init
      # Add your testing framework files
      git add .
      git commit -m "Initial commit of testing framework"
      git remote add origin https://github.com/glerner/wp-phpunit-framework.git
      git push -u origin main
    2. Add the submodule to your plugin project:

      cd ~/sites/gl-color-palette-generator
      git submodule add https://github.com/glerner/wp-phpunit-framework.git tests/framework
      git commit -m "Add testing framework as submodule"
    3. For developers cloning your plugin project:

      git clone https://github.com/glerner/gl-color-palette-generator.git
      cd gl-color-palette-generator
      git submodule init
      git submodule update
      
    4. To update the framework in your plugin:

      # In the main project
      git submodule update --remote tests/framework
      git commit -m "Update testing framework submodule"
      

    Advantages

    • Direct Access: Developers can directly access and modify framework files if needed
    • No Publishing Required: No need to publish packages to Packagist or set up private repositories
    • Version Control: Clear tracking of which framework version is being used
    • Independence: Framework can be developed independently of plugins using it
    • Simplicity: No need to understand Composer’s package system beyond basic dependencies

    Disadvantages

    • Git Knowledge Required: Developers need to understand Git submodules
    • Extra Clone Steps: Requires additional commands when cloning the repository
    • Potential Confusion: Submodules can be confusing for developers new to Git
    • Manual Updates: Updates to the framework must be manually pulled and committed

    Option B: Composer Packages

    What Are Composer Packages?

    Composer is PHP’s dependency manager. Packages are reusable libraries that can be required in projects via Composer.

    Implementation Steps

    1. Prepare your framework as a Composer package:

      • Create a proper composer.json in your framework repository:

             {
               "name": "yourusername/wp-phpunit-framework",
               "description": "WordPress PHPUnit Testing Framework",
               "type": "library",
               "require": {
                 "php": ">=7.4",
                 "phpunit/phpunit": "^9.0"
               },
               "autoload": {
                 "psr-4": {
                   "YourNamespace\\TestFramework\\": "src/"
                 }
               }
             }
    2. Use a private repository approach (simpler than Packagist):

      • In your plugin’s composer.json:

             {
               "repositories": [
                 {
                   "type": "vcs",
                   "url": "https://github.com/yourusername/wp-phpunit-framework.git"
                 }
               ],
               "require": {
                 "yourusername/wp-phpunit-framework": "dev-main"
               }
             }
    3. Install the dependency:

      composer require yourusername/wp-phpunit-framework:dev-main

    Advantages

    • Standard PHP Workflow: Follows standard PHP dependency management practices
    • Semantic Versioning: Can leverage semantic versioning for updates
    • Autoloading: Automatic class autoloading
    • Dependency Management: Handles nested dependencies automatically
    • Familiar to PHP Devs: Most PHP developers are familiar with Composer

    Disadvantages

    • Publishing Required: Requires understanding how to publish packages
    • Less Direct Access: Files are in vendor directory and shouldn’t be directly modified
    • More Complex Setup: More complex initial setup, especially for private packages
    • Learning Curve: Steeper learning curve for package maintenance

    Recommendation for WordPress Plugin Testing Frameworks

    For a WordPress plugin testing framework that needs to be accessible to developers with varying experience levels:

    Use Git Submodules When:

    • You’re still learning Git and Composer
    • You want direct control over the framework files
    • You prefer simplicity over standardization
    • You want to make frequent changes to both repositories
    • Your team is comfortable with Git but not necessarily with Composer package publishing

    Use Composer Packages When:

    • You’re comfortable with Composer package management
    • You have multiple projects that will use the framework
    • You want to leverage semantic versioning
    • Your team is already using Composer extensively
    • You want to follow PHP community standards for dependency management

    Practical Considerations for WordPress Developers

    1. WordPress Development Culture: Many WordPress developers are more familiar with Git than with Composer package publishing.

    2. Learning Path: Git submodules can be a stepping stone to learning more advanced dependency management.

    3. Team Composition: Consider the technical background of all developers who will work with the codebase.

    4. Long-term Maintenance: Composer packages may be easier to maintain across multiple projects in the long run.

    5. Hybrid Approach: You can start with Git submodules and transition to Composer packages as your team’s expertise grows.

    Conclusion

    For the specific context of a WordPress testing framework where experienced developers should be able to easily access just the PHPUnit part, Git submodules provide a more direct and accessible approach initially. As your project and team mature, you can consider transitioning to a Composer package for better standardization and dependency management.

    The most important factor is that your testing framework remains modular and well-documented, regardless of the integration method chosen.

  • Using PHP Packages without Composer

    Composer http://getcomposer.org/ is a “Dependency Manager for PHP”.

    If you do not have Apache command line access, like most people using a shared hosting account, instructions for installing a PHP package with Composer won’t work (at least not using the instructions given):

    The preferred method of installation is [composer](http://getcomposer.org/). In your project root (not web root), create a minimum [composer.json](http://packagist.org/) file:
    {
    "require": {
    "VerticalTab/Pillow": "x.x.x"
    }
    }
    Replace "x.x.x" above with the tag number you want to use.

    Next, get composer and use it to install (again, in your project root)
    $ wget http://getcomposer.org/composer.phar
    $ php composer.phar install
    This will put the library into your vendors directory.

    Then you would use this line of code in your program to access the package:
    require 'vendor/autoload.php';

    Well, you don’t need Composer to install this package, you can insert some standard PHP code that works, into your program. (But you won’t have all the version checking that Composer does.)

    This PHP code replaces the autoload.php:
    function __autoload($class_name) {
    require_once("./$class_name.php");
    }

    The package I am using as an example is a Zillow API package, in the VerticalTab folder, inside the current folder, and contains these files:
    /VerticalTab/Pillow/Chart.php
    /VerticalTab/Pillow/Comps.php
    /VerticalTab/Pillow/Date.php
    /VerticalTab/Pillow/HttpClient.php
    /VerticalTab/Pillow/Links.php
    /VerticalTab/Pillow/Property.php
    /VerticalTab/Pillow/Proxy.php
    /VerticalTab/Pillow/Range.php
    /VerticalTab/Pillow/ResultSet.php
    /VerticalTab/Pillow/SearchResults.php
    /VerticalTab/Pillow/Service.php
    /VerticalTab/Pillow/Xml.php
    /VerticalTab/Pillow/Zestimate.php

    List all the package’s .PHP files using a special syntax. Convert the names like below. The backslashes are required; forward slashes are incorrect syntax. Drop the .php extension

    use VerticalTab\Pillow\Chart;
    use VerticalTab\Pillow\Comps;
    use VerticalTab\Pillow\Date;
    use VerticalTab\Pillow\HttpClient;
    use VerticalTab\Pillow\Links;
    use VerticalTab\Pillow\Property;
    use VerticalTab\Pillow\Proxy;
    use VerticalTab\Pillow\Range;
    use VerticalTab\Pillow\ResultSet;
    use VerticalTab\Pillow\SearchResults;
    use VerticalTab\Pillow\Service;
    use VerticalTab\Pillow\Xml;
    use VerticalTab\Pillow\Zestimate;

    Now all the package code is accessible to your program.

    Inside the package are namespace commands, e.g. VerticalTab/Pillow/SearchResults.php has namespace VerticalTab\Pillow;