As a lowly windows user, patching is usually an immediate turn off to a new module. Compared to other CMSes, Drupal has a much more complicated module install, which is only made more difficult when people have to patch. It causes annoyances for those patching and for command line users sick of trying to teach everyone how to patch. A simple solution would be if all modules that require a patched version of a file include that patched version. This is a simple solution, not a perfect one, but it would save headaches for many.
The only reasonable argument I've heard against this is that it does no good because "What if the version of the file needing to be patched has already been patched, or if the person wants to patch it again." The reality is that someone who has troubling patching a file once, isn't going to have a customized core or module file that they are changing or patching repeatedly.
Drupal usually has 2 (at max. 3) versions that users active on drupal.org are using at once. Module developers will already have a patched version for CVS and the latest release, so it shouldn't be to difficult to post those with the tarball...and many windows users will be forever grateful.
By jasonwhat on
Comments
I do agree with this request
Hopefully not all drupal users use Linux/Unix. I am also trying to add the patches in the windows environment but in vain. I too request the module developers to release the modules without separate patch files.
Thanks & regards,
Amar
Patches are independant of each other
I feel your pain, but the thing about patches is that different modules may requre different patches to 'core' files.
Module A may insert 3 lines at line 300.
Module B may modify a conditional statement at line 999.
Core file + A + B gives you what you want to run, but your requested Module A core replacement and Module B core replacement are incompatable.
The patch function handles all of this for you, that's what it's for.
My example may not sound too common, but it's what happens in distributed development environments.
There are enough windows implimentations of patch out there, cygwin if you don't mind the command line. I find the winCVS gui very messy, but subversion will do it OK. Both of these guis look very heavy-weight for this simple task, I agree.
It's NOT too hard to just look at a patch file, and see what changes it describes - they include a few lines of 'above and below' code to help you place the change, by hand, right where it should go. This is the best solution in the short-term.
.dan.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
If you are using patched
If you are using patched core modules, then you need to take the time to learn the basics of diff, patch and cvs (not Drupal questions) and be responsible for venturing off the Drupal Core codebase. There are generally reasons for why those modifications are not in Drupal core modules so if you are going to use them, you really need to understand them.
Patch and Diff'ing are not really all that hard. I went and found a tool that works just like the *nix examples.
I found these tools: http://drupal.org/node/32635 and was able to test the search patch following these instructions
http://drupal.org/node/22293
http://drupal.org/node/28245
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
This kind of thinking is the problem
This is why mambo, or even typo3, which is overall a much more complex CMS have so many users and are known as the "easy to use versions." In typo you go to your admin interface, find a module and click "install." Done. Here we can't even get developers to agree to include a patched file. Even if you disagree and think everyone should learn more patching, php, etc, just include it in your bundle-it's not like an extra task is being added, you already have a patched version of the file.
Of course patching is ideal, but it is not the reality. I see too much on Drupal of developers lecturing people to become more like them. There is a serious gap between the mass user community and module developers that slows Drupal down overall.
As for the multi-patching argument, I addressed that above and still doubt that someone who doesn't know enough to apply a patch will be patching a core file multiple times. Many people wanted to use taxonomy access and just needed a patched version of taxonomy included. They weren't going to touch taxonomy again after that. I do see developers points about the imperfection of this solution, but I'm going for simplicity here.
Note, I am not a developer.
Note, I am not a developer. I am not lecturing. I am providing information of the importance of this for other readers. I do not know how to code php. I spent a few hours reading and googling to learn how to patch the file on a Windows system to test the important search patch. I will probably test more patches now that I know how.
The reason you need to know and understand this stuff is that if you don't understand what you are doing when you purposely change a core file with a patch to gain a feature, then you may not be able to upgrade your base Drupal install when a new Drupal core version comes out. Whether it is a point release or new version.
If people touch a file once, then they will in fact have to touch it again if they need to upgrade (security release is a reason to upgrade). So there is no 'touch a file once' as an argument.
If a security release comes out and the author of the contributed module doesn't update his file for you, then you have a serious problem. If you have taken the time to learn how to do this, then you are better able to deal with this without relying on someone else and their time frame constraints.
There is an effort to automate installation and such but I doubt that even when this automation happens, that it will support patching core modules (just speculation but it's not my effort so I don't know). I lot of work has to be done before such a point and click update process could occur. Drupal architecturally needs hooks, api's and a wider range of considerations in developing this. A security model for trusted downloads and sites. Bandwidth (until recently this potentially could have been an issue, the move to OSL should have eliminated this as a concern). Volunteers (people) and resources(servers) to maintain and administer the overall system.
In Drupal, you are right next to the engine of your site. You don't have the pretty wrappers and clicky buttons that hide you from the gears. While you don't have to touch the engine to have a nice site, if you want to customize your engine, you need to get the wrench out and work.
All that said, if a volunteer module contributer chooses to spend more time and voluntarily make a file available, that is up to them.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
still confused
I understand all your points. I do doubt that they happen often though. In my example with taxonomy access, the Drupal security changes effected some core files, but not taxonomy. I just don't understand why there would be any opposition to this. A module contributor already has a patched version of the file, why would they refuse to upload it? Spite?
What is this desire to
What is this desire to attribute malice to people you don't know who have provided hundreds and thousands of hours to provide you and others a free product and the instructions to do what you will with it?
I explained my piece. Others may answer differently, but it sure isn't malice or spite. Reread what I already posted.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
I didn't assign malice or spite
I simply raised a question. I can't for the life of me understand the reservations anyone would have about uploading a patched version. I read and responded to your post and will for the third time state that the point is moot, because people that don't know how to patch aren't likely to be patching a file multiple times, if they are, then they need to learn to patch, but this is not something that happens often.
Why the aversion to better organizing Drupal and making it easier to use? While "spite" may not be the right word, I do often detect an annoyance from developers that people don't know what they know, ask questions that have been asked elsewhere (like how to patch), and more. I believe simply including patches will erase one of these issues and make it easier for newbies.
If Drupal is to keep growing, we need newbies, and we need to recongnize that things they don't understand and other usability issues they face are important to address.