[5.2] Adding ID search to the Articles and modules manager without the [id:] suffix

[korenevskiy]

Added the ability to search by ID in the search field in the materials, categories, fields and modules manager without using the id: suffix.

In the process of working with content, you have to return to the articles for re-editing. We have to repeatedly use the ID to search. Since we often use articles with the same names. It is useless to search for an article by name. Our articles are in different categories. One article is the news about the publication, and the other article is the publication itself. Bad or good, we will not discuss it, I will say that it had to be done because of the lack of multicategories. Perhaps using tags as a category will solve this problem in the company.
Even if there were no duplicate articles, then in our company we also constantly re-edit articles.
Writing ID:1243 in the search field every time is tedious.

We know that the search services Google, Bing do not ask us, for example, about the file extension when searching in pictures, we just write the name and extension PNG in the search. After that we get some pictures with a translucent background. That's enough for us.

My add-on doesn't break the search at all. And only expands it for convenience. If there is at least one word or letter in the search, the result will not contain material with this ID, but if there is only a number in the field, then we will see as a result materials containing this number in the name of the material that has this ID.

Perhaps it will interfere with someone. But it will be 1% of users. While 99% of users will benefit from this fix.

Search additionally with ID

Search additionally with ID

Search as it was before.

[brianteeman]

This is obviously incomplete

[korenevskiy]

This is obviously incomplete

Do you mean about the bad description of PR?

[brianteeman]

[korenevskiy]

@brianteeman
I know that. I suggest making the search a little more intelligent. I can suggest that the script checks that only numbers are written in the field.
Because it is painful to search for an article every time to write the suffix ID: in it.

[brianteeman]

I was telling you what was missing from this PR to make it complete ;)

Not that I agree with you that this PR is an improvement

[korenevskiy]

I was telling you what was missing from this PR to make it complete ;)

Please repeat briefly what is missing. I can't find where you talked about what's missing.
It's not like #28311

[brianteeman]

#39966 (comment)

If you change the code then you need to change the string. Otherwise people will still type id:

[korenevskiy]

2. Maybe we can extend the check so if a number/search string is in Quotes (") not to search for the number.

My version of the clarification was as follows. it is necessary to count the number of words in the search and the number of digits, if the number matches, then search in ID, if the number of words and digits in the search is different, then search as before.
But, on the recommendation of the discussion, I deleted this option.

array_filter() Indeed, it excludes elements that return 0, BUT!, if we return a value as a string in a nested function. This way Everything will work.

[korenevskiy]

Back to pending

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

I have added ID search for these components

• users (and groups, notes, levels)
• messages
• menu (items, types)
• mails
• Banners (Contacts )
• News Feeds
• Languages
• Guidedtours
• Privacy
• Actionlogs
• Workwflow
• Scheduler
• Templates
• Redirect

[korenevskiy]

1. Please move the array_fillter code block to the ArrayHelper method in the v3.0 in the framework

@HLeithner
I wanted to move array_filter to Array_Helper. But since this class has a broader purpose. I was forced to completely rewrite the array_filter() code.

I can put this in the FrameWork

	public static function filterNum($array = [], $onlyPositive = true){
		
		$new_array = [];
		
		foreach ($array as $i => $val){
			$type = gettype($val);
			$val = trim($val);
			if($onlyPositive && is_numeric($val) && $val >= 0 ){
				settype ($val, $type);
				$new_array[$i] = $val;
			}
			elseif(is_numeric($number)){
				settype ($val, $type);
				$new_array[$i] = $val;
			}
		}
		
		return $new_array;
	}

And in components to support ID, you would have to write like this.

            // Search by ID without the prefix ID:, used numbers from the search.
           $ids        = Array_Helper::filterNum(explode(',', $search));

            if ($ids) {
                $query->orWhere($db->quoteName('a.id') . ' IN (' . implode(',', $query->bindArray($ids)) . ')');
            }

[korenevskiy]

I think that the com_finder and com_extension components
should be tested more thoroughly.

[korenevskiy]

@HLeithner , I created a PR by ArrayHelper.

joomla-framework/utilities#43

[izharaazmi]

Instead of putting it in ArrayHelper I would prefer something like this:

namespace Joomla\CMS\MVC\ListFilter;

class KeywordSearch
{
	public static function toIds(string $text): array
	{
		if (!preg_match('/^[0-9, ]+$/', $text))
		{
			return [];
		}

		$parts   = preg_split('/[,\s]+/', $text);
		$numbers = [];

		foreach ($parts as $part)
		{
			if (is_numeric($part) && $part >= 0)
			{
				$numbers[] = (int) $part;
			}
		}

		return $numbers;
	}
}

var_dump(KeywordSearch::toIds('123, 32, 0 32 43'));

// array(5) {[0]=> int(123) [1]=> int(32) [2]=> int(0) [3]=> int(32) [4]=> int(43)}

var_dump(KeywordSearch::toIds('category 123'));

// array(0) {}

On a side note, I would now exclude 0 values as it is not a valid record ID

[korenevskiy]

Instead of putting it in ArrayHelper I would prefer something like this:

You have combined 2 tasks into 1. 1.Splitting a string into an array. 2. Filtering the array. In principle, combining 2 tasks is useful. But it is useful for internal calculations. And the use of the helper class has a wider use in different places. It may turn out that you just need to filter the array without dividing the string into an array. So I suggested a simple filtering method.

Another question is the intuitiveness of the code. How would an average programmer write code.

KeywordSearch::toIds($str);

or

ArrayHelper::filterIds(explode(',',$str)); //or ArrayHelper::filterNum()

I would use only the second option. Although the first one is shorter, but it's not intuitive for me.

BUT, Let's discuss this in the PR Framework. joomla-framework/utilities#43

[izharaazmi]

I agree to your explain, and I will do the same in a common scenario.

However in current use case it is not about one task or combination of two. It simply serves one single definitive purpose - extract IDs from keyword search.

[korenevskiy]

However in current use case it is not about one task or combination of two. It simply serves one single definitive purpose - extract IDs from keyword search.

@izharaazmi Your example is very good. In the sense that it filters integer values without floating point. And so on. I'm not so good at regular expressions, I know how to put a * sign. But we need, in theory, to filter only integers. You should have emphasized this in the description of your function. But your function would be more useful exclusively only in the code of this PR. In fact, both functions are equally useful in the FrameWork.
I would suggest calling your function like this

StringHelper::toArrayFilteredNumeric($text);

This will allow only integers to be taken into account.

[HLeithner]

This pull request has been automatically rebased to 5.1-dev.

[korenevskiy]

Why is this PR not included in Joomla 5.1 alfa?

[HLeithner]

This pull request has been automatically rebased to 5.2-dev.

[rdeutz]

We discussed this again and still don't like it, we understand where you are coming from but this is the bachend of a CMS and not something like Google.

[korenevskiy]

@rdeutz You're right, it might be unnecessary. But please tell me if there was a suggestion to use the setting so that you can turn this feature on or off in the settings panel. In general, this should be turned off by default.
Has this topic been discussed? Suggest this solution for those who are against it.
In general, there may be a political justification for such a decision. But even English-speaking users will not be able to use the prefix ID:. Only developers use it. But developers have no localization boundaries.

[korenevskiy]

@rdeutz Also, the explanation that Joomla is not Google is a very dubious explanation. It becomes clear when you start thinking about it for a long time. So you can explain anything, for example, "a person does not need to wash at all, because when a person sits in the water for a long time, his skin becomes inflamed." I.e., explaining useful innovations with extremes suggests that this serves to lead participants away from the real reason for the ban.
You should think about it.

[korenevskiy]

Show these messages to the participants, let them discuss the new idea with the settings panel.

[brianteeman]

You are completely wrong that only developers use this. I observed a conversation about how useful it was on facebook just this week,

And please, please no more options!!

[korenevskiy]

Similarly. 80% of MS Excel users do not know such magic functions, and only 20% do. And 20% of users know 80% of the possibilities. I can say with confidence that I know only 20% of MS Excel, as it is easier for me to work with data in SQL. but the majority also have no need.
It is quite logical that most admin panel users need to write an article based on intuition. Have you witnessed a user's interaction with FaceBook, do you think that he got this knowledge intuitively? or he read the instructions from cover to cover.
In fact, we limit the capabilities of most users, of course I mentioned programmers, but this was a simplification. Of course, writing the keyword ID concerns a minority, since this is not intuitive knowledge.
But I told you that you can make a setting so that it is disabled. It is quite obvious that it will not work by default.
We also know that the search works by aliases, I'm sure that Facebook does not work by aliases, you need to attribute a dog there, but the search is conducted on Facebook by the full user name, and in Joomla the search is based on the alias part of the name, so it's not entirely logical to compare, their UX is different

[rdeutz]

@korenevskiy we discussed any possible aspect of this idea and decided to close the PR.