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.
This patch adds constants to define node publication status, node promotion and node sticky status.
Also documents the existent node constants and change values per the defined constants on node and blogapi modules.
Comment | File | Size | Author |
---|---|---|---|
#33 | node_constants.patch | 6.57 KB | robertgarrigos |
#22 | node_constants.patch | 9.93 KB | lilou |
#19 | node_constants_b.patch | 11.82 KB | theborg |
node_constants_a.patch | 4.58 KB | theborg | |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedooh - nice. code looks good. i hope to test this.
Comment #2
asimmonds CreditAttribution: asimmonds commentedDo we want to reconsider this again? Issue for 5.x that was marked won't-fix, http://drupal.org/node/43355
Comment #3
ScoutBaker CreditAttribution: ScoutBaker commented-1 as I tend to agree with the conclusions from the 5.x issue. For simple boolean values, 0 and 1 are good enough. If we had a negative logic situation (i.e., status = 0 means published), I could see doing this, but that's not the case for these three.
Comment #4
sasconsul CreditAttribution: sasconsul commentedI vote +1 for self documenting code vs magic numbers. Magic numbers are very dangerous!
The Wikipedia page, http://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constant , provides some background.
In this case how much code would I have to read to find meaning of status=0 is published? I know that PHP is interpreted, so the overhead of looking up the constants is a issue. But, good software engineering should be the rule.
Comment #5
moshe weitzman CreditAttribution: moshe weitzman commentedi think this is desireable for consistency. that issue was not marked won't fix by a committer so it really doesn't represent a "decision". the documentation here is a nice bonus.
Comment #6
Crell CreditAttribution: Crell commentedI'm also +1 on constants over magic numbers, even when there's just 2 of them. The performance hit is so small as to not be worth mentioning. Also, it's all in compile time. If you're running an Opcode Cache, there isn't even a cycle's worth of cost.
Comment #7
pwolanin CreditAttribution: pwolanin commentedA nice idea - but I have to think the patch is incomplete?
Also, if we're going down this road, there are some even more serious magic number issues in menu.inc that deserve this treatment first.
Comment #8
robertgarrigos CreditAttribution: robertgarrigos commented+1 for this patch. Very handy for more than 2 choices and consistent with comments. Also: status = 1 means published ? not so clear as promote = 1.
+1 to look for other magic number issues but this doesn't mean this patch is incomplete. I tested it and, for me, it's RTBC
Comment #9
Gábor HojtsyWell, pwolanin's point is that lots of places, the magic numbers are still used for status, promote, etc.
Comment #10
robertgarrigos CreditAttribution: robertgarrigos commentedHe is talking about the menu.inc and I only could find some
and
but nothing else.
I did a grep also looking for '$node->status = 1' and '$node->promote = 1' and only could find the ones already patched here....so I don't know what are those magic numbers actually pwolanin is referencing to.
Comment #11
Gábor HojtsyLet me give some examples. Not all of them are node status, but well... We can also look for INSERTs, where there is no such clear pattern to look for, as well as array formats for submitted forms, etc. In short I am not convinced that having a small number of these magic numbers disappear from core is what we should concentrate this close to a release. There are lots of places to introduce this if you aim for consistency.
Comment #12
pwolanin CreditAttribution: pwolanin commentedI don't think something as simple as 0/1 for FALSE/TRUE needs constants very badly.
I was thinking in terms of the menu system, about the use of "(1 = a disabled menu item that may be shown on admin screens, -1 = a menu callback, 0 = a normal, visible link)" in {menu_links}.hidden as a case where the code in menu.inc is confusing because of the magic -1/0/1 system
Comment #13
robertgarrigos CreditAttribution: robertgarrigos commented@Gabor, you are right. SQl queries should be changed also, just like comment.module does with comment status...
Comment #14
pwolanin CreditAttribution: pwolanin commented@robertgarrigos -- I thiink you are volunteering for a D7 node module cleanup. I think it would be foolish to undertake revising all those (working) queries and code at this stage for D6. I'd only weakly support doing it for menu.inc for the exapmle I cited for D6 just because that it much less obvious in what the "magic" numbers mean.
Comment #15
asimmonds CreditAttribution: asimmonds commentedI have a patch that I had done for the previous 5.x node constants issue as it was marked won't fix, so I had never got around to finishing and uploading it. That patch ended up being a 35KB patch (unfinished), and that's just for 5.x at the time, a current HEAD patch will probably be a bit bigger.
Comment #16
catchOk then.
Comment #17
Gábor HojtsyNote that comment module uses the status constants because it has status = 0 for published and status = 1 for unpublished, and it is rather unusual.
Comment #18
robertgarrigos CreditAttribution: robertgarrigos commented@powlanin: you are right at #12 and #14 but not that I'm volunteering (yet) ;-). theborg should say something about it first and assimmonds might almost have it.
Comment #19
theborg CreditAttribution: theborg commented@asimmonds: Sorry, I didn't know about your patch.
I don't like magic numbers and at least this is useful for documenting purposes. I changed some SQL queries on node, blogapi and ping modules, I will take a look at Gábor's #11 queries.
Also I added the 'promoted' and 'sticky' status to admin/content/node table for testing the changes, I will remove them if you don't like it but I think it's an interface improvement.
I volunteer to clean up the node and other modules from node magic numbers but I need to know if you plan to do it with all modules magic numbers at once.
Anyway, waiting for asimmonds comments on this.
Comment #20
theborg CreditAttribution: theborg commentedComment #21
Crell CreditAttribution: Crell commentedRe #17: In Drupal 7 we should probably just switch those around to be standardized and be done with it. Then we can use the same constants across the board.
Comment #22
lilou CreditAttribution: lilou commentedReroll to HEAD.
Comment #23
catchre: #17/#21 comment.module was fixed in a recent commit.
Comment #24
lilou CreditAttribution: lilou commentedExact : #237636: Comment status field should match node status field
Comment #25
recidive CreditAttribution: recidive commentedThese are not 'magic numbers'. node.sticky, node.published, node.promoted are (pseudo) booleans. You can read them as:
Is it sticky? Yes/No
Is it published? Yes/No
Is it promoted? Yes/No
What's wrong with that?
Unless you want to take on serious inconsistencies like comments (#17), I'm +1 to won't fix. All that I see on the patch is:
A_B = 1
A_NOT_B = 0
There are already the 'constants' TRUE and FALSE we can use for that.
Comment #26
sasconsul CreditAttribution: sasconsul commentedThe problem is the word "can" in the sentence, "You can read them as:"
Anything that is up for interpretation will be interpreted incorrectly at 3 am.
Stuart
Comment #27
webchick+100 kabillion for this.
Comment #28
webchickTagging as novice. Looks like this was pretty close before it fell off the radar.
Comment #29
Damien Tournoud CreditAttribution: Damien Tournoud commentedAn alternative implementation strategy for this would be (as discussed earlier), to simply remove the 3am - 4am timeframe, which is actually very bad for rolling core patches.
Comment #30
floretan CreditAttribution: floretan commentedAdded #428234: Use constants for block visibility. Same issue, but for block attributes.
Comment #31
robertgarrigos CreditAttribution: robertgarrigos commentedrerolled to HEAD. I left out the extra columns added by theborg at #19 in order to not interefere with actual interface works. If you are happy with this, I may add other constants found in other core modules, as this patch only acts on node module.
Comment #33
robertgarrigos CreditAttribution: robertgarrigos commentedsorry, I missed the patch :-)
Comment #34
lilou CreditAttribution: lilou commentedComment #35
pwolanin CreditAttribution: pwolanin commentedI really don't see this as helpful in terms of understanding the code. @webchick - why is this not a "won't fix"?
Comment #36
Crell CreditAttribution: Crell commented@pwolanin: You don't see how replacing undocumented magic numbers with named constants improves code readability?
Comment #37
recidive CreditAttribution: recidive commentedThey are not "magic numbers" but booleans, we can add schema support to booleans and change those table fields to booleans (optional) and change code to use TRUE/FALSE instead of 1/0 and ensure they are correct handled by db layer.
Comment #38
pwolanin CreditAttribution: pwolanin commented@Crell - no I really don't if the only possible values are 1/0
Comment #39
moshe weitzman CreditAttribution: moshe weitzman commentedWe have had great success replacing 1/0 with constants like COMMENT_PUBLISHED/COMMENT_UNPUBLISHED. This looks good. It isn't complete as far as i can tell, but once it is it is RTBC IMO.
Comment #40
chx CreditAttribution: chx commentedI tend to agree that booleans do not need constants and that comment had it backwads and there it's useful.
Comment #41
chx CreditAttribution: chx commentedHowever... if I remember correctly comments now are fixed and yet we kept the constants. I am unsure how to proceed... do we want to remove them, then?
Comment #42
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.