Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I am noticing the following (with the latest 6.x-1.0-beta2, but can not confirm if everything was OK about that before...):
I have a non-sticky node. When I set (change) its weight through admin/content/node page, it somehow gets a sticky bit set (while through node/edit, the weight setting works OK).
In addition to the misbehavior as above, when I set the weight of a non-sticky node to 99 (through admin/content/node page), it looks like it was actually set to sticky node with weight 0 (values displayed on admin/content/node and node/edit, but obviously both wrong, as the value stored in a node table is 1 - I believe 1 shall mean a sticky node with weight of 99, or?!).
It looks like something is wrong with weight / stickyness logic (handling) somewhere, so be careful while changing the weight of your nodes (I've found quite some sticky nodes after manually setting the node weights recently...).
Probably the easiest way to see what is the actual situation (with the assumption that the current situation is not always displayed properly) is to check the node table. If I am right, the values shall be (according to the formula I've found in the code):
node 99 non-sticky: -199
node 0 non-sticky: -100
node -99 non-sticky: -1
node 99 sticky: 1
node 0 sticky: 100
node -99 sticky: 199
By the way, it would be nice to have some indication about a sticky / non-sticky flag on admin/content/node page - it would help in this case (to notice that the node status has changed while it shouldn't) and it would make it easier to have an overview about that (which nodes are sticky and which are not...).
I've almost forgotten - I've simply added the range up to 99 (-99 to 99), as the maximum up to 40 (-40 to 40) was not sufficient for my needs. But this shall probably not be the reason, as the ranges for sticky and non-sticky nodes are not overlapping... I have it like that since a few years ago now, and have never had any issue due to that up to now. Or, can this be a reason? If yes, why and how to correct it (I really need more than 80 node weights...).
Comments
Comment #1
nancydruOkay, first, you must not take the weight to 99. 98 would have to be the maximum, otherwise a node could look unweighted.
Comment #2
nancydruThe old double-encoding trick!!! Fix committed to both branches. You also get your sticky flag.
Comment #3
nancydruComment #4
luti commentedI see you've already fixed my issue (it seems to work well, altough after just a brief test).
Moreover, you've also added range up to 99.
A really big thanks, Nancy, you're great!
Comment #5
nancydruOops, I need to remove the 99. That's a bad value; I had it in there to test out what you were saying.
Comment #6
nancydruSorry, I put it back to 90 max. Even if you change it, do not go higher than 98, please, or you could cause yourself some problems.
Comment #7
luti commentedNancy, are you sure 99 can cause a problem? Because I using it for more than 1 year now, and have never noticed any issue...
In which situation exactly it could behave wrong? Because as in my initial post, ranges using also value 99 need sticky values between -199 and -1 and between 1 and 199, which are not overlapping or so... I have some nodes now with weight 99 and -99, and they all seem to be OK (such weight is displayed properly everywhere I've checked, can be changed to something else and back without a problem, and such a node is also displayed in its expected position...).
I really would like to avoid the change of all nodes which are 99 (or, -99) now, because it is not that easy (I have to change the whole weighting system of my nodes, and renumber a lot of them...).
Comment #8
nancydruYes, because when you subtract 99 from 100 you get 1, which looks like an unweighted sticky node.
Comment #9
luti commentedI see, you are preserving values 0 and 1 (a default behavior, without Weight module)...
Shall this mean that an unweighted non-sticky node (sticky value 0) is treated exactly as 0 weighted non-sticky node (which could / or does have normally a sticky value -100)? And, that an unweighted sticky node (sticky value 1) is treated exactly as 0 weighted sticky node (which could / or does have normally a sticky value 100)?
If yes, shall in a database be 0s and 1s when weight module is installed, but modules (module weights) were not edited? Or, shall there be values -100 and 100 for such modules? And, what happens if I edit the weight (change it to some non-zero value) and change the weight back to 0 after? Shall such a node get back value 0 or 1, or -100 or 100?
I mean, what is the purpose of preserving the values 0 and 1, if they can be represented with -100 and 100, when Weight module is installed? In case Weight module would have to be uninstalled, all sticky values shall be properly transformed back to 0 or 1 in any case, or? Or, is this not the case? As all weighted modules in such a case would be treated as sticky after Weight is uninstalled (by MySQL logic, that 0 means FALSE and any other - not only 1 - value means TRUE)?
And, if the only danger is that a sticky node with weight 99 will be treated as it has weight 0, I believe I can live with that at the moment (I have only a very few sticky nodes, which can have all of the values but 99; for me, bigger issue would be to narrow the range for non-sticky nodes, where I have quite some with weight 99, which can not be so easily converted into 98, as also this weight is already used, and it would go like dominoes in this case...).
Sorry that I bother so much about this, but I would really like to know what happens with weight and stickyness, as the order of nodes is sometimes very important for me (and, nodes shall be ordered manually, not by date and/or some other criteria Drupal provides by default, without a Weight module...) and I really wouldn't like to get some surprises about that in the future.
Comment #10
nancydruThere are several reasons why I would prefer to keep 0 and 1 as special.