Open mikeschinkel opened 8 years ago
I need to use the SOAP-module. So I have added this to the README of our box at work. It would be really nice to be able to activate/disable this kind of things from another place. But this works.
3. Install SOAP
vagrant ssh sudo apt-get install php7.0-soap
@nonameolsson First, condolences having to work with SOAP. :-(
2nd, given experience with the easy breakage of VVV, I am wanting us to explore ways to do this w/o having to use apt-get
. It seems to me that since we control the O/S on the box we should literally be able to collect up all the appropriately compiled PHP extensions and store them on Amazon S3 or similar for download on update. We could also give you a way to point to your own downloadable extensions.
Wondering what you, @clubdeuce and anyone else reading this think about this approach?
It seems to me that since we control the O/S on the box we should literally be able to collect up all the appropriately compiled PHP extensions and store them on Amazon S3 or similar for download on update. We could also give you a way to point to your own downloadable extensions.
That would be great! This would make this box a lot different from the other popular ones.
But we are working on a new architecture that will support multiple sites that will have an admin console and an API to allow you to add and reconfigure sites. Once we get to that then wplib.box will be the admin console and you would set up your domains how ever you want them to work. https://github.com/wplib/wplib-box/issues/143#issuecomment-235930488
How's this going? Do you have a discussion, a release plan etc? Would be interesting to be able to follow this, and maybe contribute?
This would make this box a lot different from the other popular ones.
That too is part of what we are striving for.
But we are working on a new architecture...
How's this going? Do you have a discussion, a release plan etc? Would be interesting to be able to follow this, and maybe contribute?
We met to discuss an MVP for this and decided what we needed as a minimum for a Console & API (which we are writing in Laravel & Slim, respectively) is the following:
What we plan to do is implement the functionality using Bash (or PHP) scripts that the API will call, and then the console will implement the functionality by calling the API. Later we will build a CLI to run in the host machine that will also call the API.
How you can help is to clone and test the latest code for WPLib Box (be sure to clone a new version; I do not know how easy it will be to upgrade in place, if that is even possible) and dive into vagrant ssh
to play with the new Box CLI for the guest machine (the WPLib Box).
The Box CLIU has no real architecture yet and I don't plan to address that for a while as I am focusing on functionality first. I have added numerous features over the past 3 days; here are the current "commands"
It would be really helpful if you can collaborate with me over there via discussion of issues and via pull requests because I am in complete control of that repo. @clubdeuce manages the WPLib Box image and his availabletime to contribute is somewhat limited thus we can't move as fast here as I personally can move over there. And over there is where a lot of the features inside the box will come from.
Will that work as a way to help?
Seeing that I have run into yet another missing extension in #137 I would like to discuss how we could ensure that all well-known extensions are in the
/mods-available/
directory and possibly even pre-enable them.Given our focus is on developer experience, having to track down an error that comes from a missing extension is not the best experience that could be offered.
Potential approaches:
1.) Hook into PHP somehow (if even possible) to translate errors thrown and convert them into descriptions that say "You need to install this module." This would mean we'd need to get a list of all functions, classes and constants and map them to available modules. So while this seems like the best UX it is also the hardest to implement and maintain.
2.) Install and enable them all. I assume the problem with this is the box would take more memory and maybe run a bit slower? Also, if we have something in the box that webhosts do not normally have in the PHP it could hide an error that will appear on deploy.
3.) A middle option of some sort? Maybe there are the standard list (see #138) that we could make sure that we have, and then we can allow enabling the rest?
For #3 I think it would make sense to have all well-known extensions already available in
/mods-available/
, just enable the standard ones, and then have an command (API/Console/CLI) to enable the rest?