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 wellsy on
There is always heaps of questions, discussion, argument etc regarding this subject.
There is a fairly lengthy and heated discussion going here http://drupal.org/node/53388
First, why is this type of disclaimer not in the handbook, or is it? http://drupal.org/node/53388#comment-100888
Most of the genuine threads I have read are long and obviously take a lot of input from all concerned.
I for the life of me cannot see why the first (properly qualified?) person who patches a module and decides that it is working and worthwhile to be made public doesn't just do that. So what if someone comes along later and has another patched module, it may have different functionality and may very well be just as useful.
Simply make some notations on the head of these files and sign and date them and make them available as a download and thats that.
Or is there some other reason this is not a way forward?
Please remember....this is a discussion forum.
Comments
You want the real answer?
The real answer is that nothing is free. The developers work here and they want you to contribute to Drupal, not just take their work but they don't ask you to pay money. How you say? How am I supposed to contribute? I don't know PHP! thats right, here is the manual and some pointers, get started reading so that you can learn how to contrubute to the project.
---------------
"You can always find the storm by listening for the Thunder."
so it's simply a money thing?
well if that is it why has this not simply been stated prior to this?
The disclaimer by Steven should definitely be added to the handbook by the way. It is not clear from what I have read that this area is not for the faint hearted or low level user.
Oh by the way, the tone of your answer is getting pretty close to what I almost always expect here.
If the broadband connection I'm on could transmit thunder...I bet I would be toast now.
Lighten up!
wellsy
orchidsonline.com.au
Nail and Hammer
Somehow the issue of money always comes up in someones post when you challenge a certain longstanding drupal ideaology.
Wellsy you better tread softly. :)
It is almost like it is being said - You cannot complain about being a low level user because there is no money involved.
This is a loaded gun just waiting to backfire.
-------------
I am in no way siding with you at present reep
I have only been following the last thread you were in is all
I'll make my own complaints/ opinions known when and if I choose
these people here know that I believe
wellsy
orchidsonline.com.au
This does not compute.
You started this thread not me.
I have braodband but lets just say Thunder(yours or anyone elses for that matter) doesn't scare me.
I don't know if you noticed this - But when it comes to issues - I don't really need anyone to side with me per se . IF people agree with what I say it is just because I approach things from a pragmatist's standpoint and it just makes common sense to them too.
Whether they or you like they way it is said or who is saying it for that matter doesn't change the fact of the matter of what is being said.
I am not campaigning for drupal presidency - nor am I looking for votes of confidence.
I was simply making an observation because the overall cause/problem is the same.
While a team may have offense and defense and each may have their own ideas of how the other should have played those last set of downs but at the end of the day I believe everyone in here is on the same side -
Else they would be using Mambo.
-------------
RE:
RE:
This is a great example of how to ensure that good ideas get obscured behind unnecessary bluster.
Cheers,
Bill
-------
http://www.funnymonkey.com
Tools for Teachers
-------
http://www.funnymonkey.com
Patches work well
We depend on patches because it is a standard technology that is well understood among a wide base of developers. They are also supported by an enormous range of coding tools, including all major version control systems like CVS and SVN. Patch is the best tool we have, in terms of dependability, accessibility and wide base of support, to track changed in code.
Your suggestion that we simply add notes to the head of our files and post them here with a date would fail to preserve the history of change. The use of patch is very good for tracking the history of change in code since each patch shows only the lines of code that are affected, both before and after the change. This is very important because developers are mortal humans and make mistakes. These mistakes aren't always recognized at first, and when they're recognized later, it is important to be able to look back at a history of changes and analyze the best way to resolve the new problem. With patch and code versioning you can revert to earlier states, or merge 2-3 slightly different versions of the same document.
The final point about patches is developer convenience. With just a little practice, one becomes very adept at being able to read them and understand what is being changed, and how. This facilitates the understanding and debate between developers when competing possible solutions are being discussed. If each developer posted an entire copy of a 2,000 line file, just because s/he changed 3 characters, the other developers would never look at it. Patch solves this because it shows just what has been changed, making it very easy for someone looking at the patch to grok the issue at hand.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
PS ... host your own patched copies
It is perfectly fair game for people to make patched copies of modules or files and host them on their own sites for others to download. You could make a page on your site that describes the problem that you needed to solve and why the version you have solves it, as well as any other considerations (what version of Drupal, etc). Then post a thread here, mindful of making the keywords in the thread title match what people interested in your files will be searching for, and link to your site. This is a useful service to other Drupallers and is to be encouraged. There just isn't a place for files like this on Drupal.org because it isn't part of how Drupal is developed.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
If I could patch files I would
I am certain that if this practice was officially santioned - encouraged - or even organised somehow? That there would be more people do that.
Could a provision be made like this on osCommerce support site?
http://www.oscommerce.com/community/contributions,2226
see how the past history and versions are still available.
wellsy
orchidsonline.com.au
yes and no
the good thing about patches is that even if the module changes, the patch still might apply and if not, it's very easy to adopt. It happened in the past that people hosted modules, the contrib cvs contains patched modules by the dozen and we have not released weredruplicons on them.
--
My developer blog. | The news is Now Public | Ask not what Drupal can do for you -- ask what you can do for Drupal.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Different things
What I'm seeing at the os commerce link you posted is a change log, similar to what you see here: http://www.drupal.org/cvs
I don't know how os commerce does it, but it is probaby similar to what we do. They probably read the messages that developers write when they make commits to CVS (the code versioning system we use). Patches occupy a different place in the cycle. Let's say that developer A finds a bug in a module that developer B maintains. Developer A isn't allowed (by Drupal.org protocol) to simply change the code in CVS because it is developer B's module. So instead, to communicate the changes in a way that B can understand and use, A makes a patch. The patch simultaneously communicates the changes in a readable form (so that B can just open it up in the web browser and see what is happening), and gives B a way to *apply* the changes, exactly, to the code. Without the patch, B would have to either type the changes in (error-prone) or receive a copy of the entire module from A. Patch is clearly an excellent tool for this transaction.
Now for a minor (and true to real-life) variant. A finds the bug, but isn't sure how to solve it. A makes a patch that approaches the problem with a possible solution and posts it here. B reads it and thinks that it should be solved otherwise, but isn't 100% sure. B makes a patch and posts it as well. Now developer C comes, reads both patches (very easy since it is a small record of just the code changes), and decides that elements of both are correct, and "re-rolls" the patches into a new one. A, B and C all agree that the third patch is the best and B commits it. This happens all the time and wouldn't be possible without patch.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
just so I know Robert
where is the link to http://drupal.org/cvs
on drupal.org?
I have looked and I cannot find it?
wellsy
orchidsonline.com.au
on the download page
'View CVS message' on the download page - http://drupal.org/project/drupal. the url is different and better since it omits non core modules.
Good Answer
and I am not being sarcastic
It sounds good.
Patch may be well known among developers but where does this leave the non-developer.
You have this great software (somewhat under documented) called drupal.
But you have to use another under documented software like UnxUtls to get the drupal to do what you need it to do.
It doesn't seem like there is a big push to meet in the middle of the road.
-------------
Theoretically, non-developers shouldn't need it
Ideally, the modules available wouldn't need patches to work. Most of them don't. So from an end-user's point of view, patch isn't necessary. Now, there are a couple modules, like i18n, that require patching. This is because there is ongoing debate about how Drupal should handle internationalization. I think that José makes the patched files available, so patching becomes a moot point. If you're using other modules that require patches to Drupal core, and you don't have the skills to use patch, you should really question whether you should be using those modules (or you should find help from someone who understands what is happening). Seriously... if you have the skills to understand the issues at hand at the PHP code level, patch will not be hard for you to use. If you don't understand the issues a the PHP code level, patching Drupal to use 3rd party modules might work fine, but you're on thin ice and have no recourse if it all goes wrong.
From a development point of view, patches are for bug fixing and the development process. The end user who can't patch isn't likely going to be submitting bug fixes anyway. True, lots of good developers come to Drupal who have never patched before (I never had), and have to learn it in order to participate in the development process, but this is an acceptable price of entry, especially since it's a skill that can be re-used. In fact, I've started using patches for all sorts of other tasks.
So whenever someone needs to use patch who really doesn't have the skills to do so, and can't easily acquire the skills because other basic skills are missing, then there is some kind of failure at work. Either they are using software (a specific module, for example) that is of questionable quality (ie. the author doesn't care enough about its usability to provide patched copies of the affected files), or they are trying to do something that they probably shouldn't be doing.
I'm curious, wellsy, what is the background of this thread? What did you run into that prompted the post?
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
been following the thread
here http://drupal.org/node/53388
and been vaguely watching other threads where patching is a desired outcome. It seems there is no other answer than to complain for most users here.
Honestly, something better should be possible, rather than this constant begging for information and then the all too common OGRES V's TROLLS scenario I am seeing
What about saying this in the handbook http://drupal.org/node/22568#comment-101322
wellsy
orchidsonline.com.au
It looks like the handbook is being updated.
Hopefully that will clear up some of the problems that people have had.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
Theoretically is right.
I turned the book.module on - created a book but the main menu only shows the arrow indicating that there are child pages but when you click on the link it goes to the first page in the book but does not show/expand the child pages in the main menu-
Like the other top level links that have child pages do.
Although they may not be book links.
From what I read this is something addressed with the patches to the book module.
or am I missing something?
Please advise.
-------------
It will be
It will be, see http://drupal.org/node/53388#comment-101005 .
Patching solves a scaling problem (though not completely).
Suppose we have patch1, patch2, patch3 and patch 4, all independent for 1 module.
This results in modules with
(Patches may affect multiple files, making matters even worse)
The more patches, the worse it gets. Then the easiest to get, say the functionality of 9, is to apply patch 2 and 4.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
This is a very good point, one that I didn't mention
I'll restate the problem:
File 1 has two bugs, but they are unrelated. Developer A finds the first bug and developer B finds the second bug. If each developer simply wrote a note "fixed bug foo", or "fixed bug bar", you wouldn't have a working copy of File 1. You'd have two copies, each with one unsolved bug. Patches come to the rescue because you can usually apply several patches to the same file. So if A and B both submit patches, it is easy to get one working copy of File 1 that has no bugs in it.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
understood
so I still fail to see why a repository where a downloadable history of patched files residing is a bad idea?
EDIT: I must need glasses eh (fail to see? lol)
wellsy
orchidsonline.com.au
Forked versions
Heine's scalability problem arises. Let's say I want to make that repository with patched files and I've got three files and 3 patches. I'd end up having to create, describe and maintain 9 downloads to handle all the variations. There is no capacity for making a system like this. The people who are working on Drupal.org and the way it works have other, much more acute problems to solve. If you can find more developers who are able to work on Drupal.org infrastructure who are interested in adding this feature, go for it. In my opinion, though, it would be a hard thing to maintain. You're better of paying someone $10 to patch the files you need if you can't manage it yourself.
Yes, I think $10 is a reasonable price to patch files =)
No, I'm not available to do this ;-)
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
So let me get this straight.
Man this just keeps getting better.
Some of these modules have several patches.
I read someone’s suggestion to always use the latest patch.
But if I read this correctly you need ALL of the patches?
Is there not a way to get ALL necessary patches in one final approved patch or is this another project low on the totem pole?
Or am I missing something?
Please advise
-------------
I'll answer the last first
Yes. I suggest you read this explanation carefully a couple of times and let it all sink in before trying to argue about it.
You seem to be confusing 'patches' with 'versions'. A version is the state of something at a point in time. A 'patch' is a description of a set of changes in something.
You want generally will want the latest released 'version' of something. A new version is what happens when a bunch of 'patches' have been tossed about between developers and been tweaked, polished etc until they decide that set of changes is good enough to be released to the general user community.
Generally there are no official patches - an exception would be the security fixes published when a new Drupal point release is released*. There is no linear sequence of patches - no concept of any patches being the 'latest'. And you most definiately do not need ALL the patches that can be applied to something - most will be buggy or unfinished, or add things you don't need/want.
Patches are just what developers pass around to each other to discuss, test, fix and polish proposed changes to the code base. They aren't intended for general Drupal users (even if some people might publish them that way) - they are a powerful part of the development workflow. What is intended for general use by Drupal users are new 'versions'.
A patch is just a way of detailing the differences between two sets of files. Nothing more, nothing less. It is a way for a developer to express changes to code eg a bug fix, a feature enhancement or anything else to other developers in a way that is least likely to overwrite the changes that other developer has been making to their own code. This is how groups of distributed developers cooperate to write code without stepping on each other toes.
While the concept of a patch and the process of applying a patch is relatively simple, the potential consequences aren't. If you don't understand what is actually in the patch, you shouldn't be applying them. You are forking your own version of the code at that point, and are no longer using the same supported code base that everyone trying to help you will be using. You could have opened yourself up to massive security holes or code that accidentally threatens your data. You are now solely responsible for maintaining that changed bit of code to make sure future changes to the officially released code don't clash with your own changes.
By using unoffical patched code and maintaining your own fork, you have effectively become a defacto developer without the skills to actually operate as one.
There are good reasons why all these experienced developers are trying to steer you away from applying patches. Because the mechanics of patching is much much simpler than understanding the consequences, they really do have your best interests at heart when you hear the often repeated line "if you don't know how to apply a patch, you shouldn't be doing so". They aren't trying to suppress you.
For someone who isn't a software developer this all seems very chaotic and dangerous. But because Drupal is open source you are being exposed to the potentially messy internals of software development. With closed source software this is all hidden from public view, and you just get the overall results released every couple of years. Because Drupal is open source you can be tempted with prerelease functionality or other developers ideas long before they are deemed ready for general comsumption.
* RE: the only official patches: when Drupal x.y.(z+1) is released usually for security fixes, there will be a set of patches for the difference between x.y.z and the new x.y.(z+1). For users that haven't changed any source code, the best bet is to just download the latest set of files and just replace the current ones. The patches are only intended for advanced users that have customised their source code and just need the changes rather than the whole new files.
--
Anton
New to Drupal? Please read this
Also: Forum posting tips
Thanks!
Anton, thanks for that awesome explanation. I realized after reading a bit more of the thread that there was confusion about the differences between 'versions' and 'patches.'
That's a great post!
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Thanks - I think
Thx for the explanation.
Boy you just can't win for losing in here.
What makes you think I did not already read it several times.
F.Y.I.
Not understanding it != not reading it.
Now in another thread (i don't remember where) - the suggestion was made if someone answers your question but you still don't quite understand nothing is stopping you from continuing to ask questions.
But now that is being labeled arguing. (shaking my head)
N.E. Way There is another thread that talks about applying more than one patch to the same module and it seems to lead you to believe you need more than one patch to accomplish certain things.
Since you obviously did not understand what I was talking about when I was talking about suppression I will not deal with that little comment.
Thanks again for the DETAILED explanation.
-------------
Using the book.module as an example.
Again- Using the book.moduleas an example
From what I have read the current version of the book.module that comes with the current stable version of drupal only allows for the expanded menu to show up on pages labled as a book.
If you want them to show up on all pages - book or not -
you need to apply a patch.
Am I correct.
Or is there a newer version of the book.module other than the one that comes with the latest stable version of the software.
-------------
That's correct.
...Because what you're trying to do is use a feature that Drupal doesn't yet offer. The patch in question is an unsupported hack that is currently under testing and development by several programmers. In the future, an 'official' version of the Drupal core may offer that feature.
Think of it like an aftermarket engine upgrade for your car. It goes faster, it gets better mileage -- and the car manufacturer may well put the new features into next year's model. If you can't wait until then, though, you should know what you're doing before hacking up your automobile. Otherwise, no one else can help you when the engine needs fixing.
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
Thank you
I believe I have a pretty good understand of patching now.
So if I hear you correctly "unsupported" = use with extreme caution.
Thanks to all.
One more queston.
It seems that drupal.org uses this book.module function or something similar for the handbooks.
Is that correct?
If so - I can't imagine you using this site for testing.
If not- what is being used to change book.module menu viewing.
-------------
For drupal newbies only
I have no idea about the book module specifically
But if there is a patch floating about out there to do what you want, it is because someone has thought that it would be a good idea.
This is the very first concrete stage of how changes or new features start being added to any software project. Every change to Drupal starts off as a patch for developers to review and test. If all goes well, that feature will end up in a future version - eg maybe 4.8. But there is a long road ahead for that feature on it's way to possibly making into the Drupal core. It will have to prove itself and survive code reviews and approval processes etc. Stuff doesn't just get added to the core willy nilly.
Because Drupal is an open source project you are seeing this process because it is out in the open. You are being tempted by potential future functionality. You will probably have no idea how mature the patch is, if it is an ugly hack or not, what its side effects are, if it conflicts with stuff already in development etc etc. There are hundreds or thousands of these ideas floating around as patches at any one time.
4.7 is under a feature freeze at the moment while it gets stabilised for release. If the developer of this patch is keen to get it incorporated into a future version (eg 4.8), they will have to push to get it accepted through rounds of reviews etc. If you want to help them get there, I suggest you contact the author of that patch to offer your services - eg testing, documentation etc.
--
Anton
New to Drupal? Please read this
Also: Forum posting tips
great news
I still fail to see why a system like what osCommerce provides would not be usable?
http://www.oscommerce.com/community/contributions,2226
The complete patch history (1-15) is then available as a choice to the discerning downloading user. It gives all users the choice...whats wrong with that?
A strongly worded advisory on entering patch territory is required to scare off would be low level users.
wellsy
orchidsonline.com.au
You can download different versions of Drupal, too
See the "CVS repositories" link in the Contributor links block.
Here are the different versions of the forum module:
http://cvs.drupal.org/viewcvs/drupal/drupal/modules/forum.module?rev=1.3...
The thing is, getting a different version of any files is likely to cause weird things to break. The reason we have releases is so that the developers who know the code intimately can communicate to end users which versions are stable to use.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
I invested a lot of time
I invested a lot of time setting up an OSCommerce site, and found the way they handle updates to contributions to be a complete nightmare! It completely fails to deal with the multiple bugs or changes scenario that Robert mentioned earlier in this thread. If you go to a contribution and take the top file, that doesn't mean it's the right one for you. Different people have made different patches that fix different things, or add different features. They aren't rolled up from one entry to the next.
For example; A new version of contribution x is created and posted on the contributions page. Someone decides to add a feature, amends the file and posts it after the new version (i.e. above it in the list). Somebody then spots a bug in the original release, fixes it and posts it to the contributions page (i.e. above the feature enhanced version in the list), however it doesn't contain the added features, it's just a bug fix. So you end up having to trawl through all the files to find the one that's useful to you.
If you've used OSCommerce in anger you'll also know that if you want to use any number of contributions together you end up either using a diff utility to merge in changes, or you do it all manually in a text editor. Do that for a while and believe me 'patching' is an absolute breeze!
(At this point I would like to point out that this is not a dig at OSCommerce, which is a cracking piece of software - I'm just responding to the comparison that was made)
Gonz
I agree with your summary
but
at least the patched files are available for download
Should I capitalize it as well as add more whitespace do you think?
wellsy
orchidsonline.com.au
Do you FTP on the commandline much?
Or download files via HTTP GET from the commandline?
... You probably use a GUI client of some sort.
GUI clients for CVS exist. I find an archaic version of WinCVS to be quite adequate.
Better than downloading a zipped file and installing it, I can use my client to point at the file, select the version I want, and upgrade to it.
This, for a developer, is even better than releases.
If you choose NOT to get and learn a gui client, you might as well be complaining about the difficulty of files being provided by FTP based on the difficulty of using a commandline FTP shell.
There are better ways.
It only comes down to the interfaces that you are comfortable with, despite the fact that technically better interfaces have been chosen by people who technically use them. The arguments put forward here by a few of the 'ogres' may sound a bit "so what?" to folk that want a nice windows installer to do everything for them, but the arguments are valid.
I'll agree, the first few times I tried CVS I got it horribly wrong, and it seemed a grandly difficult way of doing a simple job. Now I use it all the time just for my own private development, just because it made backups, tracking and reverting so much better.
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
while the thunder stops echoing in my ears
I will paste what I was copying from the acid free cvs
Acidfree
Acidfree 4.7.0
Download: files/projects/acidfree-4.7.0.tar.gz
Released: December 13, 2005 - 11:20
Acidfree 4.6.0
Download: files/projects/acidfree-4.6.0.tar.gz
Released: September 25, 2005 - 00:23
Acidfree cvs
Download: files/projects/acidfree-cvs.tar.gz
######################################
Phew...the thunder subsides
In response to your post below I went to have a look at what is available in cvs for the first module on the list
I note these all look like official versions to me and not the full patch history?
Take a chill pill really. This started out as a discussion and is becoming very druplified. NEW WORD OF THE DAY!
What is wrong with someone official and responsible here verifying that a certain patch works as stated by the person presenting the patch amd then makes it available for download?
Partial Disclaimer reads "Blah...all patched file downloads are at users discretion and in no way...Blah Blah"
Remember...this is a discussion folks.
And by the way. I read the above post again and it really makes not a lot of sense to me and this is absolutely not meant to be offensive to you. Just goes to show my level of knowledge I guess.
Chillllllllll
wellsy
orchidsonline.com.au
Human capacity as a limiting factor
There aren't enough people with the right mix of skills, time and altruism to do this.
By the way, unless I'm mistaken, at least for 4.7, the acidfree module is now patch-free because the filemanager module maintainer looked at the patch, said "good idea", and integrated it. This means that the patch fit into dman's scenario #2 where a patch is a temporary thing on the way to making better software, not a tool that end-users are supposed to have to deal with.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
While it feels everyone is ganging up on you...
All it means is that a lot of people agree that the patch process is neccessary. :-/
Most folk have tried to explain in their own way why certain things are neccessary to work the way they do.
You've got it. - and that is exactly what happens with verified patches. They get committed to the CVS version of a module by any of the module maintainers, bundled overnight, and are available from viewCVS at any time.
If patches are floating around unverified, it means either the patch maker or the module maintainer haven't communicated effectively. Which is a valid complaint, but a different one. See above about the whole community thing for that :-)
NOW, your constructive suggestion to provide multiple downloads of all complete files (which does make sense on the surface) has (as described by various folk) some drawbacks when we come to impliment it.
Thus nobody is very keen on doing it, and they are just trying to explain why.
Yet you feel you're banging your head against a wall. Sorry about that but...
The CVS history for acidfree is totally available if you want it.
You can choose to download each or every full file version of each branch, bugfix, patch, commit and revision. Just choose the one you want and click "download". Looks like several hundred iterations to choose from.
Welcome to the drawbacks.
The 3 bundles you listed are just the stable snapshots. They are provided like that because it's not as confusing.
If you really want to track the history, however it's all there.
The big list of CVS history versions reflects only the official changes commited by the maintainer(s) at different points in time. Several of these patches may have gone through testing and discussion of their own. So there's really too much information there for someone with an aversion to 'patch' to make use of.
Seeing as that big list of changes probably isn't what you need, I'm guessing that the reason you want to patch is because you want this version of a module with that fix applied.
While I'm sure a web interface to that could be made (the cvsview is actually doing that with patch on-the-fly in the background) - I'd suspect that just finding your way through such an interface would be much more complicated than the current process of "Put this file next to that one and merge".
That's all patch does!
Look, I tried to explain how ugly I found patch at first. I know it seems easier to just replace a file. But after losing changes wiped out by synchronization and version errors too too many times, It's just the way to go.
It's an extra layer of discipline that stops you from breaking stuff and from having problems you though you'd fixed re-appear at the next upgrade.
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
The stupid part in all this thread is
(especially if you read down the thread further)
a) the discussion proves a constant problem here on drupal which you very rightly point out dman. Yes people do gang up on others.
b) this was only ever meant to be a discussion to see what can be done to stop low level users from being constantly dissapointed trying to patch files.
c) being druplified is a problem here.
Answer me this drupal community. Would the rest of the world (certainly those newbies reading this thread) understand this line as anything other than demeaning
newbie!= idiot
I think not!
I agree with Robert that some good explanations arose amongst the thunder. I do however think the thunder probably won.
I will take Roberts advice and make no further comment here.
wellsy
orchidsonline.com.au
What happened?
Where exactly did this thread derail? To my knowledge we (all of us) were having a discussion / explanation session on patches. The fact that many replies seemed to point out the advantage of patches and the difficulties associated with downloadable patch-levels, does not mean people are ganging up on you (it may feel this way).
That is a laudable goal. I think we agreed the patch documentation needed some work, I promised to so (as I did earlier already) and Sepeck modified the current handbook page to include a warning.
And as to c) and
What can I say? Should I say something? Would it do any good?
The newbie != idiot statement was actually a gentle reminder to everyone reading the thread that people new to Drupal are not idiots or have no skills. I fail to see why you found that offensive, especially after an explanation.
I actually wanted to ignore a certain part of the thread, but I'm afraid the pattern will repeat. Allow me to share my observation: You seem to feel that you're attacked even when you are not (or perhaps an attack is not intended). Because you then act like you are being attacked and get all excited about it:
you end up in your own self-fulfilling prophecy. Over and over.
I do not believe you usually post to raise a disturbance. Please give your peers on this forum the benefit of the doubt as well and assume they're just participating in a (passionate) discussion, not trying to insult or attack you.
Perhaps it's best to take such matters offline. If you ever wish to contact me you may do so via http://drupal.org/user/17943/contact
Regards,
Heine
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
This is typical
Why is it that the "orges" responses are the only ones that are considered valid.
-------------
Think about it
Most responses here are "valid", saving only ad hominum BS or profanity.
If one person says doing something is a stupid idea, they may just be being mean or not have had their coffee yet.
If three random people say it's a stupid idea, maybe they're ganging up on you. (you could consider what seemed to prompt that)
If half a dozen long-time developers, each who have seen this or similar suggestions several times before, try to explain at length exactly why a certain approach isn't such a practical idea, consider the possibility that they may know what they are talking about.
Claiming "I'm right because the gurus disagree with me" or "I refuse to use the same tool that everyone else is using because I've never used it before" will not produce a positive outcome.
The brick wall that Wellsy has unfortunately been banging his head against is not totally immutable. Suggestions are considered (the long-winded explainations demonstrate that these issues have been considered before)
but
Every brick of that wall has been laid down over time by hundreds of people who knew what they were doing, tested thoroughly, and changed bits that didn't work.
You are walking in at the end of the day to demand a door in it, then put your fingers in your ears and sing when the builders try to explain why things will fall down if you do.
If the whole world disagrees with you, you may be the messiah, but you're probably just wrong about this one thing.
How to use patch n windows if you are afraid of the commandline
And to finish on a positive note, try just creating a bat file that just says
Then create a send-to shortcut that links to
or associate all *.patch files with that action.
Now patching is as simple as right-clicking on your downloaded patch file.
Why continue to fight it?
http://www.coders.co.nz/
Yes, you may need to tweak the above instructions for your system, but it can be made to work.
Yes, you need to have the binary, many stand-alone versions are available. Unixtools is only one of the recommendations.
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Hienes version may be slightly overstated
Whilst TRUE (I've posted a similar explanation before) it's seldom the case that you'll have four or more different branches of incompatable 'fixes' going on to a file that's supposed to be stable.
Real development (like I guess is going on with 4.7) is another story, and sorry, the answer there truly is the unhelpful "If you don't understand it, don't mess with it"
The patches that real Drupal users get unwillingly exposed to come in two flavours:
These patches are 'unofficial', and usually don't make it into Drupal core CVS, often because they only add a marginal feature that is only useful to a minority.
Sometimes, if done elegantly enough, they do make the grade and may be seen in subsequent releases.
These ones (should) be short-lived, as providing a patch is an interim step to releasing a new version with this, and all other good patches applied.
Sometimes the patch is voted down or ignored. Thus, the people in charge of the code integrity are saying "We don't support doing this, but go ahead and do it on your own system if you want"
Patches are for people that either are developing themselves, or are intentionally changing things from the way the developers in charge intend them to work.
They are provided as a service to let you upgrade bits of the system even if the full version release isn't ready.
To address your question about the patch history approach - it's fine, and addresses the situation where all patches are accepted and all patches are applied consecutively.
This feature IS available through Drupal CVS, where you can choose to regress or upgrade to any version, subversion or commit of changes that have been certified by the developers
For arbitrary, third-party branching patches (case 1 above) this is NOT available... unless you learn how to use one basic command-line utility.
To address an issue raised in the linked discussion (but I don't want to track it) I'd repeat what several have said - patch is a tool, a common tool with its own support docs and implimentations.
Drupal.org does not supply detailed docs on how to unzip gz, untar tars, Use FTP, use your text editor, administer Apache, or navigate with your web browser - but it does have a page or two on each of these somewhere in the handbook.
Patch and CVS are the same.
You can get a GUI client for either (they do exist) or you can get a basic understanding of what they are supposed to do on the commandline, but Drupal-specific support stops about there, with a link to the actual docs.
You don't have to learn much about tar files if you choose to use winzip or others.
You don't have to learn much about patch files if you use wincvs or others. But at some stage you'll have to figure out how to do the right action in the right directory - just like you did with winzip once. SOME conceptual background is needed.
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I give in
You are all right and I am obviously wrong
There is nothing wrong with the way patching modules is presented to the low level user here on drupal.org and I am sorry I have erred by entering this discussion in the first place
I do still believe you should at least consider my proposed ammendment (or words to that effect) to the patch area handbook page
wellsy
orchidsonline.com.au
Will be
Words to that effect (but not so strong) will be included. Thanks
--
newbie != idiot
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
please explain the joke Heine
I see your post contains the line
newbie != idiot
so fill me in on the big joke Heine.....I'm sure the rest of the world would like to see this on the front page.
Headline "drupal.org says newbie != idiot"
wellsy
orchidsonline.com.au
If you insist
It's not a joke, it's a deformation by an entire week of C programming; http://www.roadmap.ubc.ca/quick/C/c_ops_step3.html
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
I am sorry but the connection is lost on me
Why do you choose to post such oblique and pointless shit?
Do you really believe that anyone but you and some of the other gods here would understand your meaning?
Crawl back into the hole you oozed out of I reckon.
As an aside I have submitted this as my Drupal contributions text entry. But strangely it has not been made public as yet.
Do you think you could help get it through mediation buddy?
Cmon!
wellsy
orchidsonline.com.au
Dude, your tone is just out of place.
newbie != idiot is to say that just because someone is a n00b to Drupal they're not an idiot, so don't treat them like one. This is in his signature of the post, has nothing to do with the topic of the thread, yet you choose to attack him on it, after he has made the effort to address your question and has pledged to spend effort improving the documentation that you requested be improved. Handbook pages have their own tempo for getting through moderation, you can't just demand that someone goes and updates something for you. Step back and look at how you're talking to people here, it's just not right.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
what crap
it is in no way his normal signature (believe me I am used to seeing his signature)
he modified it for this occasions use
I read no pledge of support in between the lines of the new addition to his signature how on earth could you?
I am not at all trying to hurry my submission to the handbook page along...only submitting a proposal....mediation will decide what goes there of course.
It's more than me needs to step back and look.
Track my posts to other threads today/tonight were they in any way along these lines?
Was the original post I made in some way provocative or deserving of all this....I think not!
The post was definitely designed to get attention and was (I thought) moving along reasonably well untill it degenerated to the depths it has.
wellsy
orchidsonline.com.au
Read carefully and give the benefit of doubt
Heine said:
This is a pledge that the documentation will be updated to address the problem.
I can't see what you could find offensive about "newb != idiot". If you're unfamiliar with !=, that translates into English as "is not equal to", so the whole sentence translates to "Just because someone is new to Drupal, it doesn't mean they're an idiot". Heine often reprimands experienced Drupallers for treating newcomers badly. You find that offensive?
Anyway, your thread produced good explanations about what patches are, what they are for, and who should use them. It also got some action going on the patch documentation. It did all this before people's feelings and egos started getting bruised. Best to call it a day and leave it alone.
- Robert Douglass
-----
My Drupal book: Building Online Communities with Drupal, phpBB and WordPress
This is probably a good
This is probably a good example where programmers and users don't always communicate with the same language. While I'm not an active programmer, I have enough programming skills to know that != meant that newbies are not idots. I think in the past most Drupal users had a good understanding of the software development process. However, as Drupal has finally gone "mainstream" I don't think this is any longer true (nor should it be). It's important to realize not all users are created equally. In other words, I suppose they're right when they say communication is key.
Having said that, I think if someone is going to be critical of the method that programmers use for software development...they need to have a better understanding of the culture before assuming ill will. A simple question by the user of "What does != mean?" would have ended this discussion on a nicer note.
-Bryan
Drupal Sites Coming Soon:
CMSReport
Drupal Blog (on WordPress) at:
Like that Idea
OK, so you didn't get the reference
But oddly enough the thousands of PHP users that you may encounter on these forums would find it neither oblique, pointless, nor even insulting or annoying.
It's actually gently encouraging, and a mature comment.
The fact it went over your head may be irritating, but in the context of a bunch of coders, it was not intended to belittle you, but to make you nod in agreement.
I'll stop reading any more into this little line :-B you probably should too.
.dan.
http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
?
Where did you post this? I can't seem to find it in your tracker. What is the purpose of the text?
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.
the purpose was simply this Heine
It is my personal statement of the position I find myself in as a user here.
The statement is true for me at this time.
If my position changes I may edit it.
The way I see it. This may be looked at by the moderators here and they will decide whether or not to make it public.
Perhaps no-one will ever publicly see it (they will need to visit my profile to be even aware of it - admins can see it no doubt right now) but if they take the time to do that I am happy that statement is listed at this time.
visit....yourUserNumber/edit/Drupal
Then look to the "Drupal contributions:" textbox
wellsy
orchidsonline.com.au
Patching is VERY easy
I did not know how to patch when I started really digging into Drupal. I was a bit scared by having to run this nefarious process from a command line. But patching is really about as easy as writing the first sentence of this comment. (The hard work was done in making the patch.)
I think once you have learned how to do it and done it a couple of times, patching will drop from intimidating to a level of perhaps a deep sigh. That's how it was for me.
Ideally you shouldn't have to patch, and in other free open source systems maybe one doesn't come across the need nearly as often as here. But Drupal is way way more complex and powerful than most open source systems. With well over 300 contributed modules that are not part of the core, it can get pretty complicated.
The acid-free patch requirement is because the module came out only last year, after Drupal 4.6 was out and after the other modules required by acid-free were out. Those modules are maintained by different people, so the acid-free developer cannot just go in and change someone else's module -- and even if he or she did, that changed module would not be included in any fixes or upgrades that the original module will be receiving.
Really, patching does end up being the easiest way -- kind of like a component system for changes.
I run patches usually right on the server. Most web hosts have the patch function pre-installed.
A couple of times, I've posted patched modules on pingVision for convenience. But really, running patches is so easy you could learn how to do it in 5 minutes, and become an expert in 15 minutes. And there are many comments already explaining why that could end up being the best 15 minutes spent all day.
It's not that hard. Really!
Laura
_____ ____ ___ __ _ _
pingVision, LLC • BlogHer • rare pattern • scattered sunshine
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
Simple answer...
First, I don't think anyone suggests that all Drupal users should have to understand patching. It IS often said, though, that all people wanting to participat in Drupal development should. Why? Simply put, patch files are the best and safest way to share and maintain changes to files in a development environment.
If only one person were ever making changes, it would be easy -- we could host an 'official' version of every file, and an 'under development' version of the file. At any given time, though, there may be dozens of people making changes to different things. Managing all those changes, and trying to keep them in sync without trampling on each other, is what makes it thorny.
A 'patch' file solves that by storing three pieces of information for every single change: the original version of a given line of text, the new version, and the 'context' -- the lines surrounding the change. It contains enough information that the patch program can bail out and display an error if it realizes that you're REALLY trying to apply the patch to Version 3 of the file -- if you'd simply copied and pasted a complete copy of Version 2 in, you would've blown away all the changes in Version 3, causing untold problems.
So, if using 'patch' and 'diff' sounds like a needless barrier that's erected by developers, I can understand. It IS more complicated than simply bundling up an entire file and saying, 'Here's the changed version.' Once you start working in a larger environment, though, or you start working with multiple files, or with multiple developers, the "simpler" method actually becomes a LOT more complicated to manage. It would take a separate army of people maintaining "test" versions of every file for every change currently being worked on. That's why most developers say, "If you want to participate in the developing and testing, learn to use patch." It's also why any changes to the Drupal core MUST be submitted as patches rather than 'full files.' Submitting changes as patches ensures that there are no 'hidden' alterations that accidentally slip in, overwriting older fixes or clobbering other new code.
If someone doesn't want to use patch, and doesn't want to get dirty working with code that's still in testing, they CAN stick to the current 'bundled' version of Drupal that's available for download. It requires no patching whatsoever!
--
Jeff Eaton | I heart Drupal.
--
Eaton — Partner at Autogram
I ususally lurk these threads quietly...
ahh well what the heck... my understanding of drupal has increased greatly ... so i'll roll the dice:
Patching is how drupal is set up. Thats how the core developers like to do it ... so if you want to use the system you've got to know how it's done. I can guarantee you if i made a complex CMS tomorrow, then people who wanted to contribute etc would need to use a system that i liked ( subversion, for example ) and i'd make the contribution process one that i was familiar.. that's for sure. CVS and patch are standard tools for distributed software development. You could also use WebDAV and subversion, or other methods.. but it's important to pick a method and use it. the drupal core people have and that's that.
Drupal is in my opinion the best PHP cms available. It's definitely not perfect .. and I'd do a few things differently, _if_ i cared enough to want to write a bunch of code for free. But the reason that i use drupal, is to use a CMS system for projects so that i _dont_ have to write , and debug a bunch of code, that provides a framework to do standard website and cms things.
However:
From reading and lurking a great deal... it does in fact seem that people who dont agree with the party line do get burned excessively. I've been on a lot of lists, lurking , posting whatever, on a lot of different subjects and the feel on this list definitely is not a friendly one, especially for people who question the politics of drupal. It is often intimidating not so much for new users, but rather for people who seem to want to contribute new ideas.
There has been improvement in the tone though... that must also be mentioned. When i first came here i used to think that the developers were extra nasty indeed... but now i notice a more measured response to criticism.. which really is all that one can ask for
Ahh well, coffee is kicking in now, time to move on to useful work.
what about something like this
So a possible addition to each module listing would be
___________________________________________________
Projects
___________________________________________________
Acidfree
A full-featured media management system for drupal. This makes it so you can easily manage your photos and videos with drupal. Acidfree albums and media items are drupal nodes to integrate better into your system. It offers themeable drawing routines for albums and each media type so it can fit in better with the rest of your website. Items can be added individually (the drupal node-centric method) and also via a mass-import page that allows server-side directories of media to be imported or zipped, bzipped or gzipped archives to be uploaded and imported.
Download · Find out more · Bugs and feature requests · Patched file contribs
___________________________________________________
So you want to find the latest patched files....Yes? Patched file contribs
you visit a new page which is fully covered by disclaimer to proceed at your own risk and has a list of nodes which are "attachment enabled". The contributors will have left a short or long (whatever is required) explanation of the reasons for this patched file and whether the know of any major/minor bugs etc.
The potential user gets to look the list over carefully and decide on whether or not to proceed.
Whether patching is easy or hard is then (IMO) irrelevant.
Why not make it easy for the whole community to just pickup the latest you-beaut patched file that was just contributed by a known good source with their explanation as to its intended use as a guide.
Developers are happy because they don't have to answer all the cries for help.
Low level users get the new functionality without the heartache and by the way they then become possible bug squashers.
When the new version of the module hits the streets wipe the slate on the patched files page...or just make a new page with a link to the old maybe?
Just re-entering a discussion (which I know I said I was out of - but it's hard to resist) in the vague hope that something useful can be salvaged.
wellsy
orchidsonline.com.au
Time is the limiting factor
As many have stated, this is a human capacity issue. Making fixes, turning them into patches, and posting them takes *time*. Time that takes away from actually adding features to the main version and squashing bugs in the _stable_ version.
However, people DO post patched modules available for download. Some developers actually include a patched version of, for example, a core module with their module.
In others, people who do have the time continue to make a patched version available in easily downloadable form. For example, Uwe Hermann is using an issue to link to the updated version of video.module for 4.6. Using the issue tracker (the link for features and bug requests) is a valid way to track this if someone has the desire to.
So. Creating/maintaining a patch is part of the development process by non-module maintainers. It may or may not solve a particular problem, and may or may not get added into the main version of the module. It takes time to create and maintain patches against a version (patches are only ever valid for one particular version...they need updating every time a maintainer edits the main, official version). Some people may provide pre-patched files. Asking nicely in an issue and/or contacting the original poster of the patch directly and they may provide a patched version if they have time.
I do appreciated the calmer tone in this thread now
I also thank those who are still around for their continued attention.
All your points Boris (as well as those from several other like posts above) are taken.
My one last question here is this. If someone wants to make a patched file available. Wouldn't it best if it were firmly attached (as it were) to the module it is patching? IE: something like my solution I offered above.
wellsy
orchidsonline.com.au
As a developer I am not
As a developer I am not really interested in having a multitude of patched versions of my modules floating about. It makes giving support even harder and tends to confuse users.
The case is different if your module requires patches to Drupal core. In this case I encourage people to include the patched core files with the module (for the stable versions).
--
Drupal services
My Drupal services
--
Drupal services
My Drupal services