🇳🇴Norway @vegardjo

Hi, thanks a lot for taking the time to look at this!

I have tested it with first having required the module normally, and added 2 pages. It loos like this then:

Then cloned the MR, ran the database update, and edited the records to add an admin title, and it now looks like:

Also tested to add record without admin title, removing admin title, changing password and various to see if anything was affected, which it was not. So in short, works as advertised as far as I can see and does to me (not surprisingly) add value to the module :)

thorandre → credited vegardjo → .

Marking as fixed as this can now be handled via a custom event subscriber.

Tested on 2.9 using this as a patch file: https://git.drupalcode.org/issue/gutenberg-3452390/-/commit/6f173ec402ea... and it solves the problem.

This is sadly a regression from 🐛 Render custom classes for dynamic blocks Fixed , also present in 2.9, Doxigos (👋) fix should do it.

I can confirm that using field group module, adding a new "details sidebar" group, and adding the moderation state to that group works:

url fix

improved example

made code block more readable

added doc for new event

Thanks for the effort, @fjgarlin!

I do however agree that we could just remove the list on these pages. I don't see the scenario "I am reading documentation for one specific module, and need fast access to documentation for all the other modules" as very likely.

A quick fix could even be swapping the list for one link "See documentation for all modules" that goes to https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → , then the scenario above would be solvable both through this link and the breadcrumbs.

vegardjo → created an issue.

I've released alpha4 that includes this event + added documentation here: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → (with your use case as example code)

finished documenting the event

Hi, thanks for your feedback! As it happens I have a similar case myself, so I am doing some changes that I aim to release in a new alpha shortly.

There are 2 relevant changes upcoming:

• Instead of hard coding username to be UPN, you will get a choice between UPN or email.
• I will add en event you can subscribe to, where you can alter the data you save on the user before saving it. If the first change is not sufficient, you are able to do your logic in that. I will make a documentation page for it.

Hi, could you please make a release containing this fix?

I just did this in twig today. I have added a new (media) image field to my remote video entity, and a view mode for my remote video entity called "small". The view mode has two fields, the new image field, and the thumbnail field. 

Twig file is: media--remote-video--small.html.twig

With content:
 

{%
set classes = [
'media',
'media--type-' ~ media.bundle()|clean_class,
]
%}

<div{{ attributes.addClass(classes) }}>

  {% if media.field_alternative_thumb is not empty %}
	{{content.alternative_thumb}}
  {% else %}
	{{content}}
  {% endif %}
</div>

There's also a similar preprocess solution here: https://drupal.stackexchange.com/a/286296/4723 

Branch no longer supported, use 2.x branch

I see now that I got a new issue after I made a 2.x-dev branch, so that's the answer.

Hi, this is the issue https://www.drupal.org/project/entrasync/issues/3430280 📌 Automated Drupal 11 compatibility fixes for entrasync Needs review on version 1.0.0-alpha3, on the 1.x branch that will not be used anymore. Yesterday I released https://www.drupal.org/project/entrasync/releases/2.0.0-alpha1 → , on the 2.x branch, where I would like these in the future.

But if I understand you correctly, there will be posted a separate issue for the new branch(es) then, I just need to wait till the bot finds time to do it? There is no rush, I just wanted to understand if I needed to do anything actively to make it happen :)

vegardjo → created an issue.

vegardjo → created an issue.

Hi, thanks!

I tested this on a fresh GB install, and got the errors that BlockControls and Toolbar was not defined. I guess you had them loaded from a different block.

Also, didn't get Toolbar to work, but the more recent ToolbarGroup + ToolbarButton did, so switched it, and after this the changes work as advertised.

Using GB 2.8 and Drupal 10.2.3.

This makes a lot of sense for the external communication, and this is also how I have pitched Drupal since 8, without maybe having reflected a lot on it.

There are several sides to pitching Drupal, and one quite rare one is that some clients are tormented by an earlier 7 to 8 upgrade. For these I simply explain that 7 to 8 was a rewrite, not an update, and this is not how we do it now. However, this is actually in the past, and for the majority of prospective new clients / users it is simply not relevant, and ought not to be a part of the discussion.

For new clients we present an evergreen model. You pay a monthly fee and you are always on the latest version. If that is called 9.3, 10.4 or 11 is not relevant. Much like I myself don't know which version number the browser I'm using to write this in has, except that it is the latest.

The other side of this is that pitching version numbers also gives an expectation that you get something new and fancy when you bump version, while this is seldom true for the editors and end users. It also gives the impression that innovation is bound to version numbers, which is equally not true.

Most visible innovation / change for clients in my experience happen when introducing for instance Gin, Gutenberg, Paragraphs ecosystem, Layout Builder ecosystem, Webform, or simply new and smarter ways of building their functionality, or improvements to design / theme. And all this goes async to core version numbers.

I figured it out, we had an implementation of hook_leaflet_views_feature_alter() that altered $feature['popup'], and that after the update needs to alter $feature['popup']['value'] instead.

Hi, I also have this issue after upgrading to d10 and then Leaflet 10.2.12 on a project. The DOM for the .leaflet-popup-content is simply empty.

There are no console errors or php logs. The issue is both in views, and when the field is rendered through the field formatter on a node. Tried with php 8.1 and 8.2.

I have tried making a complete new view with one node, and configured the view display again. Whatever I put as Popup Source below Leaftet Popup har the same result of nothing rendered. Also, both "Leaflet Tooltip" and "Simple Tooltip" works as it should.

Did anyone figure this out?

vegardjo → created an issue.

I had the same issue, and solved it with changing the owner in the database. First access the container with ddev ssh, then use psql to run the following:

DO $$DECLARE r RECORD;
BEGIN
    FOR r IN (SELECT tablename FROM pg_tables WHERE schemaname = 'public') LOOP
        EXECUTE 'ALTER TABLE IF EXISTS public.' || quote_ident(r.tablename) || ' OWNER TO db';
    END LOOP;
END$$;

I also ran this for sequences, but didn't test first if it was actually needed:

DO $$DECLARE r RECORD;
BEGIN
    FOR r IN (SELECT sequence_name FROM information_schema.sequences WHERE sequence_schema = 'public') LOOP
        EXECUTE 'ALTER SEQUENCE public.' || quote_ident(r.sequence_name) || ' OWNER TO db';
    END LOOP;
END$$;

Note: this worked for me, by help of chatGPT. It is not an area I know deeply, so do backup first and use at own risk!

Takk for møtet!

Alternatively reference to https://www.drupal.org/project/siteimprove_analytics → on the project page if this is not in the scope for this module.

vegardjo → created an issue.

I made a very quick search in the code base and found 40 results in 13 files for \Drupal::service, so I think that this particular issue can be closed, as the php error will no longer happen, and then refactoring to use DI everywhere could be done in one or more new issues.

No tests still, but MR of last patch created ☝️

vegardjo → made their first commit to this issue’s fork.

More context: https://drupal.slack.com/archives/CCTTWUN87/p1706861598178329 - thanks to codebymikey for guidance!

vegardjo → created an issue.

Seems like nested templates also have a problem if you add a dynamic block (block rendered with template) to it. In the case below where text/gb-orgmanager is a dynamic block, the block will only render in edit mode, and not show when you save. If it's not a dynamic block it works fine.

[
    ["core/group", {"className": "header-container"}, [
        ["drupal/simple-text", {"placeholder": "Insert title","tag":"h1"}],
        ["text/gb-orgmanager", {}]
    ]]
]

Thanks folks, it was indeed the wrong reference, I have fixed it to refer to the graph_key instead :)

Thank you, merged!

vegardjo → made their first commit to this issue’s fork.

You can try this as the patch file, as it also applies on 4.0.3, but please test beforehand :)

https://git.drupalcode.org/project/smart_date/-/commit/15d9092432fecccde...

Thanks, this is the module that is using it BTW: https://www.drupal.org/project/entrasync → - not having API many calls as of yet, so still fine to use the 1.x version

Thank you! Merged

vegardjo → made their first commit to this issue’s fork.

Thanks! Fixed :)

vegardjo → made their first commit to this issue’s fork.

I believe this is php 8.2 related, and not Drupal version related, see: https://php.watch/versions/8.2/dynamic-properties-deprecated - also there is no release on the 4.0 branch that has this fix, so people on 4.0.3 with php 8.2 will see it :)

I actually have some similar weird behavior, also with a node type called event. 

I have a view of search results, where all results renders as entities in the view mode "search_index". 

I have a template file node--search-index.html.twig to make all nodes render the same. 

This works as it should for 5 other content types, but simply not for event. The twig output says this for the others:
 

<!-- FILE NAME SUGGESTIONS:
   * node--view--site-search--search-results.html.twig
   * node--view--site-search.html.twig
   * node--164--search-index.html.twig
   * node--164.html.twig
   * node--article--search-index.html.twig
   * node--article.html.twig
   x node--search-index.html.twig
   * node.html.twig
-->

(note the x, indicating chosen template file)

but for event it says this:

<!-- FILE NAME SUGGESTIONS:
   * node--view--site-search--search-results.html.twig
   * node--view--site-search.html.twig
   * node--174--search-index.html.twig
   * node--174.html.twig
   * node--event--search-index.html.twig
   * node--event.html.twig
   * node--search-index.html.twig
   x node.html.twig
-->

..so for events it choses the node.html.twig instead of the one above that it should, and that it choses for all other content types. 

If I make a node--event--search-index.html.twig, it will chose this instead, and all is fine, so there is nothing wrong with the configuration in neither the view or the content type. There is also no preprocess logic in place. 

vegardjo → created an issue.

I updated the documentation for this at https://www.drupal.org/docs/contributed-modules/gutenberg/gutenberg-bloc... →

I also updated the title, but the navigation link in the sidebar to it needs to be updated accordingly, and seems a documentation maintainer would have to do that.

However, adding this also results in a php warning per custom block you add, at /admin/structure/types/manage/[bundle], so I believe this should also be fixed before we can close this.

Warning: Undefined array key "default" in {closure}() (line 303 of modules/contrib/gutenberg/gutenberg.module).
{closure}(Array)
array_map(Object, Array) (Line: 305)
gutenberg_form_alter(Array, Object, 'node_type_edit_form') (Line: 545)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'node_type_edit_form') (Line: 840)
Drupal\Core\Form\FormBuilder->prepareForm('node_type_edit_form', Array, Object) (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->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: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Added documentation to manage custom blocks as well 

Gutenberg cloud is AFAIK being deprecated 

Added documentation for mapping rich text fields, added more readable formatting on the code examples, and moved the old deprecation notice to the bottom of the page instead of the top. 

Seems the solution in #2 has been committed as part of https://www.drupal.org/node/3329297 → in alpha4, not tested it, but patch does not apply anymore, and code is updated: https://git.drupalcode.org/project/h5p/-/blob/2.0.0-alpha4/src/Plugin/Fi...

Hi guys, as with Alison I'm not quite getting this. I have upgraded on an existing site + a vanilla d10, and I have no UI for custom modules. On my vanilla I have installed this custom block which I would expect to find in the UI:

const settings = {
  title: __('Factbox'),
  description: __('Block with title and content that can be aligned'),
  icon: 'info-outline',
  attributes: {
    title: {
      type: 'string',
    },
    alignment: {
      type: 'string',
      default: 'full'
    }
  },

  edit({ attributes, setAttributes }) { ... }
  save({ attributes, setAttributes }) { ... }
}

const category = {
  slug: 'text',
  title: __('Text'),
};

registerBlockType(`${category.slug}/gb-factbox`, { category: category.slug, ...settings });
 

Patch from #7 works for me too when using the https://graph.microsoft.com/oidc/userinfo endpoint (have not tried other settings)

vegardjo → created an issue.

Thanks Stephan, the patch did indeed fix the problem 🙂

vegardjo → created an issue.

vegardjo → created an issue.

Hi, I can't reproduce #7.

I have tested this with 3 different roles, one that has only the "administer unmanaged files", one that has only the "administer unmanaged files settings" and one that has none, and it works like expected. I had to clear cache after applying the patch, though.

vegardjo → created an issue.

FWIW: I experienced this on a fresh 10.0.7 minimal install, including not being able to set a title on the page. Turned out I hadn't ticked the box "use admin theme for adding / editing content" below the admin theme setting. As Gutenberg pretty much takes over the admin theme this wasn't obvious to see first.

Looks like this was handled in the 2.6 release here, and that this issue and patch is deprecated: https://git.drupalcode.org/project/gutenberg/-/blame/8.x-2.x/src/Form/Bl...

Hi, this patch is no longer applying for me on Gutenberg 2.7 (but also not able to recreate Toms error above with the webform block). Deprecated?

Good point, with a single file change it's probably best to add it to the commit instead, anyways a nice trick! :)

Thanks, can confirm that this works too.

@joco_sp: I didn't know you could get the patch file URL directly from GitLab, I've only seen the download option before. Is there a UI I'm not seeing here, or you simply have to know to add .patch on the URL? (I also found it works directly at a PR too: https://git.drupalcode.org/project/draggableviews/-/merge_requests/18.patch) - In any ways: thanks for the tip :)

I don't think this should be marked as fixed. The "Open file browser" is present in the default CK link tool, so that is not the issue.

This is related to the Gutenberg 2.6 release somehow. Downgrade Gutenberg to 2.5 and it appears again. It also works in the 3-dev version (but on my site I could no longer edit content with that version, so be aware).

Just a small note on the patch from #97, there is a mixup in the last 3 digits: It's named 2473898-97.patch while it should be named 2473989-97.patch.