Core Enhancements is a module I made for myself two years ago, which addressed many problems/issues/bugs I saw with Drupal 5 when it first came out and were not addressed in other modules. Core Enhancements IMHO is still a relevent module in my Drupal development, because it is a flexible environment for me to add features, functions and thirdparty files without having to add another flippin community driven module. There are a lot of reasons, but in short the more modules you add to Drupal, the slower it gets, especially using CCK, Views, and the myriad of modules that populate most Drupal sites. Modules can get resource intensive very, very, quickly and let's face it, the less cooks in the kitchen, the better the results usually.
The original module was developed for Drupal 5, and I ported it over to D6 earlier this year. While doing so, I realized that there where many repetetive pieces of code that I kept adding into modules, little functions and the like that where being repeated over and over, and since the philosophy of DRY is Don't Repeat Yourself, I decided to re-roll my module's mission and add in many common PHP, Javascript functions, Drupal.settings (js settings), arrays for populating data, many many jquery addons (those ltitle annoying 3k files) that do not exist in other modules, basically making one giant helper module to assist my other modules.
In short, I realized I have re-written the whole darn thing to Drupal's exacting standards, and I realized I have a whole new module. So, I am killing off the 1.0 branch and adding a 2.0 branch, and adding a whole lot more. There is no current documentation for Core Enhacnements so I resolve I will have some reasonable documentation at least for features sake. If I really want to, I will try and see if Drupal wants to use it, but I loathe thinking I should support a project, so I am a little up in the air on that.
Adding features to Core Enhancements is already well on it's way. Here's a quick synopsis of what I am working on:
Inline Editing via AJAX
Inline Editing of Node Form and Block Form. I use Views and CCK for almost everything, so there is a lot of node/block editing on my site. On most front pages alone, there are at least ten items that can be edited, maybe more! I always have to make a quick edit, so I wanted an easy way to load a WYSIWYG editor on my nodes that I load in views. My solution is to add some code to the top of the node.tpl and block.tpl files to make them display an apporpriate admin link, and have that load call a valid Drupal form that the user can edit/preview/save. This is a huge time saver, and makes it so easy to administrate content in the long run. Everything is handled through post and get (AJAX) so you edit right on the page. It's already well on it's way, and if I can figure out a way to get FCKEditor to load faster on FF I will be super happy.
New Admin Menu Layout
My biggest peeve about Drupal's backend is that it is too Developer centric, and not Site Admin and End User savvy enough. Even though Drupal 7 is planning on making wide changes to workflow, nomenclature etc I still want a solution for Drupal 6 that makes sense to me and my end users. I am waiting for some back porting of the Drupal 7 usability that should backport to D6, so at this point I think the best thing I can do is create an override for the Admin Menu Module, that makes the Admin Menu more useable to low-level admins and end users. My plans are to add high level "Workspaces" named "User", "Super User", "Site Admin" and reflow the tasks that are in the downline menues, so that they make sense in many workflow options. The best part is that the original Admin menu layout is still there, and you can assign a workspace somehow, most likely by role. I'll be posting on the final Menu layout, very soon.
Core Enhancements Documentation
Of course, all of this is for not without decent end user documentation. So, I will throw together a book here on this site, and make it so people can comment, etc. We'll see what happens next!
Comments
Post new comment