Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Dries on
Thanks to all the hard work we've done in the past months, the next version of Drupal will have a lot of great improvements!
- improved logging functionality
- support for reverse proxies
- many language system improvements (support for right to left languages, advanced language detection, support for translating posts to different languages, etc)
- improved handling of teasers
- drastic theme system improvements
- an improved installer
- support for OpenID
- and much more
There are also a ton of API improvements that should lead to more and better contributed modules. For a complete overview of the most notable improvements, take a look at the CHANGELOG.txt.
Drupal 6 will be an important factor for Drupal's continued success in 2007 and 2008. Needless to say, I'm really happy with what we accomplished together. Especially with the improved localization (l10n) support and the newly added internationalization (i18n) support, we hope to reach out to a much larger group of people.
In preparation of the Drupal 6.0 release development of Drupal core is frozen as of July 1st. During the initial stage of the code freeze, documentation updates, usability improvements, and performance improvements will still be accepted. New functionality or API changes / additions, on the other hand, will not be unless deemed critical. As of today, the focus is to strengthen the code base's performance, usability, and stability. 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. As always, everyone is invited to help.
Because some patches were 98% ready before the code freeze, I also granted six exceptions. Six patches will have another two weeks to make it into Drupal 6 (or not). These patches are documented at patch spotlight page and are screaming for your help. Two weeks isn't a whole lot of time.
As usual, we can't say when Drupal 6.0 will be ready (it's ready when it's ready) but it is estimated that it will take at least two months before Drupal 6.0 can be released. During that period, one or more release candidates will be made available. Furthermore, a two month code freeze should give module maintainers plenty of time to upgrade their contributed modules.
Comments
what are your plans
what are your plans regarding updating drupal.org to D6 release?
Sometimes something interesting appears on http://litwol.com
First of all: There isn't a
First of all: There isn't a release yet, not even a beta
Second: We run number of contributed modules on drupal.org that need to be updated.
So, everybody who wants us to update d.o should subit patches for updateing project module and friends to D6....
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services
contributed modules
Lack of updated contributed modules is one of the reasons why I still run Drupal 4.7 on my site. With Drupal 6 coming so quickly, I'm concerned the problem will only get worse.
--
John Forsythe
Need reliable Drupal hosting?
Curious...
What contrib modules are you referring to? I haven't found any contrib modules that didn't make the 5.0 transition. At least, none that can't be replaced by other 5.0-compatible modules.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Gmap is one
Gmap is one I've been waiting on for one of my projects since setting up the Drupal 5 basis for the site last year.
I believe...
That the GMap module is 5.x compatible now.
All good things must come to an end, enjoy them before they do!
Check out DreamHost.com for down to earth hosting. If you like, use 'KarmaSpread' to save some $. 10% of my referral goes to charity.
Not sure about that
Its undergoing a complete rewrite apparently, and the issue tracker is full of people saying rather crucial things are not working in the existing 5 dev version.
playlist
The Playlist module. There was an effort to integrate it with the Audio module, but it seems to be in limbo at the moment.
--
John Forsythe
Need reliable Drupal hosting?
filestore2 and fscache were never updated to 5.0
there is a thread about that --> http://drupal.org/node/134305
Actually
There were many that didn't go to 5.x. And more that were very much delayed. And some (e.g. Acidfree) that still don't have official, stable releases yet. So I have to agree with the writer's concerns.
I'm wondering how many modules are going to be significantly delayed (or even dropped) because of changes in 6.x, such as the forms changes. I'd really like to see the "Converting 5.x to 6.x" section of the handbook be beefed up with better (real life) examples. And even better would be if the Coder module could suggest exactly how to change things. That would greatly speed up the conversion.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Wiki pages at g.d.o for the latest status to Contributed Modules
I share your concern.
People often wonder what the status is of Drupal contributed modules, especially just before and after a new version of Drupal such as 5.x or 6.x is made available to the public. People wonder, "Will module xyz be updated soon or will module abc be integrated into core or will module 123 be discontinued?"
Michelle and I emailed each other regarding Contrib modules version 5.x status - Module maintainers please read and I suggested it might make sense to post the contents of the body of that page, particularly the table that lists the status of a majority of the contributed modules, onto a wiki at groups.drupal.org. The result is the Contributed Module Status group! The hope is that it will become THE status resource for ALL contributed modules, THE place where everyone can go to see what will happen to this or that module as a release gets closer and closer as well as shortly after a release. Michelle was very kind in providing the HTML from the main post on her page. Thanks Michelle!
Now, ANYONE can easily make updates to the status of 6.x contributed modules with a few clicks because the tables exist on wiki pages! At first, it appeared best if contributed module maintainers could visit the Contributed Module Status group and update the status of their own contributed module(s) for the community. However, it's simply faster and easier to encourage EVERYONE to contribute and update the wiki pages with any known pertinent details in order for all contributed modules to have the latest and best-known status!
This group's benefit to the Drupal community is that anyone will be able to, at a glance, view the status of contributed modules that have been included. The goal is to include ALL contributed modules AND allow anyone to contribute updates.
A wiki page will be created for each Drupal release, and each wiki page will be an informal list of plans for contributed modules being ported to that release. The list of plans will consist of informal guesstimates and no one should expect exact delivery dates. However, if you are a module maintainer and have an idea of if and/or when you'll be porting it to the specific release, e.g. 6.x, being cited on a wiki page, your comments would be especially helpful.
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Good question! :) In
Good question! :)
In addition to what killes said: historically, we always upgraded drupal.org before the final Drupal release is made because it makes for a great final (stress) test. We'll try to do the same this time around but it all depends on how much people are willing to help upgrade some of the required modules.
Digg this!
Digg this!
what about the performance patches
it took me months to find several very Key performance patches, have they been implemented ... my list is as follow:
1- http://drupal.org/node/105639#comment-245280
2- http://drupal.org/node/106559
3- http://drupal.org/node/100301
4- http://drupal.org/node/137934
5- http://drupal.org/node/108752
one of the key problems of drupal, as many others also agree, is the performance, from a 10 to 20 second ping time and memory and cashing issues. i hope drupal 6 has addressed these huge issues, or is in the process of improving them. i personally was hoping with all the patches contributed in that past few months that we see drupal 5.2 before 6.
from the log file it doesn't seem to me that the entire system has been overhauled, there are tweaks and major improvement only in certain areas so why a whole point jump to 6 where 5.2 or even 5.5 is more logical since majority of system is still intact.
Incremental
Drupal6 core API was changed enough to make all contrib modules break. so its not logical to say its a D5 family member.
However, i dont see the big reason on jump to another version/revision instead do a incremental work. There are thousands of opened issues for D5 and D4.7 that is still pending. Update contrib module is also problematic. Since many users still uses D4.7 (or even D4.6), its even more confusing to maintain 4 different versions.
Many of the new features will not colide with the contrib modules, so it could be made on D5. Some of the "focus is to strengthen the code base's performance, usability, and stability" could be made on D5. Taking a look on Changelog.txt, 2/3 are only incremental work.
The worst is that D6 hasnt that Killer Feature that will make "ow!" on current users nor on new users. It could be baked a bit longer to provide a whole new set of features. PHP E_ALL or drupal.sh or OpenID could also done on D5 without ANY side effect on contrib modules!
"The worst is that D6 hasnt
"The worst is that D6 hasnt that Killer Feature that will make "ow!" on cur......."
agreed.
Please do not repeat the mistake that jxxmla did in their 1.5beta.
faster new version number coming up do not help the CMS in any area.
Killer features
Drupal 5 came with a new core theme, an installer, a redesign of the administration pages and much more. It had an incredibly strong focus on improving the experience for Drupal site administrators. With Drupal 6, we're reaching out to different Drupal users; developers, designers, system administrators, and translators -- and to a lesser extend to Drupal site administrators.
For a lot of people, the internationalization support is a killer feature though. Frankly, Drupal 6 will be the Open Source CMS (written in PHP) to use if you want rock solid l10n and i18n features, and that should not be taken lightly. At the same time, a lot of people could care less about l10n/i18n support. As a feature, l10n/i18n is somewhat black and white; either you care about it, or not. Nonetheless, it is a killer feature for many of us. Trust me.
There are also sweeping changes to the theme system. Finally, the theme system will be easy to use. For designer this is going to be a killer feature, and hopefully, this will lead to more good Drupal themes.
Furthermore, there a ton of API changes that will make it easier/possible to write certain types of modules and that enables modules like the CCK and views to further flourish. Drupal 6 will indirectly result in more and better contributed modules, and developers will enjoy working with Drupal 6 more than working with Drupal 5. Drupal 6 will let a 1000 contributed modules bloom. ;-)
Last but not least, with Drupal 6 it should also be significantly easier to administer and scale large Drupal sites.
Personally, I think there is a lot to be liked, and that certainly warrants a Drupal 6 release.
Killer features on Drupal 5.2
Dries,
seeing the changelog, i see the i18n module with some good new features. automatic import, for example, can be added to D5 without any module break. Many of them already exist, but its a contrib module. I have a international drupal site (i use i18n) and im a ubuntu developer, so i use a really stunning translation system. Translations are horribly hard to do on drupal (so hard that almost no module has updated translations for more than 3 languages)! Our idea about translation.drupal.org may not come, so the problem might continue. Whats the importance of a automatic importer if no modules will come with updated translations?!
maybe its my fault about not seeing that miracle on these new APIs, but whats the big thing? Im ecommerce dev team member and im praying to be true!! (since Ecommerce module is bigger than Drupal itself)
There are two kinds of program versions: date-fixed versions (like Fifa Soccer, Ubuntu) and feature-fixed versions (like apache, firefox and drupal). unlike date-fixed programs, that can break some APIs each version, feature-fixed programs usually have a progressive and evolutive development (debian is 4, apache is 2, but drupal, only during 2007, will have 3 versions!). New versions are only needed when important features break the current plugins. If D5 with PHP E_ALL and OpenID doesnt break any other modules, so its better than having a D6. as i said, 2/3 of D6 could be added to D5 and the issue list is getting bigger and bigger.
bottom line: i18n and nodeteaser modules included on core and a new API to force all contrib developers to rewrite all over again and support legacy versions. These killer features could be on the "stunning" D5.2 or D5.3... I always see the status_update module if there is a new drupal update...
Release number confusion?
It looks like you might be confused about the version numbering scheme and the Drupal conventions surrounding those. Last summer we decided to replace the 3 digit scheme (i.e. Drupal 4.7.3) with a 2 digit scheme (i.e. Drupal 5.0). As of Drupal 5, we're increasing the first digit with every major release, and the second digit for every bugfix release. After we got stuck in the 4.7.x branch for 3-4 years, there is no such thing anymore as intermediate releases. Drupal 5.1 and Drupal 5.2 are bugfix releases, and not feature releases. This was discussed at length about 11 months ago -- read up on the archives/forums if you want to learn more about that.
This means that Drupal 5 is frozen and that we have a strict policy of not backporting features to Drupal 5 -- we're only fixing bugs in the Drupal 5 branch. We want Drupal 5 to be a stable platform that people can rely and build on. Backporting features to Drupal 5, would make the Drupal 5 release a moving target and contributed modules might, or might not, work with specific versions of Drupal 5.
A key reason for this change was to simplify the release management of contributed modules, and to let contributed modules flourish by having their own release cycles. That is done on purpose so some of the action would shift to the contributed modules. Chances are that "Drupal 6 + some contributed modules" will give you the killer features that you are looking for. Drupal 6 will provide a better framework for contributed modules. (It looks like you're asking for more action in core.)
As far as translations is concerned -- there are 1 or 2 summer of code students that are working on better tools to translate Drupal, and to distribute and install these translations. These new tools will be able to leverage the locale module improvements in Drupal 6. Both Drupal 6 and these tools are hopefully going to be ready around the same time. I'd suggest that you work with these people to make Drupal 6 easier to translate: making Drupal easier to translate is exactly what we're trying to accomplish, and it is certainly not too late to help. (You make it sound as if it is too late to help. Not quite!)
Release number confusion
Dries,
yes, you are right! i was confused by this numbers! but partially its because it is confusing: code optimizations are oftem not considered new versions (unless it make any change on API). the 3-digit way was not wrong. that was wrong was the implementation: breaking the API. Changing the API should be always considered a new version. changing the API three times a year is not making D5 a moving target, its making Drupal itself a moving target. I believed that the second digit was a mix between bug fix and general optimization. somewhat like a monthly release.
Well, since its the way it is, drupal.org should warn developers and bug reporters that "bug report" (unless its critical) or any other patch provided to "Drupal 5-dev" will only be implemented to D6. And once D6 and D5 codes are different, the patch, in fact, will never be used. its kinda bizarre. maybe its the reason behind 1000+ issues.
There are three types of changes:
Optimization Features: PHP E_ALL code, SQL optimizations, working under reverse proxy and code cleaning (but only internally). Since there is no colateral effects (except positive ones) on contrib modules, it can be implemented on current release.
New features that dont touch a contrib area: OpenID, some i18n features, some watchdog features and even the new installer doesnt alter any current contrib module, so it can be implemented on the current release or it can continue to be a contribution, but now with a "supervision" and recommendation from Drupal Core.
New API: menu and form changes will break the current modules, so it should be on the next release.
The current model is only forcing users to have a static program (with basicly no support, since new stuff, small bug fixes or optimization will only show up 8 months later). All tutorials, screencasts, blogs, magazine reviews should be reviewed. puf... its going to be hard
finally, i MUST have to say that i like the changes and i will support it (converting modules, rewriting documentation, and supporing newbies on forums here and the brazilian site), i only dont like much the way its getting done... but i must say Good Job!
Agreed
For what it is worth, i have to say i agree with Bruno on his comments about release numbers, types of changes, and moving targets.
I will add that personally, i don’t like to see major Drupal updates occurring more than once a year. 18 months between major releases would suit me just fine. Contributed modules sometimes aren’t updated until months after an API-breaking release. I can’t migrate to the new version until the modules i use are compatible. The more often i have to go through the process of waiting and watching for all the updates to the modules i need, the less happy i am about running a Drupal site. I understand that it is sometimes necessary to change the API to make advances, but if you do it too often, people are not happy.
Just my 2¢ worth.
new features -> api changes
- The openID module required lots of changes in how users are authenticated, how distributed authentication could plug into the system, so this break at least all the authentication modules (jabber, ldap, etc).
- The i18n features needed *very deep* core changes (we introduced a new bootstrap phase just as a simple example), modified tables, broken many APIs to allow for easy programmability. Sending of emails was completely broken for example, and impossible to fix in a multilanguage scenario without modifying the whole process.
- The watchdog features were refactored from the 5.x watchdog module, as we basically needed to decouple the database storage from the logging part. This already broken the API, but the external logging support would have been broken, if we do not modify the language handling methods used in there. This means you need to touch all watchdog() calls in all modules to update to support the external logging feature.
- The new installer required completely new ways to let install profiles plug into the system, or otherwise the custom install screen feature would be completely gone. Either way, we have broken all existing install profiles.
Drupal evolves with fitting the core system to the needs at hand, allowing contributions to do even more with what is given. New features both need changes in how things were done before to efficiently build the new stuff into the system, and they offer new stuff for contributed modules to build into. Both of these result in new features not being possible to be added to stable releases.
Bug fixes and even performance improvements are applied to the 5.x version, not only when they come around. On occasions, I have even been asked to provide 6.x E_ALL patches in backported format for Drupal 5.x by Niel Drumm (the 5.x maintainer).
"All tutorials, screencasts,
"All tutorials, screencasts, blogs, magazine reviews should be reviewed. puf..."
Not to mention the long awaited book I just bought ;(
Lopo
Humaneasy Consulting
iPublicis!COM
www.humaneasy.com
www.ipublicis.com
CSM & CSPO
Obsolecense? Nope!
Some of the content of the book will definitely need to be updated, but one of the most important aspects of the book -- the detailed look that it gives at how Drupal's internals work, how its APIs are structured, and so on -- is still valid. The changes in Drupal 6 are noteworthy as changes.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
theme killer features...
i'm really missing the very small patch from http://drupal.org/node/57676 in D6. A broken feature since 4.7.x :-(((
Translation is a "Killer" feature for me!
Here's one vote in support of this comment. I'm actually waiting to begin work on a project that will require extremely heavy multi-lingual capabilities until Drupal 6 is released. Is it scary to not know how long the project will sit on the shelf due to an undefined release date? Of course! On the other hand, multi-lingual issues are not trivial. The wait will be worth it. (Well, it better be or I'm toast!) Thanks to everyone who is working on the new release.
It is my belief that strength in this one area by Drupal could be a deciding factor in its survival into the next round of CMS evolution. Sharepoint Services 3.0 rocks hard. Multi-lingual tools is a space where Drupal can maintain its relevance.
Just my 2 cents...
I hope i am not duplicating
I hope i am not duplicating an issue that was brought up a long ago, i dont know if it was. but my question is, it seems that the biggest 'core' part of drupal is the FAPI. everything else spans from it. so why not call drupal core release as what it really is, instead of just a bundle of modules. drupal core modules could have been much more developed by now if they were not restricted by the 'core freeze'. taking core modules out of the core will allow them to be developed faster and yet to be bundled with the drupal distribution, or perhaps just a particular profile/bundle.
i am not critisizing at all! i hope i am not mispercieved. i would just like to raise the question "why things are done the way they are now instead of somethign that is potentialy much flexible?"
Sometimes something interesting appears on http://litwol.com
built-in modules
More modules are built-in in this release, then in Drupal 5. Built-in modules have the advantage of much more people reviewing them and fixing stuff. They also automatically get the new API updates, no need to wait for them to come out. Many people perceive them as of higher quality to contributed modules, and this is often the case. They can also be built on. Drupal 6 will include an actions module, which is a true developer (and end user) enabler. This is expected to be built on by many modules in the contributed repository.
So while a module being in Drupal core might not develop as quickly as it could in the contributed repository (although other people in this thread especially criticize Drupal for moving too quickly already), they enjoy lots of advantages when compared to contributed modules.
thank you for explaining.
thank you for explaining. now i understand and glad that things are the way they are. again, thank you.
Sometimes something interesting appears on http://litwol.com
Progress, but at what cost?
I don't claim to be any great fountain of knowledge when it comes to open source development, but I do what I can to help point out bugs, or suggest usability features where I can. But it seems to me there is sometimes a high price paid for continually developing "shiny" new features and pushing out the next Drupal release. Not that a code freeze means its necessarily being rushed or that its due out anytime soon of course.
Before I get shot down for drupal bashing, it ain't so, over the last 2 years I have grown to love Drupals flexibility which has enabled a non-coder such as myself to establish online communities, and several totally different websites. Its my most powerful web tool at this time, and something I care about the future of.
I simply sometimes feel frustrated at the apparent divide between the "shiny new features" / next drupal release movement, and the reality that many modules/features are still not working even for 4.7 (such as a working image Captcha - totally vital on todays web) in some cases, or 5.1, and other modules which I'm sure have a lot of potential users such as Gmap are not yet upgraded to drupal 5.1
I'm certainly not having a go at the various developers involved, who generously contribute their time for free to help create something for all of us to use.
All I'm trying to say is it seems at times that the continuous forward momentum in the Drupal project, always thinking of new ways to do things and cool new bells and whistles, may actually fracture the possibility of creating and maintaining a functional website for many of us in the non coding drupal community, who are left with several versions of Drupals past/present/future, and a huge array of modules/features which may or may not work.
Again, I'm not whining about everything not being perfect, just wanting to voice my opinion about Drupal, which I want to continue to use into the future along with you all. I suppose open source often tends towards always looking forward and building the next generation of the software... I wouldn't know, Drupal is the only open source project I'm involved in. I guess what I'm imagining is a Drupal where a little more focus and importance is placed on not only the core Drupal stability, but the working functionality/usability of a basic realistic Drupal website in the wild.
Now I realize that the contributed modules are on a "use at own risk" type basis generally, and its the web developers responsibility to make sure they use modules which will work correctly with their project. But to me it seems a little off in regards to what are basically going to be required modules for the majority of sites, such as a captcha that can be installed, and just works. (Not meaning to pick on captcha - but you get my point)
Does anyone else have similar concerns? Maybe I just have to live with it, but thought I'd voice my opinion on the matter.
mediafrenzy, I think you
mediafrenzy,
I think you have to take this all in stride, and realize a couple things... NAMELY that this is a far better "problem" (as you say) than the opposite. Things would be dire indeed if there were no momentum. But there's plenty of it, and frankly better to have it than not.
Secondly, and I think this is important, just because the module(s) you're using today aren't supported by current/future versions of drupal doesn't mean they won't be, and frankly, we could wait around forever waiting for people to update modules, but the truth is that a lot of those modules were developed for one customer/need and submitted to the community and never looked at again. If you like the functionality, and need it, then perhaps you should dabble in becoming a programmer yourself. the coder module provides great resources for updating stuff, and then there's always the Drupal book (which is truly excellent in this regard). It all comes back to the "Open Source isn't free, it just pays different" statement... which gets flung around a lot, but that's cause it's totally true.
Finally, I'd just like to encourage you. If the greatest problem that exists is that we're progressing very quickly, then the solution is to stay put. Don't try to make everyone else stand still just because it would be better for you in your situation. No one is compelling/forcing you to upgrade, so don't. Many professional drupal sites don't use the newest version of drupal for MANY months. There's no reason this solution won't work for you.
Eclipse
Sales Representative
The Worx Company
http://www.worxco.com
Eclipse
I agree
I agree that a total lack of momentum would be a very real issue indeed, and I'm certainly not trying to say "everyone stop moving forward, because I don't want to have to upgrade".
Consider my captcha example - why is it that Drupal, a remarkable, flexible CMS - now *mature* at version 5.1, almost 6, is still without some basic security features? Thats not moving forward, thats more like undoing real world usability in favor of shiny new features in my opinion. Thats what I'm trying to say, not that I'm sick of upgrading sites. Items which need to be considered more closely, rather than brushed off with comments such as "oh if you want to stop spam just code your own spam catcher, or switch off anon commenting". Again, this is only one example, but illustrates what I'm meaning.
I know Heine has now come to the party with his excellent module MyCaptcha for 5.1+, but thats only a recent addition - and many people don't even know about it here. How long have people been trying to get some form of captcha working correctly in the meantime. You see my point?
Far from trying to make everyone else stand still, I love the new features that come along, and the exciting new modules that get thought up along the way - but the basics need to be there, for *all* of us to create and maintain top quality websites, not just me. If the basics get consistantly overlooked or brushed aside, thats bad for all of us. Thats my concern.
Core Begets Contrib
Captcha is an excellent example of why the 'invisible' APIs that make up Drupal core are so critical, and why 'developer-focused' releases like version 6 are important. One of the primary difficulties with the current Captcha module, and the source of much of its bugginess, is the difficulty of 'injecting' certain kinds of validation questions into the form submission process. Simplifying that -- making it easier for modules to do complex tasks like displaying Captchas without breaking other modules -- is part of what the 'FormAPI 3' improvements in Drupal 6 make possible.
Which is to say, part of the reason Captcha has been buggy is the fact that some of Drupal's APIs made its task too hard. Simplifying that, so that developers can build those complex features cleanly, is important.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
CAPTCHAs
I could not have said it better. I actually spent 8 hours trying 3 different ways to add CAPTCHAs to my Drupal 5 site. It was a royal pain. With the form API improvements in Drupal 6, this is going to take me 20 minutes, at most.
Hi, features like captcha
Hi,
features like captcha that 90% of users will use and that concern security should be part of drupal core. If you spent 8 hours trying to get captcha work on Drupal 5... think about us non programmer, harassed by spambots with a buggy captcha. My only solution was to shut down user registration and ability to post.
I know that you want to keep core as light as possible, but some security features NEED to make it into core (i'm thinking here about captcha, and anti flood measures).
Other than this, my toughts about drupal 6 release are mixed. The internationalization feature is sure a killer and I will even make some nice experiment with it, maybe even hire someone to translate my site CONTENT.
But as someone said, I was using module 5.x still in dev state, and upgraded my site to 5.x 2 months ago only (waiting for modules) and now drupal 6 is arround the corner already. The 1 year period between release is a good one I think, it is just that some developers take so much time to upgrade their module....
Cordially,
Brakkar
Good to hear
Its good to have this explained, and I hope it will take shape as you describe.
As I'm not a coder, most of that API / core knowledgeable stuff goes over my head, so I guess myself and others in my position are kind of in the dark as to what the "big picture" is.
Its encouraging to hear that it seems like one of the main reasons for this development drive is for exactly the reasons I'm drawing attention to here. I do hope that it is a realized goal, not a shifting set of ideal goals.
Thanks for your efforts guys.
Progress, but at what cost?
I would agree with mediafrenzy. It is true that a lot of modules were never even ported to 5.x and now they need to get to 6.x? I think that the new features are kickass and I would not take anything away from the hard work that has gone into them, but in the software dev world the most secure and robust OS's and systems have long release cycles.
Long system release cycles ==> Stable platform ==> Modules can be developed and extended
Short release cycles ==> Kickass system ==> Modules fall by the wayside
And I think that summarizes what the cost is.
BTW I love Drupal
how can one help?
Well, we can lament about contributed module developers falling behind, but there are many ways to help:
- most of these developers love to get patches against their code, to update the module
- some of these developers just look for an exit (another more responsible maintainer to take over, who can come from the community)
- some of these developers are happy when get sponsored for an update
If you can neither help with coding, paying for someone to code, or finding/encouraging someone else to fix the problem, then surely all is left is lamenting about contributed modules lagging behind...
If some features are critical for some people, they will either develop it themselfs (and sometimes even release the code), or pay someone to develop it. If neither of this happens for a *popular* module, then there is possibly some problem with the maintainer, and he could just look for an exit, as I have explained.
Some challenges I've faced due to release frequency...
First off, well done everyone contributing to D6!
At the most basic level I totally agree with mediafrenzy. Compared to other OS projects I've had involvement with Drupal development does seem to move very quickly, and as Drupal users depend so heavily on using contrib modules I am not sure that having three major versions within the space of 12 months is necessarily in the best interest of the wider community. That said I think it is a credit to the Drupal Devs that they maintain several code bases to try and prevent leaving anyone behind. Still though, the frequency of major releases, lag of contrib updates to these releases and several other factors are all of concern when choosing Drupal as a long term option. The main issues I've faced can be summarized as;
System dependence;
As a Windows/IIS user I find it concerning that there seems to be an increasing amount of dependence on a Drupal site being hosted on a *nix/Apache based server to get full/unhindered functionality. Things like specific checks for .htaccess rewrite rules, drupal.sh and the syslog module are all dependent on a *nix/Apache based server. Regardless of where your loyalties lay, the fact is that 1 in every 3 websites on the net use IIS, and it is the most significant webserver in use after Apache (which has 50% market share). The beauty of using a platform independent language such as PHP is lost when platform specific functionality is built into the core.
Access to competent, available and affordable Drupal consulting resources;
I REALLY think Drupal needs a better way to manage their market place. Since I first decided to move my Xoops based site to Drupal near 2 years ago now I have been faced with a constant and frustrating uphill battle trying to find and secure time from competent Drupal developers who are even remotely affordable. I am not a business, I am a Drupal hobbyist, but I have been looking to spend around $4000USD to develop a custom module and theme for Drupal 5 since the start of the year. This is a MASSIVE amount of money for me (especially for a hobby), and now it looks like I'll have to wait for Drupal 6 as I'd be mad to go ahead with Drupal 5 now when Drupal 6 is only a matter of months away and I won't be able to afford to spend a lump sum like this for at least another year.
Major release frequency;
I have sponsored several Drupal module developments which I happily release back to the Drupal community. However, the combination of frequent major releases and shortage of affordable, available and competent consultancy resources have cost me a lot of money. For example in my preparation to upgrade from 4.7 to 5.1 I paid a significant amount to have a module ungraded to 5.1, but with Drupal 6 now looming larger and no budget to be revisiting my site for another upgrade again in another 6 months I will now likely re focus to Drupal 6. This meaning all that money I spent on upgrading this module has been totally useless to me, and I will have to spend this again for Drupal 6.
Just my 2c anyway...
----------------
Dominic Ryan
www.iis-aid.com
dependecies and a pressure to upgrade?
Well, Drupal can run fine without the .htaccess rules. Sure, it will not provide the nice URLs, but there are still a whole lot of different tools used on IIS servers to achive clean URLs, so we would need to ship with 3-5 different rule sets (some very similar to .htaccess rewrite rules) to support them. drupal.sh is far from being a required part of the system, it will only be used by hardcore power users and possibly solution providers. The last one you mentioned is syslog, which logs to the system log, which is perfectly available on Windows servers from at least Windows NT (in which version I used it with PHP, just as Drupal uses it now).
It sounds as if you are running around circles in upgrading your site, but do you really needs these updates? I am one of the Drupal 6 core committers, so I can easily say I am close to the top of things. Yet, one of the big Drupal sites I run uses Drupal 4.6.x(!), of which the last maintenance release was published in january this year (half a year ago). This is not a supported Drupal version now, but we still kept it as-is, because it worked just fine. It supports the community greatly. Although there are some smaller issues, it was not worth the upgrade. Now we think about upgrading it to Drupal 5 (even if Drupal 6 is released in the meantime), as we have the contributed modules ready for *that* version, and it certainly allows the development of some features the community started to ask for.
*Not* being on the bleeding edge has some serious advantages, and you did not give any clear reasons about why you have a pressure to upgrade as soon as a new version comes out. Are the new stuff so important or critical for your site, that you cannot operate without pushing to have them?
Release schedule: getting the facts right
Compared to other OS projects I've had involvement with Drupal development does seem to move very quickly, and as Drupal users depend so heavily on using contrib modules I am not sure that having three major versions within the space of 12 months is necessarily in the best interest of the wider community.
FUD alert! ;)
Drupal 5 was released on January 15th. That is 7 months ago. It will easily take another 2-3 months before Drupal 6 is released. As a reference, the Drupal 5 code freeze took 4 months. So if you do the math, you end up with little more than one major Drupal release a year, not three major Drupal releases a year.
Go ahead and use Drupal 5. You might not be able to upgrade for another 6 months (depending on what modules you want to use). Make the modules available, and maybe someone will help maintain them free of charge. You never know ...
Drupal 5.x is not dead !!!
I have seen that there are many people being worried, Drupal 5. x is not dead, just now is when is flourishing.
Drupal 6.x will not replace immediately Drupal 5.x, this will be in a long time.
Still with Drupal 6 released, Drupal 5.x will be maintained, a long time, just until a Drupal 7 release.
Do not believe you guys that there is plenty of time so that all the modules can be migrated to Drupal 6 a long time before Drupal 5 leave of to be maintained ?
Drupal 5.x will continue being a stable version, 5.x modules will be maintained for a while, just like 4.7.x are now.
In my opinion, who want to continue with Drupal 5.x, do not have to be worried. If you need and want to use the features of Drupal 6, go ahead, let's help to migrate the modules that we need.
Welcome to Drupal 6 !!!, very good work !!!
You never know...
Maybe "you never know" is part of the problem here. Now, nothing's ever certain in life, but in general people dislike uncertainty very much and try to make their lives as certain and predictable as they can.
Even if there are good reasons and several plausible and realistic upgrade scenarios, I can understand the unpleasant feeling of knowing in advance that (at some point) you're going to have to deal with the uncertainty of how direly needed contrib modules will or will not become available for the next major release.
If you are a developer and able to fix such technical problems yourself, your uncertainty won't vex you very much, but being a model Drupal citizen (as I see it, with brashquido actually spending money in the community to have his problems fixed), the job of (eventually) upgrading can seem daunting indeed.
It seems to me that the uncertainty over contrib modules, that are considered crucial by their users, drives quite a few posts and discussions on the forums. There probably is no simple solution, either technical or social, but addressing it (maybe by taking a formal stance on it) could help alleviate some of the certainty.
Pretty much hitting the nail
Pretty much hitting the nail on the head there fschaap. A great deal of Drupal's power comes from the sum of the modules you are using, so having an environment where Drupal core development charges ahead with the contrib modules struggling to keep up, and users one step behind that again doesn't seem to be optimal to me. It wouldn't be so bad if;
a) Extend the maintaince life span so that the last 3 or at a stretch even 4 major versions of Drupal are updated security wise. This way Drupal "citizens" have longer to prepare, plan and save (if necessary) to upgrade their Drupal environment without fear of the versions they are using to fall out of step with security issues.
b) Divert some of the "forward motion" of the Drupal core development out into updating the popular contrib modules to close the gap between current Drupal release and supported modules.
----------------
Dominic Ryan
www.iis-aid.com
Thanks for the replies
Thanks for the replies Gábor and Dries.
@Gábor
That's exactly my point. These functions (rewrite and drupal.sh) are made specifcally for *nix/Apache based systems. Required or not (wasn't aware that the syslog module would be compatible with Windows event log) if you are using a platform other than *nix/Apache and need these functions then you are at a disadvantage. Point I'm getting at is that it seems Drupal dev is almost entirely focused on a *nix/Apache which accomodates for at best 50% of the market, and the
I certainly do see your point about being on the bleeding edge, but the main pressure for me and I suspect others to stay with the latest release is simply to maximise my investments lifespan. If I'm spending this sort of money I want at least 12 months before I even ponder the idea of upgrading again, not 6 months. If only the latest 2 versions of Drupal are maintained and we end up going from Drupal 4.7 to 6.0 inside of a year, then unless I am mistaken it is entirely conceivable that the current version of Drupal could be on the unmaintained list inside of 18 months. That means that unless you are a coder you are going to find it very hard and/or expensive to maintain your site so that it evolves with the Drupal life cycle. The only other choice is to stick with one version until it is no longer maintained and then upgrade to the latest in one big swoop, and just hope that no major security flaws are found in the period of use while it is not maintained. Either way is expensive.
@ Dries
I didn't say three releases of Drupal Dries, I said there had been 3 major versions, i.e 2 releases. If Drupal 6 is released before Janurary 15th 2008 which is highly likely, then that will mean we have had 3 major versions (4.7, 5 & 6) of Drupal in 12 months. If I only migrate to Drupal 5, and assuming the current release cycle is maintained then I'd be using a version of Drupal that is about to be added to the unmaintained list by this time next year. No two ways about it, this is expensive financially for a non coder with custom modules to be upgraded.
----------------
Dominic Ryan
www.iis-aid.com
What is new for our customers / end users?
First of all, I really appreciate the hard work done by the developers of the new Drupal 6! My comment is absolutely not to bash Drupal!
Looking at the changelog the biggest change for the end user is the language system. Another minor thing is improved handling of teasers in posts.
The rest is as far as I can understand rather technical and not directly visible on the outside.
Most clients wont need the multilanguage system (could this not be created as an optional module?), so the only end user improvement is the improved handling of teasers in posts.
Having said that, how can we explain our end users that there is a new version of Drupal coming out that just has improved handling of teasers in posts? Explaining all the great technical improvements to end users is IMHO not possible because they will not understand it or they are just not interested.
Please bring in some more usability improvements like the ones below so we are able to sell the story of this beatifull product to our customers and end users:
Keep up the good work!
-----------------------------------------
CompuBase, websites and webdesign
-----------------------------------------
Joep
CompuBase, Dutch Drupal full service agency
No need to. :-)
There's no need to sell end-users on Drupal 6, or Drupal 5 for that matter. Wait until the modules you use on your sites are upgraded, and (more importantly) take advantage of new features in Drupal 6 like the streamlined theme system, the advanced FormAPI features, the Actions system for simplifying site configuration, and so on.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Firstly, I would also enjoy
Firstly, I would also enjoy having better image handling in the core or in the image module. I mean not just uploading images in galleries as it is right now with the image.module, but also being able to attach a new image in a story (for example) without having to write the html code for it. Upload and attach on the fly. Maybe an integrated WYSIWYG editor with image upload and attach features would be cool. Kind of like the way WordPress is doing it.
Secondly, I am not so excited about the OpenID support in the core. I agree with this post here http://www.neomeme.net/2007/02/28/why-openid-is-going-to-destroy-the-int...
Nevertheless though, it is a nice feature to have available.
[/whining]
Anyways, Drupal is a great CMS and framework, getting better and better with every release. I love it. :)
Thanks to all the devs that have made Drupal what it is today. ^.^
About OpenID criticisms...
The author's argument against OpenID seems to be primarily levelled against the privacy implications of consolidating online activity into single-sign-on services in general. But Drupal already had this feature with the drupal.module. The difference is OpenID is actually secure, and an open standard. :)
There's nothing that bars people from setting up multiple identities for different purposes. There's nothing that bars people from not using OpenID at all. But it's a very nice improvement for those who want it, and for those who were using the drupal.module it's a *much* better option.
end users
The multilanguage stuff is optional, for sure. If you don't turn it on, you will not get disturbed with these features on the interface and in the running code. Anyway, maybe you took a little short time to look at that changelog. Some of the bigger end user changes from the top of my head:
- openid module
- actions module (you should really need to check this out, as well as the whole Drupal 6.x-dev system)
- a much more flexible forum (you can put polls or other type of content into your forum, make them sticky, etc)
There were also already lots of smaller usability improvements, like password strength checking, sticky table headers, email notifications, remembering anonymous posters, HTML correction filter (which is quite important in HTML input), etc.
Also as other people noted, Drupal 6 will shine better with it's APIs allowing even more powerful contributed modules.
Anyway, at the end, noone forces any end user/client to upgrade. I am not entirely sure about the point of your comment. You ask about what *you* can tell your clients, or you ask about what will *we* say to Drupal users? If you think you have nothing to tell to your clients, then frankly, you will not get money for a Drupal 6 upgrade from them. If Drupal 5 fits them well, then good for them!
problem regards hooks and modules
Hi,
for me the more big problem of drupal is how are used hooks and modules load.
Drupal load all the modules enabled in any page. But there are moments where modules not be loaded.
Why the module forum must be loaded when i see a node type that haven't nothing with the module forum.
Xaraya have a better gesture of hooks. The hooks are added directly from the user and not in the system.
Another nice things of xaraya is that any function is splitted inside a page and loaded only when must really loaded.
Modules should be loaded dynamic.
Only the modules that implements some hooks should be loaded ad only when the node type implements some particularity of the module.
If modules become class we should use the autoload function of php5 for loading it dinamically how make other framework (see Prado for example)
Drupal 6 will have a
Drupal 6 will have a mechanism that allows us to partially load modules. We've yet to take advantage of that by splitting modules into multiple files. These qualify as performance improvements so they can still make it into Drupal 6. We could use a help with that, fagati.
Example
Is there an example of module that using this tecnique?
System.module
System.module, for example. It has quite a bit of code that manages just building forms and processing them when people visit the administration section. Those functions are all split out into system_admin.inc now, and are not loaded unless the user is actually using that functionality.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Another (better?) example: update.module
An even better example that takes advantage of the new technique is one of the new (IMHO) killer features that Dries called "98% done" which hasn't quite yet been committed to D6 core: the update.module (which has lived in D5 as a contrib module called update_status). This will automatically check for new updates for your Drupal site, and tell you if new versions are available, and/or if you're missing any security releases. The implementation of this new code is a perfect example of only loading the code that's needed for any given page. See comments #40, #41, and especially #42 in the issue where it's moving into core, and/or the latest patch for details.
Cheers,
-Derek
___________________
3281d Consulting
My idea
split the hooks in other file of module.
For example create in mymodule the files:
my_module_nodeapi_hook.inc
my_module_view_hook.inc
my_module_workflow_hook.inc
my_module_user_hook.inc
ecc....
in this mode the various hooks are loaded only when necessary and the file my_module.module is really thin.
When we have too much modules loaded now drupal is really slow
idealy you would want to
idealy you would want to minimize IO to filesystem because having to perform hundreds of file_exist(..); on every server access will generate hundreds of HDD MISS and that is a bad idea, we are talking about milliseconds delay for every miss which in the end acumulates and there is not much you can do to optimize those. i know D6 integrated the idea of splitting modules into multiple files. but you can further split them by taking code out into your own includes when you know that a particular code would not be accessed regularly.
Sometimes something interesting appears on http://litwol.com
The idea is that the system
The idea is that the system know first what hooks include and after get it directly.
If you see on xaraya the hooks are added manually
please excuse my ignorance
please excuse my ignorance if i'm stating something very known as its very fresh to myself.
to expand on your "system knows first...", if you include some kind of registly that knows which files exist, check against the register (one io) and it will know then which files to include without having to do file_exist(..).
hmm i like the idea :)
Sometimes something interesting appears on http://litwol.com
Done!
Doing this at the hook level may be overkill -- and breaking up everything into individual files would mean shocking overkill for most modules (which might implement dozens of hooks). In Drupal 6, though, every menu callback (like the path for the admin page for a module, etc) can be mapped to a separate file. That tends to be a very clean way to include certain functionality. It lets core modules maintain 'pure API' functions while UI stuff is held in separate includes and only loaded when they're needed. Views module has used this technique to good effect for a while, and it gains much of the performance boost without the hassle of splitting everything up into a million .inc files.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
could you please guide us to
could you please guide us to where examples & documentation can be found of what you are describing?
Sometimes something interesting appears on http://litwol.com
Exactly
When a module is loaded the first time there is a file in the module that say to drupal what hooks are defined.
So when drupal load the node_api hooks load it directly from my_module_nodeapi_hooks.inc instead of my_module.module
For the view module i have see the code of view module.
The modules wizard and ui of the view are only adminstrative but are loaded also if i am in the frontend.
Another example that should become change in the module are the help.
Why put the text of the help in the module file?
Drupal 7.0 - The "let's eat what we cook up" release ;)
Drupal already being the best CMS on the third planet from the sun, please let me make the following suggestion ...
(1) Use www.durpal.org as a showcase community site as well as a showcase of how to do it in Drupal.
(2) Move into core all of the contributed modules that end up being required to make number (1) happen.
(3) In addition to site organization and the look & feel, make across the board performance improvements.
(1) + (2) + (3) = the biggest possible bang for the buck
Otherwise, the whole will never be as good as the sum of all of its pieces.
Take care everybody.
___________________________________
Svi smo mi zarobljenici svojih ličnih iskustva.
We are all prisoners of our own experiences.
Probably not the best bet...
This is probably not a very good idea. Why? The mix of modules used on Drupal.org isn't geared towards general purpose community sites, or any sort of general-purpose application at all. It would clutter up core with hundreds of K of code for managing mailing lists, keeping track of software issue tracking and release management, integrating with CVS version control systems, and so on.
Drupal.org is actually a good example of what can be done using the core system and just one or two very specialized modules to provide a 'customized' solution. It might be worth bundling some of them together as an install profile, and distributing THAT as an 'Open Source Project Management Site in a Box'...
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Adding to Eaton's wisdom
A) Moving all of the project management code into Drupal core would be a disaster for many reasons:
- 1) Most sites don't care about this functionality at all.
- 2) It's a huge amount of very complicated, special-purpose code.
- 3) The development cycle on this critical functionality for drupal.org would slow WAY down. Contrary to popular belief, Drupal core actually moves incredibly slowly. ;) If all of this code was part of core, it'd be *much* harder for me to continue to maintain it, fix problems, add new functionality, and make it useful enough to power our development process (and sites like http://jquery.com/plugins and others).
B) Such an installation profile already exists (sort of). See the Drupal.org testing installation profile. ;)
Anyway, drupal.org definitely "eats its own dogfood" all the time. That doesn't mean every Drupal site on Earth needs to be just like drupal.org.
Cheers,
-Derek
___________________
3281d Consulting
Well Done!
Just want to say well done to all the team involved. It's always nice to see Drupal moving forward even if I am not a Drupal user (yet!).
I just want to say that I really think the project could do with more funding - I have posted previously of how a premium suport site for Drupal where an annual license is purchased could help bring in revenue that could be used to pay professional coders to code the bits that are needed.
Scalability should be of utmost concern - Drupal should not be a resource hog, as otherwise this basically cuts out the people on the street to run large successful sites (they couldn't afford the servers if too much horsepower was needed).
Thanks again to all the team and please consider my idea! I'd be the first to sign-up!
Scalability
Performance and scalability are tricky things -- they're often used interchangeably when they're really not.
1) Performance is how fast a given site runs.
2) Scalability is how easy it is to boost performance by giving the site more resources to work with
2a) Vertical scalability is how much performance boost you get by throwing a bigger server at the problem (more RAM, faster processor, etc)
2b) Horizontal scalability is how much performance boost you get by throwing multiple servers at the problem (more web servers and a load-balancing system, multiple database severs with replication, dedicated memory-caching servers, dedicated file servers for speedier image/css access, etc.)
Drupal is actually very good at 2, 2a, and 2b. We've worked with some shockingly huge high-traffic Drupal installs, and it's possible to build very complex sites that scale very efficiently. #1, though, is traditionally the killer for sites on small shared hosting plans that grow large enough to tax their servers. They don't have the resources to take advantage of scalability, so they have to eke every bit of performance out of the constrained server environment they're running in.
There's a lot of work going into performance optimization that doesn't make it into the Changelog -- they tend to be extremely focused optimizations, like speeding up a specific query or eliminating an unecessary SQL JOIN. In addition, under-the-hood improvements that are not obviously performance related (like recent changes to make the plug-in caching API more flexible) can be USED by developers who are building cache systems that are optimized for low-resource server scenarios, etc.
Aaaanyhow. I don't want to disagree with you at all -- you've correctly identified the tricky 'grey zone' for Drupal right now. Folks with small shared hosting plans, complex dynamic sites, and rapidly growing traffic are in a tricky spot. We're hoping that focused optimizations, as well as additional flexibility to swap in 'shared host-friendly' cache systems and optimizations, will boost performance on those sites will preserving the scalability for large installations.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Hi Eaton - thanks for taking
Hi Eaton - thanks for taking the time to reply.
I think most people who run a successful site wouldn't mind taking on more servers, but only if it is feasible and the site owner doesn't also have to be a business expert to get the revenue to run the set-up. I mean, someone with simple google ads on their site should be able to afford their set-up to run their busy Drupal site. I guess the best comparison is forums - these are high traffic sites that can pretty much run ok on a dedicated server, and the owners can pay for this relatively easy from the revenue they get from google ads.
I must admit that the biggest obstacle for me jumping ship to Drupal is the server issue. My site runs modified vbulletin that gives me a relatively decent CMS, along with blogs and forums. We serve over 2 million pages a month and are managing on a modest dedicated server. I really would love to move to Drupal, but do fear I may be crippled by the server costs.
Of course it will also mean spending time to learn Drupal and how to design for it, but we don't mind putting that time in, we're just worried about the server costs, speed and scalability.
I think it's also a shame because I feel we could be a showcase site for Drupal.
How has Drupal 6 changed in terms of this? How much more effecient is it than Drupal 5?
Good to plan ahead
It's a legitimate issue to consider. Drupal is designed to offer a lot of flexibility, but that comes at a price in terms of server resources sometimes (obviously). Do you know what the ratio is of registered vs. anonymous users on your site? Does your dedicated server have much flexibility in terms of upping the RAM or tweaking various settings? Just the fact that you have a dedicated server (modest though it may be) puts you in a MUCH better position than the average shared hosting subscriber. Why? You can tweak the server's configuration in ways that shared hosting customers can't.
Before making the jump, definitely chat with some of the other folks in Drupal's forums, and perhaps the groups.drupal.org site. There are a number of discussion groups that revolve around those kinds of questions. Looking for some focused answers -- ie, 'how can I optimize my site performance on a dedicated server with X specs, Y hits per day, and Z ratio of logged-in users doing this list of tasks...' will probably help get things rolling. A LOT of performance optimization is site and situation specific rather than general.
That last bit is why so much energy has been put on providing 'plug in points' for Drupal, where different performance optimization strategies can be swapped into place depending on a site's specific needs. While it doesn't instantly solve problems, it means that there are more ways to cool down a specific site's "hot spots" without hacking core.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
It's around 65% guests 35%
It's around 65% guests 35% logged in users. I have complete control over the server, so can buy more ram if needed, tweak settings, use php cache etc etc
I keep saying to myself, it can't be that bad , but then look at some of the posts on the forums and get scared again lol. I guess, at the moment my pages load with between 12 - 25 queries, and I guess vB is known for it's server effeciency.
On top of that, the only Drupal powered site I use is... Drupal - and very often it runs, or at least 'feels' a lot slower than other forums and community sites I use.
In saying that, popsugar - which is Drupal based seems to run pretty fast - I would love to know the specifications of their server set-up, as this would give us a good indication of what to expect. Any chance you could find this out for us?
Thanks again for the reply, everytime I log on to Drupal.org I want to give it a go... I guess I just need that final push!
I have been running phpbb,
I have been running phpbb, vbulletin and Drupal (4.7.x though).
Phpbb is the fastest and it can handles in the order of hundreds of thousands posts. Vbulletin is not as fast. Drupal is the slowest, significantly slower than the other two, unfortunately.
I hope performance is improved in the future versions.
Performance improvements
Remember that we're still accepting patches that improve performance. I'd like to invite you to help test and improve Drupal 6's performance. Give it a try, do some load testing and report back.
What about Oracle support?
Hi,
thanx to all developers, i love drupal and i love you :)
A question: so, D6 will not have embedded Oracle DB support?
thanx again
-vinx
look like someone is working on it...
I saw some CVS comments on D6 schema API about fixes for Oracle... look like someone is working on it. I hoped to see mssql implemented, but the guy who started looks like no more working on it. Maybe related to the very big schema api change after he offered his patches. I haven't had time to take a deep look at the schema api, but all i have seen looks like the right step. I'm not sure if the db abstraction is 100% complete in D6, what will allow to simply place a "database.oracle.inc" in the include folder, set up the connection and that's it. So this may stand in contrib...
Maybe someone else more inside schema api can say more about this great feature?
i am still working about
i am still working about oracle driver for drupal-6.x-dev! BTW face some great problem about CLOB handling, see http://drupal.org/node/147947#comment-270113 for more information.
after reference this with ADOdb LOBs handling, i design to add some helper APIs in order to handle the CLOB problem. i just submit the patch (http://drupal.org/node/147947#comment-271846) and waiting for review. it seems a bit difficult to let it in after code freeze, but i will try my best for it :)
other than CLOB problem (if patch is accepted, lots of handy works can move away), we still left:
----------------------------------------
What do you hope from my personal blog??
Edison Wong
CEO, Co-founder
PantaRei Design Limited
:)
GREAT!!
oracle driver is almost complete
after 2 weeks more development, the driver is now almost complete, and able to function as like as MySQL and PgSQL :)
please check here for more information :)
----------------------------------------
What do you hope from my personal blog??
Edison Wong
CEO, Co-founder
PantaRei Design Limited
Safe mode restriction problems
Dear Drupal developers,
while it is not too late to do something about it, please consider the problems that plague a lot of site admins with safe mode restrictions, which appeared after release of drupal 5.0.
4.7 was working perfectly, and in my personal opinion there was no reason to change the system which is well working (which means that some of us prefer to switch back to what was used in 4.7 in regards to safe mode).
Thank you.
Marius
www.cringel.com
left our jobs and went to Asia
SSL
Probably late to comment on this, but would like to hear your thoughts about it. Back then somewhere around 4.6 a customer needs was to have some critical information encrypted over SSL (address book and payments details for instance). It is/was possible to keep all drupal urls using https but not just some parts. To do that, I modified the core, mainly on the url() and l() functions to support https links and some of the form api to generate posts to https so posted information also goes through SSL.
I thought it was important those days and even now to have this kind of feature along a web framework, to have it in the core so modules that would like to keep sensitive information over SSL have the possibility as well as doing some basics like login and my account settings using it (if it is the user's choice).
I guess it's not actually really important, because it was never considered for 4.7, 5 or even 6?? (not sure here, correct me if I am wrong), but while reading through this post I remembered about this and wanted to mention it. Hope to here some comments from drupal core developers.
Thanks and looking forward for this new release,
a.=
Best place to advocate for this is in the issue queue.
You should search the issue queue for topics related to this (I know there are some already). Find the oldest and/or most appropriate for the changes you have in mind, and "bump" the issue by replying to it. If we need to make changes to the core API to make this easier, I'd certainly support that. However, it's possible D6 already does all you need, so you should check that first. Either way, reply here with a link or an answer.
Thanks,
-Derek
___________________
3281d Consulting
link altering
in drupal6 you can alter all links that go through url so this should be easy. also see http://drupal.org/node/65632
Drupal 6.0 and 7.0 worries
What worries me most with this current coming version 6 release is that you already also announce the plans for version 7, I mean why ? Concentrate on version 5 and 6.
Develop any new major version also with an import feature of previous major release websites, and allow this import feature to support addons for any module maintainer who may wish to also get their content imported to the new environment.
I can understand why so many sticks with version 4.7.x, it's because it would demand a such huge amount of work to move their website to version 5, and version 6 would be even worse, the problems are of course always worst with sites using 3rd party modules and not only the core modules.
Roberth Andersson
Administrator/Developer @ Jump-Gate and Webworqs, Inc
Misunderstandings
A) The only reason there's any talk of 7.x these days is because of the goPHP5 effort and the impending end-of-life of PHP4 support. That's exactly the sort of thing that people want/need a lot of advanced warning about, so we're letting people know as soon as possible that whenver, in the distant future, they want to run Drupal 7.x, they better have found a hosting environment that provides PHP5 support. That's all.
B) Since long before version 4.6.x (the first I have any personal experience with), every version of Drupal has provided a migration path to move all of your content from a previous version into the new version. Drupal does not support backwards compatibility of the code's API, meaning that 4.7.x modules can't run on a 5.x or 6.x core site. However, the Drupal project has always taken data migration incredibly seriously, and probably 1000s of hours of development time have gone into refining that system, and making sure that every new release will allow sites to migrate all of their data. Furthermore, contrib modules can (and do) use the same system. Ever since 4.7.x, it's been called "update.php", so search the docs for that if you want to know more.
Cheers,
-Derek
___________________
3281d Consulting
Tweaks to Blogging Functionality in Drupal 6
I don't know if this is still on the table for the next release, but a thought on Drupal's core blogging functionality.
I've run into this myself and I see it mentioned on the forums from time to time. The core blog module includes a lot of hard-wired stuff that people don't like -- and thus the workaround often suggested is to use story node for blog posts. Then, you need to use views to create your blog page with RSS -- or some other similar solution -- for sites where the blog is not the front page.
OK, this is the approach I've taken. But what if you want to use blog API with, say, Ecto? As far as I can tell, it doesn't work properly without blog module in use. At least, I've been unable to connect with anyone but the first "superadmin" user.
Then, there's the core ping module. I've been unable to get it to work in 5.1. Perhaps there's a blog module dependency. Not sure. I've instead installed a multiping module that is not in the drupal.org repository but seems to work, nontheless.
My point is this. A lot of folks new to Drupal want to have blogging on their sites or simply build a blog using Drupal. It seems to me that the above is a lot of workaround to simply get a blog up and running. I wonder if, perhaps, cleaning up this issue might be the kind of thing that would go a long way toward making Drupal 6 a big step forward in usability.
I'd code it myself if I knew how. So, please accept this feedback as the best contribution I can make to this issue. I hope it is helpful and please take it in the spirit it is intended -- to help Drupal become even better than it is today.
--
Farrell Kramer
farrell kramer communications
Drupal 6 code generation using D4PHP
For the past 2 days I have lost my sleep using from CodeGear(Borland, qadram joint venture) Delphi for PHP.
Since I am a fanatic user of Borland's IDEs' this product seems very familiar to me.
The RAD approach to PHP sounds like a very interesting feature.
The produced code is pretty small and runs quite fast.
Saying that though, since it is based on VCL for PHP GPL framework even for a single button a mere of about 8 inherited classes is in use.
The question is if the core development team of Drupal is thinking to develop-provide a framework that can be used within D4PHP in order to produce modules using Delphi for PHP.
That would greatly enhance the module development.
Just making a question/suggestion here. I don't even know if this is possible.
Any insight on this?
David Oster aka George Pasparakis
P.S. I think VCL for PHP is using version 5 of PHP, does this means that the above needs to be considered for Drupal 7?