Skip to content

[RFC] Add Configuration notices widget to overview and edit pages in backend #1506

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nestordedios opened this issue Jun 18, 2020 · 6 comments
Assignees
Labels
Milestone

Comments

@nestordedios
Copy link
Collaborator

I don't know if this is already possible with some extra configuration but at this moment the Configuration notices widget is displayed only in the Bolt Dashboard /bolt.

For a more user friendly experience, I think this notices should also be added to the overview /bolt/content/{contenttype}, new /bolt/new/{contenttype} and edit pages /bolt/edit/{recordID}.

I think it would be good to get these notices throughout the biggest part of the backend so the user will get notified when navigating throw overview and edit pages. It would be even better if this could be done async, so there was no need to refresh/reload the page to get this notices.

Making this notices more visible will make users more aware of these notices. It has happened to me that:

  • I added a new Contenttype
  • I reloaded an edit record page (where I was at that moment) to see the new added Contettype on the left menu
  • Directly created a new record of the new Contenttype following the options of the menu
  • Missed the notice that said I needed to do a cache clear after I added the new Contenttype.

Dasboard overview page

notices-in-dashboard

Edit page

no-notices-in-edit

New record page

no-notices-in-new

Contenttype records oveview page

no-notices-in-overview

@bobdenotter
Copy link
Member

I'm not sure yet, if we should..

Thing is: If we put it on many places, people will develop a blind spot for it, as opposed to it sticking out like a sore thumb (as it should, imho).

Apart from that, we'd need to consider if it has a negartive impact on performance. I think some of the tests are a bit CPU-intensive. 🤔

I'd be happy to hear opinions from other people on this, as well.

@I-Valchev
Copy link
Member

Maybe we can find some common ground here.

I think it's pretty common when you're developing (as an implementer) to not look at the dashboard page. For this, I think it's helpful to have it more often and on other pages too. + it only shows when there's an issue, not otherwise.

For performance, it'll definitely be annoying to have it run all the time. Once the disable extension button is implemented, people will be able to disable it on production, after making sure all is fine. Hence, no extra CPU burden, right? :-)

@I-Valchev I-Valchev reopened this Jun 19, 2020
@bobdenotter
Copy link
Member

I'm not fond of disabling this.. From Bolt 3 we know the most important check this extension does is: "Hey stupid! You've left DEBUG on in PROD, and now your cache folder is rapidly consuming all of your disk space". If we advise people to disable it on PROD, you'd miss out on these.

@nestordedios
Copy link
Collaborator Author

I agree on what @I-Valchev said here:

I think it's pretty common when you're developing (as an implementer) to not look at the dashboard page. For this, I think it's helpful to have it more often and on other pages too. + it only shows when there's an issue, not otherwise.

on reply to @bobdenotter:

Thing is: If we put it on many places, people will develop a blind spot for it, as opposed to it sticking out like a sore thumb (as it should, imho).

I understand having it enabled in more places might be CPU consuming but I don't think this is the only thing it warns about in Bolt 3.

"Hey stupid! You've left DEBUG on in PROD, and now your cache folder is rapidly consuming all of your disk space". If we advise people to disable it on PROD, you'd miss out on these.

Why I opened this issue is not to discuss what this extension does, should do, tell or not. I'm thinking more about the experience of a non experienced (or even experienced) user that might find himself trapped when things are not going smoothly and a certain notification could have saved some troubleshooting.

See examples of Bolt 3 when user gets notified that the database needs to be updated (This notifications are not only on the Dashboard page):

Database update notification in content overview page

bolt-3-notices-overview

Database update notification in content edit page

bolt-3-notices-edit

@bobdenotter
Copy link
Member

I've come around on my opinion, and i think we should show these notices on other pages as well.

There's one tricky thing, though. We can currently only target one location for a widget: https://github.com/bobdenotter/configuration-notices/blob/master/src/ConfigurationWidget.php#L24

I've made a separate issue, of this wider problem: #1585

@bobdenotter bobdenotter added this to the Bolt 4.1 milestone Jul 1, 2020
@bobdenotter
Copy link
Member

Closing this, because we'll handle this in #1585

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants