#Needs product manager review

I've been meeting to revisit but I've tried to remove that body creation feature and default config and it is definitely tricky. Hit failures everywhere.

@pameela it's not a blocker to starshot contrib efforts, but I think it's at least a soft blocker to core integration. We originally decided to remove text with summary about eight years ago in 🌱 Deprecate text_with_summary Closed: duplicate but it didn't happen at the time.

To fully deprecate install profiles in core and provide recipe selection in the installer, we need to convert Umami and Standard profiles to recipes. When we convert them to recipes, the constituent parts of those recipes may/should also be re-usable recipes, but then they need to make sense.

Umami was using the text + summary field type despite not using the summary anywhere (as in, none of the content populates the filed, and the special formatter for it is never used), recently changed in 🐛 Don't use text_with_summary in Umami Needs review .

Standard also uses text with summary, but it's not a good basis for building a site from (IMO, I always make a completely separate summary field if needed). So if we want the current core install profiles to work nicely together based on common recipes for an article content type etc., we need to clean this up.

The approach in #16 worked well for us — thanks @aludescher!

One note: be sure to add 'converterPriority' => 'high' to your new options, e.g.:

  $options[] = [
    'model' => 'headingFancy',
    'view' => [
      'name' => 'h2',
      'classes' => 'fancy',
    ],
    'title' => t('Heading 2 (fancy)'),
    'class' => 'ck-heading_heading2_fancy',
    'converterPriority' => 'high',
  ];

Without that, added options likely won't still be selected on subsequent edits of the content. Standard options that operate on the same element (in this case 'Heading 2') will take precedence.

@taote you might be missing a use statement for CKEditor5PluginDefinition at the top of your module file:

use Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition;

The change in the merge request and what the title says doesn't really correspond. the body field *storage* is regular default config, what this changes and removes is the automatic addition of the field itself, aka the per-bundle auto-configuration.

@sime could you provide a bit more info about what makes this a Starshot blocker?

I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

Yes this is going to be one of the harder pieces. We can probably cover a lot if we keep track in the user's session that they started a batch (probably the batch ID), check the session on every page request to see if we need to show the batch element, and then the element resumes where it left off if there's a batch still running. Then finishing a batch needs to clear $_SESSION['active_batches'] or similar.

IMHO this sounds fantastic. For its use in the installer, but also in other cases, I think its important that it actually runs through, which is what may be hard to ensure. I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

Note there's now a stable trash module in contrib https://www.drupal.org/project/trash →

I haven't personally used it, but I believe it is the result of @amateescu's comment in #50.

The release managers discussed this at the end of May and I am only now commenting. We noted that this is part of the Workflow Initiative but that initiative has ended and there isn't anything here for us to review. We also are aware that there is the Trash module and a core issue to move that to core, 📌 Add experimental Trash module Active .

This issue was also closed; as won't fix in 2017 and then re-opened in 2019. But since then there has been no activity here despite a prompt for more information 2 years ago. After 5 years without comment here from someone from the workflow initiative it seems sensible to restore the won't fix from 2017.

And, if that there is a desire to add this to core, then it would be better to start fresh with a new initiative or plan. Therefore, I am going to close this. I trust someone will correct that if it is wrong.

No longer postponed on Workspaces

Also if we were to add this, I think it should be its own filter doing this generally for all site-relative links, not within the file reference filter.

For example https://www.drupal.org/project/rel_to_abs → provides this in contrib.

The issue summary doesn't explain the problem with relative URLs, why is this a problem?

Additionally, Drupal sites can be run from multiple domains, using domain module and similar. Relative URLs allow this to work, I don't think we're able to cache text formats by arbitrary cache contexts so it would probably break that.

Yeah, one could work locally with DDEV or with a binary (both desktop or in the browser, see https://mglaman.dev/blog/running-drupal-edge-webassembly) and commit the changes to some repository or data availability protocol in general (Github, traditional or decentralized hosting).

I've opened 🌱 [meta] Streamline the UI installer Active which is more about re-organising the order of the installer with project browser et al - installerless Drupal doesn't mean anything if you still have to choose an install profile in step 2. So I'm postponing this issue on that (and moving it to core since I can never find it when I'm looking for it).