[4.2] [RFC] System health page

[zero-24]

Is your feature request related to a problem? Please describe.

Such health check page could show problems and suggests fixes for problems like #25920 as well as other problems like broken #__updates_sites table etc. and also different other checks like suggested config options, and we also could include the magic fixer button etc.

Part of the things we did by postinstall but the problem of them is that the checks are run on any login and this does not makes sense for some intensive checks.

Describe the solution you'd like

Well the idea would be an dedicated system health page where we can start system checks implement system corrections etc.

Additional context

For example i would like to correct there some issues like #25920 but also issues with the #__update_sites etc.

An other thing would be to make more things like this: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/postinstall/languageaccess340.php#L25 without requiring the checks to run on any login.

Throughts? @mbabker @rdeutz @wilsonge @HLeithner @SniperSister @brianteeman ?

[mbabker]

I’ve been saying for years to add a health check system so “yes yes frickin’ yes” from me. And no “magical fix button to do all the things”. Every check should have its own fixer with a separate action (maybe a button to fire them all). And similar to the competition and other well designed components, this system MUST be hookable by plugins do extensions can add their own stuff here.

On Sat, Aug 17, 2019 at 10:25 AM zero-24 ***@***.***> wrote: Is your feature request related to a problem? Please describe. Such health check page could show problems and suggests fixes for problems like #25920 <#25920> as well as other problems like broken #__updates_sites table etc. and also different other checks like suggested config options, and we also could include the magic fixer button etc. Part of the things we did by postinstall but the problem of them is that the checks are run on any login and this does not makes sense for some intensive checks. Describe the solution you'd like Well the idea would be an dedicated system health page where we can start system checks implement system corrections etc. Additional context For example i would like to correct there some issues like #25920 <#25920> but also issues with the #__update_sites etc. [image: modified] <https://user-images.githubusercontent.com/2596554/63214005-46ed3180-c113-11e9-818c-6976d7f948f6.png> An other thing would be to make more things like this: https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/postinstall/languageaccess340.php#L25 without requiring the checks to run on any login. Throughts? @mbabker <https://github.com/mbabker> @rdeutz <https://github.com/rdeutz> @wilsonge <https://github.com/wilsonge> @HLeithner <https://github.com/HLeithner> @SniperSister <https://github.com/SniperSister> @brianteeman <https://github.com/brianteeman> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25921?email_source=notifications&email_token=AACZ7IOWCILM73S3BLMJNXLQFAJ7PA5CNFSM4IMPWFG2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HFZFNQQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACZ7IOXXCSXQ2FDP72M66DQFAJ7PANCNFSM4IMPWFGQ> .

-- - Michael Please pardon any errors, this message was sent from my iPhone.

[HLeithner]

We already have some system information pages there would be there place it should be imo and yes I would like it too.

[mbabker]

There isn’t a central spot for runtime environment checks (both for core concerns or suggestions on improvements or for the checks in the install app to be done on an installed site), and some of the things that do exist do more than you would expect based on context (why does database fix delete files?). So a more centralized dashboard that exposes more information is going to be beneficial for everyone, and creating a system that lets devs try to fix errors or give suggestions on improving the site (suggest PHP upgrade, suggest optional PHP extensions, suggest cache use, etc.) helps everyone.

On Sat, Aug 17, 2019 at 10:56 AM Harald Leithner ***@***.***> wrote: We already have some system information pages there would be there place it should be imo and yes I would like it too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25921?email_source=notifications&email_token=AACZ7IIOBU4EEZ6BAAA7MS3QFANUVA5CNFSM4IMPWFG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QOIMY#issuecomment-522249267>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACZ7IK7S6CCFMEM3U3OHBTQFANUVANCNFSM4IMPWFGQ> .

-- - Michael Please pardon any errors, this message was sent from my iPhone.

[richard67]

@zero-24 Do you plan to implement that yourself? Or is it just a suggestion but someone else has to do it? Currently we have a bit a lack of coders and testers due to holiday period maybe. I like the idea and can help with testing and with some knowledge about current implementation of so-called database schema checker and fixer, how it works and what it does and what it can't do.

[HLeithner]

I thought about administrator/index.php?option=com_admin&view=sysinfo but the place should be one place where everything (also databasefixer?) could be found

[zero-24]

And no “magical fix button to do all the things”. Every check should have
its own fixer with a separate action (maybe a button to fire them all).
And similar to the competition and other well designed components, this
system MUST be hookable by plugins do extensions can add their own stuff
here.

Fully agree. :D

@zero-24 Do you plan to implement that yourself?

I have not done any coding yet, that idea came into my mind because i saw that broken #__updates_sites but i think com_postinstall is not the good way to fix such problems.

I thought about administrator/index.php?option=com_admin&view=sysinfo but the place should be one place where everything (also databasefixer?) could be found

I would suggest to do the new stuff in a dedicated component as this has than nothing to-do with com_admin anymore ;)

[richard67]

Let's call it com_intern ... 😄 (Sorry, joke for old communists)

[mbabker]

A new view in com_admin is fine. Though a new component makes it easier to develop and test standalone.

On Sat, Aug 17, 2019 at 11:20 AM zero-24 ***@***.***> wrote: And no “magical fix button to do all the things”. Every check should have its own fixer with a separate action (maybe a button to fire them all). And similar to the competition and other well designed components, this system MUST be hookable by plugins do extensions can add their own stuff here. Fully agree. :D @zero-24 <https://github.com/zero-24> Do you plan to implement that yourself? I have not done any coding yet, that idea came into my mind because i saw that broken #__updates_sites but i think com_postinstall is not the good way to fix such problems. I thought about administrator/index.php?option=com_admin&view=sysinfo but the place should be one place where everything (also databasefixer?) could be found I would suggest to do the new stuff in a dedicated component as this has than nothing to-do with com_admin anymore ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25921?email_source=notifications&email_token=AACZ7IMKNLIGMKLUTSFHGU3QFAQLRA5CNFSM4IMPWFG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QOUXA#issuecomment-522250844>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACZ7IPF5VD3C2TN6Z2R4JTQFAQLRANCNFSM4IMPWFGQ> .

-- - Michael Please pardon any errors, this message was sent from my iPhone.

[zero-24]

A new view in com_admin is fine. Though a new component makes it easier to
develop and test standalone.

So your suggestion would be to build this into com_admin including all the future check and fix scripts / logic?

[mbabker]

I’d add a new view to that component. Because realistically you’re talking about one view for the actual info, the MVC to gather and display it, and the MC (no view) to handle actioning an issue that provides a fix button. If we were talking about something with multiple screens then a new component would make more sense, but the “core” API for such a feature actually has a very small footprint while more of the code is going to lie in the logic of what each individual check actually does (calculating what info to display on that view, how to arrange it, and anything needed to handle a “fix this” button where applicable). It’s almost the same as the com_privacy capabilities screen at its simplest implementation.

On Sat, Aug 17, 2019 at 3:08 PM zero-24 ***@***.***> wrote: A new view in com_admin is fine. Though a new component makes it easier to develop and test standalone. So your suggestion would be to build this into com_admin including all the future check and fix scripts / logic? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#25921?email_source=notifications&email_token=AACZ7IIW27YADYFWGHIYCYLQFBLEZA5CNFSM4IMPWFG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QSTFA#issuecomment-522267028>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACZ7IIK4PVMD3XD3UHHZ2LQFBLEZANCNFSM4IMPWFGQ> .

-- - Michael Please pardon any errors, this message was sent from my iPhone.

[zero-24]

Ok got your point, thanks!

[wilsonge]

Definitely would like to see the health check expanded. If that means for example the database fix button does just fix the database and doesn't also do the outdated file deletion etc. that would be awesome!

[jeckodevelopment]

The idea is really great and useful. A Status/Health dashboard would help ensuring that everything is running as expected.

[brianteeman]

@zero-24 Do you plan to work on this - it's a great idea

[zero-24]

This is not something that I have the time to work on right now.

[richard67]

Not sure if I have enough knowledge and time to work on it, but I will help where I can e.g. with testing.

But whoever will work on it, do me one favour: Don't use silly percentage figures like "99.9 % up to date" or "99.9 % healthy" or so like they do in this "alternative backend template" project. Beside the question how such percentages shall be calculated the main problem with them is that they make people feel safe when they are high, like "99.9 %", but in fact the remaining 0.1 % can be the big problem.

[zero-24]

Two years but no progress when looking into implementing something like that into J5 we should start with a new concept and not use this outdated one from the J3 times. Closing