?
Referenced as Related to: # 14164
avatar AndySDH
AndySDH
21 Feb 2017

Steps to reproduce the issue

  • Set up a Search Module
  • Give a fixed menu item ID for the Search Module
  • "Open Search Autodiscovery" option must be active (should be by default)

Expected result

  • The Open Search Autodiscovery module option should account for the Item ID that you set in those module options. When the "Open Search Autodiscovery" adds its link to the head of the page, it should respect the item ID setting set in the module.

Actual result

  • It doesn't respect it. Instead, it uses the current Item ID (the one that you are browsing) regardless of the settings, so it always changes based on the page you're in. This generates duplicate URLs.

System information (as much as possible)

Database Version 5.5.54-38.6-log
Database Collation utf8_general_ci
Database Connection Collation utf8mb4_general_ci
PHP Version 5.6.30
Web Server Apache
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 3.6.5 Stable [ Noether ] 1-December-2016 22:46 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0

avatar AndySDH AndySDH - open - 21 Feb 2017
avatar joomla-cms-bot joomla-cms-bot - labeled - 21 Feb 2017
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 5 Apr 2017

tried using Smart Search module with this Settings but don't get the Issue to understand. Can you please describe?

avatar franz-wohlkoenig franz-wohlkoenig - change - 5 Apr 2017
Priority Medium Very low
Status New Information Required
avatar AndySDH
AndySDH - comment - 5 Apr 2017

This does not refer to Smart Search (so not sure if this is an issue there as well or not), this refers to the normal regular Search module.

When you enabled this setting for the Search module, it adds the autodiscovery code to the head of the document.
The problem is that it contains the ItemID of the page that you're currently viewing, ignoring the fixed ItemID that you set. It should instead contain the fixed ItemID that you set in module settings (if it's set).

avatar brianteeman
brianteeman - comment - 5 Apr 2017

Indeed it is only regular search as there is no Open Search Autodiscovery available if using smart Search (there is an issue for that)

avatar brianteeman
brianteeman - comment - 5 Apr 2017

Looking at the open search link on my blog I can see that the itemid in the link is always that of the current page - exactly as you report
eg
<link href="https://brian.teeman.net/component/search/?Itemid=147&amp;format=opensearch" rel="search" title="Search Brian Teeman" type="application/opensearchdescription+xml" />
HOWEVER
When i try to use the open search then it correctly uses the Itemid set in the module of 149

https://brian.teeman.net/index.php?option=com_search&searchword=test&Itemid=149

avatar AndySDH
AndySDH - comment - 5 Apr 2017

Hello,
Yeah, that seems to work correctly, it's just the code generated in the head that it's wrong. But this causes duplicate URLs, for example when using sh404sef this causes to store duplicate URLs for every single ItemID. So the code generated in the head should be corrected too to be 100% precise.

PS: I added more information on this other ticket too: #14164 (which I don't have permission to re-open)

avatar brianteeman
brianteeman - comment - 5 Apr 2017

Sorry but this sounds like an issue in sh404 to me as I have shown that opensearch is working correctly in the core of joomla using the itemid specified in the module

avatar AndySDH
AndySDH - comment - 5 Apr 2017

The issue is not with sh404sef, the issue is that the wrong ItemID is generated in the head of the document by the module.
sh404 does its job, which is storing every URL that it's found on each page.
sh404sef sees the page and sees those URLs in the head of the document and stores them as duplicate. This is expected behavior by sh404, that's the whole point of what it does.

The problem is that those URLs with the wrong ItemID shouldn't be there in the first place :)
Only one URL with the fixed ItemID should be there.

avatar franz-wohlkoenig
franz-wohlkoenig - comment - 5 Apr 2017

reopened #14164

avatar franz-wohlkoenig
franz-wohlkoenig - comment - 27 May 2017

If this Issue get no Response, it will be closed at 22th June 2017.

avatar AndySDH
AndySDH - comment - 27 May 2017

Hello.
What response is needed?
The issue has been described in detail. It just needs fixing by who is concerned.

avatar franz-wohlkoenig franz-wohlkoenig - change - 27 May 2017
Status Information Required Discussion
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 27 May 2017

set Status back on "Discussion".


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/14163.

avatar AndySDH
AndySDH - comment - 26 Jul 2017

Hello, any update on this?

avatar brianteeman brianteeman - labeled - 25 Mar 2018
avatar franz-wohlkoenig franz-wohlkoenig - change - 19 Aug 2018
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2018-08-19 10:58:58
Closed_By franz-wohlkoenig
avatar joomla-cms-bot joomla-cms-bot - change - 19 Aug 2018
Closed_By franz-wohlkoenig joomla-cms-bot
avatar joomla-cms-bot joomla-cms-bot - unlabeled - 19 Aug 2018
avatar joomla-cms-bot joomla-cms-bot - close - 19 Aug 2018
avatar joomla-cms-bot
joomla-cms-bot - comment - 19 Aug 2018
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 19 Aug 2018

closed as having Pull Request #21713

avatar AndySDH
AndySDH - comment - 19 Aug 2018

Nice only 1 year and a half for a PR. Forgot about this myself.

avatar wilsonge
wilsonge - comment - 19 Aug 2018

Thanks for the patience :) I was doing a tracker cleanup and came across it

avatar franz-wohlkoenig
franz-wohlkoenig - comment - 19 Aug 2018

@AndySDH can you please test #21713?

avatar AndySDH
AndySDH - comment - 19 Aug 2018

Yep testing right now!

@wilsonge No worries man, thanks for taking the time to do it!

Add a Comment

Login with GitHub to post a comment