VOOZH about

URL: https://deepwiki.com/calevans/staticforge/9.3-make-commands

⇱ Make Commands | calevans/staticforge | DeepWiki

Loading...
Loading...
Last indexed: 11 February 2026 (5f6a2a)
Menu

Make Commands

Purpose and Scope

This page documents the make:* namespace of CLI commands in StaticForge. Make Commands are utility commands that generate deployment artifacts and configuration files needed for production environments. These commands do not directly process content or build the site; instead, they create supplementary files such as web server configuration, deployment scripts, and other infrastructure artifacts.

For commands that build and render site content, see Site Commands. For commands that validate site quality and configuration, see Audit Commands.

Command Architecture

Make Commands follow the standard Symfony Console Command pattern and are registered during application bootstrap. They extend Symfony\Component\Console\Command\Command and receive the dependency injection Container through their constructors, allowing access to site configuration and environment variables.

Registration Flow



Sources: bin/staticforge.php1-79


The registration process occurs in bin/staticforge.php52-79 where:


    

  1. The application bootstraps and loads the Container [lines 52-58]
    2. 

  2. A Symfony Console Application is instantiated [line 61]
    3. 

  3. Make Commands are instantiated with the Container and added to the application [line 70]
    4. 

  4. The application runs and dispatches to the appropriate command [line 79]
    5. 



Sources: bin/staticforge.php52-79




make:htaccess Command


The make:htaccess command generates a production-ready Apache .htaccess file with security headers, performance optimizations, and StaticForge-specific protections.


Command Signature


php bin/staticforge make:htaccess [options]



Options




























OptionShortTypeDefaultDescription
--write-wFlagfalseWrite the output to a file instead of stdout
--output-oStringhtaccess.txtSpecify the output filename (requires --write)


Sources: src/Commands/Make/HtaccessCommand.php28-33


Generated Content


The command generates three categories of Apache directives:


1. StaticForge Manifest Protection


Prevents public access to the staticforge-manifest.json file, which may contain internal build metadata.




Sources: src/Commands/Make/HtaccessCommand.php40-46


2. Security Headers


Implements defense-in-depth security measures:


    

  • Strict-Transport-Security (HSTS): Forces HTTPS for one year, including subdomains
    • 

  • X-Content-Type-Options: Prevents MIME-type sniffing attacks
    • 

  • X-Frame-Options: Mitigates clickjacking by restricting iframe embedding
    • 



The always set directive ensures headers apply even to redirect responses.


Sources: src/Commands/Make/HtaccessCommand.php48-62


3. Performance Headers (Browser Caching)


Configures aggressive caching for static assets:


    

  • HTML/Data: 1 hour cache (max-age=3600)
    • 

  • Assets (CSS, JS, images, fonts): 1 week cache (max-age=604800)
    • 



The set directive (rather than always set) prevents caching of error pages (404, 500).


Sources: src/Commands/Make/HtaccessCommand.php64-77


Usage Examples


Preview Output (Default)




Outputs the .htaccess content to stdout for review. This is the safest mode for inspecting the generated configuration before deployment.


Sources: src/Commands/Make/HtaccessCommand.php95-101


Write to Default File




Writes the content to htaccess.txt in the current directory. This file can be reviewed and manually renamed to .htaccess when ready for deployment.


Sources: src/Commands/Make/HtaccessCommand.php79-94


Write to Custom Location




Directly writes to public/.htaccess. The command displays a note if overwriting an existing .htaccess file.


Sources: src/Commands/Make/HtaccessCommand.php79-94




Implementation Details


Class Structure




Sources: src/Commands/Make/HtaccessCommand.php14-26


The HtaccessCommand class follows a straightforward pattern:


    

  1. Constructor Injection [lines 22-26]: Receives the Container to access configuration if needed (though current implementation uses hardcoded content)
    2. 

  2. Configuration [lines 28-33]: Defines command name, description, and options using Symfony Console's fluent API
    3. 

  3. Execution [lines 35-102]: Generates content and either writes to file or prints to stdout based on options
    4. 



Sources: src/Commands/Make/HtaccessCommand.php14-103


Content Generation Strategy


The command uses a heredoc string (<<<'EOT') to define the .htaccess template as a static string literal. This approach prioritizes:


    

  • Simplicity: No template engine or variable substitution required
    • 

  • Reliability: Output is deterministic and testable
    • 

  • Maintainability: The configuration is visible in the source code
    • 



Future extensions could read configuration from the Container to customize cache durations or security headers based on siteconfig.yaml settings.


Sources: src/Commands/Make/HtaccessCommand.php40-77




Integration with Other Systems


Relationship to Deployment Features




Sources: src/Commands/Make/HtaccessCommand.php40-77 src/Commands/Audit/LiveCommand.php260-304


The make:htaccess command integrates into the deployment workflow:


    

  1. Before Deployment: Generate the .htaccess file with appropriate security and caching headers
    2. 

  2. During Deployment: The file is uploaded alongside the static site content (typically to the public/ directory root)
    3. 

  3. After Deployment: The audit:live command validates that the expected headers are present in server responses
    4. 



Validation by audit:live


The audit:live command explicitly checks for the presence of headers generated by make:htaccess:


    

  • HSTS: Validates Strict-Transport-Security header src/Commands/Audit/LiveCommand.php276-282
    • 

  • X-Content-Type-Options: Checks for nosniff directive [lines 284-293]
    • 

  • X-Frame-Options: Confirms clickjacking protection [lines 295-300]
    • 

  • Cache-Control: Verifies caching headers are present [lines 337-342]
    • 



This creates a feedback loop where deployment artifacts are validated against production behavior.


Sources: src/Commands/Audit/LiveCommand.php260-356




Extending Make Commands


Creating New Make Commands


To add additional make commands (e.g., make:nginx, make:dockerfile), follow this pattern:


    

  1. 

    Create Command Class: Place in src/Commands/Make/ namespace
    

    

    2. 

  2. 

    Register Command: Add to bin/staticforge.php alongside existing commands:
    

    

    3. 

  3. 

    Implement Generation Logic: Use the same pattern as HtaccessCommand:
    

      

    • Accept --write and --output options for file generation
      • 

    • Use heredoc for template content
      • 

    • Output to stdout by default, file with --write
      • 

    

    4. 



Sources: src/Commands/Make/HtaccessCommand.php14-103 bin/staticforge.php70


Accessing Configuration in Make Commands


Make Commands have access to the Container, enabling dynamic content generation based on site configuration:




This pattern allows make commands to generate files customized to the specific site's configuration.


Sources: src/Commands/Make/HtaccessCommand.php22-26 src/Commands/Audit/ConfigCommand.php38-39




Command Execution Flow


Detailed Execution Sequence




Sources: src/Commands/Make/HtaccessCommand.php35-102


Error Handling


The command implements defensive error handling:


    

  1. File Overwrite Warning: When writing directly to .htaccess, displays a note if the file already exists [lines 82-86]
    2. 

  2. Write Failure: Checks file_put_contents() return value and reports errors [lines 88-94]
    3. 

  3. Output Modes: Clearly differentiates between preview (stdout) and persistent (file) modes [lines 95-101]
    4. 



Sources: src/Commands/Make/HtaccessCommand.php79-102




Best Practices


Deployment Workflow


The recommended workflow for using make commands in production:


    

  1. 

    Preview: Run without --write to review generated content
    

    

    2. 

  2. 

    Generate: Write to a temporary file for version control
    

    

    3. 

  3. 

    Deploy: Rename during deployment or use deployment scripts to place the file correctly
    

    

    4. 

  4. 

    Validate: Use audit:live to verify the configuration is active on the server
    

    

    5. 



Sources: src/Commands/Make/HtaccessCommand.php35-102 src/Commands/Audit/LiveCommand.php34-124


Security Considerations


    

  • Review Before Deployment: Always preview generated configurations before deploying to production
    • 

  • Test Locally: Use a local Apache server to test .htaccess rules before live deployment
    • 

  • Version Control: Commit generated configuration files to track changes over time
    • 

  • Validate Headers: Use audit:live to confirm server configuration is correctly applied
    • 



Sources: src/Commands/Make/HtaccessCommand.php40-77 src/Commands/Audit/LiveCommand.php260-304




Future Extensions


The Make Commands namespace is designed for extensibility. Potential future additions include:


    

  • make:nginx: Generate Nginx server block configurations
    • 

  • make:dockerfile: Create Docker container configurations for the built site
    • 

  • make:deploy: Generate deployment scripts for various hosting platforms
    • 

  • make:systemd: Create systemd service files for the development server
    • 

  • make:vercel: Generate vercel.json for Vercel deployments
    • 

  • make:netlify: Create _redirects and _headers for Netlify
    • 



Each would follow the same pattern as HtaccessCommand: accept Container for configuration access, generate deterministic output, support --write mode, and integrate with validation commands.


Sources: src/Commands/Make/HtaccessCommand.php14-103 bin/staticforge.php47-70