Riddle me this: Where, oh where, does the Syntax API register or even define the "check_date" validation function?
My answer? Dunno. Spent two hours looking for the little bugger. It must be defined in software somehow so that a grep for "check_date" reveals nothing. Somewhere there is a lambda function generating "check_" and "date", in some sort of bizarre obfuscation technique.
After all, it's not important that we know how we validate dates, is it? I mean, it's not like there are any errors in the code elsewhere, so why should I be concerned?
Update: I found it--it's not in the framework, where one might expect a default dbfield type to be validated. It's set and managed strictly in the Context tool, as basically client functionality.
It's nifty that you can extend the validation a second way like that, but that implies that such validation won't happen when you write an app that uses pxdb_commit and pxdb_input in the regular CMS--or any non Context application, for that matter.
The upshot is, I'm going to change this at some point. In the meantime, beware. Validation that seems like it should be framework level may be happening in client code.
Securing dbasis with the standard, Syntax session-based authentication turns out to be relatively simple. The version of dbasis in cvs now has this for all future sites going forward. To secure exisiting instances drop in the following code after line 115. This requires a login from a user in the admin group.
line 115: $session->initialize();
# Authentication
# --------------
require_once($PXDB_PATH . '/classes/auth/pxdb_auth.class.php');
$auth = &new pxdb_auth('dbasis');
$auth->set_username_field('idnum');
//$auth->debug = true;
// restrict to admin group
if($_GET['logout']) { $auth->logout(); }
$auth->restrict( 'admin' );
if(!($user = &$auth->authenticate())) {
//include(SITE_ROOT . '/display/header.disp.php');
$auth->showlogin();
//include(SITE_ROOT . '/display/footer.disp.php');
exit;
}
I had to re-figure this out today, so I thought I'd document it to save hair-pulling later.
If you are mucking about with Syntax's API innards (the pxdb_* classes) and make a structural change to the database, you need to create an upgrade script to handle it.
Background: Every time the Syntax API gets used, it calls PxDB/config/initialize.php. This checks to see if its sister-file run-once.php has been modified more recently than the database has been initialized. If so, it runs it.
initialize.php has a place to define the current version of the Syntax API. This is used by run-once to determine if an upgrade script needs to be run. If the version number is lower in the database than the file, it runs the script. If the version number is higher in the database than the file, it fires off a warning. If two version numbers are the same, it does not include an upgrade script.
The upgrade script goes in PxDB/config/install/ and should be named according to the ADODB name for the database you're using followed by a hyphen and the word "upgrade", e.g. mysql-upgrade.php. The script should ideally check the version number and retain previous upgrades, so theoretically someone could go from a version 0.0.1 to the absolute latest and catch all relevant upgrades.
You should also test for the existence of various columns and tables that you wish to affect so you don't get someone with a mismatched version number in too much trouble.
Once you've done all your testing, alter any tables and convert any data. Finally the script should set the version number in the DB pref key to the version number you've declared in initialize.php IF AND ONLY IF every SQL statement has executed successfully.
Note: This is true as of version 0.0.5. Oooh! Did I slip some news in? Maybe!
Problem:
On a Syntax site, You have a uri like
http://www.mysite.com/content/news/detail/5678/ and you need to extract
the number to use as your record id:
Continue reading "From Oscar: Extracting parameters from Request URI"
