[drupal-devel] I do not care about PHP 5
Hi! PHP 5.0.5 broke Drupal 4.6 (reference is now an error). Reading http://shiflett.org/archive/150 this, I can not care less and I am not likely to put any efforts into making Drupal PHP5 compatible. If my code is PHP5 compatible, fine, but I will not bother myself. (This does not mean slopy code, $_POST['op'] which results in notices is acceptable) I think I'll wait another year before looking again. Opinions, please. Regards NK
You may not be running on PHP 5, but some of us are or will be soon. That means if you code non-PHP 5 code, we can't use your code. Web hosts will eventually upgrade to PHP 5, be it next month or next year, and Drupal WILL, sooner or later, have to be 100% PHP 5 friendly. The more PHP5-incompatibility you code now, the more time you'll spend fixing it all later. Whether later is December 2005 or December 2007, you'll still have to go back and fix it. Develop under PHP 5 E_STRICT | E_ALL. Make the system nitpicky. Fix everything it complains about. That way whenever people DO start migrating to PHP 5 en masse, Drupal is already there. That makes it something people migrate TO, instead of away FROM, when they find their old web apps don't work on PHP 5 anymore. Do you really want people to get upgraded to PHP 5 and find "Oh, Drupal doesn't work anymore. I guess I'll have to dump it and switch to Typo3"? I'd rather they face the opposite situation. :-) On Friday 14 October 2005 04:17 am, Karoly Negyesi wrote:
Hi!
PHP 5.0.5 broke Drupal 4.6 (reference is now an error).
Reading http://shiflett.org/archive/150 this, I can not care less and I am not likely to put any efforts into making Drupal PHP5 compatible. If my code is PHP5 compatible, fine, but I will not bother myself. (This does not mean slopy code, $_POST['op'] which results in notices is acceptable)
I think I'll wait another year before looking again.
Opinions, please.
Regards
NK
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
it all later. Whether later is December 2005 or December 2007, you'll still have to go back and fix it.
By then, PHP6 will be there, incompatbile again, and I'd need to fix anyways. And who knows, it's possible that 5.0.6 will break stuff again and I need to fix my code again. No, thanks, I code for PHP4.
to PHP 5 en masse
You suppose this will happen. I am not sure. I see only one reason to change: if we can find a cool metaschema for PHP 5.1's PDO. I do not hold my breath. Regards NK
It is going to be a huge undertaking, but I thik there is only one clean solution: standard, clean use of ONE coding style. Not objects here, keyed arrays there, referenced objects here, returned objects there. one hook expecting an object another similar one expecting a keyed array and yet another one expecting a string or integer. Here is how I think we should go for this: Rewrite, finetune and detail the coding guidelines so they aim for _one_ php5 compatible standard rewrite parts of the core to follow these standards. Not let in any patches that do not follow these guidelines. With coding style, in this, i do not mean spaces, tabs etc. But when to use objects, when to return what, when to call what etc. Ber
Karoly Negyesi wrote:
it all later. Whether later is December 2005 or December 2007, you'll still have to go back and fix it.
By then, PHP6 will be there, incompatbile again, and I'd need to fix anyways. And who knows, it's possible that 5.0.6 will break stuff again and I need to fix my code again. No, thanks, I code for PHP4.
to PHP 5 en masse
You suppose this will happen. I am not sure.
I see only one reason to change: if we can find a cool metaschema for PHP 5.1's PDO. I do not hold my breath.
Which modules are you maintaining ? Bertrand Mansion Mamasam
it all later. Whether later is December 2005 or December 2007, you'll still have to go back and fix it.
By then, PHP6 will be there, incompatbile again, and I'd need to fix anyways. And who knows, it's possible that 5.0.6 will break stuff again and I need to fix my code again. No, thanks, I code for PHP4.
Coding for PHP 4 does not help, as similar fixes were intorduced in PHP 4.4.0 too. Before ranting against PHP 5 support, you should really go after what was changed, and why it was neccessery: http://tinyurl.com/bo7pr Read the anchored comment, not the blogpost! What this says to us: - PHP 4.4.0 / PHP 5.0.5 fix several crash bugs (people will upgrade to these, and they do it rightly) - unfortunately some of these bugs were caused because PHP was forgiving in handling references, and this resulted in problems, which can only be fixed by making PHP stricter, breaking BC Read what Derick things about this change being good for making PHP applications better: http://derickrethans.nl/fanmail.php Sure, if you are not going on this route, you can do so. But be warned that quite some Drupal developers are or at least try to be on the bleeding edge with actual software (to get bug fixes, use new features), so actually these core developers will not be able to use your code. Eg. last time it was asked, drupaldevs.org ran on PHP 5, JonBob, Killes and others having development spaces there. Kalid B suggested that I should try to escalate this to the developers. There is no need to escalate this, as you will see from Derick's fanmail, this was escalated enough. Those who don't like this situation should either improve their code or submit a patch to the Zend Engine itself, this is the situation. I don't think it is a problem, if Drupal comes out of this as a better written application. I doubt Rasmus will tell you otherwise at EurOSCON (and I doubt he is using Drupal on PHP 4). Goba
On Sat, 15 Oct 2005, Gabor Hojtsy wrote:
By then, PHP6 will be there, incompatbile again, and I'd need to fix anyways. And who knows, it's possible that 5.0.6 will break stuff again and I need to fix my code again. No, thanks, I code for PHP4.
Coding for PHP 4 does not help, as similar fixes were intorduced in PHP 4.4.0 too. Before ranting against PHP 5 support, you should really go after what was changed, and why it was neccessery:
Read the anchored comment, not the blogpost! What this says to us:
- PHP 4.4.0 / PHP 5.0.5 fix several crash bugs (people will upgrade to these, and they do it rightly)
- unfortunately some of these bugs were caused because PHP was forgiving in handling references, and this resulted in problems, which can only be fixed by making PHP stricter, breaking BC
Thanks for explaining this.
Read what Derick things about this change being good for making PHP applications better:
I find it kind of amusing to observe a script language trying to become a real programing language. :p
http://derickrethans.nl/fanmail.php
Sure, if you are not going on this route, you can do so. But be warned that quite some Drupal developers are or at least try to be on the bleeding edge with actual software (to get bug fixes, use new features), so actually these core developers will not be able to use your code. Eg. last time it was asked, drupaldevs.org ran on PHP 5, JonBob, Killes and others having development spaces there.
Drupaldevs is down for several months now. :p
Kalid B suggested that I should try to escalate this to the developers. There is no need to escalate this, as you will see from Derick's fanmail, this was escalated enough. Those who don't like this situation should either improve their code or submit a patch to the Zend Engine itself, this is the situation. I don't think it is a problem, if Drupal comes out of this as a better written application. I doubt Rasmus will tell you otherwise at EurOSCON (and I doubt he is using Drupal on PHP 4).
Yep, the situation is pretty much settled. There is no doubt that the more rigid handling of what is allowed and what not will improve code. I have been submitting patches for fixing notices in the past and think that more patches like this should be comitted. Large mega patches are unlikely to make it, though, as experience has shown. Cheers, Gerhard
Read what Derick things about this change being good for making PHP applications better:
I find it kind of amusing to observe a script language trying to become a real programing language. :p
It is indeed. ;)
http://derickrethans.nl/fanmail.php
Sure, if you are not going on this route, you can do so. But be warned that quite some Drupal developers are or at least try to be on the bleeding edge with actual software (to get bug fixes, use new features), so actually these core developers will not be able to use your code. Eg. last time it was asked, drupaldevs.org ran on PHP 5, JonBob, Killes and others having development spaces there.
Drupaldevs is down for several months now. :p
Which is not relevant, really :P I just wanted to point out that PHP 5 was used quite some time ago on this server, and I personally expect that other core developers (and high profile users, even among the PHP developers) will (try to) use Drupal with PHP 5. Goba
On Saturday 15 October 2005 08:17 am, Gerhard Killesreiter wrote:
Yep, the situation is pretty much settled. There is no doubt that the more rigid handling of what is allowed and what not will improve code. I have been submitting patches for fixing notices in the past and think that more patches like this should be comitted. Large mega patches are unlikely to make it, though, as experience has shown.
Cheers, Gerhard
What do you suggest, then, in order to make Drupal E_ALL | E_STRICT compliant? Lots of little patches, one per isset() call? :-) One patch per core module? I do agree that more complete coding guidelines (objects vs. arrays, when to pass what, optimal way to check for variable existence, etc.) are a good idea. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I thought that 4.7 is PHP compliant. Judging from all the comments here, and the new info from Goba (thanks btw, escalation or not, you DID help settle it), it seems to me that there is no way other than to go forward. It is fine to stay on an old version of a language for an inhouse application, where you have full control of the environment. However, no one can afford to stay on an old version when their application is used by untold thousands and hosted on machines outside their control. So, sooner or later, we will have to make it PHP 5.0.5 compliant. Coding guidelines will help, but they have to be explicit in why the specific syntax variant is used (because of forward compatibility with PHP). The other thing is to mandate that we develop with E_ALL and remove all the warnings. Of course, writing guidelines is one thing, and converting all the code is another huge lengthy effort. It is a huge effort, but I don't see any options other than to go forward with this.
Yep, the situation is pretty much settled. There is no doubt that the more rigid handling of what is allowed and what not will improve code. I have been submitting patches for fixing notices in the past and think that more patches like this should be comitted. Large mega patches are unlikely to make it, though, as experience has shown.
Cheers, Gerhard
What do you suggest, then, in order to make Drupal E_ALL | E_STRICT compliant? Lots of little patches, one per isset() call? :-) One patch per core module?
I do agree that more complete coding guidelines (objects vs. arrays, when to pass what, optimal way to check for variable existence, etc.) are a good idea.
Per issue patches. 1. Identify a problematic practice. 2. Fix all occurances of this single practice. 3. Submit a patch for the code. 4. Submit a patch for the coding guidelines. *. Iterate from (1) with another problematic practice. It is much easier to focus on one problematic practice, when creating and reviewing patches. Goba
On Sunday 16 October 2005 05:42 am, Gabor Hojtsy wrote:
I do agree that more complete coding guidelines (objects vs. arrays, when to pass what, optimal way to check for variable existence, etc.) are a good idea.
Per issue patches.
1. Identify a problematic practice. 2. Fix all occurances of this single practice. 3. Submit a patch for the code. 4. Submit a patch for the coding guidelines.
*. Iterate from (1) with another problematic practice.
It is much easier to focus on one problematic practice, when creating and reviewing patches.
Goba
I agree, generally, but fix to what? We should decide whether we're going to standardize on is_null() or === NULL before we start writing patches to always use one or the other, for instance. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sun, Oct 16, 2005 at 03:20:02PM -0500, Larry Garfield wrote:
I agree, generally, but fix to what? We should decide whether we're going to standardize on is_null() or === NULL before we start writing patches to always use one or the other, for instance.
That is why i proposed to write the standards first. Off course we cannot yet agree on the details, untill they are tested in patches. But the general decisions should be made before we start patching with again a variety of solutions. Ber
On Sunday 16 October 2005 04:23 pm, Bèr Kessels wrote:
On Sun, Oct 16, 2005 at 03:20:02PM -0500, Larry Garfield wrote:
I agree, generally, but fix to what? We should decide whether we're going to standardize on is_null() or === NULL before we start writing patches to always use one or the other, for instance.
That is why i proposed to write the standards first. Off course we cannot yet agree on the details, untill they are tested in patches. But the general decisions should be made before we start patching with again a variety of solutions.
Ber
Well, let's sort out what sorts of errors we're dealing with under E_STRICT, and then see what the options are. In general I'd suggest going with the most pretty-code-friendly solution in most cases, unless there's a dramatic speed difference. - I don't believe there's any classes in Drupal, so var vs. public/private is a non-issue. - Checking for variable existence. isset() is the standard way I know of, baring just always initializing a variable. The latter is not always possible, though. Does PHP have a cleaner default value syntax than the ternary operator? It works, but it's ugly. :-) (Python, I believe, can do x = y || z to use z as a default value if y is not set. I don't know if PHP has an equivalent.) - NULL values. Where would these be an issue other than pulling data from the database? I'm of the mind that given MySQL's poor handling of null vs. default values, we should just always specify NOT NULL and a default for every field, period. That default value is then understood to be the "no value" flag. Other thoughts? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sun, Oct 16, 2005 at 04:41:27PM -0500, Larry Garfield wrote:
- NULL values. Where would these be an issue other than pulling data from the database? I'm of the mind that given MySQL's poor handling of null vs. default values, we should just always specify NOT NULL and a default for every field, period. That default value is then understood to be the "no value" flag.
Postgres does not accept NULL values for NOT NULL columns, iirc Mysql will silently convert NULL to default value. -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!
Well, let's sort out what sorts of errors we're dealing with under E_STRICT, and then see what the options are. In general I'd suggest going with the most pretty-code-friendly solution in most cases, unless there's a dramatic speed difference.
- I don't believe there's any classes in Drupal, so var vs. public/private is a non-issue.
- Checking for variable existence. isset() is the standard way I know of, baring just always initializing a variable. The latter is not always possible, though. Does PHP have a cleaner default value syntax than the ternary operator? It works, but it's ugly. :-) (Python, I believe, can do x = y || z to use z as a default value if y is not set. I don't know if PHP has an equivalent.)
- NULL values. Where would these be an issue other than pulling data from the database? I'm of the mind that given MySQL's poor handling of null vs. default values, we should just always specify NOT NULL and a default for every field, period. That default value is then understood to be the "no value" flag.
Other thoughts?
Please identify the problems you find in Drupal while running. These above just seem to be made up somehow. Concentrate on real problems, do not made up possible problems please. Goba
I agree, generally, but fix to what? We should decide whether we're going to standardize on is_null() or === NULL before we start writing patches to always use one or the other, for instance.
That is why i proposed to write the standards first. Off course we cannot yet agree on the details, untill they are tested in patches. But the general decisions should be made before we start patching with again a variety of solutions.
The route which leads there: 1. Identify (seemigly) bad usage of code practice in Drupal. 2. Decide on better practice (either by discussing a patch, or a code extract showing the practice) 3. Apply patch to code and guildelines. *. Iterate from (1) with another (seemigly) bad practice. One, who runs Drupal on E_ALL can do (1), anyone can do (2). Goba
Hello all, Thank you Goba for your good advice. On Monday 17 October 2005 05:09 pm, Gabor Hojtsy wrote:
1. Identify (seemigly) bad usage of code practice in Drupal.
When preparing the big patch I introduced earlier in the thread, I have had the opportunity to identify several common but unfortunate coding practices. Let's start with the most common and uncontroversial ones, and we'll see later what we have left.
2. Decide on better practice (either by discussing a patch, or a code extract showing the practice)
Here is a start: http://drupal.org/node/34341 Please comment.
3. Apply patch to code and guildelines.
If the above proves fairly uncontrovertial, I'll move on to the next step and prepare some patches.... then reiterate with the next bad practice...
*. Iterate from (1) with another (seemigly) bad practice.
beginner. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
Let's start with the most common and uncontroversial ones, and we'll see later what we have left.
Great.
2. Decide on better practice (either by discussing a patch, or a code extract showing the practice)
Here is a start: http://drupal.org/node/34341 Please comment.
This method of discussion does not scale. Having issues, you exactly know what status of a modification you discuss (the latest submitted patch). Having a node which is purposedly about to change does not constitute a good base for discussion as it renders some comments obsolote. Also you kick off this node as if you intend to add other pratices later in there. Expect some issues to heat up (ot least I do so :), so that you are going to have hunderds of comments on the same node, hard to filter what comment is about what issue. Also discussions should not end up in the handbook IMHO. Once we have the discussed guidelines, then add it to the handbook. This way it looks quite official, while it is "just" a proposal. What I would do: - start an issue (drupal.org/node/add/issue), per problem type (ie. start an issue for the undefined variable notice) - attach a sample patch (correct one instance of this error, and let the discussion roll around this possible solution) - set the issue status to "patch (code needs work)" (actually a cross between "patch (code needs review)" and "code needs work" would be better, but such status does not exist :) + This way you can identify every issue update as belonging to this piece of coding practice (this is *very hard* with the handbook method you tried to start with). + This way you can show code changes in the form understood by developers. Patches, yam. + This way, it is quite easy to end up in a patch to commit, as you are already in an issue. I would name these issues "E_ALL: undefined variable/index notices" "E_ALL: reference handling notices" "E_ALL: ...." You understand the pattern I guess. This tags these issues somehow, and makes it easy to find them later. Note that all issues should end up as a patch for core and as an update for the coding guidelines (handbook update, patch for any CVS copy). Goba
On Tuesday 18 October 2005 02:49 am, Gabor Hojtsy wrote:
What I would do:
- start an issue (drupal.org/node/add/issue), per problem type (ie. start an issue for the undefined variable notice) - attach a sample patch (correct one instance of this error, and let the discussion roll around this possible solution) - set the issue status to "patch (code needs work)" (actually a cross between "patch (code needs review)" and "code needs work" would be better, but such status does not exist :)
Thanks. Page updated: http://drupal.org/node/34341 First issue created: http://drupal.org/node/34434 -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
I do agree that more complete coding guidelines (objects vs. arrays, when to pass what, optimal way to check for variable existence, etc.) are a good idea.
Per issue patches.
1. Identify a problematic practice. 2. Fix all occurances of this single practice. 3. Submit a patch for the code. 4. Submit a patch for the coding guidelines.
*. Iterate from (1) with another problematic practice.
It is much easier to focus on one problematic practice, when creating and reviewing patches.
I agree, generally, but fix to what? We should decide whether we're going to standardize on is_null() or === NULL before we start writing patches to always use one or the other, for instance.
Yes, this is why it helps if you pick and show us a problem (either in the form of a patch, or in the form of a discussion), and then we decide on the proper way, and get the patch committed. The answer to "fix to what" is to fix bugs, where Drupal is not E_ALL compatible. In the particular example, is_null() and === NULL are used in different ways (ie. sometimes values are explicitly set to null, sometimes unset, sometimes not set at all). These might be different cases, depending on how code is written for them in Drupal. Someone who does run Drupal on E_ALL can identify the different places and cases. Goba
On Saturday 15 October 2005 09:17 pm, Gerhard Killesreiter wrote:
I have been submitting patches for fixing notices in the past and think that more patches like this should be comitted. Large mega patches are unlikely to make it, though, as experience has shown.
May you say more, please? Have 'mega patches' been submitted before to solve all E_ALL notices??? If I understand well Drupal's development model, it all boils down to whether Dries wants the patch or not? He doesn't seem to be very active on this list, so I guess he doesn't read it. Has he said anything specific for or against this E_ALL issue? There's absolutely no point for us to prepare a patch if he's already made his mind against committing it. You may have seen on this list that I'm working on precisely this. http://drupal.org/node/28540 And I plan to work on incorporating all similar issues and patches, like: http://drupal.org/node/30930 http://drupal.org/node/30800 What you say about 'large mega patches' being unlikely to be committed surprises me, because I would have believed the opposite was true for the E_ALL issue. Part of the patch reads like this: function error_handler($errno, $message, $filename, $line) { - if ($errno & (E_ALL ^ E_NOTICE)) { + if ($errno & (E_ALL )) { This is the heart of the matter! but changing this line will suddenly affect all the code, because it is currently quite messy, and error notices will start to crop up everywhere, making more than one person unhappy. So the patch would need to be BIIIG so as to cover at the very least 90% of possible errors (one single page view of admin/settings printed no less than 1480 errors and maybe more than 1500 on the screen... all dealt with by the patch I propose!!!) The solution would be to NOT change that line, but then, other developpers will not see the error notices and would carry on with their bad coding practices while we try to keep up providing patches, hoping they get committed. What's the point in creating disparate small patches while the codes changes rapidly and more mistakes (undeclared variables) are made than we get the opportunity to fix? If you understand the dilemma above, you'll also understand why I thought a big patch would have had a better chance to be committed, and set a cut off point beyond which all developpers would have to adopt stricter coding practices. Yet, I am very new in this community, and I do not know people and stuff... Certainly you have experience that I do not have and you know things I don't. That's why I beg you to clarify your statement and advise me on the best course of action so that we can work from cleaner code (I had to clear some php that read, for example: $sql .= "SELECT blah...."; that would create an error notice about $sql not being set... I wonder why the dot in .= what put there in the first place...). Please, kindly advise. thanks. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
On Sun, 16 Oct 2005, Anguo wrote:
On Saturday 15 October 2005 09:17 pm, Gerhard Killesreiter wrote:
I have been submitting patches for fixing notices in the past and think that more patches like this should be comitted. Large mega patches are unlikely to make it, though, as experience has shown.
May you say more, please? Have 'mega patches' been submitted before to solve all E_ALL notices???
No, but small ones have.
If I understand well Drupal's development model, it all boils down to whether Dries wants the patch or not? He
Right.
doesn't seem to be very active on this list, so I guess he doesn't read it.
He rather writes code than discussing less important stuff.
Has he said anything specific for or against this E_ALL issue? There's absolutely no point for us to prepare a patch if he's already made his mind against committing it.
I don't like playing Dries oracle. He has previously rejected patches that fixed notices on the expense of readable code. So I guess you should make patches that keep the code readable. Dries also does not really like lengthy patches (who does?). I guess it is easioer to find time for reviewing and committing multiple short patches than one large one. Large emails are almost as evil as large patches. Cheers, Gerhard
Part of the patch reads like this:
function error_handler($errno, $message, $filename, $line) { - if ($errno & (E_ALL ^ E_NOTICE)) { + if ($errno & (E_ALL )) {
This is the heart of the matter! but changing this line will suddenly affect all the code, because it is currently quite messy, and error notices will start to crop up everywhere, making more than one person unhappy. So the patch would need to be BIIIG so as to cover at the very least 90% of possible errors (one single page view of admin/settings printed no less than 1480 errors and maybe more than 1500 on the screen... all dealt with by the patch I propose!!!)
The solution is to fix the problems in different smaller to test/review patches, and then once all errors are fixed, apply this E_ALL change (which might not be a good idea for contrib module users, but that is a different question). If you provide smaller patches, they are more likely to come into the code, because they are easier to review, and it is easier to find the free time slot to do so. It is also easier to discuss one type of change, which you applied to the whole Drupal, then several issues at once. Also it is easier to introduce the coding guideline which comes out of the acceptance (or rejection) of the smaller patch.
The solution would be to NOT change that line, but then, other developpers will not see the error notices and would carry on with their bad coding practices while we try to keep up providing patches, hoping they get committed. What's the point in creating disparate small patches while the codes changes rapidly and more mistakes (undeclared variables) are made than we get the opportunity to fix?
Update the coding guildelines, and with the accepted small patches, Dries et. al. will get the message that they should look for conformance to the updated guidelines in future accepted patches. This approach worked before. Keep up the good work. I myself very much appreciate the work done to make Drupal E_ALL compliant, but I can only find the time to look into and review smaller patches, and I am sure there are numerous others like me. Goba
One last question on this issue. As a Drupal developer I am not alien to the concept of BC breaking. Where is the "update your script to PHP 5.0" and "to 5.0.5" handbook page? Regards NK
One last question on this issue. As a Drupal developer I am not alien to the concept of BC breaking. Where is the "update your script to PHP 5.0" and "to 5.0.5" handbook page?
I don't know of a document, this is only possible to test with a trial and error method, ie. try to use Drupal on PHP 5.0.5/4.4.0, and see what errors you get. Drupal was made capable of running on PHP 5.x the same way before. Goba
I thought we had PHP5 running OK with 4.6. So this seems to be an issue with the 5.0.5 release of PHP. Perhaps we should report this as a concern to Rasmus or whomever. Goba, I think you are on the PHP team. Can you escalate this to whomever will listen? I guess Karoly can provide examples of what code was broken. On 10/14/05, Karoly Negyesi <karoly@negyesi.net> wrote:
Hi!
PHP 5.0.5 broke Drupal 4.6 (reference is now an error).
Reading http://shiflett.org/archive/150 this, I can not care less and I am not likely to put any efforts into making Drupal PHP5 compatible. If my code is PHP5 compatible, fine, but I will not bother myself. (This does not mean slopy code, $_POST['op'] which results in notices is acceptable)
I think I'll wait another year before looking again.
Opinions, please.
Regards
NK
participants (9)
-
Anguo -
Bertrand Mansion -
B�r Kessels -
Gabor Hojtsy -
Gerhard Killesreiter -
Karoly Negyesi -
Khalid B -
Larry Garfield -
piotrwww＠krukowiecki.net