Got this odd little bug forwarded to me from a client:

There seems to be a minor bug in the Article / Resource "add" page, and perhaps elsewhere, but I haven't tried to track down whether or not it comes up everywhere. When the time of day is between the hour and the half hour, the default posting time is 12:00am. After the half hour, the default posting time is the correct time of day.

I looked into it and it was a weird bug left over from the initial implementation. I fixed it on a test site and checked it into CVS. The original author was making the number of minutes round down to the next lowest 15 minutes this way: floor($minutes / 15) * 15 (and casting it to an int) but then he simply concatenated that value with the number of hours, which worked great 3/4 of the time. In the case of anything less than 15, however, that expression evaluates to zero, so after concatenation, you got: 10:0 instead of the 10:00 that you would expect. A quick sprintf() fixed it. The upshot is, the bug only happens on the first 15 minutes of each hour, which is why nobody from our first Syntax client forward has noticed it until now, I'm guessing. Anyway, if you see this bug, that's the class to update from CVS. Update: Oops, that class I'm referring to is pxdb_widget in private/lib/ext/PxDB/classes/content/input/

I've had two instances of the same bug today. The symptom is this: You use Context, the Syntax CMS administration tool, and it works fine except that once you login, any link you click on will take you back to the login screen. It just can't remember your login. That's because it can't write the session files it needs. The solution is twofold: Make sure the directory private/tmp/session/ exists and is readable and writeable by the Web server. Then, in your public/.htaccess file, make sure that this line exists and points to your site: php_value session.save_path "/path/to/your/Syntax/CMS/instance/private/tmp/session" Once you do both of those, your admin tool should work (or at least be free of that problem).

One of our contractors today had an issue with the pxdb_auth class and login behavior. He wanted to submit a login form but stay on the members page he was submitting the login to (instead of $_SERVER['SCRIPT_URL'] as is expected). Even though the URL changed to reflect the fact he was POST-ing to a different URL, the section he'd logged in from stubbornly kept displaying. It turns out that there are two hidden variables that by default are passed with login forms (you can see them in the login.tpl template). They are preserved_get_vars and preserved_post_vars. While the pxdb_auth class doesn't do anything different because of them, it does directly array_merge() them into the $_GET and $_POST arrays directly. And in /private/init.php we see this line: $Request->setPath($_GET['request']); That means that the preserved_get_vars were encoding the current request path and passing them along. pxdb_auth->authenticate() was blythely putting them into the $_GET array, and the above line in init.php set the script to the previous request path. The upshot being that no matter what you set the login form's action to, it would be clobbered by the preserved_get_vars setting for request. I suppose the rationale behind this was to preserve any variables, such as ad-hoc search terms or sorting, and make sure that simply logging in to a URL didn't divert you from the exact page you were trying to view in the exact state you were trying to view it in. However, I think that's a kind of fragile way to do it, and maybe too limiting. I'm not sure if it was really intended to preserve the request path as well, and I'm not sure why the request path should always be expected to be in the $_GET variable. So that's the way things work in the pre-release version of Syntax CMS, but I'd not rely on this behavior, as I think it's a prime candidate for correction in the near future.