That would make one very complicated module for the user to use. If you look at _categories and _category they are already pretty complex

I had that idea once as well, but the sheer amount of options of some of those modules made me give up ?

Technically however, all of those modules except mod_articles_categories do the same: they show a list of articles from certain categories. Just with some small flavor. So they should indeed be merged into one and the other ones deprecated. The deprecation could be done with a warning message in the backend if those deprecated modules are detected.

My feeling is that we would have to drop some features of the current modules if we want to merge them to keep the code sane. I think those modules grew out of hand over the years and one should reevaluate if all those options and filters really still make sense. And then best create a flexible "mod_content" with a sensible amount of filters and sorting options and two or three layouts.

the main issue that I would see would be the b/c

the main issue that I would see would be the b/c

You can't have B/C if you merge modules. The merged modules will eventually have to manually replaced with the new one. Automatically doing something here is most likely either massiv complex or prone to fail. Personally I would not even try to do it.

As @Bakual said all the modules are basically doing the same but clutter the backend. I'm sure we can find a concept how to make it still work for B/C if a module like this already exists.

@Bakual Why is it not possible? You could have a file that indentifies that if a module type xyz is called "this is the new location" of the module? Like a legancy layer? Well - i can try that and if i get some help maybe it's possible... I think it's worth to clean up the backend a bit.

You can try if you can do it B/C, but from memory when I had a look this spring option names and their values plus layouts just don't match enough between the modules. So it's not simply "redirecting" from old to new module.

Create a new module that merges all of them together, then don't ship the separate modules in J4 so that people migrating from 3.x to 4.x still have the old ones?

good idea @C-Lodder and probably the easiest way.

Do we then have to support the "old" modules?
Wont it be confusing that for an existing site you have 7 modules but on a new site you only have one?

Same would be for template and other things - I suppose beez will not be shipped with 4 ? We could provide them like weblinks if someone really needs the old version?

but beez wont work - the modules will

When I thought about it earlier this year, my plan would have been to create a new module for J3 and then drop them from J4. In J3 I would have shown a deprecation warning message in the Joomla backend if any of the old modules was in use, the message indicating to use the new one instead.

We could leave the old modules during updates, but I certainly wouldn't support them anymore. That would be a bit against the point and just leave us with yet another additional module ?
Not supporting would mean the old modules look at least ugly in J4 due to wrong HTML markup, maybe they even break due to changes in J4.

I don't see a problem with having multiple modules, from the perspective of providing discrete UI for each of them.

But there may be a good case for combining a lot of the code that is similar between them, ie a de-duplication effort, by putting the core code into a helper class in a shared plugin, and having the modules act as relatively lightweight shells.

That way you would deal with the clean code issues caused by having multiple similar modules, but without having any BC breaks, etc.

. Why create a Frankenstein module if you can't use the existing module. Even if you can transfer the params/values you won't be able to transfer the css classes those modules are wrapped in. I just see lots of pain and no benefits

Because that's the list a user can chose from and combining as much modules as possible that do basically the same creates a better overview and less confusion for the users. It's a better User Experience and also if you find out Newsflash was not 100% the right Module you don't have to set up everything from new.

1. Article Module
2. Category/Categories Module

instead of:
Archived
Categories
Category
Latest
Most Read
News Flash
Related

I give it a try to merge and maybe we can discuss then if there is a method to migrate it smoothly.

I rarely use any of these modules and usually, I disable them. A single module could cover all the functionality most of these are offering and it won't need to be a Frankenstein one. Take for example RAXO mod - it provides all this and even more functionality, and yet it's easy and fun to use, within a nice UI.

However, indeed just removing and replacing them with a new one will be BC break and any solution must be thoroughly thought. Having the content module available in parallel for some time, along with the old ones that will be deprecated might be a good option.

I guess an upgrade script to transform old modules to the new one could be possible - but the new module must be developed first - at least a basic form of it.

I actually think multiple modules are better in this scenario.

Merging into one can get confusing and is quite a lot of work for little gain.

I have recently being using com_content a lot more and the sheer amount of options is crazy. It would be better split into a few views to be easier to understand and create from.

Also, if you wanted to do a template override for one view and another when it is in the same module it becomes more confusing again for the end User.

I vote to leave it as is, or maybe put some info into each module saying what you can do with the other modules, maybe with a related modules tab or similar.

You only have to look at the K2 module to see what a Frankenstein !onster it can become

There is power in simplicity

Exactly! Well out indeed ?

On 31 Oct 2017, 21:48 +0000, Brian Teeman notifications@github.com, wrote:

You only have to look at the K2 module to see what a Frankenstein !onster it can become
There is power in simplicity
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I quite disagree because: They really do all the same stuff. It would be NOT a Frankenstein module.
For Example: one shows the latest articles the other one the articles where you can order by the latest ones. It does not make sense to have two modules here?

I'd say I create a draft for further discussion ;-) and if you still say no i'll be ok with the descision.

I quite disagree with the opinion about K2 "tools" or k2 "content" module. They are more usable than we think, every "admin" that i known have disabled standard module from joomla and installed a "multi utility" tool, like RAXO or K2 modules if K2 is installed (needed for manage the granular category -> article templating that joomla lacks).
From a developer point of view, a good developed unique module is more maintainable and more efficient. I'm think to mysql queries, server inodes, overrides... A BE user/admin can be in love with a module like this in two nanoseconds. And for UIX we have the power of JS and Ajax, for example in the first tab we can see "What do you want to do? List, column, wall, masonry, carousel, etc" and then other tabs that adapt settings to the first choice.

PS: why not to create poll for these proposal? I think some choices must be done by "users, admin and SEO" not only by developers...

And I never install any modules. But that is meaningless and we can't develop based on polls. I want a poll for more pay :)

I create a draft for further discussion

i'd like to to read your draft before to express that i'm against, because i like the Keep It Simple Stupid approach, but till now it has been very easy when you 've to explain to newbies how things works...
and after all there are already some ALL-IN-ONE 3dp solutions

I worked on the "merge" concept and can say that the result would actually not be a "Frankenstein" module. The module with the most fields and options is the mod articles category, if you add some list options to the sorting field and one field for the month count for articles we have already one single module that covers all options from the existing modules. I made the mistake that I merged first all modules one by one in the mod articles news and now I see that i should have use the mod articles category as the base module for merging. Will post it hopefully next week.

@coolcat-creations is it next week yet?

Thanks for the reminder. I'm currently not able to finish this - altough I' still conviced that the modules can be merged "easy" into one. Mostly I started from the wrong side. I'd be happy to keep that open until GSoC is over or I reopen it afterwards.

Best to close it for now and if you ever find the time to create the Pr it can be re-opened