Well, the WebKernel interface looks almost identical to how it did 2 months ago, but under the hood it's grown a nice set of teeth, and it's seething to sink em into the web.
The most valuable update lately has been the addition of a small bug-tracer utility. Outside the standard PHP riffs about what's wrong with your code, WK uses PHPs much more critical error detection functions and pipes them into the debugger. Overall a minimum of 21 bugs have been fixed, more than a few could have caused some system instability later in the line, as any core code literally affects every plugin in the system.
The latest builds are starting to include the concept of "Shells", if you use Linux, a WebKernel Shell is like an X Desktop Environment. Really, the shell just builds the basics of the page, and decides how it will present content. There's 2 major shells planned for WK, and each one will fragment the plugins that run - not good. But, very much like Android and Gnome/KDE apps don't play nice, it will also (hopefully) allow more creativity overall with the platform. Also, the apps/plugins might easily be made with the same underlying libraries, and eventually a global spec might be made so apps are cross-compatible.
The command-line interface has grown continuously more powerful, as every single new plugin is trated like just another command. It is at the point now, where though the browser-based CLI, an administrator can create, move, copy and delete files, aswell as work with secure-by-design MySQL layers and even run embedded commands. It was interesting when I found I was able to pipe mysql results though the FTP utility to produce a file with MySQL output, while taking that same file, back it up, then read the file contents though the debugging utility through only a few commands.
Granted, most users will never do that, and only root-level admins have level of access, but it gives you massive satisfaction to know a plugin could easily make, say, a backup utility with only a few lines of code. I could very easily see an OSX-like automator-utility being made.
The only drawback the CLI has at this point, is being unable to process things like loops or conditions. The current CLI parser is a somewhat basic semi-recursive function just advanced enough to handle the most common problems. A new parser is being written, instead of being a flat command it's a series of smaller modular functions, and should be able to expand the CLI to handle full-out programming. The reason for any CLI functionality whatsoever has already became apparent with AJAX protoypes, allowing full Ajax websites with incredible, versatile functionality.
Other major improvements include session and configuration variables, with authors able to simply set certain variables in the course of the script that will automatically be saved to the database instead of performing manual queries and cookie-setting. The system also supports rich anonymous 'accounts', with anonymous users able to have sessions just as rich as regular users. Tripcodes will be introduced later so users can save their sessions to a specified tripcode; Though unless granted those permissions, anonymous users will still fall short of the richest features the website has to offer.
Last bit of news;
I tested an impromptu plugin I dubbed 'social', which made use of most of the features I mentioned. Sure, it was hacked in as a 'core' plugin, and lots of info had to be hardcoded because it was just a test - but WebKernel was able to easily create a plugin capable of connecting to the social networks FaceBook and Twitter. Through the ever-magical CLI I was able to test it, and send a basic message to both networks at once, updating my status. What excites me is that it was though this command:
I had, before executing that, saved my passwords and account names to the semi-permanent user-variable '$_USER', and the actual connection-methods were hard-coded. But there is no reason why each social website could not be a sub-plugin. What this means is that, when WK hits maturity and an author creates a news plugin, users and authors could easily have social-updates pointing to their news posts, or images, or anything else. Since the API is universal, it's incredibly easy to update for.
here's the total code a news post might have to use, to update to all the users signed-in social networks:
__('social', 'send', array
'message'=>'The meat of the update'
This could probably also work for an anonymous user, too (be only half-signed into a WebKernel site and still push fully-logged social updates)