Problem/Motivation

We have some confirm forms that are more destructive than others. For example, the module uninstall confirm form can result in deleting large numbers of configuration entities, dropping database tables etc..

This came up whilst reviewing a new feature to delete content entities prior to uninstallation of a module where it was suggested that we swap the buttons and mark the delete all button as a danger button. See #2688945-90: Allow removing a module's content entities prior to module uninstallation. Eventually we decided not to do that because of UX concerns.

Proposed resolution

Some proposed designs so far have included one or more of these elements:

  1. A modal confirm form, like the node preview links provide.
  2. An extra field that forces the user to type in "Delete".
  3. An extra checkbox that is something like "Yes, I really want to delete all these things."
  4. Making the destructive operation link-styled instead of button-styled.
  5. Using more red.
  6. Swapping the position of the "Do it" and "Cancel" buttons.

Remaining tasks

Review the design.

User interface changes

API changes

Data model changes

None

Screenshots

Modules

http://127.0.0.1:8888/admin/modules/uninstall/confirm

Module

Themes

http://127.0.0.1:8888/admin/appearance

Uninstalling a theme displays no warning even though all of the theme's blocks are deleted.

Nodes

http://127.0.0.1:8888/node/16/delete

Nodes

Block: Custom

http://127.0.0.1:8888/block/1/delete

Block custom

Block Block layout (Remove)

http://127.0.0.1:8888/admin/structure/block/manage/umami_search/delete

Block layout

Book: Main

http://127.0.0.1:8888/node/BID/delete
Book Main

Book: Page

http://127.0.0.1:8888/node/NID/delete
Book Page

Comment

http://127.0.0.1:8888/comment/COMMENT_ID/delete

Comment

Contact form

http://127.0.0.1:8888/admin/structure/contact/manage/feedback/delete

Contact form

Content type

http://127.0.0.1:8888/admin/structure/types/manage/article/delete

Content type

Field

http://127.0.0.1:8888/admin/structure/types/manage/article/fields/node.a...

Field

Image style

http://127.0.0.1:8888/admin/config/media/image-styles/manage/large/delete

Image style

Media type

http://127.0.0.1:8888/admin/structure/media/manage/audio/delete

Media type

Media entity

http://127.0.0.1:8888/media/1/deletee

Media entity

Menu

http://127.0.0.1:8888/admin/structure/menu/manage/example/delete

Menu

Menu: Link

http://127.0.0.1:8888/admin/structure/menu/item/1/delete

 Link

Language

http://127.0.0.1:8888/admin/config/regional/language/delete/es

Language

Taxonomy: Vocabulary

http://127.0.0.1:8888/admin/structure/taxonomy/manage/recipe_category/de...

 Vocabulary

Taxonomy: Term

http://127.0.0.1:8888/taxonomy/term/27/delete

 Term

Text format (Disable)

http://127.0.0.1:8888/admin/config/content/formats/manage/basic_html/dis...

Text form

User (Cancel)

http://127.0.0.1:8888/user/2/cancel

User

User: Role

http://127.0.0.1:8888/admin/people/roles/manage/administrator/delete

 Role

Views

http://127.0.0.1:8888/admin/structure/views/view/articles_aside/delete

View

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott created an issue. See original summary.

xjm’s picture

Title: Introduce some friction into super destructive operations in confirm forms » Come up with a design for highly destructive operations in confirm forms
Issue summary: View changes
Related issues: +#2468045: When deleting a content type field, users do not realize the related View also is deleted

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mpdonadio’s picture

For a confirmation for a dangerous operation, I think we also need to make accessibility a high priority.

I think that modals may be a bad idea here, but would defer to A11Y team.

Link-styled vs button styled may not appear as different to some users.

Red text (on its own) may not look different to people with certain forms of color-blindness (color should be an enhancement, not sole indicator, of dangerous).

The tab-order of the Action and Cancel buttons is definitely wrong (Action comes before Cancel in the tab-index and render order). The Action is also the sole submit input in the form (so it is the default action).

A textfield or checkbox sound like the best options. Both could also take advantage of #states to enhance the experience. You could also argue that this would be the least disruptive fix. We could create a DangerousConfirmFormBase that extends ConfirmFormBase to implement this behavior, and then just swap out base classes where needed.

joachim’s picture

> Swapping the position of the "Do it" and "Cancel" buttons.

That's not a good idea at all. People remember the position of things and often don't even read the labels of things when they recognize a UI pattern. So that could lead to a lot of lost data when people are intending to cancel!

> Making the destructive operation link-styled instead of button-styled.

Same with this. Links don't mean an action that changes something, they just take you somewhere else.

In both of cases, it's a bad idea to take a UI element that at a glance looks safe to users and make it destructive instead.

alexpott’s picture

@joachim I agree! I think swapping the buttons and making destructive things links are bad ideas - the list in the summary came from suggestions in #2688945: Allow removing a module's content entities prior to module uninstallation

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

xjm’s picture

We should also possibly file or find a Drush PR and relate it here since Drush is not informing the user at all (as in the above issue).

Bumping to major since any bug users encounter from this will feel like data loss, even when they are confirming the change.

yoroy’s picture

masipila’s picture

We've been discussing this topic with @yoroy in the context of #2876085: Before upgrading, audit for potential ID conflicts. The UX team will discuss this later in a call today.

The proposed UI, still to be discussed in today's call, looks like this:
Proposed UI for the confirmation

I personally think that this has a lot of good elements:
1. It is accessible.

2. It doesn't do surprise the user like some of the proposals in this issue (button swap, changing the button to a link).

  • We don't want to prevent the user from confirming...
  • We want that the user understands what he / she is doing.

3. Re-using the standard 'warning' message is a very good idea IMO to catch the attention of the user. And using the yellow 'warning' instead of red 'error' is the correct way to handle this in my opinion.

4. Brief and understandable explanatory text combined with an optional link to documentation helps the user to judge if he / she the consequences.

5. Using a label other than 'OK' in the button also helps to do the same.

Cheers,
Markus

Edit: typos, formatting.

webchick’s picture

Interesting. That extended button would definitely capture attention.

masipila’s picture

The UI for the migration ID conflicts was improved further after the UX review.

Improved UI.

Cheers,
Markus

yoroy’s picture

See the attached gif: https://www.drupal.org/files/issues/destructive-action-confirmation.gif for a fun in-place way to do a check-double check on a destructive action button.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick’s picture

Adding #2935790: Configuration change data loss prevention functionality inconsistent, restrictive as a related issue; this presents both a UX problem as well as a DX problem. Maybe something we can revisit at a future UX meeting.

andrewmacpherson’s picture

Accessibility - @mpdonadio already made some good points, just want to add some.

Making the destructive operation link-styled instead of button-styled.

I don't see any value in this, if we're just talking about appearance. Buttons are more prominent than links - are we just hoping users won't notice the destructive option, if we make it smaller...? @joachim already made the point about buttons and links being totally different things anyway.

Using more red.

Nothing wrong with using more red, but on it's own this isn't an inclusive design. It needs to address WCAG 2.0 "Use of Color" i.e. not relying on colour alone. I think what this really means is look more dangerous, so red is fine but a dangerous looking shape (icon. heading, ...) should be part of it too. Of course, the actual button text is the most important bit.

I think that modals may be a bad idea here, but would defer to A11Y team.

Nothing wrong with using modal dialogs here, but there is an interesting gotcha with double keypresses. When a dialog appears, focus moves to the first operable control inside the dialog's main content area. But if there isn't any operable control in the main content, focus will move to the first button in the dialog footer. (This behaviour comes from jQuery UI dialog.)

If you're using a pointer, the delete button and the confirm button are in different locations, so you have to move your pointer to the dialog to confirm.

But using a keyboard (with or without assisitve tech) you press space-or-return to operate the delete button, a dialog opens and focus moves immediately to the confirm button, which is also operated with space-or-enter. If you accidentally press space-or-enter twice, you delete the data. I have managed to make this happen reliably. I noticed it last week when testing #2830584-246: Use modals for creating, updating, and deleting workflows, with a new DialogFormTrait, and have left detailed steps-to-reproduce there.

When the confirmation step is a separate page, focus goes to the start of the document. There's no risk of accidentally confirming it with a double keypress, because the user has to move focus down through the document first.

If we use a dialog, whose content is just a message, we should find a way to avoid putting focus immediately onto the confirm button. Putting focus onto the cancel button would be one way to do this. An accidental double keypress would be harmless in that case.

Note: This can also be mitigated by the "Slow Keys" accessibility option available in most operating systems. But double-presses can happen to any keyboard user, and many don't use Slow Keys.

Desktop applications are inconsistent about which buttons they focus first when a simple confirmation dialog opens. I noticed that KDE's Dolphin file manager puts focus on the confirm button for deleting files, but KTorrent puts focus on the cancel button when deleting a partly-downloaded torrent. I think it could be worth looking at what the human interface guidelines from Microsoft, Apple, Google, Gnome, etc. say about this.

Re: #15 - the button pattern @yoroy mentioned would also have this risk of accidental double-press, worse because it would also put pointer users at risk too, because delete and confirm are in the same place.

If we use dialogs, it would be good to follow the pattern for role="alertdialog" instead of role="dialog". Not sure if that's possible at present, but it's not a must-have.

Swapping the position of the "Do it" and "Cancel" buttons.

This has a some merit, if we use a confirm dialog, as a way to avoid putting focus on the confirm button. Swapping the order of the confirm/cancel buttons would make cancel the first button in the dialog footer, which gets focus when the dialog opens. But this isn't the same as explicitly putting focus on the cancel button, it's just exploiting the jQuery UI fallback order.

Tagging needs accessibility review, wherever this goes I'd like to look at it again before we're finished. Sign-off, like.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

webchick credited ckrina.

webchick’s picture

@TravisCarden brought this to the UX meeting today.

What we discussed was the idea of providing a DestructiveConfirmInterface (or similar), that encapsulates the following behaviour:

- Existing settings from the existing ConfirmInterface. (Title / Message / etc.)
- Displays a list of sub-elements that will also be deleted.
- Provides an access check that must be passed in order to delete sub-items (tied to a permission or similar).
- Displays the confirm form in a modal vs. a separate page (common UX pattern)
- Maybe as well, the ability to give different "tiers" of destruction? ("Highly" == Red, "Moderately" == Orange, etc.)

Ideally, we would convert everything in core to this new API/UI, and make it available and encouraged for contrib authors as well. (Deprecate the existing one for removal in Drupal 9?)

Another suggestion was to create a global setting for this, to dictate the behaviour of all destructive options (shut it off entirely; only allow for people > XXX permissions; also delete sub-items or only allow deletion if all sub-items are gone...). This would allow sites to customize the behaviour for their use case.

A good starter use case to build some mockups around would be taxonomy. Vocabularies contain terms, and while you might want authors to be able to delete individual terms, you probably don't want them to be able to delete entire vocabularies along with terms, at least unless they have a higher permission level.

Questions
Should Content Entity delete vs Config Entity delete form have slight different UX?
Config Entities currently show all the related config files; ideally these would be human-readable.

@jrockowitz offered to take on a research task of figuring out all of the various ways in which Drupal presents deletion so we can try and extract patterns on the next meeting.

masipila’s picture

Thanks for the update @wechick, eagar to see progress with this!

#26 is quite much around content deletions and related permission checks. I would like to remind that we have also other use cases which can be considered as potentially destructive, see for example #12 and #14. The additional permission checks do not fit to that kind of scenarios very well.

It is of course possible to use the current confirmation capabilities for uses cases like #12 (like we today) but I wanted to drop this comment to at least mention this.

Cheers,
Markus

jrockowitz’s picture

Issue summary: View changes

I have added screenshots and URLs to issue summary for most of core's delete/remove/disable confirmation forms. There are at least 26 unique confirmation forms in core.

I am using the Umami demo or standard profile with the new Evaluator Guide's.

php core/scripts/drupal quick-start demo_umami
php core/scripts/drupal quick-start standard

My personal thoughts after looking at all these screenshots…

  • Anytime a delete/remove/disable impacts other content or config, this information should always be displayed.
  • Moving 'This action can't be undone' into a warning message could improve the UX.
  • Deleting content entities vs config entities has slightly different ramifications.
  • Deleting certain config entities is recoverable if the config is exported.
  • The confirmation should indicate the level of destructive based the entities or items context. For example, deleting a single term is no big deal but deleting a term with child term is big deal.
jrockowitz’s picture

Issue summary: View changes
jrockowitz’s picture

I just watched the usability meeting recording from October 9.

A few thoughts...

Anytime something is being deleted there should be three things displayed...

  • What is being deleted (Object, entity, or plugin)
  • What else is being deleted (Relationships, records, etc...
  • Confirmation that the end-user wants to continue.

There could be three different levels of destruction which alter the above three things...

  • Minimally destructive - SImple delete
  • Highly destructive - Major delete
  • Blocked - Thing can't be deleted

The warning's color could hint at the level of destruction.

  • Blue/Info - Minimally destructive
  • Orange/Warning - Highly destructive
  • Red/Error - Blocked

The confirmation could have different levels.

  • Confirm button - Minimally destructive
  • Confirm checkbox (check delete) + Continue button - Highly destructive
  • Confirm textfield (type delete) + Continue button - Completely destructive

"What else is being deleted" should be grouped by content entities, config entities, and maybe relationships. For example, deleting a vocabulary deletes content and config entities. Having a generic description with a link to what is content and configuration could be helpful. Finally, "What is being deleted" could be placed in a collapsed details widget to prevent scrolling.

benjifisher’s picture

I like the idea of using the standard info/warning/error classification, with standard colors, as suggested in #31. But I think the confirmation should follow the same classification, and "Completely destructive" does not seem to fit.

Whether we use a checkbox or a text field or something else is to be determined, but either seems like a good starting point for discussion.

One existing pattern I have seen for "blocked" actions is a list of "you must first delete entities of these types" messages, with links for each one. I do not remember off hand how to reproduce that.

benjifisher’s picture

Issue summary: View changes
benjifisher’s picture

I did an inventory of the design elements in the screenshots in the issue summary. Note that most of the screenshots do not count as "highly destructive", and can continue to use the standard confirmation form (ConfirmFormBase).

  • Element / Example
  • Select list / Replacement stlye (when deleting an image style)
  • Radios and/or Checkboxes / (options when deleting a user account)
  • Title / "Confirm uninstall" or "Are you sure you want to remove the block Search?"
  • Message / This action cannot be undone
  • List of items that will be deleted / ...
  • Prompt / Would you like to continue with uninstalling the above?
  • Confirm and Cancel buttons / Delete, Cancel

The list of items to be deleted is sometimes in a collapsible fieldset.

Sometimes, the message includes other text in addition to the standard "This action cannot be undone." Sometimes they are separate paragraphs, sometimes not.

Some elements are only used on one or two of the forms: Select list, Radios, Checkboxes, Prompt. It seems to me that a short title and a prompt (with the prompt directly above the buttons) is clearer, although only one of the screenshots (uinstalling a module) uses this pattern.

None of the current confirm forms uses the standard notice/warning/error message indicators.

benjifisher’s picture

We discussed this issue at the weekly UX meeting a week ago (October 9).

We agreed that deciding which deletions count as "highly destructive" is not in the scope of this issue. We should provide a design. If that design cannot be implemented easily with the standard ConfirmFormBase, then we should also provide another base class for implementing the design, either in this issue or in a follow-up. Anywhere the design (or the new base class) is used is self-identifying as a "highly destructive" operation.

One advantage of having a new base class is that we will be able to find where it is used, and then have a list of these operations.

One thing we did not decide was how much structure to impose on the information being presented. Should we let the implementer provide an arbitrary form snippet or should we impose more structure?

benjifisher’s picture

At the UX meeting today, we discussed this issue and came up with the following proposal.

The "highly destructive" confirmation form should include the following elements. They will all be required, and some will have default values:

  • Title
  • Message (displayed as a warning)
  • Information on what else will be deleted
  • Checkbox with a prompt
  • Confirm and Cancel buttons

The Confirm button should be disabled until the checkbox is selected.

The screenshot from #14 seems like a good starting point, except that the long text on the confirmation button would become the prompt next to the checkbox. The list of what will be deleted might be put into one or more details element.

In addition to the required elements, the design will make some recommendations:

  • Keep the title short. "Confirm uninstall" (when uninstalling a module) is a good example. The longer text currently used as a title in many cases can be used as the prompt next to the checkbox.
  • Provide information on what else will be deleted:
    • List the additional deletions (or count of items and a link to the list).
    • Indicate the relationships that will be affected.
    • Estimate and/or warn of the time it will take to do the mass deletion (batch processing)? E.g., node grants and search indexing.

Here are some examples of relationships that should be called out:

  • Deleting a vocabulary will delete the terms in that vocabulary and the references to those terms.
  • Deleting a role affects the users with that role.
  • Deleting a user affects any content authored by that user.
  • Deleting a field affects the content types and views that depend on it.
andrewmacpherson’s picture

Note that most of the screenshots do not count as "highly destructive",

The discussion is missing something important: what does "highly destructive" mean? Comment #31 compares it with "minimally destructive" but I don't think we have a basis for classifying an operation as highly vs. minimally destructive.

andrewmacpherson’s picture

The list of what will be deleted might be put into one or more details element.

What's the benefit of that?

If we show a closed details group, that's effectively hiding the very consequences that we're trying to warn the user about.

If we show an open details group, how does the ability to close it help?

jrockowitz’s picture

benjifisher’s picture

@andrewmacpherson:

what does "highly destructive" mean?

(Your comment #37.) I already addressed that question--or maybe I dodged the question--in #35:

We agreed that deciding which deletions count as "highly destructive" is not in the scope of this issue. We should provide a design. ... Anywhere the design ... is used is self-identifying as a "highly destructive" operation.

If we show an open details group, how does the ability to close it help?

(Your comment #38.) I am not insisting on a details element. Just a suggestion. But if the list of stuff-to-be-deleted is overwhelming, then making it collapsible might be a convenient feature.

ckrina’s picture

FileSize
48.21 KB

Here's a quick visual example of what we discussed last week and with some changes done during this week's UX call:

Uninstall confirmation page

jrockowitz’s picture

I spent some time reviewing all the delete forms in core and came up with the below editorial patterns. I am trying to see if there is a way to abstract some basic editorial guidelines/recommendations.


TITLE: @action @title @item

WARNING: Are you sure you want to @action @title @item? This action cannot be undone.

EXPLANATION: @action @title @item will…

  • Delete this @item configuration
  • Delete (all or X) (related|associated) @other_items
  • Delete (all or X) child @sub_items
  • Affect (all or X) (blocks|entities|styles) that display this @item
  • Change (all or X) @dependencies to @result
  • Remove (all or X) references to this @item
  • Take a (long time|few minutes) to complete

UPDATES: Configuration changes

  • Configuration deletions
  • Configuration updates

POST ACTION: Replace @title @item with [select menu]

CONFIRMATION: [checkbox] Yes, I want to @action @title @item?

ACTION: (Delete|Confirm|Continue) or Cancel

jrockowitz’s picture

I wanted to experiment and understand the level of effort required to rework a core or contrib module's delete confirmation UX, so applied the general wireframe from #41 and editorial #42 to the Webform module.

The change record includes screenshots . I am planning on updating the webform module's delete confirmation layout, components, and editorial to follow this ticket's final recommendation. BTW, opening delete confirmation within a modal is beyond the scope of the tickets but works well for the Webform module's UX.

I found clearing stating 'This action will…' helped make it easier to document what exactly is going to happen when someone clicks 'Delete'. I also feel the shorter page title format (i.e. Delete Contact webform?) works better because it directly states what is being deleted.

benjifisher’s picture

@jrockowitz:

Thanks for this great work! The generic recommendations really benefit from the time you have spent looking at lots of real-world examples.

The only thing I would do differently is make the title even shorter. The name of the item being deleted also appears in the warning message and in the text next to the checkbox, so I do not think we need it in the title as well. Also, we do not use italics in the title, which makes it hard to identify how much of the message is the name of the item. Taking the first screenshot in the change record, for example, I suggest making the title just "Delete webform?".

jrockowitz’s picture

@benjifisher Thanks for the feedback.

I think in the modal dialogs using just 'Delete webform?' is a better UX but when the delete confirmation is opened in a dedicated page the page title might need to be a little more descriptive and also does support italics.

ckrina’s picture

Here's the design proposal discussed during today's UX call with @jrockowitz and @benjifisher, but text needs to be redefined.

anavarre’s picture

That's a nice improvement already. Couldn't the DSM embed everything we need to know about the issue directly? (I didn't initially see the error description below). Something like:

The Basic page content type is being used 8 times on your site. You may not remove this content type until you have removed all of the Basic page content first.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

maxilein’s picture

A list of the concerned pages should be included:

The Basic page content type is being used 8 times on your site. You may not remove this content type until you have removed all of the Basic page content first.

Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8