There have been a few threads on jQuery in 4.7, mostly filled with disappointing tales of incompatibilities of Drupal's JS files and jQuery.

Not being a JS guru, and not wanting to be, I decided to use jQuery for a client project and created a jquery47 module to allow anyone else to use my hacked up jQuery.

You can find it here: http://drupal.org/project/jquery47

What an auspicious day to start the Drupal For Evil group. I welcome you, my brothers and sisters in evilness, to this group. May our reign of terror be long and fruitful.

<-- break -->

As we march forward in our world domination, feel free to use this forum as a place to post your evil tricks and hacks. Deriding alternative web technologies is welcome and encouraged. We will rule them all. Post evil code snippets, laugh at evil websites, and generally take pleasure in all that is Drupal for Evil.

I'm considering to start rewriting the workflow module.
You may ask: But why?

• to make programmatically supplying a workflow easier
• to make it more modular and so more extensible
• to allow multiple workflows per content type
• to make it more efficent and to have it cleaned up

So how do I imagine the new improved workflow module?

I am thinking of dividing it into three modules, that can be bundled in one archive/drupal project.

• workflow module (the engine)
• workflow UI
• worklfow permissions

The workflow module would be an API only module. It allows other modules to define workflows and to execute their transitions. It doesn't provide any access checks, as this is needed rarely for programmatically supplied workflows. So this modules task is to make programmatically supplied workflows possible.

Because the problem is not creating a node (menu, etc) in two languages, that's peanuts. You either add a lang to the primary key of the node or create a (nid, nid, lang) relationship table and you are basically done.

Basically. Because with more complex node types, some things are shared. Dates of events for example are the same with a different formatting. On the other hand, places are not necessarily -- even the country names can be different. So, we either extend the node API with provisions for this (shared/not shared among languages) or every single module needs to think on this. I can't say I love either.

Post your suggestions here ;)

Now that we have jQuery in Core, there are new JavaScript enhancements for Drupal popping up everywhere. Most of these enhancements are pretty small. To add them to a page, it usually requires a module. But those modules don't do much more than just adding the JavaScript file with drupal_add_js - the whole module system with all of its callbacks and so on is just overkill for that problem.

On #drupal we have discussed the need for a module that gathers all those JavaScript enhancements in just one module. In the rest of the proposal, I will use the word "behavior" for a JavaScript enhancement file.

For us (an end user who occasionaly develops for others) the concept of a six monthly update that does not have backward compatiblity is one of the biggest worries in using Drupal. While I understand the ideal and applaud it, it does bring up the issue of leverage in regard to the financial investment made.

We want to see a return on any investment we make so having to start an upgrade cycle every six months if going to be very hard to justify especially as the size of our sites mean that we are going to be constantly programming to stay still. Our most recent project has had over 400 man days in development and uses a huge number of contributed modules to update to V5 is going to be a major task.

So, we have a few modules that we are running for a new client. We're running drupal on about 60K worth of hardware, not including the Oracle database sitting on it's own nice slice of hardware (about 4 tearbytes of data).

So we get data once a week, millions of rows of data (60 million+). The module that we made for the client has a cron job that runs through and makes some updates (this is along with a Database-side PL\SQL script, and a sprinkle of java. A nice orchestra of apps that work beautifully togather). Well, this takes days to do. Literally days, and we noticed a problem when the "aggregator" failed because it through an error trying to read a certain RSS feed. We were not aware of this for about a week. This cost us and our customer prescious time because since aggregator had filed, the clients custom module never got to run!!! Futher more, I concluded that if I put the custom module first, it would eat up all the cron run time. On top of than, we were seriously "under" utilizing our hardware. This was just totally unaccepatble. Thus comes "Mutli-Threaded Cron" runs.

What this does bascially is fire each modules cron run in it's own "sandbox" if you will. So that each modules cron run has the FULL use of PHP's time out, and does not have to worry about another modules cron run failing. The multi-threaded cron also gives more detailed information about each modules cron run. This will better help site admins control the PHP time out variable (which can now also be set dynamically), and see what modules are taking hte most time to run, the least time, and which ones are currently failing.

I believe this is a BIG improvment over the current cron implementation.
Some items I would like to implement next:

• Emailing the admin if these is a "cron run fail" escalation (say in a 20 min. period, there are 10 failure, email me), etc.
• Being able to set each modules individual PHP execution time variable. (be nice to give search.module more time than aggregator module)
• "Throttle" the cron runs. Meaning, I only want to have 5 cron "threads" running at any given time. So it needs to wait until a few have finished before running more cron threads.

You can review the patch and a detailed discussion of it here: http://drupal.org/node/87528
I'll be discussing more options for mutli-threaded cron runs on my blog: http://www.eb3it.com

Below is a snipped from my blog:

So, I have started an ambitous patch. For those who do not want to read the explination, and just gain knowledge by reading the patch: