Index Page error with anonymous user

Other authenticated users can not access this module too with the same issue. It works for user 1 only.

I'm not good at PHP (only remember it from my school) so I'm not sure this is the way to fix it... but here is fast and dirty fix:

In function indexpage_page() there is a line:
$exist_type = @db_result(db_query('SELECT count(type) FROM {node} WHERE type = "'.arg(1).'"'.($access ? ' AND '.$access : '')));

I've changed it to:
$exist_type = @db_result(db_query('SELECT count(type) FROM {node} WHERE type = "'.arg(1).'"'));

It works fine for me now.

Actually, I think soupp's solution will prevent you from having proper access control. I'm totally new to Drupal and this is the first error I've gotten, first time I've looked at the code, but unfortunately there's some pretty bad abstraction going on here for reasons I don't understand. Be that as it may, the "na" is coming from the function that controls access parameters in the sql WHERE clause. This is found in node.module, line 1891

function _node_access_where_sql($op = 'view', <strong>$node_access_alias = 'na'</strong>, $uid = NULL) {
  <strong>if (user_access('administer nodes')) {</strong>
    return;
  }
  $sql = <strong>$node_access_alias</strong> .'.grant_'. $op .' = 1 AND CONCAT('. $node_access_alias .'.realm, '. $node_access_alias .'.gid) IN (';
<em><snip></em>
  return $sql;

So you can see why it is not a problem for the admin - the function returns without effect if the current user can administer nodes. In the other case, though, it attaches the $node_access_alias.

The problem is that this function is apparently intended to be used with function _node_access_join_sql

function _node_access_join_sql($node_alias = 'n', $node_access_alias = 'na') {
  if (user_access('administer nodes')) {
    return '';
  }
  return 'INNER JOIN {node_access} '. $node_access_alias .' ON '. $node_access_alias .'.nid = '. $node_alias .'.nid';
}

Since this is all procedural, though, there's nothing to require that the two get used together (that's what I mean by bad abstraction). This is hte case in the indexpage.module. Since there is no INNER JOIN, there is no alias.

The Quick Hack

The quick hack is simply to add another table to the FROM clause, though this might cause issues for the admin b/c the table won't be mentioned in the WHERE clause.

In any case the query needs to get updated like so

$exist_type = @db_result(db_query('SELECT count(type) FROM {node}, {node_access} na WHERE type = "'.arg(1).'"'.($access ? ' AND '.$access : '')));

This is probably not the best solution, but it seems to work okay.

Hmm... I don't seem to be able to edit my post. Sorry about the sidescroll caused by the <pre> tags

Argggh. Sorry for the spam. I just wanted to say that when I say "there's some pretty bad abstraction" I'm talking about the access routines in the nodes module, not the indexpage module, which is just using that. Still far from seeing the whys and wherefores of Drupal as I'm just now checking it out. I didn't mean to come off ungrateful or anything.

thanks rick_deckard. that worked for me (admin seems to have no problems with it either)
+1 to this patch getting included in the next release of the module.

Great work!! Everything looks like working fine, thx again Robert :D

I am having this problem, as well, and I'm not an advanced programmer, so I need an easier solution. I have granted permission to everyone to view indexpages, but users are getting:

index page for story
ERROR: That node type doesn't exist, there are no entries, or the index page for this node type is disabled.

I'll keep searching here for help, if I can't figure it out, I'll just remove the story module or disable it.

Thanks for any help.

Doug

Thanks Rick,

Worked like a charm!

esto es una prueba

Can you please speak english here? I have no idea what you said and why you changes the bug details.

"esto es una prueba" translates to "this is a test".

As for why the issue has been changed from pertaining to the "IndexPage" module to the "location" module, I am not sure. That must be a mistake. Switching project back to "IndexPage". Get off my queue, issue!

-Ankur

Thanks to this patch, now it runs right.

To those who are scared about programming, the only thing that they have to do is open the indexpage.module file with a text editor, find the $exist_type setence and replace the line. Save it, and upload. And the problem will be solved.

Thanks for your help.

gr8 patch thanks

Thanks for the simple directions webmestre@www.coll-vallcarca.net. I can now use Indexpage module again.

I tried the hack with no luck. I still get the same error for unregistered users. I like IndexPage and would like to use but will be unable to if I can't get this problem resolved.

I got it to work. For those like me who tried the hack and found it did not help, deactivate the module and reactivate it from the Admin-->modules page. It works fine now. Thanks for the hack.

PLEASE can someone incorporate these patches into the main code? Do we have to wait for someone? Can someone else take over CVS responsibility?

I had the same problem with indexpage module, and before I saw this thread, I came up with a solution that worked. Basically it uses the _node_access_join_sql function to add the node_access table to do the join

Can someone please tell me if this patch is right? I mean, it resolved the problem, and it works fine now, but it is ok to use the _node_access_join_sql function here?

Thanks

--- indexpage.module.old        2006-06-12 16:30:22.000000000 -0500
+++ indexpage.module    2006-06-12 16:41:20.000000000 -0500
@@ -72,8 +72,9 @@
     print theme("page", $output);
   }
   else {
+    $join = _node_access_join_sql();
     $access = _node_access_where_sql();
-    $exist_type = @db_result(db_query('SELECT count(type) FROM {node} WHERE type = "'.arg(1).'"'.($access ? ' AND '.$access : '')));
+    $exist_type = @db_result(db_query('SELECT count(n.type) FROM {node} n '.$join.' WHERE type = "'.arg(1).'"'.($access ? ' AND '.$access : '')));
     if ($exist_type && variable_get("indexpage_".arg(1)."_enable", 1)) {
       if (!arg(2)) {
         indexpage_page_index(arg(1));

Really strange, yes. I will commit the solution proposed by rick_deckard, and I note it for investigate.

Thanks a lot!