In my search for a replacement for Drupal, I started playing with SilverStripe over the weekend.
The site looks pretty good, the demo—while minimal (which is totally fine by me)—seems to work decently. It made my "to test" list.
The bottom line:
FWIW, SilverStripe made my "do not recommend" list today. )-:
A bunch of people replied asking "why?" This is my response to those people. My intent is not to bash SilverStripe, but to explain how it fell short of my wants and needs, quickly.
First stop: the code.
SilverStripe is built on a framework called Sapphire, which is developed by the same folks as SilverStripe (a bit like the CodeIgniter-Expression Engine relationship, I guess). A [very] quick look through the tutorials had me interested, and the actual functionality of SilverStripe seems to be something we could work with. I downloaded it, unpacked the archive, and dove straight into the code.
Again, maybe my expectations are too high.
Here's an excerpt from the root index.php.
<p><![CDATA[ // For linux $_SERVER['SCRIPT_FILENAME'] = str_replace('/index.php','/sapphire/main.php', $_SERVER['SCRIPT_FILENAME']); $_SERVER['SCRIPT_NAME'] = str_replace('/index.php','/sapphire/main.php', $_SERVER['SCRIPT_NAME']); // And for windows $_SERVER['SCRIPT_FILENAME'] = str_replace('\\index.php','\\sapphire\\main.php', $_SERVER['SCRIPT_FILENAME']); $_SERVER['SCRIPT_NAME'] = str_replace('\\index.php','\\sapphire\\main.php', $_SERVER['SCRIPT_NAME']); chdir('sapphire'); require_once('sapphire/main.php'); ]]>
The useless str_replace calls aren't a huge problem, but they demonstrate sloppiness. It's easy enough to detect whether or not we're on Windows (hint: the PHP_OS constant) without redundantly replacing everything twice.
What really got my attention was the chdir call. They must have some reason to do this, but it's almost certainly a bad one. At the very least, it should have a comment indicating why they'd do something weird like this.
Next, sapphire/main.php (excerpt; the first two executable lines in the file):
<p><![CDATA[ $majorVersion = strtok(phpversion(),'.'); if($majorVersion < 5) { ... ]]>
This raised all kinds of warning flags to me. Maybe they're worried about PHP_VERSION constant being missing from some old versions of PHP (to their benefit, the manual doesn't say when this was introduced), and that's why they've decided to use the phpversion() function. There is, however, a function built in to PHP to compare versions: version_compare(). That's the safest way to do this. A more obscure, but faster way to handle this is to check if a function or class only defined in 5.x exists.
.htaccess also hints at something weird:
<p><![CDATA[ <Files *.ss> Order deny,allow Deny from all Allow from 127.0.0.1 </Files> ]]>
"What's this *.ss stuff?" I wondered. It's SilverStripe's templating system. I didn't even bother to see how they're interpreted, but they're apparently not PHP-based, with syntax such as <% base_tag %> and $SilverStripeNavigator (the latter was not within tags of any sort).
I made it through barely a handful of files before deciding to just plug my nose and ignore the code, hoping that I would be so blown away by the functionality that I would forget what lies under the covers.
I tried the installer. It complained that I didn't have the mysql extension built. Fair enough, it's true. I didn't have the mysql extension. I did have pdo_mysql and mysqli but no, I didn't have the ancient extension installed. I expected better.
Once I rebuilt PHP with mysql-proper support, I went through the installation process, and when it finished, I was redirected to a page that said "The requested page couldn't be found." So, I gave up.
I could probably fix that problem, and none of the other problems on their own are insurmountable, but combined, they leave me with the impression that the code isn't what I'd like to commit to maintaining.
The search continues...
