core

I recently upgraded a website to drupal 5.19, and ever since updating, I am forced to run cron.php, and in some cases even clear the cache to see any changes I make to my style sheets, and/or .tpl files.

Also, around style, in firebug my style.css file is showing as 0f2ab7e0...62c1a.css

I am using Firefox 3.5.2 and Firebug 1.4.2

Anyone else experiencing issues like this?

I have been harboring some growing concerns about the direction of the plugin manager integration proposals for Drupal core almost since their inception, but have not been able to make an informed opinion on the subject until I had properly reviewed the proposed system on a much deeper scale.

While my impressions of the project and the current implementation are fairly negative, I have aimed to frame my criticisms in a positive constructive manner because I believe that the goals of the project are worthwhile, and that for a large section of users this could be a very flexible and usable solution.

Unfortunately a lot of my concerns have been well founded, and I believe that the implementation of this system needs to be taken in a different direction for it to be able to succeed in its goals, while not negatively affecting projects like Aegir, Open Atrium and many other ‘serious developers’.

I have been writing up a white paper on how Drupal could work, but wanted to submit an initial and important first step. I know allot of people see comments as nodes being a major issue. Many want it, while others site potential problems with performance. Without comments as Nodes we have no code uniformity making any CCK features and Views features needing exceptions based on if its a node or if its a comment.

DrupalCon DC 2009 featured a nice selection of RDF related sessions. 2 regular presentations served as introduction to those who were unfamiliar with the topic, or just wanted to refresh their mind with the latest happenings.

I remember hearing talk about the need for a new database field to be added to Drupal core taxonomy.module's term_data table to stash the GUID/UUID/URI associated with a term. This was particularly relevant for sharing/importing/exporting taxonomies and using standard vocabularies. I suspect it also has relevance to RDF, but my comprehension is still a bit hazy on it.

OpenCalais calais.module adds a column 'guid' to the term_data table. I can't imagine that there would be any collision risks if other modules insert in this field as well for their own vocabularies.

Currently there are various contrib modules implementing form validation and/or submission via AJAX/AHAH.

The earliest is Ajax submit. Originally part of the Javascript Tools package, Ajax submit was moved to its own project for Drupal 6. In Drupal 5 Ajax submit combined an API and a UI. For Drupal 6, the UI was (temporarily) removed in order to produce a pure API module that could be used by other module developers free from a UI. At the same time the Javascript was rewritten to use the jQuery forms plugin.

Good news! During the week of December 15, we're organizing a 5-day Fields in Drupal core code sprint at Acquia! The goal is to get CCK functionality into Drupal 7.

So far, Karen, Yves and Barry have signed up -- Karen and Yves are the main CCK maintainers, and Barry has done a lot of work on CCK as well.

To help us fund the sprint, please consider making a donation using the ChipIn widget on this page. We need money for airline tickets, hotel rooms, food and transportation. It would also be great to fly in a few additional people with extensive core and CCK experience.

I've tentatively worked out a budget of $7,000 USD, which covers flight, food and hotel costs for at least four people (Karen, Yves, and two additional people). Since Acquia is covering my travel expenses and allowing Barry to participate all week long, that gives us six people working on CCK-fields-in-core for an entire week. Any excess money will be used to add more people, or donated to the Drupal Association.

To guarantee that Yves and Karen can attend, Acquia is funding Yves' and Karen's hotel and airplane tickets if enough money can't be raised through donations. Acquia is also providing working space in our Andover office.

We'll try to allow people to participate in the sprint remotely, and provide a daily update on our progress. If you're interested and available to participate, join the Fields in Core group, enable e-mail notifications, and block time in your calendar between December 15 and December 19. We'll use the Fields in Core group to plan and to let you know how you can contribute and participate.

We conducted some benchmarks for Drupal 5.12, Drupal 6.6 and Drupal 7.x (Oct 24 checkout).

We used the same data set for all 3 instances:

Users 4,950
Nodes 5,000
Comments 20,000
Vocabularies 10
Terms 1,000

And same test parameters: 10 concurrent users, 2 minutes stress test on 30 individual nodes, and the home page.

At Drupalcon Szeged, I had some discussions with the documentation team and the usability team regarding workflow for getting their feedback injected early into the core development process. I'd like to start a similar discussion here with you folks.

Drupal 7 with its code freeze date of "When it's ready" represents a great opportunity for us all to collectively "kick it up a notch." Key to this is involving many more people in the core development process than we normally have. There are always several relatively minor core patches that affect themers in the queue at any given time, such as add $node_classes to node templates, as well as huge, over-arching efforts such as administration theme in core.
But unfortunately, a lot of these patches stagnate and die, because designers have not traditionally been a group of people that we've served particularly well. I'd like to see that changed.

Been sitting on this idea for a while: curious to see what people think.
In a nutshell, the idea is to combine and generalize the various flags for a node that are available in node.tpl.php, and open them up to modules.

For example, instead of the $is_front, $page, $sticky, and $teaser booleans, you'd have an array with entries present if the flag is true. Something like this, for example:

Core would take care of shoving those keys in; other modules would given a chance to add their own to a node.

That's the plan. Here's why I think it's cool: