It's been exactly one month since we released Drupal 4.7.0, and exactly three months until the next code and feature freeze. You might think that, since Drupal 4.7.0 was only recently released, we've been enjoying cocktails and other carnal delights on exotic beaches. Quite the contrary, in fact, and so it is time to provide a quick overview of the completed developments. Read on for more information.
The following changes are available in the development version of Drupal and will be available in the next major Drupal version (not to be confused with 4.7 bugfix and security releases):
- Improved configurability for contact forms: permissions have been introduced to define who can use a personal contact form.
- Block visibility by role: made it easy to configure the visibility of blocks by role.
- Poll module improvements: added functionality that optionally allows people to revise their vote, and that enables administrators to inspect all votes.
- Profile module improvements: user profiles can now use auto-complete textfields.
- Improved the themability of node and primary/secondary links, along with introducing a new hook_link_alter() to alter node links generated from any module.
Of course, there are a number of other features that are currently being worked on, but we'll talk about these when they hit the development version in a usable form. There is still lots and lots of stuff to work on, so don't hesitate to provide patches for all your personal battle plans and feature requests.
Comments
Does this mean...
Does this mean that cvs versions will no longer work with 4.7? There is essential functionality that is still not working on 4.7 and only CVS versions are available. For example, there is no stable way to create new types of content. CCK has been broken for several weeks and you must choose between hacking the latest version or using a previous one. Flexinode was behaving strangely last time I tried it.
Not wanting to write themes and modules that would need to be re-written immenently, site development has been on hold for 6 months not wanting to use the lame-duck 4.6. and with 4.7 not being ready to use. That has been followed by 4 weeks of 20 hour days trying to crank out sites.
If we are going to have such a short life cycle, can you please, Please, PLEASE consider making 4.8 compatible with 4.7?
I would have thought the Bryght guys especially would be fighting for this, since they have hundreds of sites to fix and I have less than a dozen.
Too late, Drupal CVS and 4.7
Too late, Drupal CVS and 4.7 already are apart by a (small) number of incompatible changes.
The bryght guys are actually pushing for a lot more changes. :p
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
How the heck
How the heck is anyone supposed to get a site working?
There are so many modules not working yet with 4.7. This is insane.
PLEASE, at least start publishing 4.7 CVS on the download pages first. So people have a chance to get a site working.
You show an absolute total lack of respect for the people working to use Drupal.
No idea how you are supposed
No idea how you are supposed to get your sites working, mine work fine...
There is really no need to hunt for the most recent release. If you find contrib modules to be not working, then I suggest you fix them and send patches to the maintainer.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Patches are bad
Patches are a bad thing on a live site. They result in a site that will mysteriously explode if an upgrade comes along.
Plus several critical modules are still only available as CVS versions (Most notably CCK and Flexinode and until today, E-Commerce, but there are others). Now there is no way to get a working version.
If any fixes are made to any of these, there is no way to download the interim version.
The idea is to send the
The idea is to send the patches to the maintainers so that they can apply them and release their module for 4.7.
WRT CCK: It isn't the brightest idea to use software that wasn't ever released for any version as a critical part of development for a new site.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
There is no choice
There is no choice. CCK or Flexinode is absolutely critical to any web site that I can concieve of.
Neither one of these modules is "released" for 4.7 yet. Now is hardly the time to move on. Version 4.7 is not done yet, it is still raw in the middle.
CCK
We'd like to see the CCK become part of Drupal core at some point (some additional information). Unfortunately, it won't happen overnight, and we're looking for people to help with this.
If CCK and/or flexinode are
If CCK and/or flexinode are so critical for you, you should contribute to the ongoing effort to get them ready for 4.7. I didn't notice any such participation from you, which again appears to be rather typical for a certain kind of Drupal users..
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Ouch
Please don't complain that I don't contribute enough. I have seen you make similar comments to other people in the forums and as much as I do not like to jump up and down and wave, especially when I know many others have contributed much more:
I apologize for not tempering the above message enough. I don't have time to keep revising it and I need to get back to work.
I am not complaining that
I am not complaining that you or anybody else wouldn't contribute enough, I complain about the fact that you seem to expect others to work in areas which benefit you.
And please stop seeing the contrib CVS guidelines as my personal invention, this is just plain silly. They were created before I got a CVS account myself. I am just enforcing them and deny access to people who don't want to follow them. If you changed your mind on this you are welcome to apply again.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
drupal, cck, open source participation
I think people who already have access/are part of the development group underestimate the barriers for people who just want to use the software with the least amount of friction and confusion. In fact I often see the attitude about open source where you're not legitimately using open source unless you are constantly involved in development, but in reality the sign of software that is really "ready" is it just works for the majority of users.
Contributing to an open source project is very much like being a performing artist; it's a lot of hard work but pays off in the recognition, but you're nothing without your audience, who give you feedback (and from what I've seen are very often willing to pay for fixes). Having no audience but all performers is a nice ideal, but in reality performing open source development - fixing things that haven't already been fixed or are obsolete, working in a forward compatible way, talking to the right people, etc - is a speciality that is not always compatible with other demands.
The flexinode/cck problems with the current Drupal are pretty serious, particularly since these are are often promoted as significant features of Drupal. It's almost like a classic "bait and switch" - people expect things to work, yet the deeper they go the less they find working and the more time is wasted. (and yes, there are warnings about CCK not being ready, but there are also plenty of examples that imply it's the thing to use).
I have some client work that screams for CCK so I don't have to saddle them with a custom module. I've had to fix some bugs myself - bugs which other people have noted, but are in the in between land of Drupal and CCK development so I can't submit patches (you do know the expression "yak shaving," right?), and will certainly lead to pain when a new version comes out.
I'm working on "sponsoring" a module developer now to make some changes that will benefit many people, if CCK is ever solid. I've seen a lot of ugly back and forth on the community's attitude. In this regard, Drupal's slogan "community plumbing" kind of gets the idea across in identifying the type of audience, but perhaps it should be "code that might do what you want, if you can roll up your sleeves and diagnose and fix the occasional defect" so people can be better warned.
Anyway, I hope there's something to think about in this post. I'm hoping to see a constant focus on making the features that define Drupal work well.
Never give up!
Never give up!
Perhaps behind one person's vitriol is a thousand people supporting and believing they too can make a difference... I hope that you remain committed and receive the support and recognition you deserve...
Best of luck.
Russ
---
Russ @ Firewize
Why is 4.6 a lame-duck?
Why is 4.6 a lame-duck?
Drupal neither forward nor backwards compatible
Because it is Drupal project policy that every version is incompatible with the previous one, so that templates and modules developed for one will need to be rewritten before they will work with another version (this is where you get the lecture about cruft).
If you are working with version 4.6 then you will need to update all of your modules and themes before you can use 4.7, (unless you run a separate copy of Drupal for each site). So if you don't like spending a huge whack of un-billable time rebuilding all of the templates and any custom modules for all past work, 4.6 was lame-duck and now, it appears, so is 4.7 after only 4 short (yet very long) weeks.
I never wanted to be a programmer anyway. I'd rather be a lumberjack in British Columbia! Leaping from tree to tree...
how so?
Perhaps I'm missing something, but I think that most modules that have a CVS version but not a 4.7 version are still developing the 4.7 version. There is nothing that forces the module's latest version (i.e. CVS) to match the Drupal HEAD/CVS development branch. I don't think most/typical module developers are going to even think about updating their modules to 4.8 until well after the API freeze September.
---
Work: BioRAFT
Not sure how Drupal works
but on most multiversion projects, there are certain constants that change the way modules are extracted from CVS, so if the default cvs version extracted is "head" then included bits from core will just make the CVS versions extracted for that version broken if those changes are not taken into account.
Of course, I don't have access to CVS (I have been banned on religious grounds) so I don't know exactly how Drupal is set up.
Sigh.
You have not been banned on religious grounds -- you have chosen not to release software under the license that covers the contents of Drupal CVS.
You don't seem to understand the concept of the CVS HEAD version -- it's simply the latest development version of a given file. That could be something written to work with the new functions being added to Drupal 4-7, and it could be something written for Drupal 4.0, in the dim recesses of history. One of my modules, VotingAPI, has a 4.7 tagged version and a CVS version -- both run without problems under 4.7, but the CVS version has experimental features that are not yet ready for prime time.
The "CVS" version of CCK is compatible with Drupal 4.7, and is being readied for an (eventual) 4.7 release. It's not tagged as '4.7' yet because it's not done -- same as Flexinode.
--
Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Thank-you
Thank-you for clearing that up. As I said, I wasn't sure how it is organized, if 4.7 is forked or built or tagged. But the fact remains, those of us struggling to use Drupal in the infancy of 4.7 need a way to be protected from 4.8. Couldn't 4.8 be a fork for now to protect us?
Oh, and just for the record, I agreed to release code under GNU, just not only under GNU. I have personal ethical issues with creating anything with GNU-only license and my name on it. It is against my religious beliefs to force someone else to do something against their will.
Read again, maybe?
It still doesn't sound like you get it. We don't need protection from 4.8, because there is no impetus upon module developers to develop for Drupal CVS rather than Drupal 4.7. At this point it is normal and to be expected that a contribution's CVS version will be in prep for its 4.7 release. Even after a module's 4.7 release, its CVS might still be for a 4.7 release, just with experimental features.
"CVS" does not mean "pre-4.8" for everything just because it means that for Drupal Core.
4.7 is the first time
That we broke compatibility with phptemplate templates since 4.4
We don't go out of our way to break things, but if we must break things to make them better, we don't hesitate.
And most of the stuff in CVS is 4.7 ready, but just hasn't been tagged, for reasons the module developer alone knows.
Not wanting to run HEAD code is understandable, but ultimately it's up to the module contributer, not the drupal project itself to update that code.
We only provide the space and infrastructure.
--
The future is so Bryght, I have to wear shades.
Where angels fear to tread
That is the big problem here. No respect for the work of the users.
I have lived though 4.5->4.6 and 4.6->4.7 and we spend more time waiting because the impending version promises to make all of our work moot than actually getting any work done.
I don't know what you are basing the "first time we broke compatibility" statement because I dare you to show me a site that was written in any version of drupal that works in a new version without major rework.
Let people get something done with 4.6 first.
Nobody stops you from
Nobody stops you from running 4.6. Really, nobody. I think that your problems are mostly due to poor planning following from misunderstanding the development process. Hint: We don't do Drupal so that /you/ can get stuff done...
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
Sorry. Meant 4.7, not 4.6
Sorry, I was getting hasty and rushing out the door. I meant give us a chance to use 4.7 first.
I never wrote any modules for 4.6 because the api was already declared dead.
Now one month after the release of 4.7 it is scheduled for imminent obsolescence too. I am not going to write any modules with a life span of 4 months.
I have programs that I wrote in 1996 on Windows 95 that still work on Windows XP Media Center, 10 years later. The template for a Drupal site I did in December won't even work on Drupal today.
I am walking away on this one.
I will never convince any of you that a stable API is a good idea. We obviously learned product design on different planets, and I just have to learn to accept your cultural differences (which I had, btw, it's just that this announcement was such a stab in the gut). No moss grows under your wrists. It will always remain one of the top 3 problems with Drupal.
Granted.
The difference between 4.7 and 4.8, API-wise, is the hook_links() function and its corresponding theme_links() function. It's used by modules to put a list of clickable links (like 'add a comment' or 'bookmark this node') at the bottom of a node or a teaser. For years it's been a pain in the ass to theme, because these links are raw HTML jammed into an array. Most modules don't use that hook, but those that do just have to return an array (the HREF, the title, and a class name for the link) rather than the raw HTML.
One hook.
One hook that most modules don't even use.
One hook that most modules don't use that most theme developers have been clamoring for change on literally for years.
I recently grabbed a module written for Drupal 4.5, years ago, and installed it. It worked fine with no modifications. On the other hand, I have Windows 98 software that doesn't work under Windows XP. In my day job, we use a UI Controls package that has had a new version out for a year, but it breaks API compatability and we don't have time to refactor all of our software. We've just put off upgrading it until we can.
I DO understand the frustration of working with changing APIs, but that's nothing new in software. The real question is 'how much work does it take to upgrade this?' In the case of 4.7 -> 4.8, the answer is 'almost none, and it doesn't matter until November at the earliest.'
Further discussion of API compatability and upgrade issues should be taken to a different thread or the developer mailing list, I think. This thread is for 'quick development updates.' :)
--
Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Summary of answers to a similar question
I asked a similar question on a related thread:
http://drupal.org/node/63688#comment-120381
I don't have the link handy, but somone helpfully pointed me to the archive of an extensive discussion on the developer list archive about this. I think I can summarize the answers as this: a given aspect of the API naturally becomes stable when the community is satisfied with it, rather than there being some mechanism of enforced stability.
---
Work: BioRAFT
Long time to 4.8 for Category module
The Category module looks really useful, has some problems and says to use the CVS version of Drupal. Could we have a Drupal 4.7.3 with every enhancement needed for Category?
We are looking at a long time before 4.8. If problem reports for Drupal and Category always refer to the "CVS" version then it could be anything from a four month timeframe. A simpler approach might be to line up the changes needed for Category and put them in a nominal 4.7.3. Next time there is a security update, place that in 4.7.3 and release. The Category module could then be released immediately after as Category 4.7.3. People would then have a more precise reference than the generic CVS.
petermoulding.com/web_architect
petermoulding.com/web_architect
No
There will be a Drupal 4.7.3 but it will be a maintenance release with bugfixes and no new features.
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
My 2 cents...
1) Talk to Jaza (the creator) about compatibility, as the version I am currently running works with 4.7. Is suspect the same is true of the latest cvs. Also, insn't there a version tagged as 4.7 anyways? My memory could be a bit funny.
2) The category module is much more experimental than others and has limitations due to the current structure of Drupal. This is why it may be keeping up to developments in head - patches applied may directly influence the module. There is also the fact that the module is experimental, Not to mention the fact that it is a "hack" (I mean this kindly) of the existing taxonomy and book systems. I imagine that the module will be reworked when 4.8 is out and maybe CCK is in core.
-------------------------------------------------------------------
Rick Vugteveen | Image X Media (work) | Blog (personal)
-------------------------------------------------------------------
Rick Vugteveen |rickvug.com @rickvug on Twitter
My recipe to make Drupal a killing cms
My recipe to make Drupal a killing cms:
As soon as I get broadband, I'm gonna spend my entire summer holidays improving Drupal by this list and http://drupal.org/project/issues?projects=3060&versions=6487,11551,11252....
Cheers Johan F
[fixed tags]
hi
i can't open this link
http://drupal.org/node/64590 is it workable?
------------------
Regards
Tomash Sanderson
music blog
It works for me at least, it
It works for me at least, it points to the "version module"
Some things i forgot: Add
Some things i forgot: