Also reposting my comment from the previous PR:
One should at least also adjust the various language strings to indicate that the featured view now is not really a featured view anymore but a mutlicategory view (with optional featured filter).

@Bakual before @yozmag starts writing language strings and updating codestyle can you please confirm that the concerns you raised in the original issue are resolved. If not there is no point in proceeding

My concern doesn't apply since it isn't a new view. He just takes of the "featured" filter from the "featuired" view.
Since there are no routes to this view (besides direct menuitems) it should be fine.

I don't think it makes sense to remove the filter that names a view. And I think using tags or a right setup of nested categories is actually the better way to solve this (as you get routes to it).

I don't think it makes sense to remove the filter that names a view. And I think using tags or a right setup of nested categories is actually the better way to solve this (as you get routes to it).

@Bakual I do understand the legacy part of the description in the view.
Before a change the Feature view I had made a copy of the feature folder to a "multicat" folder a change what need to be changed, created a new model class be copy.
I after all that work I realized that a made an all new view, and model just to turn off a "filter", this in my option didn't made sense, if something is maintain in the feature view it need to be replicated in the multicat view, if we just need to select witch articles attributes we want to filter, we shouldn't need a new model and view, It must be a parameter in the view menu. For me these views show articles in a blog format, witch articles they show is defined at the view menu, not hard code in the view.
I do understand the legacy issue, but if something is not correct it should be fixed.

I do understand the legacy issue, but if something is not correct it should be fixed.

It is correct as it is.
You just want to add the possibility of another use of the "traditional" featured view.
Even if default is set to 1 (still missing in your code...) this means a whole lot of changes for language strings and tutorials.

I think, adding to @Bakual suggestions, that this can be done also via a system plugin.

For me these views show articles in a blog format, witch articles they show is defined at the view menu, not hard code in the view.

The "format" (eg multirow, teaserarticles, ...) is given by the layout, not the view. You can do the exact same format in a category view. It's just "hardcoded" to that category and its children in that case.
The view only decides which articles it shows.
There is nothing hardcoded into the featured view beside that It's named "featured" because its purpose was to show specially marked (featured) articles across categories.

I still don't really understand the purpose of your request, why you want to show "all" articles from various categories in one view. Why don't you just use the category view and nested categories for that?

@yozmag please give in open Comment "Test Instructions" (also if this can be tested by Patchtester or NPM).

I have tested this item ✅ successfully on 8629be8

I have tested this item ✅ successfully on 8629be8

It works fine. Thx

I have tested this item ✅ successfully on 8629be8

Only the translation of COM_CONTENT_FEATURED_CATEGORIES_DESC is missing

I have tested this item ✅ successfully on 8629be8

Only the translation of COM_CONTENT_FEATURED_CATEGORIES_DESC is missing
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24454.

This is not a new language keyword, it's already translated on https://github.com/joomla/joomla-cms/blob/staging/administrator/language/en-GB/en-GB.com_content.ini other language should have the keyword already translated.

Is this in rtc state?
Is it considered for 4.0?

@yozmag can you solve the conflict please

btw i think joomla 4.0 needs to consider new features (no matter how small they are) that are sleeping in github and are almost ready to commit as selling points to make migration to 4.0 worth it.
I know it's main selling point will be accesibility, media manager (better cleaner code etc unfortunately is not a selling point for the consumers) but we need to find and activate small features no matter how unimportant it seems to us and our use cases bacause for some may be the key to migrate.

setting RTC as the changes are only cosmetic

COM_CONTENT_FEATURED_CATEGORIES_DESC does not exist in 4.0 en-GB
It existed in 3.x but someone deleted it as many descriptions in 4.0...

Therefore, or we re-add the string in 4.0, or we take it off from the new xml field.
Wait then for RTC imho.

The good thing of reusing text is that the translations probably exist too. Can we reuse other string with similar text?

What I would do is modify the field

	 	<field 
			name="show_only_featured" 
			type="radio"
			class="switcher"
			label="COM_CONTENT_FEATURED_ARTICLES"
		        default="1"
			>
			<option value="0">JHIDE</option>
			<option value="1">JSHOW</option>
		</field>

Edited type and class

I am not on a computer to test but should this be a switcher?

yes it should

I still think this proposal is architectural wrong and shouldn't be included.

I am not on a computer to test but should this be a switcher?

Indeed not as this part uses only lists.

so, if pr is accepted it should be

		 	<field 
				name="show_only_featured" 
				type="list"
				label="COM_CONTENT_FEATURED_ARTICLES"
			        default="1". // cs issue. should be tabs only and not spaces
				class="custom-select-color-state""
				>
				<option value="0">JHIDE</option>
				<option value="1">JSHOW</option>
			</field>

I agree with @Bakual this should be a new mutil category view, I think we had this in 1.5 but it got lost at some point. Removing rtc and set to needs review @wilsonge your turn

Indeed not as this part uses only lists.

Yes only because the other settings use global. This one has only 2 values.

@Quy is correct
Two options ==> switcher
and anyway chzn is not used in joomla4

should be a new mutil category view

Or like I said before, you use nested categories or a tags view to achieve the same.

A multicategory view itself isn't really something that works well with Joomla because the architecture (eg routing) doesn't support it. Even if this PR is rewritten to a real multicategory view, it would still be a hack at best.

Bakual, if the routing works with the feature view it continues to work. In my opinion there is no reason to create other menu view to show all articles, it more to maintain and we are not reusing code. If a switch is all that is needed, in my opinion we don't need to have a two views so specify for feature or all articles.
For me menu views show all article, we should use the view parameters if we want to narrow the articles (categories, featured, etc... ).

Bakual, if the routing works with the feature view

That's the point. It doesn't. The featured view is already a hack.

in my opinion we don't need to have a two views

If you read what I wrote, you see that I wrote to not have that feature at all. Because you should use the existing tools to achieve the same (or similar) outcome.

If it doesn't work correctly with feature articles it should be removed until a solution is found. Maybe remove the feature option from articles.

If it doesn't work correctly with feature articles it should be removed until a solution is found.

It should at least not be expanded with other features since people will make wrong assumptions on how it should work. Removing certainly isn't an option.
The featured view makes sense to a degree as you can have a homepage showcasing specific articles.

Personally I don't like it much, I would prefer a system where we could have a homepage having "featured" items from various extensions. Basically what com_tags does, but expanded more. Eg something like I did here: #10242.

@wilsonge Should this be closed and require another PR that properly handles the featured view?

I have tested this item ? unsuccessfully on a61f150

The file marked for modification does not exist: components/com_content/Model/FeaturedModel.php

noted

On Sat, Oct 17, 2020 at 3:40 PM gostn notifications@github.com wrote:

@tushar33 https://github.com/tushar33 before test you can see this
information which means dont test.

[image: image]
https://user-images.githubusercontent.com/71960554/96334501-93166780-1071-11eb-892c-ebdfa20dcdb2.png

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24454 (comment),
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGELJVAE6BRTDUIV6S2OE2DSLFUP7ANCNFSM4HDAFBXA
.

--
Best Regards,

Tushar Shekokar
PHP Developer
Tekdi Technologies Pvt. Ltd.
http://www.tekdi.net | +91 20 6050 2226 |

Thank you @yozmag for you contribution.

I have to agree, that removing the featured parameter from the featured view is not the expected way to go. Probably a fresh conception of the articles would be a better way.
If you're interested to start that, feel free to ping me.

For now I'm closing this PR.