Drupal for PHP5
Hiveminds - January 4, 2005 - 18:40
I have uploaded the modified files for running Drupal on PHP5. These files are from the community site and will be updated periodically as errors are found and fixed . This is not a project to move Drupal over to OOP (although if it works then....) but an effort to get errorless functionality out of Drupal and contributed modules when using PHP5. A few caveats:
- Bandwidth: the archive (/incudes and /modules is 750k and so could cause bandwith problems with the site. If this occurs then the file repository will be moved off-site to a free CVS or as a last resort to sourceforge.net
- Modules: the site does not use every contributed Drupal module and may never do so. So although all fixes may be posted as code they may not make it into the archive until a CVS is created.
- Version: Only the 4.5.1 version will be used in the project. Older and newer versions can be modified by their owners using the information from the 4.5.1. effort
Remember if you don't post the problem then it may go unnoticed. The common site login for Drupal function is on. Any and all PHP5 coders are welcome as well as those with errors to contribute.
Eh?
Why on earth are you forking for PHP5 compatibility?
Why PHP5? Simple.
I see two camps here. Those that control their own servers and can have any software versions they want, and those that are on virtual servers and don't have a choice.
You may be using Drupal on a hosted server and the host upgrades to PHP5. That is a reason on earth you would want PHP5 as soon as possible. A statement that Drupal does not support PHP5 really doesn't help if you have your entire site on Drupal and your host upgrades to PHP5. Do you drop Drupal or drop your host. Each is a big project.
Note: I have my own server and don't need Drupal to move to PHP5 (except for security concerns). But, I am not so oblivious that I don't realize why some in our community might be panicked about PHP 5 support.
I appreciate Carl's efforts to make Drupal functional on PHP5. It may not be perfect, but at least it is something.
Brian
Brian, Please note that
Brian,
Please note that the development community is working to make Drupal php5 compatible. It is not ignoring the issue. If you would review the cvs commit log and various bug reports, you would see this activity.
You will notice in some of the links below this information was provided. Links to how to report bugs. Links to how to contribute patches. Links to coding standards that mature projects have. Links to the php5 bug reports that exist. It is
As has been stated through many posts in this thread and others, the work is being done. There are also some issues with some methods of achieving apparent php5 compatibility that introduce errors over time that are not readily apparent.
Steven's response probably more fully reads, "why on earth do you want to fork the code for php5 compatibility when this work is already being done."
It would be more productive were such contributions to be continued within the existing contributions methods outlined in the documents where anyone may contribute and anyone may test and anyone may comment on a proposed patch. In this manner, it helps prevent upgrade disasters for future Drupal users.
-sp
---------
Test site...always start with a test site.
Why this is bad
Sepeck has already talked about this: Drupal will be PHP5 compatible in the future, but it is not simple. Carl's main focus seems to be on making all visible error messages go away, regardless of what's causing those messages. Stuffing problems under the carpet does not solve them. Even more, his promoting of his supposedly PHP5-compatible Drupal only confuses newbies because they don't know who to believe.
On top of that, it is bad for Drupal if people use PHP5, and think that problems they experience are Drupal's fault rather than the fault of using PHP5, when that platform is not supported yet.
Carl's continuing persistence to work outside the normal Drupal development process means that time is wasted and people get annoyed. We have to actively figure out which changes he made, and how they apply to the current Drupal version. His work is already a minor version behind, nevermind the huge differences with the current development version, which will go into code freeze soon.
Here's an overview of all PHP5-related changes that were committed:
http://drupal.org/cvs?rid=1&user=&branch=&file=&message=php5&op=Search
--
If you have a problem, please search before posting a question.
Those interested can just go
Those interested can just go to the link in my sig and surf to the file area. I am not going to make this a campaign or crusade. I thought that those wanting to use PHP5 should get more help than a "not supported" message.
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
You should really tell
You should really tell people that Drupal cannot be made working with PHP 5 by adding some "new StdClass()" at strategically important places alone. PHP 5 changed the handling of objects and thus the Drupal core needs more in depth changes. If it were that simple we'd have done it long ago.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
Right, This is why this is
Right, This is why this is not really a fork but a helping hand. I have done some OOP classes that work in the core but since that would be considered to be a forking of the project I am not going to release them. Also not everything has to be PHP5 OOP. PHP5 is still just as procedural as PHP4 It just has different rules.
I am however interested in getting things working as they should and taking it as far as it can go. Things that don't work like the HTMLarea module, Uploader and fscache don't require more than a little massaging. This effort is more to help the non-coders and to spark the interest of the PHP5ers out there. The project will include Mambo also.
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
You don't seem to get it.
You don't seem to get it. The main problem with Drupal and php 5 is that php 5 insists on passing all objects by reference which will cause some rather unexpected errors in Drupal that cannot be mitigated by the addition of "new stdClass" when creating an object. I have however taken the three changes you made to forum.module, made them into a patch, and will upload it shortly.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.
If it works then it should
If it works then it should be used, with discretion of course. The complaints are that PHP5 in strict mode is causing problems. There are lots of them that are based in that Drupal uses an object based paradigm but PHP5 does not create objects automatically as PHP4 does. Some are problems with array creation but PHP5 does not cooperate. Many problems are because there is no datatype check (object,array) or error check which cause PHP 5 to not create a needed object.
I am not going to rewrite Drupal just tweak it a bit so that PHP5 can accomodate it. Maybe future versions of Drupal will have complete PHP5 compliancy but that does not really help those that have PHP5 today. So far the changes I have made have no produce any quirkyness in the application so I keep on using them. I will fix the any problems if and when they occur. Can't just sit and not do anything because it "may not" work ;)
"A good plan today is better than a perfect plan tomorrow."
Sorry, if this is not the accepted practice. Just trying to help people help themselves
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
Help - the good way please
If you submit patches against the core code, they will get accepted, and everyone will be a lot happier. Please. It is not the good route to start a new project. You can only help the community if you join the community.
I second that
I second that, contributing directly to Drupal is SO much better than making a fork. I am sure Drupal will eventually end up working with PHP5, it's a better idea in the long run to contribute to that goal rather than what you're proposing. My 2 cents.
Sami
--
Consultant Etopian Net Services
http://www.etopian.net/
good
despite some discouragement in your approach... it is nice to see the effort, since we are upgrading to php5 to run all our sites and it would be nice to have drupal as an eventual framework for us to experiment with using on top of php5.
thanks.
maybe provide patches with your work so you cover both potential scenarios of interested folk.
Fork bad
Every fork of the code disentegrates support. There has been a long standing preference and request for patches against core for this. This kind of stuff is reviewed and commited(or rejected) over time. It is an open process and different approaches are discussed and refined on the issues tracker, email list and even the forums.
This leads to a better product.
Perhaps not as fast as some would want.
Perhaps not the way some would want.
I, as a non-developer, benefit from this measured approach. If it splinters, then few benefit and some who don't understand the ramifications of using non-standard custom forks will suffer, get mad and go to a different solution (not to mention bad mouthing Drupal to their user community).
Don't worry. Since the
Don't worry.
Since the man responsible for this micro fork does not seem to care too much about the possible ill effects his misunderstanding has on people using his "fork" in good faith we should not care as well. People have been warned. I'll just update my signature to include a standard php 5 warning.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks. And, by the way, Drupal 4.5 does not work with PHP 5.
you mean...
*Php5* does not work with drupal!
www.WorldPerfect.org
Towards PHP 5!
I'm not a full-time developer. And for Drupal, I'm more a end-user than a developer.
Any work on making Drupal compatible with PHP 5 is welcome. However, I will wait until Drupal ships a PHP 5 version before doing any tests or upgrade.
My Internet Provider is already giving me the opportunity to test out all my PHP sites with PHP 5 using a modified URL. All my PHP sites hosted there are compliant and working very well with PHP 5. The only Web site not working is my Drupal powered site.
Does that cause me any problem? No, not yet, I think that my provider will stay with PHP 4 for at least another year... I just hope that Drupal 4.6 or 5.0 will be running with PHP 5.
This is why I welcome this effort to test out Drupal on PHP 5.
Comments on PHP5 effort
I normally avoid getting into such discussions where opinions are polarized heavily (or has the potential for severe polarization), but this is an important issue so here goes.
PHP5 has been released, and is a fact of life. Many of the people using Drupal would have their ISP upgrade at some point in the future, which would break their sites badly, with no solution whatsoever. They would be completely stuck.
Carl McDade decided to go it alone, and do something about the PHP5 issue. It many be less than perfect, it may have issues, it is a fork, ...etc. BUT, it is an attempt to address an issue that rest of us (the Drupal community) have been ignoring (his comment about the usual response people get that "PHP 5 does not work with Drupal" is on the mark, and indicates a brick wall that obstructs those who want to go the PHP5 route).
He does not intend his fork to become permanent. Nor does he want the code base to be forked. But remember folks: this is a GNU licensed project, and in Open Source projects, a fork indicates to the rest of us that something is missing, and there is a need out there that is not being met.
This is a wakeup call for the Drupal community that something needs to be done.
So, what is the best way to handle the PHP 5 marriage to Drupal? We know there are issues that killes and others listed (I am not that familiar with PHP4 vs. PHP5 difference myself, but obviously we have people who know in the team).
What we are lacking is:
1. How are they to be handled? Do we know what exactly all the issue areas are? Do we have an idea of how many cases of each exist in our code base, hence an initial estimate of the effort required?
2. A task force to undergo this project.
3. A rough timeframe for finishing this task.
If we have those areas identified, and announced, then no one would have attempted to do what Carl did, because there is something being done about it, and it is not left hanging in the air. Even if no code is being worked on at the moment.
So, let us try to do the definition and estimation phase only, the proper way, for now ...
These are my 0.02$Cdn worth ...
Feel free to comment on where I was right, or off the mark ...
I do normally not brag about
I do normally not brag about my Drupal achievements but I just want to point out that I created this issue: http://drupal.org/node/9292 long before Carl even became a member at drupal.org...
So I am certainly aware of the need to release a php 5 compliant Drupal. We had intented the 4.5 release to be fully 4.5 compliant, but it did not work out because the issues involved need some consideration.
You can read about it in Steven's blog. http://www.acko.net/blog/php-clone
As always we welcome patches submitted through our patch tracker.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks. And, by the way, Drupal 4.5 does not work with PHP 5.
So I guess it is ....
So, I guess it is a "communication breakdown" then, as they say in the army ...
There is a task (collectively for all contributors) to submit patches for PHP5 compatibility.
This leaves then the following:
1. Do we have a list of all the issues that we know exist? Or are we expecting suprises? In other words, do we know what needs to be done, but just need to get to do it? Or we know most of it, and some may cause surprises?
2. Would if be of any benefit to nominate someone to lead this sub-project, and be the point contact person for it, a clearing house for all PHP5 patches if you will?
3. Do we intend this to become a 4.6 or a post-4.6 feature? If it is post-4.6, do we have a rought time line (are we talking weeks, months, a year?)
Killes, I do not mean this as criticism at all, but it may have been best to nudge and encourage Carl to work "thru the system" and point him to the above issue, then he would submit patches for it, and they make it into CVS, rather than being a fork.
Of course, the same should be said to Carl here, since he is reading this, so go ahead and convert that fork to patches, and see if they get accepted/rejected and more importantly, why they get rejected (because of serious technical issues, ..etc.)
Does this help in anyway? Hope that something good comes from that thread ...
Yes,
Yes, Everyone is right in what they are saying.
1. If I was really going to fork Drupal then I would start at the core and start in designing a pattern and doing some OOP layers to pull together the object-based code into object-oriented code. I have done so for two parts of the database and system code. But I will not release this, it is only for my own experimentation.
2. patches are something that also is not really in my schedule. There is a problem with the time it takes and having to go back to them. We are talking about litterally 20's to 100's of minor changes. Submitting them as patches would take up all of my waking hours given the way that the submission system works.
3. cvs submission is a good idea if there was a beta testing group. But as I see it there is no such group just people who like the way Drupal works but have PHP5 on their web host or servers. If this is a large group then maybe thoughts should be made to branch efforts from Drupal.org into another project similar to that of internationalization or v4.6.
4. Someone said this was opensource? This person should get an A+! I am sharing my good and bad efforts in using Drupal on PHP5. Basically just handing out a little knowledge to those that want it. This is the way of opensource as I see it. Developer groups are a good thing but they can be like closed coporations in their efforts.
5. forks - what's so bad about them? They are the foundation of opensource. Look at all the Linux distros. Distros that would not exist if Linus had not wanted to "fork" Unix OS over to a PC. Folk that want to hold things in a close controlled community are not really seeing to it that software gets better through opensource but are in effect making the source code propietory to one community. Not Good. Apache is the only true community that benefited from something like this but they are now making a concerted effort to getting their developers away from that thinking. Why? because they saw that they are putting a ceiling on improvemnts and that is not what they want. So in the last two years they have spread "forked" their community efforts to include Java, XML and other items. Do I have to mention MySQL and berkely database? When things get stagnate it may be necessary to stick a "fork" in it to see if it's done yet :)
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
»2. patches are something
»2. patches are something that also is not really in my schedule. There is a problem with the time it takes and having to go back to them.«
Carl, many thanks for this explanation of your commitment to the Drupal project. I will take the liberty to ignore your ramblings from now on. It was a waste of time to not do so in the first place.
--
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.
Are the patches integrated
Earlier in this thread Killes mentioned an effort being made to make Drupal 4.5 ready for PHP 5. That effort brought in a load of patches. Have they made it into Drupal 4.5, or do we have to start out again?
And still, even if Carl isn't willing to create 100+ patches, he takes enough time to think about the problem. We need to become PHP5 compliant, and that doesn't go away.
By the way, how far are we from being XHTML 1.0 Strict compliant?
Arie Dirk Schenkeveld - http://www.combraillesreseaux.biz
It's an ongoing process.
It's an ongoing process.
Check out the issue killes posted. It's actually one of many. You will see patch discussion. Also, if you look through other issue's, you will see mention of many other patches designed to increase php5 compatibility going forward.
Thinking about the problem and agitating about the problem becuase one does't want to work within the existing process is not the same thing. It excites people to no cause and presents the illusion that no one cares or is doing anything.
There is a lot of work being done. Check the issues and patches. Check the drupal-devel list archives. You will see the discussions and the patches and the commits into CVS and 4.5.x line. You will also see patches that were rejected because while they fixed one issue 'here', they broke another core module 'there'.
The reason that the developers want the patches very small, is so that the maintainers of various modules can test each change individually. It is easier to find any issue's with patches and correct them before they become bugs for someone else. More planning and testing up front reaps huge dividends in the long run.
Carl himself mentions how big the issue is with his unwillingness to create '100's of patches'. It is not a small thing to change and deal with the results of those changes in a way that maintains compatibility with the various php and mySQL (postGRE too) versions that Drupal works with.
No one ever said there wasn't a goal to be php5 compliant. The developers researched the issue's and began work towards it with the goal of having 4.5 be that target. It turns out that there were some gotcha's that core maintainers found. These gotcha's need to be discussed and approaches agreed upon so the implications can be accounted for. So, rather than delay the improvements in 4.5 until those issue's were addressed, 4.5 was released and php5 compatibility went forward on 4.6 and whatever bug fixes were needed for 4.5.
Isn't xhtml strict compliance a theme issue? This would be seperate from Drupal core if so and becomes a theme design issue.
The patches mentioned on
The patches mentioned on that old issue are in Drupal 4.5.
"hundreds of patches" is a more than slight exaggeration.
Drupal can be XHTML 1.0 Strict compliant if the theme is it.
--
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.
Sadly Not Quite True
Using PHPTemplate I can get a theme together that will validate 1.0 strict - but only for normal pages - the admin pages are a whole other matter since modules produce invalid forms.
It is on my todo list to provide patches. Most of them would be tiny. But I know Bèr is also working on some of these issues - as well as forming some sort of ad hoc task force looking into UI design standards in general.
I'm sure we can get there by 4.7. - or even 4.6 if these type of issues don't fall under the upcoming code freeze.
andre
1 change is not 1 patch
If you have a hundred modifications, well do them all and send in as one unified patch. What's the problem??
hmm
1. some issue's are known, patches are being worked on or approaches discussed. The outcome of those fixes may uncover other issue's.
2. All the developers are involved to some degree or anther.
3. don't know.
Anyone may submit patches.
http://drupal.org/node/316
http://drupal.org/patch
http://drupal.org/node/772
Anyone can work through the system. I am not a developer myself, but I have seen on devel list someone gain enough consensues on a given issue/feature/fix that it ended up being commited to HEAD despite Dries not liking it. All it takes is time and discussion to build that consensous on a given approach. This discussion has also seemed to result in a better long term approach as the various interested party worked through the issues. (I can't wait until the new image module comes out for 4.6).
Education and communication is always good.
Failed to unrar
I can't unrar your archive:
Unknown method in modules/throttle.module
modules\tracker.module - file header broken
Unknown method in modules/tracker.module
modules\upload.module - file header broken
I can't unrar your
I use WinRar 3.30. So you have to have that or newer. I have tried to check the file. I assumed that filestore2 would store on the server hd but I can't find it so it must be stuffed in the db somewhere. I will upload a regular zip also though. WinRar was an attempt to keep the file size down.
Has anyone else had this problem?
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
I use GNU unrar. Can't you
I use GNU unrar. Can't you make a zip-file or patch-file available so I can have a look at what you have changed?
Changed to zip format
I changed to zip format.
I have also changed the filestore2 module so that only authenticated users or @Drupal id users can download after login. Sorry, no more anonymous downloads.
I'll look at the patch system after I get the documentation CHM done and uploaded. But no guarantees on wether I use it or not.
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.hivemindz.com
PREAMBLE
===================================
I am re awakening this thread because I am tired or the snobbery of some of the Drupal developers. Some of which seem to think that they are the only good coders around and that other users and developers should have to obey their decision not to support PHP5.
I recieved email asking about running Drupal on PHP5 and if there was a list of sites running Drupal. In an effort to help I pointed to my own site which is running Drupal 4.5.1 on PHP5. I changed my sig to show this and did some other things like make the code available to those that were asking about it. I really don't have time to do it on an individual basis so I just dumped the code onto my site.
Then there was a noted effort by the Drupal Team to shut down any questions about using Drupal on PHP5 by adding in "does not work on PHP5" to both their sigs and to Drupal.org. This was done even given evidence to the contrary. I and several others are running Drupal on PHP5 without much effort.
So here it is. A thread that those that want to talk about PHP5 and Drupal can post their thoughts. It will get heated and off topic quickly so put on some asbestos. I will also try to reply venomously to any personal attacks that have nothing to do with Drupal. So if yoyu are sensitive to this type of thing then you may want to close your eyes. It may get ugly.
=====================================
THE DEVELOPMENT TALK
=====================================
I will start out by saying that I think that I have finally gotten xmlrpc.inc to work without causing a chain of errors. I am still testing this because their seems to be a difference from when cron.php uses xml.rpc and when it is initialized from the aggregator module. The aggregator does not throw errors while cron.php does.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
drupal look on this
You interpret it wrongly I think. Drupal currently does not work with PHP 5. This is out of question. You needed to modify it don't you? Users need to be informed about this, if they try it out, it will not work. There is absolutely an intention to make Drupal PHP 5 compatible. Those who shared the exact modifications they done to the code (in the form of patches) got their improvements into Drupal, and thanks to them, Drupal is getting closer to be PHP 5 compatible. It is not there yet, and is only going to go further if people share their patches. Start from the issue submission page please.
Doing patches would be a lot
Doing patches would be a lot easier if I was running Linux. I have tried to do this with windows but I don't have the patience for the different processes that have to be used to create and test the patches. I may have to break down and install Xandros again or use Vmware to run another distro.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Different Processes?
I use wincvs - I right click my modified file - "diff selected" (with the appropriate switches) - copy the output to notepad - save - drag and drop the file on to a dos2unix conversion command (to change line breaks) - upload my patch.
All in all it is a 26second process. And I'm sure there is even an easier way - but I have 26 seconds to spare every now and then - so I haven't bothered finding a faster solution.
andre
Don't you test the patch to
Don't you test the patch to see what happens after the original file is changed by it? or even if it patches? I only know bitkeeper cvs slightly but I have experienced two problems with diff patch. One is that it is not perfect and the second is that can do weird things at a binary level. I have had students complain that their mates are not checking patches and having to backtrack to older versions. This was Java development, but I would guess that it is the same for PHP.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
cvs diffs are not problematic
I also frequently submit CVS patches for Drupal, without ever checking, that the patch generated by CVS will work. It should.
I mean if you have tested (or even just proposed) solutions for making Drupal PHP 5 compatible, please take your time preparing patches instead of instructing others on how to fix Drupal. That way you will not need to redo your changes, once a new version of Drupal is out, and your wish of a lot of testers and adopters will instatly come true. Posting instructions is fine, but now you seem to have a customized Drupal 4.5.1, which is XSS vulnerable, since it does not contain the fixes that went into Drupal 4.5.2, including cross site scripting fixes, and other good stuff.
I bet your intention is not to catch up with Drupal releases as time goes by. But with submitting your changes as patches into Drupal, your name will get instantly recognized as a contributor, plus you will need to work on this less later. Think about it!
I make fixes and patches
I make fixes and patches without using patch. So my version not only contains Drupal fixes like the XSS attack fix but also other items that I think are necessary and did not make it into Drupal like the ability to edit the first post in the forum. I added a warning to this effect to the download text.
I did not upgrade to 4.5.2 because I saw problems with it before it was released when checking the CVS updates and patches.
Drupal really does need a consistent Beta testing group because there are somethings in the latest4.5.2 release which need to be patched just days after its release.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Please submit patches
I cannot stretch this more. Please do not speak about 'some problems' if you know about them, just submit those patches and they will get fixed. PHP 5 related fixes, or other stuff. Trust us. They will get fixed, if you help instead of just speaking or writing about it.
Not to be contrary but three
Not to be contrary but three of the patches that I use are not in the core of the 4.5.2 release and were not part of 4.5.1. I found them by searching the bug reports. They were not approved for lack of general interest or because of whatever, I don't know. I tested them extensively and did not find anything wrong in how they function so I added them.
I am providing code not just talk. But it's just in a form that is convenient for me.
This is one of the reasons I started FireOrb.org. Because there are a lot of good code snippets ot there that will never get into the core because they don't fit in with the coding guidlines of Drupal.org. I got the idea from www.phpclasses.org which stores PHP that will never make it into PEAR or PECL because of various reasons.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Have you showed your support?
You talk about lack of interest, and you say you have tested those patches. Have you showed your support with commenting on them? Can you please point out those you have commented to be useful, so that we can help push them into the code?
Can you update the docs?
I struggled for a while just to use drupal. I had to learn php, had to learn mysql, had to learn apache and had to learn how drupal worked. Then to contribute to drupal development I had to learn cvs, I had to learn how to create diffs. I am an experienced programmer but by the time I got to diffs and patches and there was no documentation for windows users I was frustrated and tired. A lot of the documentation was linux based and I did my fair share of adding windows docs but man, I know how Carl feels about this. If his experience was anything like mine give him a friggen break and some time to recoup!
Anyway, I needed to get that off my chest (not directed at anyone). Long live drupal.
Andre, or someone, if you have time please update the docs with how to create diff's and patches on a windows system. And maybe a better explaination of the process. Maybe then people like Carl and I can help too.
May I ask for something?
Judah
People normally contribute what they know, whether it is Linux, PHP, MySQL, PostgreSQL, CSS, themes, ... you name it.
Therefore, it is best that people who know something, and see a void in the documentation to step in and fill that void with their knowledge.
Since you already use Windows, and know how to set Drupal up, then please use the knowledge you have and edit the appropriate pages that are lacking (e.g. installation instructions are nor Windows specific, How to use CVs? How to patch? ...etc.
This is not solely aimed at you, but to anyone who has the know how of an area that is lacking.
Please contribute.
Diff and patch on Windows
Doing a search for "diff" has this as the first result: Diff and patch on Windows
No. Carl says things that
No. Carl says things that are not correct or unqualified. He confuses people who are new to Drupal use. He encourages people to use unsupported configurations that will have NO supported upgrade path.
He constantly complains about things without contributing back to the community. Patching using diffs and cvs is NOT a Drupal thing, it is a programming thing and it is not up to Drupal.org to teach you that.
He is like Chicken Little or the boy who cries wolf. He benefits from the work of others. Complains about it not being delivered to him on a silver plate, claims to have fixed things yet refuses to bring those alleged 'fixes' back to the community. For example, he complains that blogapi is broken and has a seperate downloadable fix for it, but it seems to work just fine for me using w.blogger as well as my not computer literate sister-in-law. So when Drupal goes to 4.6, his alleged fixes will not be there. Anyone upgrading to 4.6 will be left high and dry. So, no, no sympathy for Carl. It's a pity he won't contribute back.
Most of the developers use *nix. As you have figured out diff and patches on Windows, please write a handbook page for us, and I am sure it will be appraoved.
-sp
---------
Test site...always start with a test site.
I think you are at the point
I think you are at the point where you are just embarassing yourself. Please go on...
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Why? Everything I've said
Why? Everything I've said is true. How can that be embarrasing. Please read the other responses asking you to contribute. PLEASE please please contribute back to the community. Everyone would be thrilled to see you contribute. We all want a better product.
For crying out loud, as far as I can tell, fireorb doesn't even run Drupal.
-sp
---------
Test site...always start with a test site.
Now, I think you are
Now, I think you are embarassing others who may be watching.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Carl, I had tried to ignore
Carl, I had tried to ignore your postings. I confess that I was not able to do so. I've found them most entertaining and will continue to observe your struggle with reality.
--
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.
I think that you have that
I think that you have that reversed. The reality principle is when someone takes the hard road (trying to use php5 as I am) as versus the pleasure principle (immediate gratification of using PHP4) which is to say things are fine and dandy, why struggle?
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
You are just struggling yourself
The problem is that your struggles would be worthy, if you would give your results back to the community. This way you just struggle yourself, and only let people smile at you. You struggle through making something you call 'Drupal' PHP 5 compatible and try to portrait yourself as not being able to download diff.exe and use it on the command line. This is ironic at best...
There is also a diff and patch for windows page since 2002 december in the manual, which you had no questions about. Does that mean you have not found it or that you not tried to found it, or that it is not clear enough? How would we be able to help you contribute?
You might have a point if I
You might have a point if I had not been "running" Drupal on PHP5 long before you made your first public appearance here. In fact, it was me who created the issue (http://drupal.org/node/9292) to remind the developer community to investigate the neccessary changes to the Drupal core last July. I also found a lot of problems and contributed several patches.
So, what's your point besides being obnoxious?
--
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.
My point is that my opinion
My point is that my opinion and my doings are my own and of those who choose to take my advice. It has nothing to do with you or anyone else because I and that person are communicating. If you choose to join in on that communication then you should be aware of the facts. Seek information and go on what you have tried and concluded to be the actual reality and not heresay evidence.
The truth of the matter is that the Zend 2 engine was built with PHP4 code in mind and it does not take much to convince it to work. You do not have to make PHP4 code into PHP5 not do you have to use any particular parts of PHP5. The Zend 2 engine is built to accept everything that the latest version of PHP4 does. You only have to be aware of "how" you code in PHP4 not change coding languages.
With that in mind there is nothing in Drupal that cannot be fixed so that it will operate on the Zend 2 engine without errors. The only thing it calls for is what everyone claims to be the main point in Drupal development, "clean code". The code just has to be cleaner and tighter to operate in the PHP5 environment.
On a personal level no one is protecting the non-programmer user from me. I am not out to harm anyone. Anyone that asks for or has asked for help has recieved it. They will continue to get that help to the point of satisfying their need or until we conclude that nothing else viable can be done. What you all need to remember is that it is I who is providing the help and I am the one responsible along with the second party. If you yourself cannot help or choose not to then you should remain quiet and let us figure it out. You may learn something from the transactions. But to blindly come in and say that things are a certain way without at least seeking out possible solutions is not support only condemnation. It seems to me to be petty and unwanted on any level.
If you think that I am interfering with your "support" of Drupal then open a "support" forum and I and any others that only want open discussion on the possiblilities will stay out of it. Even setting of a section for "alternative development" would fix a lot of things. But since this does not exist and the forum is a free-for-all then we will be at each other throats until someone blows a vein.
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
Mirror mirror on the wall
This has your most verbose post ever. Hint, it doesn't help your image as a timewaster. I'm locking this thread as there is nothing new being added here.
--
If you have a problem, please search before posting a question.
Eclipse
My Eclipse generated patches from a Windoze machine work just fine. www.eclipse.org
- Robert Douglass
-----
visit me at www.robshouse.net
Which set of eclipse tools
Which set of eclipse tools are you using?
---------------------------
www.hivemindz.com (running PHP5)
www.fireorb.org (documentation and hacks)
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
phpeclipse
http://www.phpeclipse.de/tiki-view_articles.php
But that doesn't have anything to do with the patch generation. That's built into the main Eclipse program. I'm quite happy using eclipse for my Drupal development - I even like it better than the Zend Studio that I bought.
- Robert Douglass
-----
visit me at www.robshouse.net