This is obviously incomplete

This is obviously incomplete

Do you mean about the bad description of PR?

@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.

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

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

#39966 (comment)

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

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

I suppose you meant the field description . Ok. I'll need some time.

Hi Sergiy,

After a discussion in the Maintainer group we decided that this is not a change we see in a future Release of Joomla.
Thank you for your work, don't feel discouraged and continue to contribute to Joomla.

Hi Sergiy,

After a discussion in the Maintainer group we decided that this is not a change we see in a future Release of Joomla. Thank you for your work, don't feel discouraged and continue to contribute to Joomla.

Maybe the problem is something else? Maybe I suggested the wrong search logic?
In the screenshot, I suggested displaying the article by ID along with other articles that may have a number in the title.

I would suggest the second option. Show articles with ID search only if only a number is in the search. I.e. if a word is in the search, then such a search is considered classic. But if there is not a single word and there is only a number, then only the article by ID and the article with the number in the title will be displayed.

Perhaps in the group, you discussed how the result will break when searching for words and numbers.
Example: Search: "Article 312".

I suggest reviewing the logic after your decision. And in this example, since there is the word ARTICLE, the result will be only in the classical style, without searching by ID.

But as soon as there is only a digit in the search, then the search will be by ID as well.

Perhaps in the group you discussed the correctness of my previous search option. But maybe you haven't considered other logic, and possible options.

Maybe my previous option is really too intrusive. And the new one is more delicate. Please consider more delicate options!!

Or. Perhaps I would suggest calling a plugin. This allows those who wish to use the plugin to enable ID search without using a suffix.

After thinking more about the reason for you wanting to make this change I think I now understand why and its not something that will have been considered by the maintenance team and should be a reason for them to reconsider their decision.

For me it is easy to type ID:1234 and at first glance it would appear to be easy for everyone making this change a matter of personal preference only.

However for a language that does not use a latin character set such as russian, greek and arabic it is not so easy as they have to switch from their default keyboard to a latin keyboard. This is definitely undesirable. Just as it is also undesirable that to search inside the content of an article you have to type CONTENT:string where CONTENT is not translatable etc

@Fedik please ask the maintainers to reconsider this

You are absolutely right.
As a programmer, I always have English. But my wife always uses Russian by default.
This is reminiscent of how programmers make apps for phones for $1,000. Because programmers have high salaries.

I’m not Fedir, but I was reading too so I’ve notified other maintainers.

Thanks @richard67

Dear colleagues. In my work, there is support for museum websites. Don't get me wrong. I treat pensioners well. But I am constantly (always) faced with the stupidity of people working on a PC. I see many times how people print out a document, make corrections on it with a pen, then scan it and send it by mail, or send it to Whatsapp. And they do this not because they are bosses and want to show the places where they have been corrected, but because they do not know how to do it differently. These people from Excel rewrite the numbers on paper, recalculate them on a calculator and write them back into Excel. These people became familiar with the computer in quarantine.
This is not 1 person, it is a large organization with 3 branches. I learned to think like these pensioners. I am constantly thinking about how people can work with the Joomla Admin Panel. I live in a modern city. But as if there is a fact that half of humanity on earth lives without electricity at all, and even more so without the Internet. This means that there will still be many people, even English speakers, who will print out the document in order to scan it later. This means that the convenience of working with Joomla should be made simple to the very minimum, to the utmost minimum.
If anything, then printing out a document and scanning it is not a joke. And recalculating data to an Excel calculator is also not a joke. These are real people, and the whole organization is just such people. But these are the most ordinary pensioners.
The task of the developer is so that even an idiot can use his product. After all, a manager, a consultant, a doctor really does not care about the subtleties of prefixes at all. These people will just do it the way it would work on other platforms. They will do it for 3 hours, but they will do it without prefixes.

Addition
Microsoft converted its office to a Ribbon Panel in 2007. If anyone remembers the reason why Microsoft took this step. I'll try to remind you. The new interface is a pain for the user. Remember those times when it was somehow hard and unusual to master. But the bottom line is that 99% of People asked for functions in Word, which were already in it in 2003 and earlier versions. This means that the interface is bad. Here, in the same way, people should search for articles by ID intuitively, Even if you can use a prefix, even English-speaking people will have no idea about prefixes. If you want, just ask your friends, those who are not a programmer, but a Joomla user.

Everyone who participates in the adoption of this PR. They themselves are the same as pensioners. The proof of this is that on the streets of any city, the prices of shops that are located on the road are always available 30%-50% higher than in stores from the yard. Do you always buy a product in the store from the yard? Of course, only when you know that there is a store there. This is such a big phenomenon that the prices are much higher. Understand, it's not that it's too lazy to write a prefix for the ID. It's just that few people know about it. It turns out that every website of any organization has its own problems, everywhere has its own entrance from the courtyard. For each site, you need to remember your own special regular expression. Every programmer will say, but it's not difficult for me to write regulars. 90%(I was wrong it's 95%) of people will just sort the list by ID column, and then flip through the pages at random.

After some discussion, I reopening it.

I have to warn that not everyone like this approach,
you have to make it really good, or it have a big chance to be closed again.

After some discussion, I reopening it.

I have to warn that not everyone like this approach, you have to make it really good, or it have a big chance to be closed again.

It is not about if people like it but about rectifying the search so that it is not dependant on hard coded strings in the latin character set and english language.

My personal preference would be to keep the search prefix but to make it translatable

PS no idea how to do that

My personal preference would be to keep the search prefix but to make it translatable

I think this can lead to translation mess. I do not think that we can guarantee that it will be translated correctly.
Example: tooltip may say use "ID:", and for a placeholder translator will translate it as "IDENTIFIER", and whole thing will be unusable.
We already had issue with Date format and Date filter translations, for calendar input.

I will be happy to be wong here :)

I will be happy to be wong here :)

Am not saying it will be easy but it is wrong that in this part of the UI you have to type in latin characters and in english language. I don't think removing the ID etc is the solution however.

Suprised that no one has brought this up before

The PR do not remove ID:, it still will be in use for "exact search". It just extends general search.

The PR do not remove ID:, it still will be in use for "exact search". It just extends general search.

My bad - I misread it then

And how can we consider cases when it is necessary to edit, say, 20 or 30 articles? It often happens that people just made a mistake in the date or something else.

Maybe the other participants also misunderstood? And participants thought that the prefix would be canceled.

I will fix it as the team wants. But what about the other components? For example, Notes in users, and other components.

administrator/components/com_content/src/Model/ArticlesModel.php

@Fedik Please take a look. Removed the heuristic, added a comment.

Removed the heuristic, added a comment.

I meant, remove space and comma mix, use only comma.

And check the code I sugested.

I meant, remove space and comma mix, use only comma.

But if we use only a comma. Then the request "Article 123" will not be regarded as a search in the ID. You suggest using a more delicate search.
I'll fix it now

Then the request "Article 123" will not be regarded as a search in the ID

That what I mean, with heuristic. It is seems to much magic.

Also please check how I map the values, to keep the integers,
Thanks.

I also propose to make similar amendments to:

1. Manager Menu
2. Manager Tags
3. Manager Banners: Tracks, Clients, Banner
4. Manager Contacts
5. Manager Redirect
6. Manager Workflows
7. Manager News Feeds
8. Manager Search/Filter
9. Manager Users: users, groups, levels, Notes, Messages, Categories.

If you don't mind, I will make similar amendments further.

I also propose to make similar amendments to:

Keep it only for articles, categories, fields, modules for now.

I also propose to make similar amendments to:

Keep it only for articles, categories, fields, modules for now.

OK. but I think Tags are just as important. Only Tags.

okay

okay

Thanks. It seems that the world has become a little better.
I had another idea to make the search a little more delicate.

To begin with, for example, we will return the space separator. After that, we divide the string into an array by a space and a comma. Then we filter it. And then we compare the amount of the filtered array with the unfiltered array.
If the number matches, then the user was obviously looking for numbers.
This will also make the search more delicate, but at the same time be able to use a space as a separator.

addtition
Because in different layouts, the dot and comma are constantly confused. Even on a digital block, the dot becomes a comma when the layout is changed.

But it's also good as it is.

It will be to much.

Please update value filter to what I sent you before:

$ids = array_filter(array_map(function ($number) {
    $number = trim($number);
    return is_numeric($number) ? (int) $number : 0;
}, explode(',', $search)));

This transform a numbers to integer, and filter out empty.

This transform a numbers to integer, and filter out empty.

But what if "-123" is entered in the search. This will be regarded as an ID. And after that, the request will search for ID with -123

As well as an anonymous function in the Array_filter function, it is not necessary to return the value of the number. Unlike Array_Map, the internal function requires a return in the BOOL type.

return is_numeric($number) ? (int) $number : 0;
In fact, this is the same thing.
return is_numeric($number) && (int) $number;

If the internal anonymous function returns -123, then this is interpreted as TRUE.
And this means that the value with "-123" will get into the $query. And there is no ID with a negative ID.

addition
I didn't see the ARRAY_MAP function at first, but even with it, a search with a negative ID will occur in the $query.

If the internal anonymous function returns -123, then this is interpreted as TRUE.

Then this:

$ids = array_filter(array_map(function ($number) {
    $number = trim($number);
    return is_numeric($number) && $number > 0 ? (int) $number : 0;
}, explode(',', $search)));

Your code produce array of strings, should be integers.

$ids = array_filter($idsPrepare, function ($number) {
    $number = trim($number);
    return is_numeric($number) && (int)$number > -1;
});

My code creates an array of strings. But I had already thought about this initially and initially checked the types. But in my code,
In these cases, ["\t123", "\n321"], an anonymous function may return TRUE.

Even if the anonymous function returns TRUE for these raw strings \n\t123.
Then the method call $query->bindArray($ids); will make the array types cast to the INT type in itself.
Since in this method of converting an element to the INT type is used by default.

Which does not cause an error in any way, which also corresponds to filtering as in your example. I.e. it is the same code and gives the same result. Let's use your code in which we explicitly cast the INT type to a value. Since I am in my case, I used the built-in type conversion in the method

$query->bindArray($ids, ParameterType::INTEGER);

Before casting the types.
["\t123", "\n321"].
After converted to array INT number
[123, 321]
But we can use explicit conversion as in your code repeatedly. But maybe in my case it's wrong to do so.

I fixed everything as you recommended.

$ids        = array_filter(array_map(function ($number) {
    $number = trim($number);
    return is_numeric($number) && $number > 0 ? (int) $number : 0;
}, explode(',', $search)));

Why can't we make the keywords translatable? Instead of this additional code executed on each search, allow for id, content, etc to be translated in the search input. Thus non-latin users can keep using their keyboard.

Theoreticaly it is possible, practicaly see my comment #39966 (comment)

Why can't we make the keywords translatable? Instead of this additional code executed on each search, allow for id, content, etc to be translated in the search input. Thus non-latin users can keep using their keyboard.

Let's simplify the work with the search for articles. After all, we do it for people: for the weak with vision, hearing, with limited mobility. Why do processing using regular expressions. If it can be done simply and conveniently for everyone.
This is called accessibility.

I have tested this item ✅ successfully on 5a7a5db

For testing in Sample data go to Articles list, and search for 1,2,3.
Should get a list of articles with ID 1,2,3.

Repeat for Categories, Fields, Field groups, Modules (with existing ids).

The interesting thing is why our colleagues are against it. In the case of a search, they are not satisfied with the fact that they may accidentally see an article with the ID specified in the search. I can't understand how this hinders them. Maybe these colleagues here will tell us about their special case in which a new logic hinders them.

We can do so that for example:
"Aticle 111, 22, 33" - The classic search from the names will be displayed.
"111, 22, 33" - A new search will be displayed in both the names and the ID.
Add a check for the presence of words in the search. And if there are words, then consider such a search classic, without searching in ID.

I have tested this item ✅ successfully on 5a7a5db

RTC

This pull request has been automatically rebased to 5.0-dev. No new features will be merged into Joomla! 4.3 series. Joomla! 4.4 series is a bridge release to make migration from Joomla! 4 to 5 as smooth as possible.

Hi @korenevskiy sorry that it took so long, we discussed this in the weekly maintainers sprint and we have 3 request.

1. Please move the array_fillter code block to the ArrayHelper method in the v3.0 in the framework
2. Maybe we can extend the check so if a number/search string is in Quotes (") not to search for the number.
3. In oppsoite to what fedir said above we would like to have it for all extensions so it's consistent for the complete cms

Then we would like to merge it.

The commaUintToArray method could be something like this but I would suggest to make sure that 0 work as return value but not a string to 0 is returned.

This function makes it a bit better but also doesn't full fill the requirements (readable and correct values). Actually it doesn't return the number 0 and it will also be not possible because of the way array_filter work.

$ids = array_filter(
    array_map(
        function ($number) {
                $number = trim($number);
                return is_numeric($number) && $number >= 0 ? (int) $number : false;
            }, 
            explode(',', $search)
        )
    );

thanks for your work.

Back to pending

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.

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

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)) . ')');
            }

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

@HLeithner , I created a PR by ArrayHelper.

joomla-framework/utilities#43

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

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

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.

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.

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

Why is this PR not included in Joomla 5.1 alfa?

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

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.

@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.

@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.

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

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!!

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

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