Issue: VW messing up the Elastic Search URL

Issue Tools
- View Changes

July 17, 2017 6:17 PM

Alfa1

Distinguished Member

VW messing up the Elastic Search URL

If I search from the XF search box, then search URLS have changed to:
https://forum.com/search/179392/?q=s...&o=relevance&c[p][vwcomment][areaid][0]=0&c[p][vwcomment][areaid][1]=0&c[p][vwcomment][areaid][2]=2&c[p][vwcomment][areaid][3]=6&c[p][vwcomment][areaid][4]=17&c[p][vwcomment][areaid][5]=4&c[p][vwcomment][areaid][6]=7&c[p][vwcomment][areaid][7]=8&c[p][vwcomment][areaid][8]=5&c[p][vwcomment][areaid][9]=16&c[p][vwcomment][areaid][10]=3&c[p][vwcomment][areaid][11]=9&c[p][vwcomment][areaid][12]=10&c[p][vwcomment][areaid][13]=11&c[p][vwcomment][areaid][14]=12&c[p][vwcomment][areaid][15]=13&c[p][vwcomment][areaid][16]=14&c[p][vwcomment][areaid][17]=15&c[p][vwcomment][areaid][18]=18&c[p][vwcomment][displayorder]=0&c[p][vwpage][areaid][0]=0&c[p][vwpage][areaid][1]=0&c[p][vwpage][areaid][2]=2&c[p][vwpage][areaid][3]=6&c[p][vwpage][areaid][4]=17&c[p][vwpage][areaid][5]=4&c[p][vwpage][areaid][6]=7&c[p][vwpage][areaid][7]=8&c[p][vwpage][areaid][8]=5&c[p][vwpage][areaid][9]=16&c[p][vwpage][areaid][10]=3&c[p][vwpage][areaid][11]=9&c[p][vwpage][areaid][12]=10&c[p][vwpage][areaid][13]=11&c[p][vwpage][areaid][14]=12&c[p][vwpage][areaid][15]=13&c[p][vwpage][areaid][16]=14&c[p][vwpage][areaid][17]=15&c[p][vwpage][areaid][18]=18

Something is going wrong there.
Please test on my live site.

Issue Details

Issue Number 5177

Issue Type Bug

Project VaultWiki 4.x Series

Category Search

Status Fixed

Priority 5 - Minor Bugs / Small Tweaks

Affected Version 4.0.18

Fixed Version 4.0.20

Milestone (none)

Software DependencyXenForo 1.x

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

August 6, 2017 8:55 AM

Alfa1

Distinguished Member

Could you provide a fix for this one?

Reply
August 6, 2017 1:25 PM

pegasus

VaultWiki Team

The extra URL information you see is a list of VaultWiki search criteria (the list is generated by VaultWiki - a list of wiki nodes that the user has permission to search), which XenForo uses to get search results and stores in the database's criteria field for a search. This information is necessary in order to perform a valid search, as without criteria, the search would return all content as results. You WANT VaultWiki to set criteria; if it didn't, search would be meaningless.

It appears that this information is added to the URL with or without Elastic Search, as long as an Advanced Search is performed. This only occurs on your site during a normal search-box+Enter, because of an Auto-Complete function you have added which uses the Advanced Search URLs (formed via XenForo_ControllerPublic_Search::rerunSearch) for a simple search.

XenForo adds other (non-VaultWiki) criteria (keywords, order, etc) to the URL for every search, simple or not.

I would argue that this is a bug in XenForo. In XenForo, when a search is performed, it includes the criteria in the Advanced search results URL in case the user wants to use the Search Again option on the next page using the same settings. However, the criteria is not needed in the URL, because the search ID is already in the URL and the search ID can be used to lookup the criteria from the database; even for a based-on URL (the link used by Search Again), it is feasible to pass the original search ID as a parameter and lookup the original search criteria that way in order to prepopulate the Advanced Search.

I would say that if this issue really bothers you, you should ask the XenForo devs to remove criteria from the search results and search-again URLs (see previous paragraph). However, they may have a good reason for having it there, such as allowing the search-results URLs to remain functional after they have expired.

Reply
August 6, 2017 8:39 PM

Alfa1

Distinguished Member

No other addon adds content to the url for categories. The permissions are simply checked in the background. For example:
/search/208556/?q=postcard&t=xengallery_media&o=relevance
Vaultwiki should do the same.

As you mention the autocomplete function, is it not a conflict with this addon: https://xenforo.com/community/resour...sentials.4801/

Reply
August 7, 2017 7:33 AM

Alfa1

Distinguished Member

Please see: https://xenforo.com/community/thread...4#post-1164256
Additionally: after inspection of the code this is a bug in vaultwiki that is exposed by the elastic search enhancement addon.

Reply
August 7, 2017 12:14 PM
pegasus

VaultWiki Team
Since the behavior of filterConstraints is extremely vague in the XenForo documentation:

Allow type-specific pre-constraint application filtering. For example, a "thread only" constraint may change the searchable content types.

This makes it seem like filterConstraints is used in a scope where input-constraints are not yet available (which would be earlier than the input, suggesting the input will be appended to the same $constraints and that all will appear in the URL).

Additionally, filterConstraints is never actually used in default XenForo in a way that would suggest that it is the "correct" method of applying constraint default-values vs getTypeConstraintsFromInput when the constraint is omitted from input or otherwise invalid or that would provide a noticeable example of how it affects the results-URL.

For this report, the code in question only runs under Advanced Search of Wiki Pages, which in normal operation includes this constraint in the form and actually passes as input, so this report is treated as an improvement request rather than a bug. Even though the result of an unmodified wiki-pages advanced search is an ugly results URL, again, XenForo did not document that filterConstraints would keep default constraint values out of the URL, so this is an improvement rather than a bug.

As such, the severity of this is very minor, and this will be fixed in the next release rather than a new build.

In library/vw/XenForo/Search/DataHandler/Base.php, find:

Code:

$areaids = vw_Hard_Core::model('Search')->conform_areachoice($ctrl->get_value('areachoice'), !empty($params['children']));

Replace with:

Code:

if (!empty($do_children)) { $constraints['area_children'] = true; } $areaids = $ctrl->get_value('areachoice'); if ($areaids) { $constraints['areaid'] = $areaids; }

Find:

Code:

public function processConstraint(XenForo_Search_SourceHandler_Abstract $sourceHandler, $constraint, $constraintInfo, array $constraints)

Before it, add:

Code:

public function filterConstraints(XenForo_Search_SourceHandler_Abstract $sourceHandler, array $constraints) { if (!isset($constraints['areaid'])) { $constraints['areaid'] = array(); } $constraints['areaid'] = vw_Hard_Core::model('Search')->conform_areachoice($constraints['areaid'], !empty($constraints['area_children'])); return $constraints; }
Reply
August 7, 2017 1:03 PM

Alfa1

Distinguished Member

Thanks!

Reply
August 7, 2017 8:40 PM

Alfa1

Distinguished Member

library/vw/Search/
this does not exist.
This should be:
library/vw/XenForo/Search/DataHandler/Base.php

Reply

+ Reply

All times are GMT -4. The time now is 6:45 PM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: VW messing up the Elastic Search URL

Issue Tools