confused - what is this pr supposed to do? Remove the category count feature

ignore me - i guess I tested too quickly - you are still working- sorry

sorry brian the connection goes down suddenly ....
can you test now

I have tested this item successfully on 7c8dafe

With my data from #9420

before

Database queries total: 31358.46 ms

after

Database queries total: 276.19 ms

WOW!!!

i'm sure we can do even better ;)

Before

Total SQL-queries: 21420.74 ms

After

Total SQL-queries: 14.74 ms

Database: 1.4Gb
Materials: >82000
Categories: 46

@alikon can you look at the codestyle issues in Travis please and then this can be merged

This PR has received new commits.

CC: @brianteeman, @wertos

RTC now that travis is happy - awesome stuff

We need to do the same thing to all the other category helpers (e.g. banners https://github.com/alikon/joomla-cms/blob/patch-61/administrator/components/com_banners/helpers/banners.php#L197, newsfeeds etc.)

• let's not forget hathor.

We honestly should be doing this in view.html.php - so these variables are not set in the default.php then no Hathor changes required

@wilsonge Would be ideal in the view.html.php but then you can't override it anymore. Perhaps in a JLayout?

Why should you be able to override a database query?

@wilsonge because that is what is causing the performance degredation or does the sql change already account for that?

#9421 (comment)

In that case the code can remain in the model or not?

It could go in getItems in the model I think yes - not the getQuery where it currently resides tho

It is in the getListQuery() but yes, perhaps getItems() is better.

I have written a PR that uses this but moves the code out of the com_content view and also does it across all the extensions with this feature. Closing in favour of #9429