Lang files should be modified to use the new name of the module. And strings constants also in lang file and core.
Also ‘Administrator Dashboard Menu’ woulbe better named ‘Administrator Dashboard Navigation ‘ imho as we should reserve the term menu to the side one. That will take off already one reason for confusion.
update sql should delete though at least the old 3.x mod_submenu.

I do not agree with your suggestion to rename dashboard navigation

Lang files should be modified to use the new name of the module. And strings constants also in lang file and core.

I do not see the need to change the constants just the values which I have done

it should be mod_dashboard.ini, and then all constants should start with MOD_ DASHBOARD_etc in the ini file as well as in the code xmls etc

Basically, mod_submenu should just disapear from j4

I respectfully disagree

I respectfully disagree

Then count me off. This makes no sense at all. Core should show the example.
As it is no more a submenu, let's call it mod_dashboard and change accordingly

@brianteeman

NOTE I have not created an update sql as that would be changing content which we shouldnt do ever on an update

This is theoretically true but practically false.

Theoretically we should not handle schema(=structure) updates and content updates together, like @mbabker often points out.

Practically we don't have another method to handle content updates, except maybe add some procedure to script.php, and so since I know Joomla from 1.5. on, we do also changes on content with schema upates. Just check for DML statements (data manipulation language, i.e. INSERT, UPDATE or DELETE) in our schema updates and you will see we use them to add menu items, insert records in extensionm table, add modules and so on.

And so there are also schema updates for the new template, which are the 2 files named "4.0.0-2019-07-13.sql". With these schema update scripts, the modules for the new backend template have been added.

You have to do the same changes which you do here in files "joomla.sql" also in files "4.0.0-2019-07-13.sql". As long as we are in alpha and so not have to support updates from alpha to alpha or beta, you can change the present 4.0 update scripts. If we were already in beta, you would have to make new schema updates which change the recods in the modules table, and this could become a bit tricky.

But as I said, you can and you should modify the "4.0.0-2019-07-13.sql" scripts, otherwise people will in future have wrong modules in their database when updating e.g. from 3.10 to 4.0.

If you don't believe me (what I almost assume because that's the standard in recent times), ask George if I am right.

@brianteeman Regarding my previous comment and to save you some work, see brianteeman#82.

I have tested this item ? unsuccessfully on e1334b1

Details see comment here: #26047 (comment)

I have tested this item ? unsuccessfully on e1334b1

Details see comment here: #26047 (comment)

Saying that it fails is incorrect. It does everything that it says it will do. The thing you want it to do is something I explicitly stated it will not do and nor should it

Well it has to be done. And it seems you never will admit that you are wrong. So it seems I have to do that later. If you have time ask George and he will confirm I am right in this point.

I have not tested this item.

it is not about being right or wrong. I specifically said what this PR does. I specifically said Any other issues with this module are completely off topic- please no bike shedding

I don't really care where in the release cycle things are at, but there are certain fields which should NEVER be changed with a Joomla update. A module's title is one of those fields, because those can be customized by the end user. Now, if you want to take away administrative management of these titles, then by all means go for it.

Now, as for the usual soapbox ranting. The SCHEMA library uses the name SCHEMA for a reason (in part because Joomla uses a half-assed schema management system that relies on change deltas and won't actually implement a proper database schema management API, it also doesn't help that the canonical source for the database schema is deleted from every Joomla installation which means change deltas are the only way you can hope that the system is in the right state). A data update should only be placed in these files when it is absolutely critical, as in the application will be FUBAR without it. I'm sure you all know what happens when you FUBAR these data updates because they weren't adequately thought through. Don't put yourselves into a spot to repeat that mistake because you're misusing an API to do something that it cannot be relied upon to execute 100% of the time every time (there's a reason that stupid magic black box fix button doesn't trigger data related statements, if that isn't a big red flag then no amount of me repeating how FUBAR things are now is ever going to make it clear).

@mbabker That might all be right regarding how it should have been done and should be done in future. But here we already have a schema update, and now this PR changes something in joomla.sql without doing the corresponding changes in these existing schema updates. And this makes this PR incomplete, regardless of your correct mentions regarding how it would be with a better architecture.

Big deal? By your argument, a new update SQL file should be introduced to arbitrarily change the module name because the joomla.sql file is updated, and that is just dead wrong. Data statements do not belong in the update SQL files, period. The data in the update SQL files does not have to be a 1-for-1 match with the joomla.sql file, period.

That said, I'm hitting unsubscribe. Once again a pull request has been derailed with a request for unrelated and unnecessary changes.

What a pity Michael got it wrong. I did not say introduce new update sql, I said change the existing one as long as we can. But anyway, I will stop to discuss about that.

1. As I have said about a thousand times, update SQL files should never be altered after a release goes out. That alone is part of the reason the project pulls the BS excuse of "you can only upgrade stable to stable otherwise good luck". The change isn't going to land on an existing site, and if the change is that urgent, you should be shipping a new file.

2. As I have said about a thousand times, the Schema library is not designed for use with data statements. Yet the contributors to this project continue to misuse this API. And nobody sees the problem with this?

3. Bikeshedding a pull request with an unnecessary and unrelated change does nothing but piss everybody off. If you really think it is THAT necessary to change an update SQL file, propose the change after this pull request lands. Hint, it's really not necessary, it's not helping anybody to change it after the fact, and it's not hurting anybody to just leave it alone.

4. I don't care how many times people try to tell me otherwise, I honestly feel like if I were not the only one pointing out half of the problems I have identified (then just accepted them as facts of life because either people don't understand or don't really care about the deep rooted architectural flaws in Joomla), people might actually be willing to fix the core flaws that exist and are abused on a daily basis in this project. Instead, we all waste our time arguing over 2 words in a meaningless SQL file.

The change makes sense to me. I would also like to see that we find a better way to communicate with each other.

Thanks

@infograf768 in this particular case given submenu's are so unique to joomla admin and given that this dashboard thing is something totally different I'd actually not be against giving the module a different name so that it solves the whole issue with whether we should name the title of the module

thanks