Solar 0.26.0 Released, and New Website

The first new release of Solar in three months, version 0.26.0 alpha, has arrived! There are over 150 separate changes and improvements noted in the change log.

In conjunction with the new release, we have a brand new website. The site design is from Matt Brett, the CSS and hosting are courtesy of Clay Loveless, and the logo was designed by Ben Carter.

The single biggest change is a move from the Facade pattern to the Factory pattern for classes using adapters, such as Access, Auth, Cache, Log, Sql, and Role. If you’ve been using Solar::factory() to create your adapter instances, you should have no problems at all with this change, because the mechanics of instantiation are encapsulated for you.

The front-controller and page-controller now support automatic discovery of alternative output formats from the URI. For example, if the URI ends in ".rss" and that page-action allows the ".rss" format, the controller will automatically load up the ".php.rss" view and turn off the layout (instead of just the ".php" view with the default layout). This means you can use one action method to provide data for multiple output formats automatically.

Solar_Sql has a lot of little improvements: built-in profiling, emulated prepare-statment using PDO, new fetch*() methods to eventually replace the select(*) method, table-column definition retrieval via fetchTableCols(), and much more.

There’s a new data filter class, although it has not been incorporated to the rest of Solar yet (look for that in a future release).

Finally, with a lot of work from Travis Swicegood, we have moved to PHPUnit3 for unit testing. Much as I love Solar_Test, there are some good arguments against using the testing library embedded in a framework to test the framework itself.

The full log of change notes follows, but it is really long, so consider yourself warned. 😉

Continue reading

Sanitation with PHP filter_var()

I’m adding a combined validate-and-sanitize class to Solar, Solar_DataFilter. It uses some of the new filter extension functions internally.

However, I found a problem with the “float” sanitizing function in the 5.2.0 release, and thought others might want to be aware of it. In short, if you allow decimal places, the sanitizer allows any number of decimal points, not just one, and it returns an un-sanitary float.

I entered a bug on it, the text of which follows:

it seems to allow any number of decimal points, not just a single
decimal point.  This results in an invalid value being reported as

Reproduce code:
$val = 'abc ... 123.45 ,.../';
$san = filter_var($val, FILTER_SANITIZE_NUMBER_FLOAT,

Expected result:
float 123.45

Actual result:
string(12) "...123.45..."

The bug has been marked as bogus, with various reasons and explanations that all make sense to the developers. “You misunderstand its use” and “it behaves the way we intended it to” seem to be the summary responses.

However, I would argue that intended behavior is at best naive and of only minimal value. If I’m sanitizing a value to be a float, I expect to get back a float, or a notification that the value cannot be sanitized to become a float … but maybe that’s just me.

Regardless, I’m not going to belabor the point any further; I’ll just avoid that particular sanitizing filter.

Update: Pierre responds with, essentially, “RTFM.” I agree that the manual describes exactly what FILTER_SANITIZE_NUMBER_FLOAT does. My point is that what it does is not very useful. I think it’s reasonable to expect that a value, once sanitized, should pass its related validation, and the situation described in the above bug report indicates that it will not. My opinion is that the filter should either (1) attempt to extract a float value, or (2) indicate in some way that the value cannot be reasonably sanitized (in the sense that the returned value is not “sane”). Since it does not, and since the developers seem unwilling to accept that approach, I’ll just avoid using that filter and write my own.

Update 2: Something just occurred to me. Pierre says in the comments that accepting “abc … 123.45 ,…/” to create a float is a bad idea. Yet the PHP float sanitizer will happily accept “,/45″ and return a float that will validate. Is *that* a good idea? If so, why?

New Year’s Benchmarks

After the previous round of benchmarking, I received one very good criticism from Matthew Weier O’Phinney about it. He suggested that the hardware I was using, a PowerPC G4 Mac Mini, had an I/O system that was not representative of what a "regular" user would have as a web server. I have to agree with that.

As such, I have prepared a new set of benchmarks for Cake, Solar, Symfony, and Zend Framework using an almost identical methodology as last time.

Much of this article is copied directly from the previous one, as it serves exactly the same purpose, and little has changed in the methodology. Please consider the older article as superseded by this one.

Continue reading