Seamless Development with Bedrock & Composer: Keeping Your Plugin and Site in Sync

Bruh, ever feel like your WordPress project is playing tug-of-war with your own plugin? You’re developing a WordPress site using Bedrock by roots.io, installing plugins via wpackagist.org, and simultaneously building your own plugin (in its own Git repo, mind you). But when you try to require your plugin as a package, Composer ends up overwriting your precious, git-controlled work in your plugin folder. What gives?

Fear not, code warrior! Here’s how you can develop both projects side-by-side without them stepping on each other’s toes.

The Dilemma

• Main Repo: Your Bedrock-based WordPress site lives at ~/lando-sites/domain.
• Plugin Repo: Your plugin (named real-coder-pty-ltd/proptrack) is in a separate folder at ~/lando-sites/proptrack and has its own Git repo.

When you require your plugin via Composer, it might pull in a packaged version that hides your local changes. Not cool, right?

The Solution: Composer’s Path Repositories

Enter Composer’s path repositories. This nifty feature lets you work on your plugin locally while still “requiring” it in your Bedrock project. By setting up a path repository with symlinks, any changes you make to your plugin will instantly be reflected in your WordPress project.

Setting It Up

Add the Path Repository to Your Composer File

In your Bedrock project’s composer.json, add the following repository configuration:

"repositories": [
  {
    "type": "path",
    "url": "../proptrack",
    "options": {
      "symlink": true
    }
  },
  {
    "type": "vcs",
    "url": "https://github.com/real-coder-pty-ltd/proptrack.git"
  }
]

Quick Breakdown:

• "url": "../proptrack" points from your main repo to the local plugin folder.
• "options": { "symlink": true } ensures a symlink is created, so any changes you make in your plugin repo are immediately visible.
• The VCS repo entry serves as a fallback for production where your local folder likely won’t exist.

Ensure Your Plugin’s Composer File Is Set Up

Inside your plugin’s repository (~/lando-sites/proptrack), make sure you have a valid composer.json with the proper name:

{
  "name": "real-coder-pty-ltd/proptrack",
  // ... other settings
}

Require Your Plugin in Your Bedrock Project

In your main composer.json, add your plugin to the "require" section:

"require": {
  "real-coder-pty-ltd/proptrack": "*"
}

With the path repository configured first, your local version will take precedence during development.

What Happens in Production?

When you deploy to production, the relative path ../proptrack likely won’t exist. No worries—Composer will fall back to the VCS repository (the GitHub URL). Just ensure your production environment has proper access to GitHub (and necessary credentials, if needed).

Final Thoughts

This dual setup lets you enjoy the best of both worlds:

• Local Dev: Rapid changes via symlink to your plugin repo.
• Production: Stable dependency resolution from your VCS repo.

Now you can juggle your Bedrock project and your plugin development without them interfering with each other. Keep coding, stay caffeinated, and always remember: code like a boss, bruh!

Handling Symlink Accessibility in Lando

If you’re using Lando, you might run into an issue where Finder shows the symlink correctly, but WordPress doesn’t see the plugin. That’s likely because the symlink is pointing to a location outside the container’s /app/ directory.

The Fix

1. Mount the Plugin Directory into Your Container
   • Update your Lando configuration (usually in your .lando.yml) to mount your plugin folder into the container. For example:

services:
  appserver:
    volumes:
      - ~/lando-sites/proptrack:/app/web/app/plugins/proptrack

1. This change ensures that your plugin is actually located within /app/, making it accessible to WordPress.
2. Rebuild or Restart LandoAfter updating the .lando.yml file, rebuild or restart your Lando environment so that the volume mounts take effect.

What Happens in Production?

On production, the relative path ../proptrack likely won’t exist. In that case, Composer will automatically fall back to the VCS repository (the GitHub URL). Just ensure your production environment has proper network access to GitHub (and any required credentials).

Final Thoughts

This dual setup lets you enjoy the best of both worlds:

• Local Development: Rapid changes via a symlink to your plugin repo, with the added Lando volume mount ensuring WordPress sees it.
• Production: Stable dependency resolution from your VCS repository, ensuring smooth deployments.

By configuring Composer with both path and VCS repositories and properly mounting your plugin directory in Lando, you can develop your WordPress site and plugin in harmony. Happy coding, and may your deployments be ever in your favor!