By dries on
In preparation of the Drupal 4.6.0 release, development of Drupal core will be frozen on February 1th. During the initial stage of the code freeze, documentation updates, usability improvements and performance improvements will be accepted. New functionality, on the other hand, will not be accepted unless deemed important. Thus, as of February 1th, 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.
It will take several weeks before Drupal 4.6.0 can be released, however, one or more release candidates will be made available during the code freeze.
Comments
What are the new features of 4.6.0?
Are we going to see flexinode as part of the core? :) I think this was called 'Content Construction Kit' at some point:
http://jonbob.drupaldevs.org/
Not in 4.6.0
This is a possiblity down the road but not for 4.6.0.
Check out the listed
Check out the listed objectives for the dev conference.
http://drupal.org/node/16188
At a guess probably for 4.7. Just a guess.
-sp
---------
Test site...always start with a test site.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
There are a number of
There are a number of patches I still would like to get into cvs before the 1st. I will be available on Sunday and Monday to discuss how we should proceed.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.5 does not work with PHP 5.
--
Drupal services
My Drupal services
drupal 4.6
Congratulations to all developers for working on 4.6. Drupal is great and I wish I had time to contribute more. I included this news on my site, here.
Will you provide an upgrade script for updating 4.5.2 installations? Where can I see a list of new features in 4.6? Will it be compatible with PHP5 and MySQL 4.1?
--
NSK, Admin of Drupal-based site http://www.wikinerds.org
Upgrading
It would be very uncharacteristic for an upgrade script to not be provided. Take a look at the 4.5.0 release announcement to see what it was like going from 4.4 to 4.5:
http://drupal.org/drupal-4.5.0
I did it on few sites and it went smoothly. I expect the same for 4.5 to 4.6!
And great work, everyone! I love Drupal!
And I can not stress enough
And I can not stress enough the value of a test site BEFORE you do so. A test site will help you test your backup and restore process as well. It will allow you to work out anything you forgot (custom themes/modules) and help forgo the panic when something doesn't go right (incompatable module).
If all goes well, then great, if not, well you have this nice tested backup/restore process you used to build your test site with your live data right? :)
-sp
---------
Test site...always start with a test site.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I second this!
I have to second this. ALWAYS use a test site.
Make a copy of your database, and the old public_html (or www) on another machine, and then upgrade that copy, and see if there are any problems before attempting to do so to the production copy.
If you find problems, then fix them first AND report them to Drupal.org so they get fixed in future releases.
With Drupal it is very easy to copy/clone a site to another. All you need is to backup the public_html (or www or whatever) directory and change the conf.php file (or create new ones with the new subdomain/domain), which you load into a new database, and you will be up in no time at all.
--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba
Test Site
I have a linux box here I use for testing all of my changes before I go live on the public site. It works out very nicely.
--
Mike Cohen, http://www.mcdevzone.com/
Thank you for considering.
I’m probably going to take a rock in the head for this, because you guys are concentrating on higher level problems and tasks and some of you might feel this is low level or inappropriate request at this moment.
But actually I think this request is going to be even more critical in the very near future -- pending a major upgrade than it is at this moment. As there will probably be several module incompatibilities and lots of module patches.
There was discussion last month about creating a patch.module for the non-programmers, us “other” people that don’t have shell access and work at the CP level.
All I ask is that you please consider the situation some of us are going to be in very near future, as well as the burden the Forum and maintainers are going to see for patch help.
Ok that’s it, I’ll go back to cave now.
Thank you for considering.
Patches
What would this module do? Patches are for developers, not for end-users. If a module requires changes, then they should be submitted to CVS so everyone can download them.
In any case, patching a Drupal site through the Drupal site is a lot tricker than it sounds due to filesystem permissions.
--
If you have a problem, please search before posting a question.
please advise
Hi Steven,
While reading and trying to understand how to install "patches" I read this statement frmo you somewhere else too. I'm very new here and sometimes I don't us the right phrases. But you say the patches are for developers. Yet, I've had to do a couple of them.
The frist time I was actually told by the maintainer, that the problem I was having was fixed in the "patch" go get it. Last night I did a patch for Articles that fixed another problem I was seeing. And there are still two "patches" for Articles and one of them is reallly gving me a problem -- I don't understand a bit of shorthand the programmer used.
So far, I haven't been doing any patches unless I'm having a problem. Then if so, I go to the download area and see if there is a patch for this problem. I compare the date the program was released to the date of the patch, if the patch is newer -- then the I have been assuming I need to get the patch into the program somewhow. And sometimes this is not easy doing this, being a non-programmer.
Back to your statement, is this something I shouldn't be doing?
But if it is, please consider the "patch.module" it would really help -- especially not having Shell. If we can't do it through the system, is there any other way I can do this - not having shell?
Best regards and please advise
Patch locally
Patching has nothing to do with Drupal: it is a generic mechanism. You can apply patches to files locally, and upload them to your site. There are ports of GNU patch for various OSes (including Windows). And there is a lot information about patching in the handbook under the contributor's guide.
If a contributed module requires a patch, then that is the module author's choice. But it is not something which is encouraged.
--
If you have a problem, please search before posting a question.
now, I think I get it
There is Drupal wiht all its features, "as it comes packaged and supported by team Drupal" for lack of a better phrase.
and then there is all the other stuff that other people have made that you can add-on to the base Drupal. Team Drupal, doesn't support these 3rd party modules, nor does it reject these other 3rd party modules. Team Drupal has actaully gone as far as to allow these 3rd programs to be posted here and supported through Drupals froum by its members at large.
Hence, I would never need a patch for Drupal. Team Drupal takes care of that stuff and will release a update ... if and when such is required.
Thanks, I think I got it now. and I don't think I'll be seeing a patch.module anytime soon. :) I also understand now why some posted questions are so hard to get answered. Its not Team Drupals responibily. Its the maintaniers or members at large. This clears up a lot of confusion I had. Thanks
But you have helped me understand where to go to ask for a backup.module now - Cron type with a cache flush :-))
Thanks Steven
Take it or leave it
I think I understand why you're annoyed, jwells: you don't like the reality here, which is that most of the time, 'Team Drupal' makes zero effort to support any 3rd-party components. Well, I hate to tell you buddy, but 'Team Drupal' is pretty busy making 1st-party stuff, i.e. Drupal itself + core modules and themes. They're flat out doing the critical stuff, and they don't have time to support anything additional.
And by the way, they don't get paid, so they all have real jobs (and real lives!) on top of their Drupal work. And speaking of pay, what are you paying for Drupal? Nothing. You're not paying for support, so any support that you get, you should consider a bonus. This is a community effort. If you want a patch module and a backup module, then what are you waiting for? Get coding!
Very sorry if I misinterpreted your post, and you weren't actually attacking 'Team Drupal'. But that's how I read it.
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
My open apology for anyone else that interrpeted my post that wa
Wow Jeremy, you completely misunderstood my reply, I sincerely hope no one else did. Communication can be challenging between people that have never meant. My reply back to Steven was not one of judgment, sarcasm or even annoyance. I was basically typing back to him, what I interrupted he was saying as a means of clarification. Giving him the opportunity to correct me, if I misunderstood him. I’ve found saying something back to someone – helps clear any grey area very quickly.
Not only am I new here, I’m new to the open source world and it never even occurred to me that there would be different teams with different tasks. It makes sense now. But I was noticing that module support was handled a bit differently than Drupal support and I couldn’t figure why. That was until Steven took a moment to explain it to me. I think the thing that confused me from the beginning was that the modules were being supported through the use of the same tools /media as the Drupal base. I also never really considered the “maintainers” to sort of be like 3rd party, because you can actually download the programs here … but that too makes sense now. As for being annoyed, naw it’s more like normal frustration, of someone learning something he has never done before, not even knowing the right questions to ask and being in a different pond than I am use to.
My open apology for anyone else that read my post with that interruption.
And as for, not liking the reality here; heck Jeremy, I don’t think I like reality anywhere. But I have no gripes with the Forum, most people here are very nice and most helpful.
Oops
Very sorry that I misinterpreted your post - although I'm glad to know that I was wrong! I'm relieved that what I took to be sarcasm, was actually genuine 'enlightenment' on your part. Perhaps I'm too often sarcastic myself, which is why I sometimes expect the same of others... ;)
Jeremy Epstein - GreenAsh
lol ..... "enlightement"?
lol ..... "enlightement"? Well I do have a flashlight, but its solor powered and only wants to work when the sun is out ;-)
Has it ever been considered opening up something seperate in the Forum, for just the modules. It must be a bit frustrating for Team Drupal to browse through all the module postings, just to find Drupal stuff.
"Team Drupal"
(I have to admit I interpreted your post in a sarcastic tone first too)
The simple answer is that there really is no single "Team Drupal". Almost every one who works on the core has also made a contributed module, which they maintain. Sometimes a module is coded only to fit a particular need, and it will be of lesser quality than another module. However, in most cases it is still useful to contribute such modules, as they might be of use to others. Some modules get orphaned, some get picked up again.
If you really want a particular module that requires a patch, then by all means get GNU Patch and try to patch it, as that will probably be the only way to do it now. However, we do our best to make sure everything is possible with Drupal core without patching. This sometimes means that it takes a while for a particular module to become "patchless" (e.g. changes to 4.6 to allow for i18n.module amongst others), but usually the delay is because a clean solution is harder to do than a quick and dirty one.
About answering questions: you should also keep in mind that we are volunteers. If we spent all our time answering questions, there would be no time left to do any developing.
--
If you have a problem, please search before posting a question.
patch module would be great
I have been unable to find a patch app that runs properly on my Windows notebook where I do most of my work. All the ones I tried would report errors when patching files...
The patching issue keeps many users (at least me) from being able to try some modules like the i18n for internationalization (I travel a lot and do most of my work on my notebook and when I'm on stable ground have little time for coding/testing).
------
Con paciencia y calma,
sube un burro a una palma
Not trivial
Just a prediction, but you probably won't see this module any time soon.
Patching is not always easy. The patch file gives a line number and a couple of lines of code for context, then begins to identify lines to delete and lines to insert. Given two identical or very similar files, it works, most of the time and a third, patched, file is created.
If the two files vary in any significant way, the patch won't work. Many of the patches that are floating around here wouldn't work in this type of environment because Drupal code is in constant flux.
When patch fails, human eyes need to compare the two files and do the pattern recognition that we are so good at - better than the patch program. Do you really expect Drupal users who can't install patch programs on Windows machines to be able to compare subtly different versions of essential code and make the right decisions? This is the first reason writing a module like this is not trivial.
The second reason is that you are expecting to use Drupal to operate on its own source code. Lets say you want the i18n patch. That patches *core files* - files that you need just to log on or look at your front page. No sane developer would automate this on a production system. A sane developer would always test the patched files on an offline version and, only after sweating a lot and praying vigorously, send the files to the production system. You're asking for a production system that could potentially destroy itself by patching its own functionality away. How do you recover from that?
Tip: if you want to patch files and haven't been able to yet, get Eclipse (www.eclipse.org). It does patch just fine and you don't need to learn how to install/use Cygwin, which is the other option.
It's not just the "Core Drupal Team" that is cold to a patch module idea, it is probably just about everybody who has ever done much patching/deploying/maintaining of Drupal sites.
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
Thanks Robert, for the info
Thanks Robert, for the info on Eclipse, downloading as I type (87.5mb). Also it seems I have a lot to learn about open source code and its enviroment. Just the structure alone is something. And its funny, I don't think I was ever intimated by a download page before tonight.
No cygwin needed
There is a native Win32 port of patch and diff floating around (google for 'GNU Win32 tools' or something). I use it to patch, and it works fine (as long as you pay attention to Unix vs DOS line endings).
--
If you have a problem, please search before posting a question.
New Features for 4.6.0
I'm curious about the new features if any. Does the "battle plan" indicate it fairly accurately? Is there a list somewhere?
Rick Cogley :: rick.cogley@esolia.co.jp
Tokyo, Japan
Check the CHANGELOG
The changelog file in CVS lists the major changes.
--
If you have a problem, please search before posting a question.
Do you mean these?
- search:
* added UTF-8 support to make it work with all languages.
* improved search indexing.
* improved search output.
- syndication:
* made the ping module ping pingomatic.com which, in turn, will ping all the major ping services.
- flood control mechanism:
* added a mechanism to throttle certain operations.
- usability:
* refactored the block configuration pages.
* refactored the statistics pages.
* refactored the watchdog pages.
* refactored the throttle module configuration.
* refactored the access rules page.
* introduced forum configuration pages.
* added a 'add child page' link to book pages.
- contact module:
* added a simple contact module that allows users to contact each other using e-mail.
- multi-site configuration:
* made it possible to run multiple sites from a single code base.
- theme system:
* added new theme functions.
- database backend:
* the PEAR database backend is no longer supported.
- performance:
* improved performance of the forum topics block.
* improved performance of the tracker module.
* improved performance of the node pages.
- documentation:
* improved and extended PHPDoc/Doxygen comments.
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
Yes, that's it
Thanks! I'll remember that CVS changelog. Must be the o-sake!
Rick Cogley :: rick.cogley@esolia.co.jp
Tokyo, Japan
I thought the image.module
I thought the image.module is being reworked too. Is it not?
---
http://creativebits.org
Contributed module, not covered in a Drupal release
That being said, there is a chance that an image API will hit core soon. This is different than a module - it is just a bunch of helper methods for programmers but doesn't do anything on its own. It will, however, slowly mark the end of Drupal's weakness in image handling.
- Robert Douglass
-----
www.robshouse.net
www.webs4.com
I think to remove the
I think to remove the database abstaction layer (like PEAR) is not a good idea.
What's if oracle became open source or max.db would be the best choise?
Then you will have to write a new database.xxx.inc ...
AAM: Building the Bridge to Real Content
Already the case
This was already the case, we only used PEAR to support PGSQL. Anything other than that was not supported.
In any case, it is not that much work to update the old one, or write a new PEAR interface. The problem is keeping everything up-to-date on every database type.
--
If you have a problem, please search before posting a question.
Only used for postgres port.
And we weren't using anywhere near the full feature set of it, and it was an extra requirement that needed to be installed to get drupal working.
We try to avoid those where possible.
In any way, all of the thousands and thousands of lines of pear that get loaded just for peardb are now not needed, it was replaced by a .pgsql.inc of maybe 150 odd lines (with comments).
--
The future is so Bryght, I have to wear shades.
Donations
Related to a previous thread: (Drupal 4.6 battle plans) http://drupal.org/node/11512, a fully featured donations module is now available and on top of that a completely new donation service based on Drupal.
About the module: http://donorge.org/d_content/integration
About free software: http://donorge.org/d_content/info_os
Also, with the donations module all projects on for example the Drupal site can have their donation history etc. visible on the one Drupal site, all without any maintenance via one donation module file and no extra tables.
--
http://donorge.org
Revision Patch
Apologies in advance if this isn't the appropriate place to comment. But I noticed that the revision patch mentioned in This Thread hadn't yet made it to core release as of 4.5.2. I only know because I searched around for it for a while before I found it. The patch allows for the default workflow of create new revision to actually work. Would be nice to see it incorporated into the next release and not forgotten.
The patch is definitely not
The patch is definitely not forgotten. I for one am very well aware of it.
Look here:
http://drupal.org/node/7582
BTW: It would be helpfull if people would test this patch in particular.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.5 does not work with PHP 5.
--
Drupal services
My Drupal services
It works well for me ...
This patch allowed me to set up a wiki-like module (just permissions) that allow anyone to edit another's post.
It now keeps a nice log of revisions too!
Getting the latest CVS version
Is there an easy way to get the latest version out of CVS without having to download it file by file?
Look around please
Click "downloads" at the top. Click "cvs". Tadaaa.
--
If you have a problem, please search before posting a question.
From the releases page click
From the releases page click the cvs tab.
http://drupal.org/project/releases/cvs
-sp
---------
Test site...always start with a test site.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide