Currently, when users search on their Panopoly site, it'll only look inside fields on the node. It won't search any content added to the node via Panelizer, ie. with the "Customize this page" button.

This is surprising behavior, since to many users they don't care what's on a field and what's in Panelizer - it's all part of the same "page".

Here is a patch to Panelizer that allows Search API to index this content:

#2416505: Allow indexing content from "Full page override" with Search API

Now, all we need to is change panopoly_search to use this and write some Behat tests for it. I'm already working on this and will post a patch soon-ish.

CommentFileSizeAuthor
#3 panopoly_core-search-panelizer-2416505-3.patch600 bytesdsnopek
#2 panopoly_test-search-panelizer-2416525-2.patch2.59 KBdsnopek
#2 panopoly_search-search-panelizer-2416525-2.patch10.11 KBdsnopek
#1 panopoly_search-search-panelizer-2416525-1.patch9.67 KBdsnopek
#1 panopoly_core-search-panelizer-2416505-1.patch601 bytesdsnopek
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
Status: Active » Needs work
FileSize
panopoly_core-search-panelizer-2416505-1.patch601 bytes
panopoly_search-search-panelizer-2416525-1.patch9.67 KB

Ok, here are the functional patches (or at least the first iteration). I'm still working on the tests.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
Status: Needs work » Needs review
FileSize
panopoly_search-search-panelizer-2416525-2.patch10.11 KB
panopoly_test-search-panelizer-2416525-2.patch2.59 KB

Here is a patch to the tests to make sure this works! And some experimental changes to the panopoly_search patch to fix the update path which I had some trouble with on a test site.

Next I'm going run this on Travis-CI, which will further test the upgrade path...

EDIT: https://travis-ci.org/dsnopek/panopoly/builds/48806022

EDIT-2: Er, we actually want the upgrade tests: https://travis-ci.org/dsnopek/panopoly/builds/48806545

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
FileSize
panopoly_core-search-panelizer-2416505-3.patch600 bytes

Blergh! Drush make didn't like my panopoly_core patch. Here is a new version.

EDIT: Here's the new Travis link - https://travis-ci.org/dsnopek/panopoly/builds/48812650

cboyden’s picture

cboyden CreditAttribution: cboyden commented
Status: Needs review » Reviewed & tested by the community

This looks great. It's doing the right thing with fields of content items inserted as widgets: When those fields are displayed in the chosen view mode, they are indexed; if the field is not displayed, it's not.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
Status: Reviewed & tested by the community » Fixed

Thanks for testing! Committed. :-)

  • dsnopek committed f32c7aa on 7.x-1.x 
    Update Panopoly Core, Search, Test for Issue #2416525 by dsnopek: Allow...

Status: Fixed » Closed (fixed)

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

sethmac’s picture

sethmac CreditAttribution: sethmac commented

Great work dsnopek. Quick question...can you explain this block further:
// Force the current user to anonymous to prevent access bypass in search
// indexes.
$original_user = $GLOBALS['user'];
$GLOBALS['user'] = drupal_anonymous_user();

Is the index populated based on the view of the user that triggers the index to be rebuilt? How does this affect a site that only has 'authenticated' users and content? I've been under the impression that the Node access filter handles many of the node_access issues but realize that may not be the case when dealing with a rendered page from panelizer.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented

Is the index populated based on the view of the user that triggers the index to be rebuilt?

No, that bit of code forces the index to be built with an anonymous users view of the node.

How does this affect a site that only has 'authenticated' users and content?

So, if there is any data specific to a the user viewing the content, it won't get included in the index. Which is a good thing! By the same token, if there is content that will be hidden entirely if the user is anonymous, it won't get included in the index, which could be either good or bad, depending on what it is. Unfortunately, I'm not sure if there is a good heuristic to make that determination, so we just err on the side of including less data for security purposes.

I've been under the impression that the Node access filter handles many of the node_access issues but realize that may not be the case when dealing with a rendered page from panelizer.

It probably does provide filtering, so you won't be given results that you can't view at all. However, if there is a single Pane on the page you shouldn't have access to, then that needs to get excluded from the index too. Unfortunately, there is only a single blob of text in the index per-node, so it's the same no matter who is searching. That's why you want to make sure that no confidential data gets in there.

I hope that makes sense!