-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide examples of embedding themes and plugins in the site's repository #23
Comments
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 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:
Summed up from the description:
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 |
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 |
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.
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 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 Another approach I recently used is to create another folder, I named it 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 Since you plugins and themes are in a separate folder, you can easily |
@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. |
@schlessera yes, symlink a develop folder is what I suggested to do "manually". The difference with using "path" are:
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" 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 |
@Giuseppe-Mazzapica Yes, all valid points that should be considered. I find the 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. |
@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 |
For the sake of completeness: For themes there could be another approach: You could just add your custom themes to |
Version v3 has a native way to do this. This need to be documented, so I am keeping opened with docs label. |
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. |
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.
The text was updated successfully, but these errors were encountered: