After 6 months of development, we are pleased to announce that CommandBox 4.0.0-RC.2 is available for your testing. In case you're wondering, RC.1 was released at Into The Box last month, but I was super busy at the time and on the road for 2 solid weeks and didn't have the docs fully updated, so I didn't have a chance to blog it then. A huge thanks goes out to everyone who help contribute ideas, pull requests, and testing for CommandBox 4. This is truly a group effort.
A common question we get now is how to take a CommandBox server and wrap it in a Windows service so it starts automatically at boot time. This is ideal for production use or just a dev site that you always want to stay running. With this new screencast, you will learn how to take any CommandBox server and install it as a Windows service using a free tool called NSSM.
CommandBox is a great product, and it is always improving. Recently, one of those improvements threw a MASSIVE wrench in my world, and it might affect you too. Long story short, ContentBox stores custom modules, themes, widgets inside of the ContentBox module, usually with some tricky gitignore magic, you can ignore the core, and just commit your custom code to your repo. Now, after an update to CommandBox, if you do a
install contentbox --force to update ContentBox around your changes, you might be surprised when CommandBox deletes all of your ContentBox modules, all of your ContentBox themes, all of your ContentBox widgets. Why CommandBox hates us all of a sudden?
The package link and package unlink commands are fairly new to CommandBox and here's a brief screencast that shows you a real life use case for them. The package link command will create a symlink from your current directory into your CommandBox's system modules folder and reload your shell.
Merry Christmas everyone! This is our final installment for this year's 12 Tips of (CommandBox) Christmas! We're leaving this year with a bang as we look forward to what's coming in the future with the next major release of CommandBox CLI.
We've talked about what packages are, how to create them and how to publish them on Forgebox. Now that you have the basics down, we've got some special ninja kung foo magic that will let you crank out modules with almost no effort at all. We obviously can't implement the module for you, but there is a lot of boilerplate around creating the Git repo, scaffolding out files, setting up tests, and publishing. We can turn all that boilerplate into 2 commands. **
** Some one-time setup required
Let's tackle a powerful module today. It will take quite a bit of configuration, but hopefully you will see the usefulness of this module by the end of this post. Meet CommandBox Migrations, a tool for managing and running your database migrations with CommandBox.
For today's 12 Tips of (CommandBox) Christmas blog, we're covering private ForgeBox packages. This has been out for a while but we haven't talked a great deal about it. The idea of private packages is that you want to have packages of code that you and your coworkers use to build your apps and you want to use ForgeBox to list them so you can have CommandBox manage their installation and updating versions. However, these are internal packages that you don't to share with the rest of the world.