SlickStack is a free LEMP stack automation script written in Bash designed to enhance and simplify WordPress provisioning, performance, and security. It is the result of several years of research and work by Jesse Nickles in pursuit of market-leading technical SEO signals.
Initially, the collection of scripts and settings were semi-private and being used solely by LittleBizzy as part of their managed WordPress hosting offering, but eventually the codebase was split off into a dedicated open source project on GitHub. Going forward, SlickStack aims to promote “free speech” just as much as “free software” in an effort to revive some of the open web values that have all but disappeared from the WordPress project lately (whose dominance among web-based CMS applications continues to grow stronger).
Our Core Values
Per that framework, we consider our core values to be:
- free speech
We believe that when values like these are a real priority, it becomes more obvious why FOSS software should not be in the business of making secret “backroom” deals with strategic partners, lying about who runs their project (and websites), censoring and banning users who ask legitimate questions, selectively enforcing their self-professed guidelines, and trying to spy on users with undisclosed cookies, analytics, or otherwise.
Unfortunately, this type of behavior is precisely what the WordPress project has devolved into in recent years.
Most of modern computing history can be traced back to one thing: Unix. Indeed, one of the only things about web servers that hasn’t changed much in several decades is the Unix shell (Bash) command language. Keeping the same pragmatism and simplicity in mind that inspired LittleBizzy’s managed hosting, SlickStack [ss] is coded entirely in Bash.
While there are clear benefits to programming languages like Python or Ruby, provisioning a server with WordPress isn’t very complicated, and every Linux machine comes with Bash built into it. Plus, let’s not forget what happens when typical web agencies rely on advanced dependencies like Ansible… yikes! Onward, then…
Rules of SlickStack
- Don’t alter system files that don’t need to be altered
- Don’t compile core modules from third party sources… if it’s not available as a native package for Ubuntu LTS the we don’t support installing it
- If you do need to alter system files, make it less invasive as possible by “source” SlickStack files instead of dumping code in the system files
- Never prevent native Bash commands from working properly (aliases should be complementary, not replacements)
- Verbose filenames, code comments and bash syntax in all scripts whenever possible (be specific… what is happening?). Unlike WordPress itself, SlickStack users are expected to interact with the bash scripts regularly (and look at their contents) so we need the filenames and contents to make sense to a typical (beginner) web developer. Instead of “ss-install-wp” our scripts are divided into core packages and config for each module so “ss-install-wordpress-core” and “ss-install-wordpress-config”… which one do you really want to run? This helps users understand exactly what our files do and thus helps them to be more specific when running the scripts. Our bash alias shortcuts are easier/faster however, for advanced users who want to save time on keystrokes… thus “ss install wp” will install both WordPress core and also WordPress config in one generic command.
- Once and only once, unless it will create instability… see #4
- Defer to upstream whenever possible… if Ubuntu LTS uses MySQL and PHP 7.2 then we use MySQL and PHP 7.2, etc
- Self-contained whenever possible… nearly all SlickStack files are solely under /var/www
- Self-reliant whenever possible… SlickStack servers will still function when third party services are removed
Because this topic involves our core philosophy, we keep it under the About section.
Making things simple actually takes a lot of planning sometimes. For SlickStack, one of our main objectives is to simplify the file structure of “core” files in our LEMP stack as much as possible. Over the years, a messy stack is one of the most common annoyances and sources of confusion among developers.
Here’s a few of our rules:
- ss core bash scripts must begin with ss- and have a human readable name e.g.
- ss core cron jobs must begin with a number and human readable name e.g.
- root crontab does nothing besides source the ss core cron jobs
- ss core cron jobs source ss core bash scripts, and also have integrity checks of ss-config, ss-functions, ss-check, and ss-worker