Flourish Blog

Cutting Down on Spam

will@flourishlib.com — Wed, 15 Jun 2011 15:03:34 EDT

Last night I got fed up with the spam that was getting through on the forum and in tickets. While Akismet and the built-in spam filtering in Trac cut out 99.9% of spam, it is frustrating for site participants to get notification emails about spam posts.

In order to cut down on the spam messages even more, I've changed the site to require a user account to post. After finding almost 9,000 spam accounts created on the site, I've also implemented reCaptcha on the registration form.

I apologize for the inconvenience of registering and logging in to participate, but I hope these steps can help keep the site even more spam free and keep the notifications relevant and frustration-free.

If you haven't already created an account, jump over to the registration page and sign up!

Alter Table Improved, Especially for SQLite

will@flourishlib.com — Tue, 24 May 2011 15:03:19 EDT

A frequent complaint among developers dealing with relational database systems is dealing with database migrations. Depending on the size of the data you are working with, that may be the issue, however the syntax and features of ALTER TABLE statements vary greatly between database systems. I’ve recently added some functionality to Flourish to make ALTER TABLE statements not only more pleasant to work with, but consistent across MySQL, PostgreSQL, SQLite, Oracle, DB2 and Microsoft SQL Server.

Implementation

Flourish now supports a full complement of ALTER TABLE statements that will run on MySQL, PostgreSQL, SQLite, Oracle, DB2 and Microsoft SQL Server. You can now write a single SQL migration script and run it on any supported database. fDatabase::translatedQuery() and fDatabase::translatedExecute() will utilize the new fSQLSchemaTranslation class when CREATE TABLE, ALTER TABLE, DROP TABLE and COMMENT ON COLUMN statements are run.

Rather than trying to abstract the SQL language into PHP method calls, I’ve always opted with Flourish to translate SQL to the various dialects supported by the database in question. The goal here isn’t to provide an abstraction layer, but a translation layer. If you look at the guts of fSQLSchemaTranslation you’ll see there is quite a bit of pattern matching, SQL statement manipulation and schema catalog lookups.

If you use PostgreSQL or Oracle you are probably used to fairly robust support for SQL DDL statements. Unfortunately some of the other supported systems are a bit more painful to use. For MySQL, foreign key constraints must be dropped before any operations can be performed on the column or table they are associated with, and then once the operation is complete they must be re-created. SQL Server requires similar requirements for dropping and re-creating constraints, but even goes to the extreme of requiring it for default value constraints. SQLite barely supports any ALTER TABLE statements in version 3 and nothing is supported in version 2. DB2 requires some management of constraints, but also that you explicitly reorganize the table index after specific statements.

What it comes down to is that to support more than a single database system, you end up having to handle all of these edge cases for each database system. This significantly slows down the development process and can be a downright frustrating experience. Flourish is here to help with that.

Show Me the Code!

Here is a basic example of how you can create a database table that work on six different database systems. If you really want to dive right into the supported syntax, please check out the FlourishSql page.

As I mentioned above, all of this functionality I’ll be explaining works through fDatabase. You don’t actually need to worry about the fSQLSchemaTranslation class at all. The class is separate from fSQLTranslation due to its sheer size, over five thousand lines of code. Simply pass a FlourishSql statement to fDatabase::translatedQuery() or fDatabase::translatedExecute() and you are in business.

$db = new fDatabase('sqlite', './path/to/db');
 
$db->translatedExecute("
    CREATE TABLE users (
        user_id INTEGER AUTOINCREMENT PRIMARY KEY,
        name VARCHAR(200) NOT NULL,
        email VARCHAR(200) NOT NULL UNIQUE
    )
");

Some of the nicest features of the translation layer in Flourish is that it handles even the gnarly edge cases like auto-incrementing integer primary keys. If you’ve ever worked with more than one database system I’m sure you are aware that they all have completely different syntax for this. PostgreSQL uses the SERIAL data type that implicitly creates a sequence. MySQL has a special keyword AUTO_INCREMENT. SQL Server uses an IDENTITY properly on the column. Oracle is possibly the most painful, requiring an explicit sequence to be created and then a trigger created to select values from the sequence and insert them into new records.

CREATE TABLE support is all great and dandy and, in fact, Flourish has supported that since early on. What you really need to maintain an app that supports multiple databases is ALTER TABLE support. Here are some example statements:

$db->translatedExecute("
    ALTER TABLE users ADD COLUMN password VARCHAR(80) NOT NULL DEFAULT '';
    ALTER TABLE users ALTER COLUMN password DROP DEFAULT;
    ALTER TABLE users RENAME COLUMN email TO email_address;
    ALTER TABLE users ALTER COLUMN name TYPE VARCHAR(250);
");

Useful Shorthand

In addition to creating consistent syntax across all of the supported database systems, Flourish provides simple shorthand syntax for dealing with constraints. For many database systems it is necessary to use system-generated constraint names when dropping constraints, and for some it is necessary to create explicit constraint names upon creation.

Here are examples of the shorthand available:

ALTER TABLE table ADD PRIMARY KEY (column) AUTOINCREMENT;
ALTER TABLE table ADD UNIQUE (column1, column2);
ALTER TABLE table ADD FOREIGN KEY (column) REFERENCES other_table(column) ON DELETE CASCADE;
ALTER TABLE table ALTER COLUMN column SET CHECK IN ('Value 1', 'Value2');
 
ALTER TABLE table DROP PRIMARY KEY;
ALTER TABLE table DROP UNIQUE (column1, column2);
ALTER TABLE table DROP FOREIGN KEY (column);
ALTER TABLE table ALTER COLUMN column DROP CHECK;

You can visit the FlourishSql page for a complete list of all of the supported syntax.

Testing

This sort of functionality wouldn’t really be possible without extensive testing. The addition of fSQLSchemaTranslation was joined by over 1500 new tests (when run on a server with all database extensions). Between the 12 different machines and configurations Flourish is tested on, the grand total number of tests run on each commit increased by well over 10,000 tests.

That said, the SQLite support is probably the least robust. While I’ve fairly extensively tested that SQLite tables created from FlourishSql statements can be altered, I would imagine there are some statements that may not work properly on all databases. Luckily SQLite supports DDL statements within transactions, meaning that your database will remain in a good state even if something fails. If you do experience any issues with SQLite, please open a ticket with your CREATE TABLE statement and the ALTER TABLE statement you executed, and I’ll fix fSQLSchemaTranslation to handle it.

Atomic Nature

One of the other things I set as a requirement for implementing ALTER TABLE support was to make individual statements atomic in nature. While it is certainly possible that a SQL statement may fail, baring extenuating circumstances with MySQL or DB2 such as a hard drive being full, Flourish can ensure your database will either remain in its original state, or be properly altered.

To make sure that operations are performed completely, or not at all, there are around 40 tests run per database system to test the atomic failure of ALTER TABLE statements. So like I said before, under normal operating conditions, Flourish will keep your database in a good state.

As I mentioned, there are some edge cases with MySQL and DB2. Unfortunately MySQL does not support DDL statements within transactions, and additionally, it requires removing foreign key constraints for many operations. fDatabase and fSQLSchemaTranslation are written in such a way that rollback statements are created in case a statement fails. These rollback statements undo any partially complete changes. It is theoretically possible that a situation arises where MySQL will not permit the rollback statements to run if a serious error occurs.

In a similar vein, DB2 support transactions for DDL statements, but requires table reorganization to occur after certain statements. This reorganization implicitly commits any open transaction. The failure edge case for DB2 would be if the primary statement succeeds and the reorganization succeeds, but remaining statements that re-create constraints fail.

What’s Next

While this new functionality has undergone quite a bit of testing on my end, I’m sure there are some edge-case bugs. It will certainly become more robust over time as people like you take the time to open tickets and report bugs.

PHP|Tek 2011

will@flourishlib.com — Wed, 18 May 2011 13:01:16 EDT

One week from today, the annual PHP|Tek conference returns to Chicago for the 2011 edition. I'm excited that I'm able to attend this year, and I'd love to meet some Flourish users in person! So, whether you want to ask questions, suggest improvements, or grill me on the finer points of how to over-use regular expressions, I'm down. :-)

The easiest way to get in contact will be through Twitter. I set up a separate twitter account, @flourishlibconf, for conferences so that I don't end up spamming normal followers. I'll also be available via my personal account, @wbond, but I'm going to try and keep that to replies. I look forward to meeting you there!

PHP Floating Point Bug

will@flourishlib.com — Fri, 14 Jan 2011 14:02:02 EST

Just last week a rather serious denial of service (DoS) vulnerability was found in PHP, affecting versions 5.2.0 through 5.2.16 and 5.3.0 through 5.3.4. The bug, #53632, causes PHP to enter an infinite loop when working with the value 2.2250738585072011e-308 as a floating point number. The simple submission of this value to a site multiple times can easily cause the web server to become unresponsive to users.

The good news is that if you are using fRequest::get() and passing float to the $cast_to parameter and Flourish r950 or newer, you will be automatically protected from this vulnerability. The value 2.2250738585072011e-308 will be converted to 2.2250738585072012e-308, which resolves to the same floating point value, but does not cause the infinite loop.

If you are using an older revision of Flourish, I strongly recommend you use the flourish.rev file in your Flourish directory with the backwards compatibility breaks page to upgrade your code to the latest revision.

Testing Across 12 OSes, 10 Versions of PHP and 6 Databases

will@flourishlib.com — Wed, 04 Aug 2010 14:02:30 EDT

Part of the goal of Flourish is to provide a solid library of code to build web apps and websites on top of. Since PHP runs on such a variety of operating systems and many users do not control the server they are installed on, operating system and PHP version compatibility is important. Thanks to recent donations by iMarc and Luke Foreman, the testing setup has been expanded to include OS X 10.6 and Windows Server 2008.

With these changes, over 60,000 tests are run with every SVN commit, on a total of 10 different versions of PHP, running on 12 different server environments. All database-related tests are run on the six supported databases, and most are run using each of the 14 supported database extensions against eight different database versions. In situations where Flourish provides a pure-PHP fallback implementation of a non-standard PHP extension, the tests are run both with the non-standard extension loaded and not.

Operating Systems

CentOS 5.3
Debian 5.0
Fedora 12
FreeBSD 7.2
NetBSD 5.0.1
OpenBSD 4.5
OpenSolaris 2009.06
OpenSuSE 11.2
OS X 10.6
Ubuntu 8.04 LTS
Windows Server 2008
Windows XP

PHP Versions

5.3.3
5.3.2
5.3.1
5.2.13
5.2.12
5.2.9
5.2.8
5.2.6
5.2.4
5.1.6

Databases

DB2 Express-C 9.7
MySQL 5.0
Oracle 10g XE
PostgreSQL 8.3
SQLite 2
SQLite 3
SQL Server 2005
SQL Server 2008

At the end of the day, this helps to ensure that Flourish will work if you deploy it on a RHEL 4 server running PHP 5.1.6, a Windows Server 2008 machine running PHP 5.3.3 or a Solaris box with PHP 5.2.9.

The Setup

Throwing around numbers is great and all, but I'd like to touch on the setup a little bit. Flourish uses PHPUnit for unit and integration tests. And yes, many of the test aren't true unit tests. Since portability and compatibility are key, I want all of the code to actually run. If I were to have written pure unit tests, I would have mocked all sorts of dependencies and missed quite a number of bugs in PHP and bizarre edge cases.

tests.php example output

PHPUnit contains an awesome amount of functionality, however when I started with it, it did not allow for running tests with different PHP configuration. I wouldn't be surprised if Sebastian has added the functionality in 3.4 or 3.5, but I started this whole process back with 3.3 so I created my own solution. There is a PHP test runner tests.php that parses class config files and runs the tests once for each different configuration. It has evolved over time, and isn't the prettiest thing I've ever written, but it gets the job done.

tests.php includes some other functionality, including a column-based, color-coded shell output for interactive testing and JSON output for automated testing. It allows for configuration values to be passed at run time (through a nasty PHP ini hack) so that passwords don't need to be hard coded in the tests and inadvertantly leaked through a source code repositories. In addition, you can included or exclude specific classes and filter the configurations to be run.

remote_tests.sh example output

Once the local test runner once was written, I went to work setting up a bunch of virtual machines. There are a total of 12 VMs running on two different physical machines, an Intel i7 quad-core with 8GB of ram and a dual-core iMarc with 3GB ram. One of the virtual machines runs DB2, MySQL, Oracle and PostgreSQL, while another runs SQL Server 2005 and 2008. Every machine, including Windows, is running OpenSSH, allowing for key-based authentication and distribution of the tests. I leave the stock OS configuration alone as much as possible, but install PHP, various extensions, PHPUnit, some command line database programs and configure the various local sendmail implementations to route through an SMTP relay. Where possible I use the OS-supplied PHP packages in an effort to find bugs related to common environments.

To run the rests on the virtual machines, I use a custom bash script remote_tests.sh that scps a tarball to each machine and then invokes tests.php over ssh. remote_tests.sh allows for parallel execution of the test scripts for the different database types, however I found that performance decreased due to disk thrashing. It also allows checking the remote server configuration to show the installed PHP version and the install status of both required and optional PHP extensions.

I haven't spent much time abstracting or refining this setup for use by others, but I could see it being useful for library and framework maintainers. You can check out the code at http://github.com/wbond/flourish/tree/master/tests/.

Offline Documentation

will@flourishlib.com — Mon, 02 Aug 2010 15:03:47 EDT

After a handful of requests, I finally took some time this weekend to create some offline documentation for Flourish. Starting with r879, every SVN commit and every time a class documentation page is updated, a single HTML page is created that contains all of the class documentation, API reference, and relevant general documentation.

The file uses the data URI scheme to allow for a single file containing all HTML, images, CSS and javascript. As long as you aren't using Internet Explorer, you'll even see the Flourish favicon.

Unfortunately, IE6 and IE7 don't support the data URI scheme and thus may not show all images. You probably won't want to use IE anyway, since it can't handle the 4mb of HTML without slowing to a crawl. Chrome, Firefox, Opera and Safari all seem to perform just great.

Head on over to the Documentation page to grab a copy while it's hot!

Do You Use ODBC?

will@flourishlib.com — Tue, 22 Jun 2010 09:09:10 EDT

Recently I've been running into more issues with ODBC not properly handling UTF-8 and blob data across the various databases that Flourish supports. I'm very strongly considering dropping ODBC support due to the fact that:

None of the ODBC database drivers pass the tests on any OS but Windows
There is no way to tell DB2 to use the UTF-8 encoding with ODBC
Oracle via ODBC fails with UTF-8 so some characters must be escaped using CHR()
CURRENT_TIMESTAMP isn't implemented for Oracle when using ODBC
The pdo_odbc driver in PHP 5.3 returns seemingly random data from an MSSQL blob column

Does anyone currently use an ODBC connection with fDatabase?

Update

7/31/10 - As of revision 879, ODBC support is no longer provided in any of Flourish's database classes. ODBC support was removed since it was holding back perfect UTF-8 support, caused stability issues on some servers and did not appear to be used by anyone.

DB2 Support Added

will@flourishlib.com — Wed, 14 Apr 2010 08:08:10 EDT

Last night I completed the final additions to the core database layer of Flourish by adding support for IBM's DB2. Along with support in all of the core database classes, such as fDatabase and fResult, DB2 support was added to fSchema and fSQLTranslation, which means that DB2 is fully supported by the ORM. The Flourish SQL page has been updated to show the non-translated compatibility of DB2 to the other supported databases.

Currently only the ibm_db2 extension is supported for DB2 access due to issues with the others. The pdo_ibm extension currently has serious issues that cause PHP to segfault when trying to access CLOB or BLOB data. The odbc and pdo_odbc drivers are not currently supported because I have not found a way to get proper UTF-8 support on Windows machines. If you have any experience with DB2 on Windows, please check out my post on the IBM developerWorks forum.

In the coming weeks I will be announcing SMTP support for fEmail and some more image manipulation functionality for fImage. Feel free to follow Flourish on Twitter, or subscribe to this blog to learn more when they are released.

Testing Enhancements

will@flourishlib.com — Mon, 29 Mar 2010 23:11:50 EDT

With the addition of comprehensive prepared statement support, I felt it time to invest in an enhanced testing architecture to help ensure that Flourish is as portable as possible. The work described below was possible due to the generous support received through the Server Fund last fall.

The hardware purchased with the server fund included an Intel Core i7 860 processor and 8GB of ram. This hardware is used to run 11 different virtual machines:

Test History Graphs

A Debian database server running MySQL 5.0, PostgreSQL 8.3 and Oracle 10g XE
A Windows XP machine used for running tests and running SQL Server 2005 and SQL Server 2008
Machines for running tests, including the following operating systems:
- CentOS 5.3, PHP 5.1.6
- Debian 5.0, PHP 5.2.6
- Fedora 12, PHP 5.3.2
- FreeBSD 7.2, PHP 5.2.12
- NetBSD 5.0, PHP 5.2.13
- OpenBSD 4.5, PHP 5.2.8
- OpenSolaris 2009.06, PHP 5.2.9
- OpenSuSE 11.2, PHP 5.3.1
- Ubuntu 8.10 LTS, PHP 5.2.4

This extensive combination of operating systems and PHP versions ensure that Flourish is tested on most of the environments that may be encountered in the wild.

To take advantage of this setup, an SVN post-commit hook is used to run the full test suite on all of the servers after each commit. As of the time of writing this article, 5989 tests have been written using PHPUnit. Each server reports the number of tests that passed, skipped, and failed. The Tests page has graphs showing a history of the results for each server.

Flourish has some extensive PHP and shell scripts that allow tests to be run on multiple different configurations per class and on remote servers with little effort. The different configurations allow running the tests with different PHP extensions loaded, or against different types of databases. When an extension or program is not available, or the test is not applicable to the current environment, it is skipped. It is by this functionality that all 16 supported database extensions can be tested.

The current plans for improving this setup include obtaining a Mac Mini or notebook for OS X testing, and a copy of Microsoft Server 2008. If you, or someone you know, would be willing to donate either of these, please contact me at will@flourishlib.com.

Prepared Statement Support Added

will@flourishlib.com — Thu, 04 Mar 2010 16:04:08 EST

Since back in December there has been kind of a lull in activity on Flourish due to some major work adding prepared statement support to fDatabase and re-architecting the tests. The result of this work was a new class added to Flourish, fStatement, that works in combination with fDatabase to provide prepared statement support across all database extensions. You can read more about it in the fDatabase section about Prepared Statements.

A good amount of time was spent adapting the various PHP extension APIs to work with the existing fDatabase::query() style of using data-type-specific placeholders. As you can see below, using prepared statements with Flourish will feel very natural if you have used the other query methods.

// Prepare a statement
$statement = $db->prepare("SELECT * FROM users WHERE user_id = %i");
 
// Execute it any number of times
$user_1 = $db->query($statement, 1);
$user_2 = $db->query($statement, 2);
// …

The fDatabase::prepare() method will create an fStatement object out of database-specific SQL string, while fDatabase::translatedPrepare() will translate the SQL throught fSQLTranslation before creating the object. The object can then be passed in place of a SQL string to fDatabase::query() or fDatabase::unbufferedQuery().

There are a couple of other methods that were added including fDatabase::execute() and fDatabate::translatedExecute(). These function the same as fDatabase::query() and fDatabase::translatedQuery(), respectively, except for the fact that they don't return anything. They will be useful for situations where the result of a SQL statement is not required, such as an UPDATE statement. As you would expect, an fStatement object can be passed as the first parameter to fDatabase::execute().

I'll be posting another blog in the near future with some details of the new testing architecture, which was made possible by the server fundraiser that was run last fall. A quick glance at the Tests page will show that the tests run on each commit have gone up from around 2500 to over 42,000!

Contributing

will@flourishlib.com — Mon, 16 Nov 2009 14:02:12 EST

Recently there has been some increased interest in contributing to Flourish. If you are interested in helping out with the project, I’m sure that everyone who uses it would be very grateful. The way that things of have been going recently, I’m going to start focusing more on approaching a stable release. Over the past year the beta has helped to improve the available functionality, increase its robustness and work out quite a number of bugs.

As the code moves to a stable release, I foresee more of a focus on improving documentation and writing tests. There are also currently a number of tickets for enhancements, plus there are some items on the original roadmap still to tackle.

So, if you do have interest in contributing to the project, please consider how you may be able to help out with:

Writing patches for tickets
Reading the documentation and providing edits or improvements
Writing tests
Answering questions in the forums

I’m currently not looking to add much more to Flourish. Right now it serves as a fairly general-purpose library for website and application development, without being tied into third party services and without getting too much into markup generation. It has fairly good support across different environments and databases, and provides a more stream-lined API for a lot that is already possible with PHP.

Third party services — things like twitter, flickr, payment gateways, etc — all require keeping up with changes to the APIs. I feel that individual libraries will be better able to keep up with changes to the services and providing product-specific features. In regards to the generation of HTML, since there are so many different approaches and styles, I think staying out of that arena as much as possible will help me to stay focused on what Flourish already does.

If you are interested in writing code or editing documentation, please note that you will need to sign a contributor license agreement (CLA) to help protect users of Flourish and myself from legal issues.

New Oracle Support and More Tests

will@flourishlib.com — Thu, 28 May 2009 13:01:00 EDT

After some prodding from a few interested parties, I took it upon myself to add Oracle support to Flourish. There now exists full support for Oracle in the fDatabase, fResult, fUnbufferedResult, fSchema and fSQLTranslation classes. I've targeted Oracle 10g since I have free access to that via Oracle Database 10g Express Edition, however I believe almost all of the functionality should work on older versions.

In addition to adding support for Oracle, I took the past couple of months to add over 1800 new tests that exercise all 16 supported database extensions and cover most of the functionality of the fDatabase, fResult, fUnbufferedResult, fSchema and fSQLTranslation classes.

Like other supported databases, the Oracle support in fDatabase will work with any of the available database extensions for Oracle. This includes OCI8, PDO_OCI, ODBC and PDO_ODBC. From my testing, the ODBC extensions only work on Windows because some of the ALTER SESSION commands executed by fDatabase are not supported by the UnixODBC driver. If you have any details on a better way to configure ODBC on Linux/BSD, please let me know.

In closing I'd like to say thanks to Chris Jones from Oracle and Aurélien Chivot for their assistance during this process!

Discussions and Comments

will@flourishlib.com — Wed, 14 Jan 2009 13:01:26 EST

Just a few days ago I posted links to Flourish on both Hacker News and the PHP Reddit. There has been some great conversation about Flourish on those sites and on a thread over on the CodeIgnitor forums.

If you run across any other conversations, I'd love to hear about them. And as always, please feel free to comment on this post or start a thread with any suggestions or questions you may have.

Flourish Demo Site

will@flourishlib.com — Mon, 05 Jan 2009 13:01:35 EST

If you've never worked with Flourish before, getting started building a site may seem a little daunting. Included below is the description and source code for a production site written with Flourish and SQLite.

The northshorewebgeeks.com site provides a simple list of upcoming and past meetups for the North Shore Web Geeks meetup. Rather than hand-editing the HTML and RSS feeds, Flourish was set up to provide a simple CMS to easily update the information.

Source Code

The source code for the demo can be found in the flourish-demo-site repository on Github. Github has a nice little code browser, so you can view the code without downloading or cloning.

Routing

The site is fairly simple, so I set up Apache with mod_rewrite to create some nice, clean URLs:

/                     # -> index.php  : Home/main page
/rss                  # -> index.php  : RSS feed
/manage               # -> manage.php : Lists all meetups
/manage/add           # -> manage.php : Allows adding a meetup
/manage/{date}/edit   # -> manage.php : Allows editing a meetup
/manage/{date}/delete # -> manage.php : Allows deleting a meetup
/log_in               # -> login.php  : Allows a user to log in
/log_out              # -> login.php  : Lets the user log out
/sup/*                # -> sup/*      : Static files including CSS and images

Anything other than those URLs will cause the page at views/404.php to be shown.

Directory Structure

The files on the filesystem are organized in the following structure:

/                     # The three php scripts that handle requests
/inc/                 # The bootstrap script init.php and config file
/inc/classes/         # The ORM classes
/inc/flourish/        # Flourish classes
/storage/db/          # The SQLite database the source .sql file
/storage/session/     # The PHP session files
/sup/css/             # The CSS files
/sup/img/             # The images
/views/               # The HTML templates for the site

Request Handling

As requests are received, they are routed the appropriate PHP page by mod_rewrite, however each of these pages first runs the bootstrapping code in inc/. Here is an example of the execution order:

config.php -> init.php -> manage.php

Live Instance

The site is currently running live on http://demo.flourishlib.com. You can log in with the following information:

Login: admin
Password: password

Right now the site will allow you to edit anything, however I may need to disabled saving changes if the site is spammed or inappropriate content is added.

Installation

If you wish to run the demo site on your own server, you’ll need to download the source from github and recursively chmod the storage directory to 777. This allows the web server to write to the SQLite database and session directory.

chmod -R 777 /path/to/flourish_demo_site/storage

All files included with the demo site, except for graphics and CSS files, are licensed under the MIT license. Graphics and CSS files are only provided for demo purposes. Please see the license.txt file for more details.

SQLite 3.2.8 Binary

will@flourishlib.com — Sat, 03 Jan 2009 23:11:43 EST

If you are working with a server running PHP 5.1.x (such as a VPS with CentOS 4) you may have run into an issue with using SQLite as a database. The version of the sqlite3 command line program is 3.3.6, however the version of the SQLite library used for the PDO SQLite driver is 3.2.8. To complicate matters further, between versions 3.2.8 and 3.3.0 the database file format was changed in a way that databases created by 3.3.0 and newer are not readable by 3.2.8 and before.

In practical terms, this means you can't use the sqlite3 binary provided by the OS to create a database to use with PHP.

Unfortunately the SQLite website has removed all source and binary files for everything before 3.6.x. While I was unable to find a 3.2.8 binary for linux, I was able to find a copy of the source tarball from an old Ubuntu repository, and I have mirrored it here along with a statically linked binary that I compiled.

Downloads

Simple/Quick Instructions

The following directions will allow you to create a new SQLite 3.2.8 database on any linux server where you have SSH access:

Log onto the server
Execute: wget http://static.flourishlib.com/sqlite_3.2.8/sqlite3
Execute: chmod 755 sqlite3
Create a database: ./sqlite3 my_new_db

Compiling

If the pre-compiled binary I provided above does not work on your system, you should be able to fairly easily compile your own binary. You'll need standard compilation tools such as gcc, make, etc installed on your system.

tar xvfz sqlite3_3.2.8.tar.gz
cd sqlite-3.2.8
./configure --disable-tcl --disable-shared
make

Once those four steps are complete, there will be an executable named sqlite3 in the current directory. You can use that to create databases that will be compatible with the PDO SQLite driver in PHP 5.1.x.

Announcing the Flourish Beta

will@flourishlib.com — Wed, 19 Nov 2008 13:01:00 EST

After about a year and a half of development and approximately 150k lines of code changes, Flourish is now officially in beta.

Flourish is a general PHP library that is focused on being robust, yet easy to use, secure, portable and well documented. It is specifically not referred to as a framework because it is quite different from most of the PHP MVC frameworks currently available.

Project Overview

Here is a brief overview of the library:

It is licensed under the MIT license
It works with PHP 5.1+
It loves Linux/BSD, Solaris and Windows environments
It includes extensive documentation covering all code?, plus the API? and other general PHP topics?
It includes features and guidance to make sites more secure
No shell access is required, simply drop the classes in and go
It uses UTF-8 everywhere and provides UTF-8 functions even without the mbstring extension
It supports MySQL, PostgreSQL, SQLite and Microsoft SQL Server
It includes support for one dialect of SQL across all database types
It supports almost all extensions for the supported databases
It includes powerful, but intuitive object-relational mapping features
- Full support and auto-exploration of foreign key relationships
- Simple, shorthand notation for querying sets of records
- Multi-column primary key support
- A simple plugin system using hooks and callbacks
It can manipulate images and automatically detects if GD or ImageMagick is installed
It provides precise number support even without the bcmath extension
It backports some PHP 5.2+ functionality to PHP 5.1 such as Httponly cookies and JSON
It includes error/exception handling and debugging features that make bug fixing much simpler
It is built with internationalization and localization in mind

General Themes

Almost every single one of the 59 classes provides functionality useful to end-developers and the class APIs have been tweaked to be easy to use and understand
There is no desire for the project to provide an MVC architecture/framework, instead the focus is on providing a usable and modular set of classes to help solve common web development issues
Instead of having monolithic and infrequent releases, each class is versioned separately and the library as a whole is versioned by the subversion revision number for easy updates and bug fixes

Thanks

As a final note, I’d like to say thanks to the following people for their encouragement and assistance in the development and testing of Flourish: Craig Ruksznis, Patrick McPhail, Dave Tufts and Bill Bushee.