Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kblanch09’s picture

For example, here is one of my views not showing up: http://library.umassd.edu/find/articles-databases

If I search for Articles & Databases logged in, I can see it. However, if im logged in as someone else (same role) or not logged in at all, I can't see it in the search results.

I have tried re-indexing my site, but still no luck

jhodgdon’s picture

Hm. I am guessing when you say "same role" that maybe the user who is logged in is user ID 1, and that is the only person who can see the Views page in search results.

Anyway, let's see what the Search by Page code is doing here. In sbp_paths.module, in sbp_paths_sbp_query_modify(), it does, basically:

    $parts = search_by_page_path_parts($item->page_path);
    $mitem = menu_get_item($parts[0]);

And then it removes the path from the search query if $mitem['access'] is FALSE.

That seems like the right thing to do, and it normally does work with Views pages. The function search_by_page_path_parts() resolves any path aliases, so that we're looking at the real system path for the URL, and then the [0] gives you the part of the path before any GET arguments (? and & suffixes). Then menu_get_item() is a Drupal core function that looks up the system path and checks access. All of this is the same thing that (at least normally) is done when someone requests a URL in their browser.

Hmmm... Here are some things to check, so we can hopefully figure out what is happening:

a) In the View, if you look at the "Access" section for this display, what do you see for the settings?

b) Are you using some method of controlling access permissions for this site, which is overriding the control Views and Drupal Core normally would give you?

c) Is the path find/articles-databases an alias, or is that the actual path set in the View settings?

kblanch09’s picture

Yes, the user that I created the sbp paths with is user ID 1.

a) For the views settings, I have the Access set to Permission | View published content. And then in my permissions for the site, I have everyone as being able to View published content.

b) I am using Content Access and Block Access on the site. But I believe those are just for nodes and blocks, not views.

c) No, find/articles-databases is not an alias. It is the path set in the view.

It is very strange how some of the views do show up in the search results and some do not. For example, http://library.umassd.edu/about/calendar is also a view with the same access permission and that shows up in the search results if you search Calendar

jhodgdon’s picture

Yes, that's very odd. So... User 1 bypasses all access permission checking, and it doesn't exactly surprise me that user 1 would be able to see certain things in search results that other users cannot see.

And I agree that Content and Block access modules shouldn't be doing anything weird to the Views permissions.

Also, if you have some views that are showing up for other users and some that are not, and they have the same permissions, then I don't know what to tell you. ??? Very odd. Sorry, I do not have any ideas right now.

kblanch09’s picture

I noticed that i'm getting a PDOException which might have something to do with the problem.

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'page_data' at row 1: UPDATE {sbp_path} SET page_data=:db_update_placeholder_0 WHERE (pid = :db_condition_placeholder_0) ; Array ( [:db_update_placeholder_0] => <h1>Sociology - Anthropology Videos</h1> <div class="region region-content" ... iv><!-- /.region --> [:db_condition_placeholder_0] => 303 ) in search_by_page_update_index() (line 864 of modules/search_by_page/search_by_page.module).

jhodgdon’s picture

Huh, that's odd. The page_data column in that database table is of type "text", which should hold a *lot* of data... let's see. It looks like it is up to 65,515 characters.

The entire page source of your page looks like it is 35,108 characters, and not all of it should be in the index (no headers, etc.)... But that is possibly the problem. In your database, you could try changing it to MEDIUMTEXT, which would give you 17M.

I don't know why that would give you different search results for user 1 vs. other users though.

jhodgdon’s picture

Category: Bug report » Support request
Status: Active » Fixed

Are you still having this problem? At this point I'm going to mark it as a support request and assume that you either found the problem or stopped using the module, since you didn't respond to my last query.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

pcorbett’s picture

We seem to be getting a similar error to #5 using search_by_page version :

PDOException: SQLSTATE[22001]: String data, right truncated:    [error]
1406 Data too long for column 'page_data' at row 1: UPDATE {sbp_path}
SET page_data=:db_update_placeholder_0
WHERE  (pid = :db_condition_placeholder_0) ; Array
(
    [:db_update_placeholder_0] => 

I would agree that the "text" format does afford 65535 characters max and the data we're trying to store looks to be max of 8000 characters, so I would expect this DB error not to be thrown.

jhodgdon’s picture

Title: Only some views show up in my search results » Only some views show up in my search results (PDO exception)
Status: Closed (fixed) » Active

Can you look at your MySQL database and verify that the "page_data" column in the "sbp_path" is of type "text"? You could also try changing it to "mediumtext", as suggested in #6. ... maybe some MySQL setups have different size limits for "text"? I am not sure... actually are you using MySQL or another database?

pcorbett’s picture

Correct, it's "text" and MySQL. Will adjust to mediumtext and report back.

pcorbett’s picture

Setting to mediumtext works. Not sure why it thought it was too big, however. Most I could see the data being passed into the column was 8,000 chars. May I suggest adjusting the .install to set that col to mediumtext?

jhodgdon’s picture

Title: Only some views show up in my search results (PDO exception) » PDO exception when some pages are indexed (needs larger database field)
Component: Search by Page Paths module » Main Search by Page module
Category: Support request » Bug report

Yes, I guess I could change that. It doesn't seem to affect many people and I think it might increase the database size for everyone, but these days that isn't much of an important factor. So it's probably a good idea.

Changing this to a bug report accordingly.

Bertjuh’s picture

"It doesn't seem to affect many people"

If you are still unsure if you should change the .install I thought I'd just let you know that I also had this problem.

jhodgdon’s picture

OK, I'm convinced! I'll get it done at some point -- thanks for the reports.

Meanwhile I guess it's fairly easy for people with this problem to find this issue (hopefully) and make the fix in their own database.

Coen van Vliet’s picture

In the meantime i have tried to create a patch for the install that will hopefully help some of you out.

jhodgdon’s picture

Thanks! That will work for people who haven't installed the module yet. I'll need to also make a hook_update_N() function for people who already have it installed.

wolcen’s picture

Hi. Since I ran into this as well, I just wanted to offer another patch with a separated update hook. Though the prior patch works, it does so only if you hadn't run 7003 already. Hopefully, the two assumptions this patch makes are correct. The first I just mentioned, the second: I moved the update of lastindextime down to avoid two messages when both updates are necessary, and also because lastindextime should have been set since search_index is called on line 859. Thanks for the module - it was just what we needed!

jhodgdon’s picture

Thanks! I'll take a look... though realistically it may not be soon, sorry. Pretty busy right now. Glad that everyone can at least keep working -- I do plan to add something very much like one of the patches here to the module sometime soon.

Jessica.K’s picture

Ran into this issue recently as well, long bit of content that still should have been short enough for the column was triggering PDO on indexing. Applied #18 and after reindexing the site, no errors. Seems to have worked!

  • jhodgdon committed f3c4b71 on 7.x-1.x
    Issue #2227765 by wolcen, coenvanvliet, kblanch09, pcorbett, Bertjuh,...
jhodgdon’s picture

Status: Active » Fixed

Oh sorry, forgot about this! Added to the -dev version of the module.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.