I have a very weird problem with this module.

As soon as i install the module, the order of nodes on the frontpage is reversed. When i deinstall the module, everything is back to normal.

Case module not installed:
The newest nodes are showed first on the frontpage. For both authorized and anonymous users.

Case module installed:
For authorized users the oldest nodes show first on the frontpage...
For anonymous users the newest nodes show first on the frontpage.

Comments

deekayen’s picture

Status: Active » Postponed (maintainer needs more info)

That is very strange indeed since I can't think of anywhere this module would alter the order of data display. Not really sure what to do about this one - obviously as maintainer I use the module, but I haven't seen this behavior before. Please tell me there is something else special about your configuration that would give a hint of what's the cause.

deekayen’s picture

Priority: Normal » Critical

http://drupal.org/node/250493 says it also breaks sticky. Now that there's two reports of it, I guess that makes it a little harder for me to assume it's a stray event. Is there an easy way for you to post the other modules you have installed (maybe it'll help me reproduce it)?

dkreviews’s picture

As I mentioned in my post I didn't know which module caused this issue, so I tried uninstalling other modules, untill I uinstalled this one. Then I installed clean database with new build of 6.2 and just that module and posted a few Stories, they all apear in the order they are submitted (oldest first...), changing revision dates did not have any affect, and sticky option also did not stick anymore. I really hope you can fix this ASAP. This is a perfect module for my needs.

I've been able to reproduce that several times by installing only 6.2 and that module and rebuilding permissions.

deekayen’s picture

I need help reproducing this. Here is what I did:

  1. Install Drupal 6.2
  2. Copy over npbr to mods directory
  3. Create a page node
  4. Activate npbr
  5. Rebuild permissions
  6. Add role with view content permission
  7. Create two test users - one authenticated, one with new role
  8. Edit node 1, publish to front page, give uid2 view, uid3 edit
  9. Logout
  10. Anonymous cannot see node 1 on front
  11. Login as uid 2, can see node, but not edit
  12. Login as uid 3, can see node and edit
  13. Login uid 1, create story, give uid 2 view, uid 3 view, edit, delete, publish to front, and make sticky
  14. Login uid 2, story 2 is on top
  15. Login uid 3, story 2 on top and edit available
  16. Login uid 1, create page node, uid 2 view, uid 3 view, edit, delete, publish to front
  17. Rebuild permissions
  18. Login uid 2, story 2 on top, page node 2 second, page node 1 on bottom
  19. Login uid 3, same display, but can edit
  20. Repeated for the poll, book, and forum modules
  21. Installed cck 6.x alpha 1
  22. Created a new content type with one text field, set default permissions same as above (note the above content types had blanks for default npbr permissions)
  23. Create a test cck node, leave the default permissions untouched, publish to front
  24. uid 3 still sees the story node sticky on top, with the nodes listed on front page newest first to oldest
  25. Rebuild permissions and still not reversed

That seems to be the expected functionality. Please give a variation that breaks the output.

dkreviews’s picture

I will try again and give you repro steps

pozdneev’s picture

Dear maintainer,
I have the very same problem: node_privacy_byrole causes front-page nodes to be shown in the order of creation (oldest first), not in the order of date specified in "Authored on". Sticky nodes are stuck between ordinary nodes, but not at the top of the page. However this is only the case for the zeroth user!
Other authorized users can see front-page nodes in the right order (including sticky ones on the top of page). But they can also see the standard Drupal Welcome message on the last page...
The view is correct only for unauthorized users!

deekayen’s picture

Maybe that's the trick then. I tried with a bunch of logged in users. I guess I can somehow vary anon.

deekayen’s picture

Category: bug » support

I've tried now with several different node types concentrated at looking at the anonymous view of <front>, but have not reproduced either the ordering or sticky problem. I'm still having a hard time believing this bug is even caused by node privacy byrole since I can't think of a single instance where it could mess with node ordering, only permissions, and that's not a real-time page load thing since node_access() just processes what it finds from what npbr saved during the node save.

I'm switching this to a support request and asking those who have reported this issue to post a list of other modules you're using. Taxonomy Access Control is a known conflicting contrib module; maybe there are others.

pozdneev’s picture

I previously reported above on my problems.
I have some minor news. After exporting database (MySQL; using phpMyAdmin) from the site with the problem and importing it to the new empty database on my local machine I found that the order of front-page nodes for superuser is now OK (including sticky ones)!

(other authorized users still can see Welcome Drupal message as the "last front-page"; and everything is OK for anonymous users)

Unfortunately, I can't reproduce the problem from scratch... But for debug purposes I could send my database (~400 KB) to maintainers.

tomsolo’s picture

Issue still live.

I tested on 2 OS (Windows and linux).
Windows clear work, but move site to Linux , have issue.

INSTALLED Modules:

CAPTCHA 6.x-1.0-rc2
Con.: CAPTCHA, Image CAPTCHA

FCKeditor - WYSIWYG HTML editor 6.x-1.2-1

Internationalization 6.x-1.0-beta1
Con.: Content Types, Internationalization, Multilingual Menu, Multilingual taxonomy, Mutilingual Blocks, Strings, Translation Synchronization

Image 6.x-1.0-alpha2
Con.: Image, Image Gallery, Image Import

IMCE 6.x-1.0

IMCE Mkdir 6.x-1.x-dev (2008-máj-13)

Node privacy byrole 6.x-1.1

Preferred Format 6.x-1.x-dev (2008-már-27)

Thickbox 6.x-1.x-dev (2008-máj-16)

Views 6.x-2.0-beta4
Con.: Views, Views UI

Webform 6.x-2.0-beta6

WordPress Comments 6.x-1.0

Enviroment: (Win and Linux shame)

Access to update.php Protected
CAPTCHA Already 6 blocked form submissions
Configuration file Protected
Cron maintenance tasks Last run 35 min ago
You can run cron manually.
Database updates Up to date
Drupal core update status Up to date
File system Writable (public download method)
GD library bundled (2.0.28 compatible)
Image module directories Exists (_files/images)
Image toolkit The gd toolkit is installed
Module and theme update status Up to date
MySQL database 4.1.21
PHP 4.4.4
PHP memory limit
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Web server Apache/1.3.37 (Unix) mod_choke/0.06
Os: Linux

tomsolo’s picture

Status: Closed (won't fix) » Postponed (maintainer needs more info)

Okay, i digged this problem. -> http://drupal.org/node/79217

Seem its a MYSQL bug under linux. Affected version 4.1.21 and 5.0b. see-> http://bugs.mysql.com/bug.php?id=21456

Solutions here -> http://drupal.org/node/79217#comment-437295 and or (recommended) upgrade mysql server

I tested onionweb's node fix too and work...

deekayen’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Good find! To the rest of you, upgrade your MySQL server.

Status: Postponed (maintainer needs more info) » Closed (won't fix)