Drupal 4.7.0 status update

By Dries on 1 Sep 2005 at 12:23 UTC

In preparation of the Drupal 4.7.0 release, development of Drupal core will be frozen on September 15th rather than on September 1st as mentioned earlier. The code freeze has been postponed for two weeks so some important changes can make it into the Drupal 4.7 release series (hopefully). Read on for more information about the Drupal 4.7.0 roadmap.

The following key features are still being worked on:

Improved form handling (Adrian et al.)
Upgrade system improvements (Neil et al.)

In addition, there are plenty of other patches that need to be reviewed and tested, patches that need more work, and bugs that need to be looked at. (If you want to help, it is a good idea to enable the "Contributor links"-block or to visit the contribute page.)

As of September 15th the code will be frozen. At that point, our focus should be to strengthen the code base's usability and stability, as well as the documention in the Drupal handbooks. I truly hope we can motivate new and existing Drupal contributors to improve the Drupal user experience. Usability suggestions can be posted in the Usability suggestions forum. More information about the usability efforts will be announced shortly.

As we progress, focus will shift towards stability and near the end of the code freeze, only bug fixes will be allowed until no release critical bugs are left. After the code freeze, it might take several weeks before Drupal 4.7.0 can be released, however, one or more release candidates will be made available during the code freeze. Finally, we'll release Drupal 4.7.0 when it is ready.

An overview of the Drupal 4.7 roadmap.

During the code freeze it is highly recommended that contributed modules, themes and translations are being updated to work with the forthcoming Drupal 4.7.0 release: upgrade instructions for themes and modules are available in the Drupal handbooks. If you want to help update modules, themes or modules, please provide patches to the maintainers using each project's issue tracker. During the code freeze, Karoly/chx is likely to host a second workshop on upgrading modules to Drupal 4.7.0. The workshop will be held on IRC and is free to attend. More details will be made available.

(Note: this thread is not meant to post feature requests or personal wishlists. If you have a feature request, add it here but search for it first.)

Comments

When do database updates stop?

m3avrck commented 1 September 2005 at 13:37

Just to clarify, is the database schema finalized when the code freeze goes into effect?

I plan to start two heavy projects after the code freeze and want to make sure the database isn't going to be changing, bug fixes and updates to the main source is no problem to deal with, but database changes can be a pain, thanks!

Database schema

Dries commented 1 September 2005 at 15:21

The database schema is unlikely to change during the code freeze, but there are no guarantees. If you want a truly stable Drupal, wait for the Drupal 4.7.0 release or use the latest Drupal 4.6 release.

three levels of patches.

Bèr Kessels commented 1 September 2005 at 14:13

We now have three kids of patches.
code needs review (CNR), ready to be committed (RTBC) and code needs work (CNW).
I would like to know if the feature freeze will exclude all of these states. i.e simply no more patches of features will be committed, or if the RTBC, or even CNW will still make a chance?

---
[Bèr Kessels | Drupal services www.webschuur.com]

Committing patches

Dries commented 1 September 2005 at 15:05

During the code freeze I commit patches that fix bugs or improve usability. New functionality, API changes or database changes are put on hold unless deemed critical.

Diagramming tool

Malthus commented 1 September 2005 at 16:02

Which diagramming tool(s) you use?

OmniGraffle

Dries commented 1 September 2005 at 18:11

I just used OmniGraffle for the Mac. Why?

OT: fun loving web developer seeks beautiful diagramming tool

Malthus commented 1 September 2005 at 19:06

I use Dia but it doesn't do very pretty diagrams. No candy like drop shadows etc. Was hoping you had used a windows or linux program that I could have tried. I guess I'll have to use Inkscape to fix up my Dia diagrams.

Why not pop your diagram into your favorite graphics program?

travischristopher commented 7 September 2005 at 04:29

Add dropshadows and candy in an image editor afterwards or better yet Illustrator does a pretty good job of importing common formats. once you have the vectors in the software of your choice, then go to town.

Travis

inkscape

Harry Slaughter

Omaha NE USA

commented 9 September 2005 at 22:45

someone recommended this to me recently. it's a bit kludgy on wintel (haven't tried linux version), but it's very nice overall. prettier than dia and easier to use imho. but it's specifically for vector graphics stuffs rather than just diagrams.

--
Devbee - http://devbee.net/

Thanks, that will give me

killes@www.drop.org commented 1 September 2005 at 16:21

Thanks, that will give me the opportunity to help with the forms API conversion (http://drupal.org/node/29465) and pushing my favourite patches, namely:

http://drupal.org/node/28159
http://drupal.org/node/30098
http://drupal.org/node/17656
http://drupal.org/node/26649
http://drupal.org/node/28255

--
Drupal services
My Drupal services

Thanks for the 4.7 Update on the Update

rmarioni commented 1 September 2005 at 18:49

Thanks!!

i18n

blackjam commented 2 September 2005 at 07:14

Is there some chance, that i18n will be possible in 4.7 without patching core files? I am using it with 4.6 and the necessity of patching complicates every update a lot...

i18n

fishingshrimp commented 2 September 2005 at 08:46

I second that!

Missing i18n support in core files was another reason why i haven't switched some sites to drupal yet. and patching core files is always a mess - especially with i18n.

No requests!

Bèr Kessels commented 2 September 2005 at 12:51

(Note: this thread is not meant to post feature requests or personal wishlists. If you have a feature request, add it here but search for it first.)

---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]

Help test

Boris Mann commented 2 September 2005 at 16:24

To follow up on what Ber says, if you want i18n in core, please help test all the i18n related patches. Perhaps Jose (one of the leading i18n implementors) can post links to the outstanding items.

Only one patch left for i18n

Jose Reyero commented 2 September 2005 at 21:14

Currently, there's only one important patch left, to run i18n -with current features- with 4.7.

This one: http://drupal.org/node/29030

So please, support this one -- or provide a good alternative.

Also, there's an interesting post, just to read and comment about multilingual features: http://drupal.org/node/29645

https://reyero.net

I find that current CVS of

Wesley Tanaka commented 10 December 2005 at 12:38

I find that current CVS of i18n works well with the current CVS of drupal if this patch is applied: http://drupal.org/node/38769

Treehouse

I want use 4.7 early!

robertb9527 commented 3 September 2005 at 01:51

I want use 4.7 early!
------
Welcome to my blog:
http://www.b9527.net

"You can't always get what you want"

ica commented 3 September 2005 at 02:18

"You can't always get what you want" - Rolling Stones

Besides I presume delay is for a good reason by hard working Developers.
and improvements 4.7 looks good and work on it should be appreciated -with patience

- and the chorus goes, like this
"You can't always get what you want, But if you try sometime, yeah "
;)

--------------------------------------------
Damn! I can not code PHP :(

?

Tobias Maier commented 3 September 2005 at 02:12

then try the CVS-HEAD version apply a patch from here
or try to reproduce a bug from here
and help solving all outstanding issues :)

Ciao Tobi

oh look

sepeck commented 3 September 2005 at 02:22

instructions for testing here: http://drupal.org/node/28245
welcome on board. :)

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

cd /path/to/web/root/mkdir drupal-cvs ???

ica commented 3 September 2005 at 02:31

sepeck, is it for me or robertb9527?

btw - can you explain what to do with this?

cd /path/to/web/root/
mkdir drupal-cvs
cd drupal-cvs

is it what called command line? if it is so what to do next with this code?
it's a virgin territory for me

for anyone

sepeck commented 3 September 2005 at 02:45

who wants to help test patches. It's a fairly recent addition to the manual.

As to what to do with the command line stuff, pick up an intro to Linux book and start playing. Check out your local LUG as well. Many of them have stuff to help new folks.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

no linux box.. just a mac

ica commented 3 September 2005 at 03:54

what is local LUG? Linux Users Group? - (I just searched -I never heard of this abbreviation before)
I dont have a Linux box,i got a macOSX - + never played with a code with Terminal...and plus -no command line server access to remote linux server only webCP+FTP access.

Last 3 months I hardly try to understand how to figure out Drupal to make something out of it as it is and it still a challenge for me -considering its potential.
Though that does not mean I can have some ideas on UI and usability stuff on the 'front' end maybe that part is is safer playground for me

CVS on Mac OS X

Robert Castelo commented 3 September 2005 at 09:25

Using CVS on Mac OS X is actually pretty easy...

http://drupal.org/node/20202

[MegaGrunt]

------------------------------------------
Drupal Specialists: Consulting, Development & Training

Robert Castelo, CTO
Code Positive
London, United Kingdom
----

Status update

Dries commented 15 September 2005 at 20:15

just a quick update on the code freeze. The next few days I'll work my way through the pending patches. CVS will be frozen once I managed to review some of the important patches that are currently pending. I'll try to review patches tonight and during the weekend. As always, you can help review patches. If you do, make sure to review them well. Bad or incomplete reviews are merely a waste of time. Thanks.

As of Monday, I'd like us to focus on both usability and performance improvements.

Usability: one of the most common complaints about Drupal relate to the out-of-the-box experience. For many people, this is either due to (i) the terminology or (ii) the awkward navigation structure. Many people feel lost and don't know where to start. As such, some people think of Drupal as "too complex" or "different than other systems". In the next few weeks, I want you to investigate how we can continue to improve the Drupal exerpience.
Performance: Drupal being used on bigger and bigger site, performance becomes more and more important. Also, because more and more complex sites are being built, memory usage is often a bottleneck. In the next few weeks, I want you to investigate how we can improve performance and reduce memory usage. Fire up your favorite profiling tool, benchmark scripts, and try to squeeze more out of Drupal.

Maybe this should be a new

beginner commented 18 September 2005 at 04:11

Maybe this should be a new article on the front page.
I'm sure many will miss a single new comment posted late.
??

--
http://www.reuniting.info/
Healing with Sexual Relationships.

Agreed.

Hosting Geek commented 18 September 2005 at 13:12

Agreed.

Performance is a huge

tamarian commented 24 September 2005 at 02:25

Performance is a huge priority for me, as I plan to use Drupal on a very busy site.

Here's what I found so far, as possible performance enhancements:

1. Block caching: I think blocks should be cached, even for logged in users, as they often generate a couple of queries per block, per page view.

The cache id for cached blocks should be based (keyed in) on the role, to avoid any complications as to whom we should show what.

2. Loading a page of nodes causes too many queries, as the node api is invoked for each node. So if the content configuration is set up to show 10 nodes per page, you will get 20 more queries per page, than if you set it up for 5 nodes per page. (a lot more if you install more modules).

A possible solution is to offer a node collection API to be used when viewing node listings, to prevent a loop of multiple node API calls. If the node collection API offers a list of node id's to be listed in a page, most modules should be able to execute once. (i.e. new hook_collection_load returning an array of objects).

The problem with caching for

killes@www.drop.org commented 24 September 2005 at 12:42

The problem with caching for registered users is that you'll have to have a cache entry per user if the block shows node or comment data. Not all users might have access to the same nodes on a site.
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

The problem with caching for

tamarian commented 24 September 2005 at 14:59

True, and there would be a need for refinement of the cache keys. Here's how I see it utilized:

1. Guests have everything cached, so they may not need cached blocks. This is already done.

2. Some blocks can be cached once for all logged in users, for an event duration, These would have a cache key type of 'any', and a lifetime of 'volatile', where volatile blocks require cache busting when new content is added.

3. Some blocks can be cached once for all logged in users, for the cache duration. Those would also have a cache type of 'any', and a life time of 'permanent', where they can remain for the cache cycle (ntil clear_all).

4. Some blocks requiere role priviliges, for an event duration,. These would have a cache type of 'role', and a lifetime of 'volatile', like #2. Users with role X, would get the X copy, while users with role Y would get the Y copy of the block.

5. Some blocks requiere role priviliges, for the cache duration. These would have a cache type of 'role', and a lifetime of 'permanent', like #3

6. Some blocks may require specific user id's. These can be skipped and not cached. Or they can still be cached with a cache type of 'userid'.

I think this would result in a huge performance gain. Consider for example the "who's online" block. You set it up to show a maximum of 10 users, and you'll get 11 queries for that block. It makes a lot of sense to cache it.

Not implying that this is trivial to develop, but it is doable, and would be a great enhancement.

IMO you are creating a monster

chx commented 24 September 2005 at 15:32

http://drupal.org/node/16216#comment-33328 in reply to http://drupal.org/node/16216#comment-33085
--
Read my developer blog on Drupal4hu.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

I'm trying to tame a monster

tamarian commented 24 September 2005 at 16:25

I'm trying to tame a monster :) hoping to shrink a scary 70+ queries monster into a huggable and lovable 10--20 queries teddy bear.

I did not like the suffix idea, it seems more complex than the secondary type key, or I may have misundrstood it.

Here's what I was thinking:

function cache_get($key, $ctid = 0)

Where cache type id $ctid is optionally (to not break other cached operations) provided for cache types of

ANY: The cache for this item does not require cache types, just use the $key.

ROLE: This cached item is role based, use the role id ($ctid) in the wehere clause.

USER: This a user based cached item, use the user id ($ctid) in the where clause.

The cache type ANY, ROLE and USER can be set in the block admin configuration, and some modules may just default them based on the functionality.

Drupal should be tamed!

Hosting Geek commented 28 September 2005 at 18:57

Drupal should be tamed!

Any update on the release date

marceloverdijk commented 12 October 2005 at 07:03

Is there any update about the planned release date of Drupal 4.7? Even if it's a release candidate.

yes i am very interested too

oliver soell commented 13 October 2005 at 20:19

many of the modules i'm working with are in this limbo between head and 4.6.. any estimated timeframe?

eagerly waiting for 4.7 for a new site

mwudrupal commented 14 October 2005 at 04:47

Hi - we are have urgent need to build our new site on drupal 4.7 mostly because of many new features (or patches incorporated) - such as optimized search and "free tagging", etc... please inform us kindly what is the estimated release date for this verions...thank you very much.

"When it's ready"

robertDouglass commented 14 October 2005 at 06:13

is the official answer, I believe. Fortunately, the forms API is now in core and the bugs created as a side-effect are slowly receeding. There is going to be a big bug-squashing session in Amsterdam, at the conference, next week. I'm sure that people will come away from the conference with some TODOs and ideas for how to improve usability, and need a week or two to get those in. All told, I personally wouldn't expect 4.7 for another month at the earliest.

Now, do you want to talk about my predictions for the stock market as well?

- Robert Douglass

-----
Rate the value of this post: http://rate.affero.net/robertDouglass/
I recommend CivicSpace: www.civicspacelabs.org
My sites: www.hornroller.com, www.robshouse.net

Offical Status Page for 4.7

neofactor commented 5 November 2005 at 00:28

Where is the official 4.7 status page?

The page should have:
1) time line
2) Feature list
3) Weekly Updates
4) List of Modules pre-certified to work.

;)

why then was the above 4.7.0 roadmap timeline made public?

wellsy commented 5 November 2005 at 01:40

Note if your prediction is correct the release date will be around December 7th. Two months later than the above timeline suggested for release candidates.

wellsy

orchidsonline.com.au

Because things change

sepeck commented 5 November 2005 at 02:21

There were a lot of major major things that were so close to being done that the freeze was help off, The changes that have gone in should allow for even cooler things to be done.

You'll see a new announcement soon.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

soon?

neofactor commented 5 November 2005 at 02:43

Is there an offical status from DRIES et al ?

Many are looking to launch new sites or holding off on changes to our sites because of the glimmer of hope that 4.7 will be released.

Please help us plan... do you have a projected date or not?

see tracking methods below :)

sepeck commented 5 November 2005 at 03:40

Some stuff HAS to get done first.
http://lists.drupal.org/archives/drupal-devel/2005-11/msg00028.html

http://lists.drupal.org/archives/drupal-devel/2005-10/msg00456.html

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

we all realise things change

wellsy commented 5 November 2005 at 02:53

But....if you are going to make roadmaps then people are going to base their future decisions on what they perceive is likely outcomes.

I recommend to err well and truly on the side of caution in future. Make predictions double the time the community think it will take and then surprise everyone when it is early.

Everyone is happy then!

wellsy

orchidsonline.com.au

Use 4.6

sepeck commented 5 November 2005 at 03:38

Use 4.6.3. It is the latest core stable release.
http://drupal.org/node/27362
It is recommended that you use the most recent stable release.

There are a huge amount of contributed modules available for it. You should not use or count on CVS release unless you are heavily involved in Drupal development and are familier with what is going on.

You can accomplish this by subscribing to drupal-devel and following trends. You can follow the cvs development and issues in project http://drupal.org/project/issues/subscribe
You can test and submit feedback and patches to help this process along.

The original projection was what was planned for. Circumstances changed and dictated a better outcome.

I will say it again. Use the latest Drupal major release for anything you are developing now. You can upgrade later.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

I agree, but

xand commented 5 November 2005 at 06:37

Using the latest stable release is an excellent idea.

However, I suspect that the impeutus is to avoid upgrading. Upgrading core is not a problem, but upgrading individual customizations can be a horrible chore.

In addition, waiting for the code freeze will allow contibution to the drupal effort - many of us are probably comfortable working with a pre-production version, and will be able to test and report bugs.

Lets hope that:

1. Upgrade system changes.
2. Forms API legacy path.
3. Node revision upgrades.

has hit core! :D

then feel free to

sepeck commented 5 November 2005 at 19:38

get involved helping out upgrade the core modules and you will be all that familier with what the changes are when you upgrade your sites.

Rather then hope... track development.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}

my god, it's full of stars!!

goncalo.dumas commented 9 November 2005 at 11:18

:o)

I'm just lovin using the cvs version of drupal... I think i'm gonna stick to it...

careful

Harry Slaughter

Omaha NE USA

commented 21 November 2005 at 01:41

do not use cvs HEAD drupal for anything you need to rely on.

those that want to plan around the drupal schedule at this point should be planning on using 4.6.*

harry

--
Living in fear of patch hell?
Want a stable development environment?
Support Dev Releases: http://drupal.org/node/30903
Support Code cleanup too: http://drupal.org/node/28540

--
Devbee - http://devbee.net/

Some people complain

David Lesieur commented 21 November 2005 at 02:27

Some people complain about 4.7 being late. Maybe future roadmaps should state more clearly that the deadlines are only targets for developers and that users should not bet their business on those deadlines.

I'm very happy with the development strategy so far, because it has brought us great quality code with no compromises. It would be sad if the developers became reluctant in making their plans public for fear of missing the deadlines.

// David Lesieur // Whisky Echo Bravo // Web applications development // Montreal, Canada //