One of the goals of the FireOrb Project is for php developers to be able to use their propietory and contributed modules coded for Drupal. This is where the FireOrb MIT Extractor comes into play. The extractor application code named "Firemite" will hijack calls to Drupal functions and route them to FireOrb.
Portals  FireOrb  FireOrb Developers Network  News

FireOrb the name The name "FireOrb" is released under the Public Domain License and is not a trademark. Use of the name in conjuction with the use, distribution and marketing of the FireOrb Content Management Framework is allow under all circumstances covered by the Public Domain license.
Portals  FireOrb  Open source

The name new FireOrb content management framework has been released into the public domain where it can be used by anyone anytime in any context. Now to get on with developing software rather than trying to become a rockstar. A new core Though the first version of FireOrb will be a release of a mirror of the previous GPLed CMS today I am going to start work on a new core. This will be a complete from scratch rewrite that will allow the use of present day modules and themes with minimal changes. The new core licensing The licensing of the new core will be one that will allow people to run businesses around the distribution and extension of the core software without forcing them to use the GPL license. At this moment I am looking at the new BSD which would allow the most freedom. With the BSD developers and business owners would be free to choose to continue to use the GPL or to re-license their products so that they can design a business model that works for them.
Announcements  FireOrb  FireOrb Developers Network  PHP  frameworks

FireOrb did not meet the march release date and I refused to release it on April first for obvious reasons. But the work continues so here is a little to list. Now that the backend is totally seperate the next thing to do is to seperate the themes. The control panel will have its own theme uninfluenced by the frontend choice. This way the code becomes simpler and things like blocks and menus don't clutter the interface. The ideal would be to have the backend look like that of Joomla! CMS. The module area is cleaned up and the code for settings has been changed so that module don't push a link into the menu system. The next thing to do is to create a similar catch all system for the admin hook. The Control Panel is in place replacing the log view with an actual interface. The system.inc file needs some new functions to take care of outputing links and information for this page. The installer is broken and needs to be fixed. The setting.php will be moved at the same time and the naming changed to make it easier to find and adjust. i18n will be installed as part of core and FireOrb will have some hard defaults for language. This will fix many of the problems with multi-language websites and permissions on translations. The path rewrite to include "/en" parameter will be removed and be made into the more conventional &lang=en querystring. FireOrb will have its own website although the blog will remain here at Hiveminds. A forum will be set up but not using the built-in FireOrb forum. People will have to sign-up for this seperately which is an inconvenience. But this one little inconvenience offsets hundreds of others when the forum has real subscriptions and other needed functionality. That it for now. I am sure the list will grow. But this is enough to keep me busy over the weekend.
Developer Zone  FireOrb

The following is a list of changes made to FireOrb and the builds: Build 0003 Started 2008-04-12 Removed the throttle module and anything that has to do with it. Having things disappear under load is just not an option. Backend templating is complete and in place.
Developer Zone  FireOrb

Going to make sure the next build is more complete by doing some house cleaning. This means the thousands of name changes, file moves and template work must be 80% complete before we move on. Dozens of instances of hardcoded HTML must also be pulled out and set into external files. This is necessary before installing i18n and making adjustments to it. So the next build release will be on Monday. We will try to keep on this schedule so that each Monday morning will see the latest changes released. Contributions have come up in some emails. These are mostly from people using Drupal 4.7. for the duration. I can't make any promises on adding these things into FireOrb. especially since many of them have to do with user features and not anything that would make coding a website easier. FireOrb is not going towards the end of making it easier for non-coders to build and administrate websites.The concentration is on making useful and simple as framework. Yes, CodeIgniter will come in. But not until the end. OOD in FireOrb is what we are after first. This will make it easier to accomodate those that want to only use OOP and nothing else. But also make it possible to mix it up for those that like to do it fast with procedural coding. Finally, Yes. FireOrb is a blantant forking of Drupal. We are not trying to hide this fact nor are we ashamed of it. FireOrb will be available as a GPL package unlike some of the other propietory modified Drupal installations. So keep your eyes open it will be here soon!
Developer Zone  FireOrb

The Drupal watchdog has been bugging me for years now. But today I have just had enough. It is a thing that just begs for a denial of service attack on the database server. It alos exposes one of the true weakness of Drupal code design. Putting everything in the database and making it dynamic "magic" impresses to the end user. That is until they get errors because their shared hosting environment can't handle the load. db_query("INSERT INTO {watchdog} (uid, type, message, severity, link, location, hostname, timestamp) VALUES (%d, '%s', '%s', %d, '%s', '%s', '%s', %d)", $user->uid, $type, $message, $severity, $link, request_uri(), $_SERVER['REMOTE_ADDR'], time()); This was in the bootstrap.inc of Drupal 4.5 to 5.7 which was pretty idiotic. Though it has been moved into a seperate module in Drupal 6.0 it is still a pain in the ass because it is a weakness in security. Anyone wanting to overload the database would only have to hit a site with millions of events that have to be logged. If you are running 5.7 or below then your site will not load because MySQL will crap out when the memory limit is reached on trying to do an insert. If you are running 6.0 you might be a bit better off since watchdog is controlled by a module. You can just turn it off. The thing is since there is hook_watchdog other things might start happening and since watchdog is off you can't track them. You also have to filter a lot of crap that may be stored in the database and comprimise its integrity. The best solution is to move the functionality to a text file. Which is what is happening today in fireOrb development.
Developer Zone  FireOrb

Okay, seperate backend and frontend theme system is done. This in not just a redirect to a new page template but an implementation of the complete theme for the backend. So now you can create a theme for the backend without interpolating the code for it into the frontends theme. Firered can be the frontend and as soon as you go to the new control panel you can choose a theme like Marvin. Blocks and regions are seperate so removing or moving theme is easy and does not conflict when changing from one area to the next. Especially important is the fact that the control panel can have a completly different navigation system from the frontend. Give it a try. demo admin/admin
Developer Zone  FireOrb  News

Because so many things have to be changed FireOrb is going to be done in a nightly build process. The function naming system has to be put into place at the same time as development of some other systems like theming are put into place. This means I can change maybe 40 function names while creating a build for say the backend theming or while cleaning up the hook system. The hook system is going to be the next big change right after getting seperate templates to work for the front and backend. The use of module_invoke_all and some other chaos makes it hard to find out just where Drupal gets its list of available hooks. While this mean flexibility for third party developers it means that core system development becomes incredibly impossible to organize. You can find hook_init and hook_exit quite easily but the rest are hidden in a mish mash of spagetti code, what function implements hook_menu? What about those other critical core hooks where are they started from? . There should be a central array that has core hooks listed. This make it easier to extend the core for both core development and third party development. Having a global containing this array would make things so much easier performance wise. The global can be called and adjusted appropiatly before calling hooks preventing loading of uneccessary modules. That's enough for now. FireOrb build 0001 is now in the demo area. File releases will come soon after the theming/templating system is complete.
Developer Zone  FireOrb  News

So what's new in fireOrb for Easter? Well I have been spending part of the vacation weekend trying to get things ready for an alpha release. The biggest change in the last few hours has been a decision to go with the use of numbers in function names to control the versioning of code and to give a more clear definition of what code is specifically asigned to core. Of course this means that all Drupal modules will have to be updated to accomodate the new function names. But the thinking is that this will only have to happen once. After having done only a few files I can tell you that it is pretty cool to be able to look into a module and see directly that a function comes from the core system, the module or PHP. Convention to ease coding After FireOrb is repackaged and ready to go then there will be work done on creating upgrades to core packages. Basically these will be a collection of functions and code that will allow a Drupal module to work within FireOrb without having to re-code the file. The new way of naming should allow module from different versions to co-exist without conflict. This mean if you write a module then it will over a long period without the need to upgrade to fit the new core. The next big trick is to throw the Drupal menu system into the trash bin.
Developer Zone  FireOrb