Enable/Disable View within View Edit page

POC dropbutton (not header)
have to rework the ajax redirect path abit.

add an "Enable View" or "Disable View" option into the edit view dropdown menu

Working on this issue, will review it.

Applied and reviewed the MR, the code which resolve the issue.
It does provide an "Enable View" or "Disable View" option into the edit view dropdown menu.
Attached Before and After screenshot.
RTBC++

#4. I was facing some trouble with ''entity.view.enable' and the ajax return to Main view list. is this addressed? i dont' think i see a code change for it...

- adds ajax route for View Edit Display.
- Standing controller for List View can not be recycled, adds new callback for this purpose.
- page title/doc meta updated triggered 'disabled' added in this ajax step. [forwarding toward #3184588]
-

thanks for the MR! I've manually tested after applying MR6793 on an install of Drupal 11.x-dev (with the umami install profile). I've tested with Safari 17.3.1 on macOS Sonoma. I've noticed one detail. If I try to enable either archive or glossary on /en/admin/structure/views (the already existing functionality) things work flawless. while when i try to enable for example the glossary view on /en/admin/structure/views/view/glossary with the enable view option i run into an error pointing me to the console (but the view gets enabled anyway):

[Error] Failed to load resource: the server responded with a status of 500 () (page_1, line 0)
[Error] AjaxError: 
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /en/admin/structure/views/view/glossary/preview/page_1
StatusText: error
ResponseText: The website encountered an unexpected error. Try again later.Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.glossary.page_1" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 208 of core/lib/Drupal/Core/Routing/RouteProvider.php). Drupal\views\ViewExecutable->getUrl(Array) (Line: 398)
template_preprocess_views_view_summary_unformatted(Array, 'views_view_summary_unformatted', Array)
call_user_func_array('template_preprocess_views_view_summary_unformatted', Array) (Line: 261)
Drupal\Core\Theme\ThemeManager->render('views_view_summary_unformatted', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 110)
__TwigTemplate_ed14baa62805cdaa1c9b79cadc693860->doDisplay(Array, Array) (Line: 394)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template->display(Array) (Line: 379)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 39)
twig_render_template('core/themes/claro/templates/classy/views/views-view.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('views_view', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 53)
__TwigTemplate_1f3ccb4a516dd0dad521be8e40f48fdb->doDisplay(Array, Array) (Line: 394)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template->display(Array) (Line: 379)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 39)
twig_render_template('core/modules/views_ui/templates/views-ui-view-preview-section.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('views_ui_view_preview_section', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 96)
__TwigTemplate_ed14baa62805cdaa1c9b79cadc693860->doDisplay(Array, Array) (Line: 394)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template->display(Array) (Line: 379)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 39)
twig_render_template('core/themes/claro/templates/classy/views/views-view.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('views_view', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 240)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 153)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 152)
Drupal\Core\Render\Renderer->renderRoot(Array) (Line: 66)
Drupal\Core\Render\MainContent\AjaxRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 60)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 736)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

	(anonymous function) (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:250:13550)
	complete (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:250:6041)
	(anonymous function) (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:287:3569)
	c (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:3:25310)
	fireWith (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:3:26055)
	l (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:3:77919)
	(anonymous function) (js_llzDdm887hr8N94dvyD2d6_aJP5C148mb1hAF2kj1yM.js:3:80267)

if i disable the view afterwards via the disable view option there is no error. if i try again to reenable the view the same error takes place again. it is reproducible consistently.

oh and i've noticed one moredetail. if you are on /en/admin/structure/views and you have archive and glossary in the disabled section and you click on edit the archive view, the h1 isn't showing Archive (Content) disabled but just Archive (Content).

Update: the points raised in this and the previous comment apply to the latest version of firefox and microsoft edge as well.

@rkoller
#15
i was testing in Stardard profile. have just re-installed with Umami -- but can not recreate that php error. with claro (theme) in both profiles and another 'normal' drupal frontend theme. again, without an error like yours..
i hope you tested with the second push to that branch. i'm sorry if not!

#16.
I can add the into the first page load too. i'll update the summary for this.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Interesting. I've created a completely new fresh install of 11.x-dev. The one I've previously tested with i did some testing already for a while so it might have had some cruft. i've applied the following steps:

- created a new site with the standard profile (with php 8.3)
- applied the latest patch
- cleared the cache
=> tested and everything was behaving as expected and no error was showing.
- ran ddev drush sql:drop
- reinstalled the site with demo_umami
=> tried to edit one of the disabled views and again the same error showed up.
- i've then set up another fresh site with demo_umami
- applied the latest patch
- cleared cache
=>and i am already getting an error when i am accessing one of the disabled views.

I can copy the console errors into a gist if that helps? but for me it looks like in the standard profile everything is behaving well while in umami there is still a problem.

-->i am NOT using PHP 8.3.
i did test in Umami too, again no error. both with js/css aggregation on or off - works fine.

even d11 dev line is still 8.2!

   */
  const MINIMUM_PHP = '8.1.0';

  /**
   * Minimum recommended value of PHP memory_limit.
   *
   * 64M was chosen as a minimum requirement in order to allow for additional
   * contributed modules to be installed prior to hitting the limit. However,
   * 40M is the target for the Standard installation profile.
   */
  const MINIMUM_PHP_MEMORY_LIMIT = '64M';

  /**
   * Minimum recommended version of PHP.
   *
   * Sites installing Drupal on PHP versions lower than this will see a warning
   * message, but Drupal can still be installed. Used for (e.g.) PHP versions
   * that have reached their EOL or will in the near future.
   */
  const RECOMMENDED_PHP = '8.2.0';

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

i usually tend to use the latest official version of php when testing. but i have two installations now, one with standard and one with demo_umami and i went from php 8.3 down to php 8.1 (using ddev) and no errors and regular behavior for the standard profile install while i get the same error consistently across 8.3 down to 8.1 with demo_umami. :/ anything else i could provide for debugging?

#28
bot is having trouble with the work 'datasource'.

#29 rkoller.
Have continued testing. i have had this happen 'sometimes' too now..
- myself: remaining in php 8.2 all tests.
- umami profile, yes. random
- standard profile, no. do not see after switching 6 times
I do myself see anything that stands out between them. i just can't get the error in standard..

seems like this point has happened before with this same view!
-> i am assuming this means they were enabling from the View List Builder page (/admin/structure/views) as this would be the only other trigger point.
#2738973: Route "view.glossary.page_1" does not exist after disabling the glossary view
#2685343: RouteNotFoundException when a view page is disabled.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

have changed word. bot wins.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

#34 removed debug

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

thanks!

Probably will need submaintainer sign off.

But will require test coverage for all the new routes.

Also issue summary appears to be missing sections. UI change should include screenshots.

Thanks.

@skaught retested with the latest changes in MR6793. For standard everything works without a problem, I am able to enable and disable a view in a row without any errors. For demo_umami that error keeps showing up every time i try to enable a view. The view gets enabled anyway and if i save the error is gone, then i am able to disable the view without an error but as soon as i try reenable again the error shows up again. And i am testing with PHP8.2 as well now.

added grab to summary

#39
i do have to agree, there is something trigging route exceptions for the first display that is the form needs to provide the link back to itself. PHP version is not the cause and there are standing reports about this (linked in related issues).

Have added test using existing 'test_view_status' view for Title/h1 and toggle of the 2 new operation button.

I have checkout to the branch and reviewed the functionality on the View Enable/Disable from the view page. The functionality looks good to me. After enabling the view from view page the view is listed under Enable section and the background color of the view changes to white. Attaching the screenshots of the same. Thank you!!

RTBC +1

thanks. changing status.

hm not sure, the error is still happening on my end if the site is using the demo_umami install profile?

and one thought about the micro copy (but i suppose that could be covered in a follow up issue in an issue where the h1/page title is tackled holistically). leaving the term disabled at the end of the h1 and page title has the disadvantage that anyone skimming the title might jump off after the context is clear. for sighted users not necessarily a problem, they notice there is "more" and they just HAVE to read the entire h1/page title. but screen reader users might only follow the announcement until archive (they know they are in the overall context of views) and then jump off and not necessarily know there is more. therefore frontloading the state might be a good idea. in the context of #2514218-101: [regression] Pages Manage Fields, Manage form, Manage display should include name of content type or entity we've agreed on a front loading pattern for content types but never discussed anything aside that like how and where to communicate a state. but probably better suited for a follow up issue and taking a look at things at a whole.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

testbot is having issues

I agree this functionality seems useful but I wonder if we have a problem with the fact it automatically applies? All the other changes in this list that make immediate changes to the view go to a confirmation - for example the delete view. The other things in this list stage the change first and then you have to press save before making changes. I think immediately disabling or enabling the view from this action button breaks that expectation. As I don't see any discussion of this usability issue on this issue setting back to needs review.

Thanks.
Myself, I. simply was not under any impression that this dropdown needed that kind of rule for items in it -- as a user is just looking to change status. Delete understandable uses a confirm form.
It is the same that on the View List Page the dropdown links do just change status.

I actually did think about adding it to the 'Edit View name/description' as this is the rest of the items a view needs. But the title alone is already not clear what a user will find here.. ie: uses edits 'tags' here which aren't seen anywhere'.

one possibility UX todo:
-add radio group *enabled/disabled" on 'Edit View name/description' (a modal form) with a label: 'View Status'

I would also think that the new item in the dropdown would behave the same as others in the dropdown. Canceling it doesn't work. But, it's easy to just reenable so not a huge deal IMO.

In today's UX meeting #3427743: Drupal Usability Meeting 2024-03-22 we were able to review the point raise in #51 about this dropdown introducing a non-modal task. Shortly, it had been realized the Views List Page does already allow for the enable/disable to be instance whereas the delete task does trigger a model, The Edit of course is a regular link and page load. There in we are within our own consistency..

I had directly brought up the idea of adding radios for status to the 'edit/description' first link (a modal with title, description, tags) but it was felt that placing here wouldn't isn't helping the user to find the status control point more readily.

Key reminder: a user may have gotten to edit a view through a context link of a block that has a disabled view, not coming form the UI list.

Thanks all! returning to RTBC.

My point was not about it being a non modal task. My point was about it making a change on the page that takes place and it happens immediately, when you are on an edit page with a save button. Delete is fine because it takes you somewhere else and you confirm. And the views listing page has no save button and thereby unrelated. Wrt to the key reminder, if the view is disabled you're not going to get at it view a contextual link in a block. If you do disable a view which is providing a block you will see the following test everywhere

This block is broken or missing. You may be missing content or you might need to install the original module.

And no contextual link the view to fix it. So that rather is an argument for not making this so simple.

And one more thing about disabling a view... looking at \Drupal\views\Entity\View::postSave

    // Rebuild the router if this is a new view, or its status changed.
    if (!isset($this->original) || ($this->status() != $this->original->status())) {
      \Drupal::service('router.builder')->setRebuildNeeded();
    }

it causes a router rebuild. So flicking this from on to off and back again can cause your site to come under serious strain.

#58 During the run through we did touch on the fact that a user does not have to save the entire view. It was still felt to be acceptable.

#59. understandable that toggling a view has load fallout. either from the List Builder page, or the individual View instance that would be the same load if a user toggle several times sequentially for whatever reason. Of course, just Flicking the switch back and forth isn't the goal here for a user [user abuses their own site (:].
IMO: As THIS user has access to Views, we should hope they have a good level of information around these types of sitebuilding points.

Mr. @alexpott
with the wisdom to introduce this toggle to a confirm form -->> Is there a message you might suggest to use for that confirm_form

with this, the List builder page should be switched that toggle to also use that same message, for consistent messaging.
is that a follow up issue (after this)??

I would think that the message would mention that disabling a view will make all it's display's including blocks and pages inaccessible. If the view has a block display I would go the extra mile and inform the user that disabling this view can result in user's seeing a message about a broken block.

I think the list builder going to a confirm form can be handled here too as it should not be much to change.

thanks.
'in act to disable' a view, show a message "Disabling this view will make any Page or Block Displays defined to become inaccessible. Route caching will also be cleared, this may cause a short-term increased server load."
'in the act of enabling a view,' show a message "Notice: Enabling a View will clear route caches. This may cause a short-term increased server load."

@SKAUGHT sounds great.