Provide examples of embedding themes and plugins in the site's repository

[simensen]

I'd like to have push-to-deploy for one repository that had a composer.json that included WordPress itself along with my own custom-built themes and plugins. (more likely one theme + potentially several custom plugins) They would be themes/plugins that would have no purpose outside of our own application (at least for now) and the idea would be that we'll be probably changing the site/feel (so the theme) more than the repo itself, so whatever we are changing and pushing should be causing the site to rebuild... I think that means that the themes/plugins should be a part of the WordPress repo itself, otherwise pushing to the theme (as an independent package) won't result in redeploying the site itself.

[franz-josef-kaiser]

The purpose of this package is not to deploy things, but to have a strategy how to build a project. This includes naming source path, building a wp-config.php, splitting out wp-content from wp, etc. For details, just take a look at the steps it performs.

If you are searching for a solution that allows "push to deploy", I can only recommend searching for a Deployment service. You can as well utilize GitHub "webhooks" for your repository:

https://github.com/<organization>/<repo>/settings/hooks

Summed up from the description:

Webhooks allow external services to be notified when certain events happen within your repository. When the specified events happen, we’ll send a POST request to each of the URLs you provide.

You can then use a pretty simple script to react on that POST request by updating a git repository on your server for e.g. GitHub features plenty of example repositories around that strategy in pretty much any language available.

About bundling all your dependencies in a single repo: I would avoid that. You might want to push only on demand, only on specific days or times (like night) or only push when certain things are solved. For that, I'd split up every single plugin or theme into their own repo. Then only update the "main" repo, containing your composer.{json|lock} file and only react and pull on your server when the master branch gets pushed and when you have actual changes in the composer.lock file. Note, that this is just my personal opinion. Still, I would want to avoid extending the docs to show the opposite and how to bundle everything in a single repo. In case I misunderstood, please just explain your goal. I might have gotten it wrong.

[simensen]

Yeah, I appreciate that this repository does not have "deployment" as its primary goal. :) I wanted to include more backstory as I was discussing this on Twitter with @Giuseppe-Mazzapica and Forge/Envoyer deployment had been discussed.

I'm also normally quite a fan of breaking out pieces of a project into their own repositories and treating each as their own composer dependency. I've gone quite far down that path in the past and it doesn't always make me happy. In fact, quite the opposite. So in some cases I prefer to have everything relating to a project in the same repo.

I don't know enough about WordPress project layouts to understand all of the tricks being done by wecodemore/wpstarter to answer the question for myself, "if I wanted to do development of a theme/plugin in the main site's repository, where would I put the files?" I'm guessing it is probably a trivial question and for people well-versed in WordPress (andwecodemore/wpstarter) it is probably easy to jump to the conclusion that I can't possibly be asking for something so simple. But there it is. :)

I'm guessing that I can maybe just add them directly to wp-content/themes and wp-content/plugins and I can just tweak .gitignore but I want to make sure that there isn't special handling for this workflow built-in somewhere ("put themes/plugins local to the repo [here]") or if some directories are expected to be able to be destroyed ("so don't put anything in wp-content/(themes|plugins) AT ALL").

[gmazzap]

Hi @simensen and thanks for your interest in WP Starter.

I had chances to use WP Starter in quite big projects, working in team (@franz-josef-kaiser know well, since he was part of that team) and breaking out the whole website in different parts was a life safer: being able to test experimental features for different plugins with different developers working at same time..., it's not that simple working a monolithic repository. Moreover, you may have independent versioning for different plugins and themes... and so on.

But when I worked in smaller websites, alone, I used the "unique repo" approach, and I was (and am) happy with the outcome.

I'm guessing that I can maybe just add them directly to wp-content/themes and wp-content/plugins and I can just tweak .gitignore

Yes, that's definetively doable. I did it. Directories are not destroyed and there's no special workflow. Note that the folder to use is not the wp-content folders that is "shipped" with WordPress, but is the content folder that WP Starter creates and that can be configured using the "extra.wordpress-content-dir" setting in composer.json. By default it is a folder named "content" in the "public" folder.

The downside of this approach is that your plugins will be in same folder of any other plugin you can pull from anywhere and even if it is surely possible to tweak .gitignore to don't ignore your plugins while ignoring the others, I personally found this approach a bit "confusing", and force you to change .gitignore every time you add a new plugin.

Another approach I recently used is to create another folder, I named it content-dev, but name is irrelevant. In this folder I put my themes and my plugins. However, WordPress has to find these plugins and themes inside the content folder, or they are not recognized. What I did for the scope is use Composer scripts to symlink all the folders from content-dev/themes to content/themes and all the folders from content-dev/plugins to content/plugins.

This is literally one liner in bash, something like:

ln -s ./content-dev/themes/* ./public/content/themes/ && ln -s ./content-dev/plugins/* ./public/content/plugins

Since Composer scripts accept bash commands as valid entries, this is a no brainer. I honestly used a PHP script to create symlinks, because I had other "startup" tasks that was easier to do PHP and so I created a script to do all these tasks, including symlinks, but if you just need to create those symlinks, I think that bash line would be enough.

Moreover, if you use Lavarel Envoyer, you could use a deploy hook to create symlinks, keeping your composer.json clean.

Since you plugins and themes are in a separate folder, you can easily .gitignore 3rd party plugins and themes while keeping under version control the code you write for the website.

[schlessera]

@simensen With some Composer magic, you can have a folder "dev-plugins" that gets used as a Composer repository to pull plugins from, using the "path" repository. It will symlink them into the correct location then. If they are not found in that location, it will look through (wp-)packagist as a fallback. https://getcomposer.org/doc/05-repositories.md#path

[gmazzap]

@schlessera yes, symlink a develop folder is what I suggested to do "manually".

The difference with using "path" are:

• to use "path" repository you need a composer.json for each plugin, which probably does not make sense, because they are part of main repo. Moreover, since they are part of the same repo and there's no dedicate git repo for them, you can't really use version in the requirement, and you are foced to use "*", unless you define version in composer.json which is annoying because you need to be kept updated at every change...
• IMO the fallback to packagist doesn't make sense either, because the package will never be on packagist in this use case

In short, I don't see any benefit on using the "path" repo, just a couple of minor issues.

Even implementation is actually simpler for manual symlink: it requires just 1 line in "root" composer.json while "path" repositories would require one 1 line per plugin in "root" composer.json + a separate composer.json for each plugin...

In summary, I think "path" repos are a very nice thing, but to me don't really make sense when those repos are part of the repo that contains the composer.json that pulls them.

[schlessera]

@Giuseppe-Mazzapica Yes, all valid points that should be considered.

I find the path repo very useful, but then I have to say that all my plugins always come with a composer.json anyway, as I pull in the plugin's dependencies through that.

I use a lot of personal libraries to reuse code whenever possible, even if it is simple stuff like creating a shortcode or a CPT. I think at the least, my plugins always depend on a config library.

[gmazzap]

@schlessera totally agree with you. I was talking about the specific issue in which theme / plugins are created just for one site and make no sense share in other places. Moreover, if a plugin has a composer.json worth a separate repo anyway, IMO.

[kraftner]

For the sake of completeness: For themes there could be another approach: You could just add your custom themes to ./public/content/themes-dev and register_theme_directory it. Unfortunately this doesn't work for plugins.

[gmazzap]

Version v3 has a native way to do this. This need to be documented, so I am keeping opened with docs label.

[gmazzap]

v3 has detailed documentation for this.

Considering I'm not going to update v2 docs for this reason, I'm gonna close this to keep issues list clean.

Thanks anyone involved.