AWESOME - tested on my blog (still enabled) and the search and replace article is now first on the list when you search for the word replace

Feel free to check it in action on my blog

!!!! THANK YOU !!!!

I have tested this item ✅ successfully on 120cb8e

I have tested this item ? unsuccessfully on 120cb8e

In some cases I get an error (system message) "An error has occurred."

When I debug it it is

1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CASE WHEN LOWER(a.title) LIKE LOWER('%modulstil%') THEN 1 ELSE 0 END as priori' at line 1

It's thrown in this line: https://github.com/alikon/joomla-cms/blob/120cb8e84231a097482187faf613ffbcc8e262a3/plugins/search/content/content.php#L396

• "Search archived" is actice in plg_search_content.

• Search limit is set to 50.

• I don't have any archived articles.

• I searched for a word that exists in only 5 articles.

• So, somewhere during search in/for archived articles the database query fails.

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20197.}

I don't know if it helps. This is the whole $query:

SELECT a.title AS title, a.metadesc, a.metakey, a.created AS created, CONCAT(a.introtext,a.fulltext) AS text, CASE WHEN CHAR_LENGTH(a.alias) != 0 THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END as slug, CASE WHEN CHAR_LENGTH(c.alias) != 0 THEN CONCAT_WS(':', c.id, c.alias) ELSE c.id END as catslug, c.title AS section, '2' AS browsernav  CASE WHEN LOWER(a.title) LIKE LOWER('%modulstil%') THEN 1  ELSE 0  END as priority
FROM #__content AS a
INNER JOIN #__categories AS c ON c.id=a.catid AND c.access IN (1,1)
WHERE ((LOWER(a.title) LIKE LOWER('%modulstil%') OR LOWER(a.introtext) LIKE LOWER('%modulstil%') OR LOWER(a.fulltext) LIKE LOWER('%modulstil%') OR LOWER(a.metakey) LIKE LOWER('%modulstil%') OR LOWER(a.metadesc) LIKE LOWER('%modulstil%'))) AND a.state = 2 AND c.published = 1 AND a.access IN (1,1) AND c.access IN (1,1) AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2018-04-18 23:21:33') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2018-04-18 23:21:33')
ORDER BY priority DESC, a.created DESC

thanks, i've forgotten the comma

Looks like working here for Articles Titles priority when choosing only Articles in the filter.
If not using filters, then categories are displaying first (no priority to title there).

The ordering filter looks broken here.

Looks like working here for Articles Titles priority when choosing only Articles in the filter.

yes this is the fix, otherwise should work as before

to work with other filters too we need to discuss a little bit more before to submit a PR

I confirm that before patch the ordering filter is also broken here. Test Oldest first or Newest first when all filters on, or only categories.
It is working though (before patch) for articles only.

EDIT: looked at the categories plugin and remarked that ordering code is quite different

		switch ($ordering)
		{
			case 'alpha':
				$order = 'a.title ASC';
				break;

			case 'category':
			case 'popular':
			case 'newest':
			case 'oldest':
			default:
				$order = 'a.title DESC';
		}

while we have for content

switch ($ordering)
		{
			case 'oldest':
				$order = 'a.created ASC';
				break;

			case 'popular':
				$order = 'a.hits DESC';
				break;

			case 'alpha':
				$order = 'a.title ASC';
				break;

			case 'category':
				$order = 'c.title ASC, a.title ASC';
				break;

			case 'newest':
			default:
				$order = 'a.created DESC';
				break;
		}

(First time I look at that code. It explains all)

I have tested this item ✅ successfully on 157eb0c

This breaks expected ordering. It should be added as ordering option.

This breaks expected ordering. It should be added as ordering option.

Agree. As I stated above, ordering is broken otherwise.

If you consider broken ordering as expected then I feel sorry for your users

To make a new "relevance" ordering

• we would need to add some weighting calculation for the number of match words, because initially we were talking to keep this more basic and only check if all words were matched in the title

@alikon
Currently this PR needs a little fixing
When searching for "any" words, it only considers the last word for "priority"

I have made a PR to your branch to fix the above and also add weight calculation according to number of words matched, and then also added introtext to it beside title

(I know we said to do this only for title, but if this is made a new ordering case then it makes sense to add it)

from a quick read i would say, yes, of course, just give me some more free time to deal with this just another pandora box

If you want a weight calculation then just use finder. I just wanted to fix
a big bug not add a level of complexity

On 20 Apr 2018 8:20 pm, "Nicola Galgano" notifications@github.com wrote:

from a quick read i would say, yes, of course, just give me some more free
time to deal with this just another pandora box

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#20197 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Sm50U8nFOKxU0UKs0_VmtWI-d8Sks5tqjUFgaJpZM4TacYk
.

@alikon (commenting @brianteeman)

If you want a weight calculation then just use finder. I just wanted to fix a big bug not add a level of complexity

If it is decided not to add weight calculation (and not a new order) and only care for the title then only remove my suggested code for introtext, the rest of PR to your branch should be valid as it fixes this

When searching for "any" words, it (this PR) only considers the last word for "priority"

If you consider broken ordering as expected then I feel sorry for your users

You seem to misunderstand the issue? The expected ordering is whatever option is selected by the user. Newest First means newest items first, Most Popular means most popular items first and so on. Ordering by relevancy is fine but forcing it on another ordering option is not.

imho we have to much option, and this obviuos search ordering don't deserve another option setting
KISS

@ggppdk replayed on your pr again KISS for now

imho we have to much option, and this obviuos search ordering don't deserve another option setting

its fixing a bug not adding a feature. we dont add options to enable bugs ;)

its fixing a bug ? ..... so it's a new feature ? #marketing

thanks to @ggppdk the last reportedd bug should be fixed now
ping @infograf768 and others please re-test

I have tested this item ? unsuccessfully on 86bd9a1

note ('%\_content%'

  CASE WHEN LOWER(a.title) LIKE LOWER('%\_content%') THEN 5 ELSE 0 END  AS relevance,a.title AS title, a.metadesc, a.metakey, a.created AS created, a.language, a.catid,CONCAT(a.introtext,a.fulltext) AS text,c.title AS section,  
  CASE WHEN CHAR_LENGTH(a.alias) != 0 THEN CONCAT_WS(':', a.id, a.alias) ELSE a.id END as slug, 
  CASE WHEN CHAR_LENGTH(c.alias) != 0 THEN CONCAT_WS(':', c.id, c.alias) ELSE c.id END as catslug, '2' AS browsernav

  FROM axbz5_content AS a

  INNER JOIN axbz5_categories AS c 
  ON c.id=a.catid

  WHERE ((LOWER(a.title) LIKE LOWER('%\_content%') OR LOWER(a.introtext) LIKE LOWER('%\_content%') OR LOWER(a.fulltext) LIKE LOWER('%\_content%') OR LOWER(a.metakey) LIKE LOWER('%\_content%') OR LOWER(a.metadesc) LIKE LOWER('%\_content%'))) 
  AND a.state=1 
  AND c.published = 1 
  AND a.access IN (1,1) 
  AND c.access IN (1,1)
  AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2018-04-25 18:44:27') 
  AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2018-04-25 18:44:27')

  GROUP BY a.id, a.title, a.metadesc, a.metakey, a.created, a.language, a.catid, a.introtext, a.fulltext, c.title, a.alias, c.alias, c.id

  ORDER BY  relevance DESC,  
  LIMIT 50```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/20197">issues.joomla.org/tracker/joomla-cms/20197</a>.</sub>

@brianteeman
You were too fast, i missed proper concatenation on order clause, @alikon please merge PR

@brianteeman you are too fast for us .... ?

I have tested this item ✅ successfully on 77352d1

all good now and live on my blog

I have tested this item ✅ successfully on 77352d1

Ready to Commit after two successful tests.

woohoo - thanks everyone