I have tested this item ✅ successfully on 2a59282

on code review

I have tested this item ✅ successfully on 2a59282

foreach works with a copy of the array so it takes more memory and IIRC for is faster, so the only argument for using foreach is readability of code. I don't think that this is needed here.

Sorry but I don't understand that. The bit more memory used, is released as soon as the function returns. So this is not a reason to close all those PR's.
The pro's are both speed and readability. Readability alone would be a huge factor to weigh in.
So why exactly are all those PR's closed with only a comment from one person only?

Also, I 'd like to point out that the memory footprint for the looped array in most, if not all, cases is negligible. So I really see no reason, that those PR's are shutdown this way.

Your "bit more" depends on the number of elements that array in question have, so the "bit more" can be "huge more". That foreach is faster than for is not 100% clear and the checks I have found giving different results. So I have closed this:

• Because it isn't a needed change and there is a fair chance that memory usage will hit us
• I don't think people should spent time on testing this, so I closed it early.

Personal note for you @frankmayer

I told you already on the other refactor PR's that I see better places to work on. You are putting a lot of work into "cosmetic" changes, usually these PR are large and hard to test. So there is the danger that these will stay a long time not ready to merge and then you've the solve all the merge conflicts. Not fun.

I would really like to see you working on some bugs, I think it is better to fix one bug rather then optimize 30 "for" usages. Form all what I have seen you can code PHP and your time can be better spend.

@rdeutz I agree on the "bit more". If there is somewhere a situation that could "hit us", then this thing could be discussed and dealt with.

As for the other points:

• If a change is a needed change or not is a discussion for itself. IMHO those changes should not have been necessary, if for example type-safe comparisons or other stuff had been done before.
• These changes are as much part of keeping a project up to date and with best practices and optimal code as with the day-to-day necessary changes. And of course the others have a higher priority, but with most of my PR's a lot of things are getting done better than before (in ways of best practices and also in performance), which in the end reduces problems.
• Yes, the merge conflicts are not fun...
• Yes, I might also choose to work on bugs, but as I also stated in my other PR's, having the best practices in place helps with solving bugs. So these are not "cosmetic" changes.
• At some point, the code will have to be "modernized" and why not "optimized"... So why not do this earlier and get it over with?
• As for my time better spent, Of course you're right in general terms, but not in the Joomla project. I chose this way to give back to the project and deal with the slack no one wants to deal with (in any project). Someone's got to do this kind of stuff.. SO IMHO, in relation to the project any time dealing with those PR's is well spent.

@rdeutz

besides the foreach changes, that's i actually agree with, this particular PR actually goes more ahead and reduces two for cycles in to just one. Clearly an improvement IMHO.

@frankmayer maybe this would be even more efficient

// Code removed for brevity
        try
        {
            $rows = (array) $db->loadObjectList();
        }
        catch (RuntimeException $e)
        {
            JFactory::getApplication()->enqueueMessage(JText::_('JERROR_AN_ERROR_HAS_OCCURRED'), 'error');

            return array();
        }

        foreach ($rows as $i => &$row)
        {
            if (!SearchHelper::checkNoHtml($row, $searchText, array('name', 'title', 'text')))
            {
                unset($rows[$i]);
                continue;
            }

            $row->href    = ContentHelperRoute::getCategoryRoute($row->slug);
            $row->section = JText::_('JCATEGORY');
        }

        return $rows;

@andrepereiradasilva On a quick view your proposal seems ok and would be even more efficient. Though right now I am not investing more time into a closed PR. If by any chance it would be reopened, I will happily continue working on it. Sorry...

@andrepereiradasilva I have opened a new PR for this one with a further optimization. I didn't implement your solution above, as it might produce a problem later on. Let me explain.
When you have an array with keys 1,2,3,4,5 and you do unset on 2 and 4 for example, the resulting array will keys 1,3,5, which will most probably lead to problems(Undefined offset) specifically on for loops that will handle this result.
Thanks for your thoughts, though. It was in a good direction. ;)