Anyway, the solution to the issue is to build locally and deploy to the server. You can use rysnc with exclusion of certain folder/files with the delete option to clean out dead wood or any number of deployment tools. If all you have is ftp, then you may have to clean up yourself. RDP could also be used for windows.
I suggest that the Vanilla team come up with non partisan local build script, without too many dependencies. Possibly some simplified ways to deploy. Rather then doing this on the production server.
Deployment tools and package managers are flavours of the month, they are very much personal to that particular developer/community. A choice should make sense for the application and audience.
It's really just ./bin/release in the Vanilla root.
I think the blocker at the moment for it useful, is that since we use it for our own releases, it clones a fresh copy of Vanilla (due to the numerous times that personal files slipped into releases).
If I made a "dirty" version of that script you would be able to make a dropdown in release bundle of whatever's on your local computer as long as you have php, composer, node, and yarn.
Yes, I'm willing to add an additional installation step to use certain addons
Late to the vote but I'd be fine with it as I'm probably the exception by the sound of it, running VF on a DigitalOcean droplet so SSH and root access is easy for me.
Coming from a shared hosting platform myself, I do shared hosting for cost. I am able to run as many sites as I want that fits in 5GB of data for $50 US a year.. You cant beat $4.16 a month to host like 12 sites!! I am not a developer in the traditional sense with a Unix box and local development and Git etc... I look for scripts that I can just plop on the server via FTP and hit the install script. I have dev and live for my sites both on the same server just different URLs. If i had to install and compile stuff on my local machine (windows Machine) I would most likely skip the product when searching. There were so many other forums that I wanted to use before I found Vanilla but all had requirements that my hosting company could not support like docker, Node etc.. When I found Vanilla I was like this is awesome! And the more I am getting into plugin customization I'm like this Garden crap you guys use is AMAZING!!! It like the forum its self is one large application plugged into Garden. I love the Methods and object oriented way of doing things and it just makes sense!
If anything I would update the documentation as it is old and hard to read from a novice programmer point of view. The forum is a great resource but its hard to know when people discuss code from 2.6 if its relevant to 3.3. I am constantly told to look at code examples from other plugins as a resource which is great but at the same extent most plugin have been not touched since 2.6 and you don't know if the code you are looking at works or not :)
Just my opinion but leave Vanilla as a drag to server and drop install and not a compiled application or else you will scare away the novice users Next to that if you do go to compiled make sure you write a step by step of how to install this on every platform and what they have to ask their hosting provider they support to install this.
I'm okay with additional installation steps.. however i must note something.
Vanilla ( as of 3.x ) is not very good at checking for it's requirements during install. The install/initial bootup scripts need to check for these things. PhpBB does a good job of this and shows a series of check marks and red X indicators.. vanilla can just bomb with weird error messages.
This little refinement would probably increase adoption itself by lowering sys admin frustration when trying out this new software. I'm personally capable of figuring these kinds of things out, but consider that most OSS users aren't web developers and linux administrators on the side :)
No, I can't/won't add an extra installation step to use certain addons
@charrondev I haven't been here for a long while so forgive me for resurrecting the original question. Would it be a reasonable "compromise" if plugins would need react.js library but not node.js? Adding JS libraries is easily available for hosted environments (obviously).
I'm asking because your original post mentioned react features several times...
Comments
Anyway, the solution to the issue is to build locally and deploy to the server. You can use rysnc with exclusion of certain folder/files with the delete option to clean out dead wood or any number of deployment tools. If all you have is ftp, then you may have to clean up yourself. RDP could also be used for windows.
I suggest that the Vanilla team come up with non partisan local build script, without too many dependencies. Possibly some simplified ways to deploy. Rather then doing this on the production server.
Deployment tools and package managers are flavours of the month, they are very much personal to that particular developer/community. A choice should make sense for the application and audience.
grep is your friend.
Also looking into separation of concern to make pre-building more feasible.
VM/docker could also be used as a local build environment.
grep is your friend.
Right now there is a single build script that for the most part works already.
It's really just
./bin/releasein the Vanilla root.I think the blocker at the moment for it useful, is that since we use it for our own releases, it clones a fresh copy of Vanilla (due to the numerous times that personal files slipped into releases).
If I made a "dirty" version of that script you would be able to make a dropdown in release bundle of whatever's on your local computer as long as you have php, composer, node, and yarn.
Late to the vote but I'd be fine with it as I'm probably the exception by the sound of it, running VF on a DigitalOcean droplet so SSH and root access is easy for me.
Coming from a shared hosting platform myself, I do shared hosting for cost. I am able to run as many sites as I want that fits in 5GB of data for $50 US a year.. You cant beat $4.16 a month to host like 12 sites!! I am not a developer in the traditional sense with a Unix box and local development and Git etc... I look for scripts that I can just plop on the server via FTP and hit the install script. I have dev and live for my sites both on the same server just different URLs. If i had to install and compile stuff on my local machine (windows Machine) I would most likely skip the product when searching. There were so many other forums that I wanted to use before I found Vanilla but all had requirements that my hosting company could not support like docker, Node etc.. When I found Vanilla I was like this is awesome! And the more I am getting into plugin customization I'm like this Garden crap you guys use is AMAZING!!! It like the forum its self is one large application plugged into Garden. I love the Methods and object oriented way of doing things and it just makes sense!
If anything I would update the documentation as it is old and hard to read from a novice programmer point of view. The forum is a great resource but its hard to know when people discuss code from 2.6 if its relevant to 3.3. I am constantly told to look at code examples from other plugins as a resource which is great but at the same extent most plugin have been not touched since 2.6 and you don't know if the code you are looking at works or not :)
Just my opinion but leave Vanilla as a drag to server and drop install and not a compiled application or else you will scare away the novice users Next to that if you do go to compiled make sure you write a step by step of how to install this on every platform and what they have to ask their hosting provider they support to install this.
Yes, I'm willing to add an additional installation step to use certain addons
On shared hosting. So if we have to add steps to install vanilla, I may be forced to find another forum software.
I'm okay with additional installation steps.. however i must note something.
Vanilla ( as of 3.x ) is not very good at checking for it's requirements during install. The install/initial bootup scripts need to check for these things. PhpBB does a good job of this and shows a series of check marks and red X indicators.. vanilla can just bomb with weird error messages.
This little refinement would probably increase adoption itself by lowering sys admin frustration when trying out this new software. I'm personally capable of figuring these kinds of things out, but consider that most OSS users aren't web developers and linux administrators on the side :)
@charrondev I haven't been here for a long while so forgive me for resurrecting the original question. Would it be a reasonable "compromise" if plugins would need react.js library but not node.js? Adding JS libraries is easily available for hosted environments (obviously).
I'm asking because your original post mentioned react features several times...