Followers of my Github profile may have noticed the arrival of a new member of the family a few weeks ago. SilverSmith is now open source! (UPDATE: Documentation has been added to README.md)
Gone is the monolithic, single file that sat way upstream in your filesystem. The newest version of SilverSmith looks much more like a standard SilverStripe module. Here’s what’s new:
- SilverSmith is now for SS 3.0+ only.
- SilverSmith is now broken into many separate files and adheres to a much more logical organization of code.
- SilverSmith can be installed on a per-project basis, offering a command-line executable within its own directory structure (/silversmith/bin/silversmith)
- The executable can be installed globally so all your projects can have access to SilverSmith CLI tools. (/silversmith/bin/cli_install). By open sourcing the install script, my hope is that we can refine it to a point where there are few, if any, installation issues.
- The dreaded MAMP failure “Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock” will be detected and addressed with the new “fix-mamp” command
- SilverSmith will auto-update with Git, and will soon follow the more conventional Composer.
The 3.0 Quandary
I would never say that it’s anything permanent, but for now it makes the most sense to me to make SilverSmith a 3.0 tool. Most users are not going to install SilverSmith retroactively on an existing project. Rather, it’s something they’ll try for new work, which is much more likely to be in the current version of SilverStripe. Adding 2.4 support is entirely possible using a new branch, but it raises questions about how to handle the global installation of the executable (would there be a “silversmith2″ script?). It seems like we’re at a perfect juncture to embrace 3.0 and get people using SilverSmith on their new projects.
Up ahead are a series of improvements to the SilverSmith ecosystem to make it a more viable tool.
Priority #1: Documentation and Resources
Silversmithproject.org will get a makeover and become a space for a variety of how-to’s and other resources for SilverSmith including:
- Getting started
- YAML library (see below)
Priority #2: The GUI
Now that SilverSmith is a true SilverStripe module, we now have the foundation to build a SilverSmith GUI right in the SS3 backend. It will loosely follow the original GUI for SilverSmith, without the code editing tools. The main features will include:
- Visual YAML builder
- Template Genius
- Translations editor
- Content seeding/population
Priority #3: A Plugin System
In earlier iterations of SilverSmith, the application depended heavily on thirdparty tools — in fact, it knew nothing about how to create a ComplexTableField or FileIFrameField. It lived in a world where everyone used DOM and Uploadify, and even its own custom form fields, forcing the user to deploy the SilverSmith application into production. That’s too much dependency for an application that markets itself as a time-saving, lightweight project kickstarter.
Rather than having SilverSmith talk to thirdparty modules, the reverse should be the case. Developers of thirdparty modules should make their code SilverSmith aware. SilverSmith will detect the existence of specific configuration files that tell SilverSmith about a new form field or new snippet of code that can be abstracted into YAML. Plugins should be installable globally or on a per-site basis.
Priority #4: The Community
One of the visions I’ve had all along for SilverSmith is the idea of free-flowing code that could be painlessly shared and modified. Because the main diet of SilverSmith is plain text (YAML), it follows easily that this code could be shared with almost no overhead. I would love to see data models shared the same way frontend themes are today — get 90% of what you need in a single download, and refine the details inexpensively and intuitively. Both the CLI and the GUI tool should have exposure to some sort of central repository of these snippets.