
Well, even though EzEdit 2.0 hasn’t yet been seen by the public, I’m already working on 2.02. So far, it appears that this will be the version that the public gets to see.
The current production version of EzEdit is 1.10, however, it has come a long way since then. Take a look at the screengrab. Neat, eh? The UI has been completely redone from the ground up. There is a much easier admin interface for staff who edit faculty pages [though this feature may be disabled for UCI School of Social Ecology since there is a possible policy change that will require faculty to edit their own pages rather than have Department Managers do it for them].
I’ve been redoing the classes used for EzEdit. I’m almost at the point of making it use Pear’s DB class. The only problem is that I like my safe_query() function which has much better error reporting than the DB class [as far as I can tell so far]. safe_query() has a debug mode which can print the actual error, along with the query that produced the error on the browser window. Or it can simply state that the w3master has been notified of the error [when debugging mode is turned off]. In both cases, an e.mail is sent to a special address that includes the exact error message, the query that was running, and most importantly the URL of the page that generated the error.
This way, it makes it easy for the w3master/developer to quickly find the page, look for the query and edit it. It doesn’t work completely in all cases due to the fact that the URL is gathered via $_SERVER[’REQUEST_URI’]. Since many of my files are called via include() or require() and are out of the w3 server’s directory structor, one has to follow the code presented by the error. I need something like PHP_SELF to report the actual file path where the error occurred.
I’ve cleaned up the graphics greatly, though I am still working on getting the main 5 faculty topic icons set. That stuff is being worked on when I need to take a break from the coding. It’s kinda nice to be doing 100% of the work here, as I have total control on how EzEdit looks and feels.
A feature that looks like it won’t be ready until version 2.5 is the long awaited Edit Buttons. Mozilla 1.3 [or is it 1.4?] along with IE 5.5+ for the PC both use the execCommand() javascript function, which I am going to exploit for all it is worth. I only wish KHTML-based browsers such as Safari and Konqueror would support that function.
EzEdit 2.02 features a preview and restore function, handy for when you need to go back to an older version of a w3 page. There are also a lot more styles supported [eg: [header] tags], but those will rely on how drastically I wish to change our site’s layout [or rather, how much i want our users to change the look and feel].
I’ll list a changelog soon that includes all the new features and bug fixes. Stay tuned!
continue reading.....