🇭🇺Hungary @Gábor Hojtsy

gábor hojtsy → created an issue.

@luukyb: it is a requirement yeah but Drupal should be more graceful when this happens and not overwrite the plural handling?

I don't think anything changed with this in the meantime.

balintbrews → credited gábor hojtsy → .

balintbrews → credited gábor hojtsy → .

Flag "administer languages" as "restrict access".

I think this makes the most sense.

Thanks a lot, good find!

Woah did the job run the analysis on all of those date spots that the MR includes dumps of JSON results for?

I think this is fine, we need to tell the community as soon as possible to give them time to do stuff they were planning quicker now as long as it is possible.

Agreed. Experience Builder already has previews in multiple viewports and the design system used should support this there.

I have not seen recent designs for content type editing, but Lauri presented a UI for mapping dynamic fields from content types to props in https://youtu.be/5ViCxc8ksb4?si=TqFStM83dgjzJTw7&t=942 (this timestamp going forward) that is based on the same UI based editing as XB for static pages, so I assume that is roughly what will happen. (Those are designs not working implementation).

I don't think this needs to be in core, it can work / improve better in contrib I think alongside the rest of the tooling.

With Drupal CMS it is not possible to add modules and content without adding them to core. Eg Drupal CMS could include this kind of messaging somewhere. There was a lot of discussion as to how to do a friendly support experience that does not require a drupal.org account right away, which is where I would start drawing the user in. That should be a related issue to this one and issue moved to Drupal CMS?

Experience Builder turns the node form inside out and you edit the content on a preview-first UI with the form on the side. I think that solves this problem?

Are there benefits for the whole ecosystem in this additionally to SDCs that are in core?

I believe this will now be within the realm of Experience Builder. Not sure if there is a corresponding XB issue, but XB explicitly provides mobile/desktop previews and may support variance based on viewports?

Hm, introduce custom hooks rather than a generic hook?

gábor hojtsy → created an issue.

You did not include a change in formatTree() but you rely on a change I think? Why not solve the formatting inside the format methods for global errors?

Anyone tested this other than roderik? Not that I don't trust roderik but a second set of eyes would be great :)

Anyone tested the suggested changes? :)

Can you post your config file that is reporting the problem?

Thanks for digging that up! Merged!

This was added in 🐛 Core config validatibility CI job stopped working on April 20 because Drupal core now requires SQLite 3.45 Fixed what made it unnecessary now?

Opened 📌 [PP-1] Parse recipe packages and make available on localization server Postponed for l.d.o integration and marked postponed on this as first we need to make sure we have a tested way for potx to parse recipes packages before we unleash l.d.o on them :)

gábor hojtsy → created an issue.

I think this is a reasonable start, however we still need the config action strings extracted, when they are translatable things. We don't have reasonable outside sources to verify which are those, so that needs explicit YAML markup I think. Maybe that could be a followup.

What would be good here is a test that has a recipe and proves these work. The text could include config shipped with the recipe and a test that ensures that is parsed too. Which should already work? (Famous last words? :D)

1. I think ✨ Extract strings from Recipes Active is a good one and simple one to make the labels of the recipes itself translatable.

2. Also config shipped with the recipes should be translatable (is it already?).

3. But finally what's not yet being solved and where I suggested the in-place YAML format support is config action values, eg. if you have a config action that updates the title of the a menu item or a views display etc that will save as-is and not translated.

Good point! Fixed.

I think the current problem is the code does not allow for different icons at all, it is hardcoded to one icon for all entities. I don't think this should be quite given to the user as an option, but the developers of the entity should be able to specify an icon, practically I think in the entity PHP annotation / attributes. Then the icons could be swapped with a different icon set assuming a contrib for that on the site or possibly the entity definition altered for even more icon customization. But the core module I don't think would need a UI to upload/change these icons only.

balintbrews → credited gábor hojtsy → .

Following 📌 Make gitlab pages for governance.drupal.org Active , I updated the URL redirects that went to the md files before.

I made the pipeline run on the MR, not sure if I've seen this as a maintainer of the project only, but this is where it allowed me to run it:

https://localize.drupal.org/translate/languages/uk/translate?project=dru... is places where a p tag is used in core.

https://api.drupal.org/api/drupal/core%21modules%21locale%21locale.modul... shows the p tag is allowed in core. So I don't think this is about the p tag?

Hm, https://drupal.org/governance already redirects to the gitlab page?

When I google for Drupal Governance, I get https://www.drupal.org/project/governance → as the first result. That did not have a clear CTA that lead to docs, so I updated it to have a big blue button. Is this helpful? I'm not sure a subdomain is a significant improvement over this as long as people use search anyway to find it?

griffynh → credited gábor hojtsy → .

Yeah downloading the translation files could be very well parallelized, if d.o file server can handle the load :) Importing them I'm not sure can be parallelized since importing a .po file can have far reaching effects on dozens of config files at once. Then the importing next .po file is has effects on another dozen files, some overlap with the previous, etc.

Also the tricky part about this may be that the installer language import updates default config en masse so we nee to be careful what other config saves we allow at the same time as they may go over each other :)

kristen pol → credited gábor hojtsy → .

kristen pol → credited gábor hojtsy → .

gábor hojtsy → changed the visibility of the branch 11.x to hidden.

gábor hojtsy → changed the visibility of the branch 3508649-use-drupal-core to hidden.

📌 Use Drupal Core Leadership Team for all the maintainers Active landed, so this is next :)

Can you provide config schema examples as to what is currently possible for the two scenarios of '0' and 'channels', and what you think should address 'node'?

kristen pol → credited gábor hojtsy → .

I understand my concerns were preexisting and/or out of scope, agree with the RTBC.

What kind of framework manager review is needed here? Is that tag still current?

When a region is configured in XB, that is saved in page region config entities, NOT as block placement entities see https://git.drupalcode.org/project/experience_builder/-/blob/0.x/docs/co...

When a region is configured in XB, that is saved in page region config entities, NOT as block placement entities see https://git.drupalcode.org/project/experience_builder/-/blob/0.x/docs/co...

Similar to #3511866-14: Create SDDS global footer config → , I think there was a misunderstanding here? I think we would thruthfully demonstrate the current features of XB if there would be a general header region, rather than it being subdivided and a column (or header column) component placed to set the layout up there with menu blocks placed and the learn more button component placed within it.

Hm, I think there was a misunderstanding somewhere. XB has native global region management. While that could mean moving and placing blocks in numerous footer regions, the real content creator power is in being able to adjust the footer layout as you see fit, since that is a core/key feature of XB. So 📌 Too many global regions Active is fundamental to this at first, that is for the theme to pare the regions down significantly to much simpler options. Then the user would be able to create multicolumn stuff in the footer if they so desire with XB components, columns, image components, etc. (SDDS could ship a default component setup for that region).

Building a page with components and managing global regions with components only gives user the flexibility if the global region is broad enough and not a Footer middle 3, a Footer bottom 2, etc.

I agree the UX is confusing of empty regions not being exposed in XB, needing to place stuff in the content and then moving it. After that though double-clicking on/into the region makes it possible to adjust it, which is for me at least natural. The initial part of how one tries to use it is confusing.

I think 📌 Too many global regions Active must be solved before this issue or as part of this issue first because otherwise you don't have a clean region to place the header onto. Otherwise I don't think this should be help up in trying to get it perfectly blend in with the hero/design at all :)

The philosophy of themes in the age of XB is that the theme will NOT provide these top, bottom, side, 1, 2, 3 regions, but the laying out of wider "Header", "Footer", etc. regions would be left to XB. So heaving a "Header top 1", "Header top 2", etc. are not demonstrating what the feature is meant to lead to. You would have a Header region and place a columns component there is you want to subdivide it, or more components above/below it if you need placement above/below. This would/will be the task of components not the theme. Hence this issue. I think this is fundamental to allow for ✨ Add SDDS global header styling Active and ✨ Create SDDS global footer config Active .

The sidebar is a similar situation but we probably want to sidestep that for now (maybe remove all sidebar options), since we don't have a good way to solve that and not enough time left :)

kristen pol → credited gábor hojtsy → .

Indeed, my bad. Yay!

Dries will demonstrate using XB with its xb_page entities, which would be good to use here :) Support for editing articles with XB is a developer-only feature. I think copying the internal field structure of the article node to an xb_page will work from the exported YAML file without manually recreating it again :) Under the components property. https://github.com/phenaproxima/xb-demo/blob/main/recipes/xb_demo/conten... is a very simple such entity.

The module has very basic smoke tests, I think its fine to land this without needing to hold it up on tests.

Being able to easily edit the translations is a separate problem from being able to translate them I think. Let's try to focus on translating recipes here?

Adding the related Gin issue at 🐛 Dialog styles are not loading correctly in Experience Builder Active so they are easier to find.

Is this a Gin issue then and not a toolbar issue? Should we move to the Gin project?

gábor hojtsy → created an issue.

I think the pieces of the recipe where translatable pieces may appear are not predictable like that? Which is why I suggested !translate in #3 above. Or do you see a way we can predictably say which parts will be translatable? I think they would depend on whether the config they reference for example are translatable, which I'm not sure we can resolve?

Opened 📌 Document icon should show when viewing Experience builder pages Active for lack of customization of the icon in XB.

Retitled and updated IS for the narrower scope here, so this can be merged then.

gábor hojtsy → created an issue.

Opened 🐛 Icon in navigation top bar cannot be customized Active for lack of icon API.

gábor hojtsy → created an issue.

I think the one line MR here can happen without waiting on upstream and its a quite crucial piece of UI to expose ASAP :) Should I open a separate issue and postpone this on that or should we repurpose this issue?

The icon problem is indeed larger and will take more time.

kristen pol → credited gábor hojtsy → .

1. Re black edit button @lauriii:

It is perfectly fine if we don't install the gin toolbar module, which is a sensible choice if we use the core top bar :)

Gin toolbar enabled (but not used):

Gin toolbar not even enabled (note not only button white text but button placement is nicer):

Opened https://github.com/phenaproxima/xb-demo/issues/24 to fix that in the demo.

2. Re navigation followup issue @wimleers:

Opened 📌 Local task name expectation in getFeaturedPageActions is fragile Active .

3. Re the icon:

After various Slack discussions, navigation module does not have a way to customize that and SDC's don't have altering or preprocess functionality to change it. I'm not sure we should hold up the Edit button fix (which is pretty fundamental, it exposes the first visible way to enter XB ever). So should we rescope this issue or open yet another one under this? :)

gábor hojtsy → created an issue. See original summary → .

For the DB icon, I'm trying to figure out how to alter the SDC component specified in the top bar context plugin code. Cited in #3 above. I did not find generic alter/preprocess hooks for plugins like this, neither components. Eg. https://www.drupal.org/docs/develop/theming-drupal/using-single-director... → documents this use of SDCs but provides no guidance on altering.

I tried some tips from chatgpt which turned out to be hallucinations :) Also searched the API docs and general google but did not turn up much. That said, I expect this is something simple but I can't see it :D

This one line fix MR makes the edit button show as expected :)

1. So the icon seems to be hardwired to the database icon in core? The Home node on xb-demo also has a db icon:

The code is in Drupal\navigation\Plugin\TopBarItem\PageContext:

    $build += [
      [
        '#type' => 'component',
        '#component' => 'navigation:title',
        '#props' => [
          'icon' => 'database',
          'html_tag' => 'span',
          'modifiers' => ['ellipsis', 'xs'],
          'extra_classes' => ['top-bar__title'],
        ],
        '#slots' => [
          'content' => $entity->label(),
        ],
      ],
    ];

2. For the edit button, the Drupal\navigation\Plugin\TopBarItem\PageActions plugin has this code:

  protected function getFeaturedPageActions(array $page_actions): ?array {
    $featured_page_actions = [];
    $current_route_name = $this->routeMatch->getRouteName();
    $canonical_pattern = '/^entity\.(.+?)\.(canonical|latest_version)$/';
    if (preg_match($canonical_pattern, $current_route_name, $matches)) {
      $entity_type = $matches[1];
      $edit_route = "entity.$entity_type.edit_form";
      // For core entities, the local task name matches the route name. If
      // needed, we could iterate over the items and check the actual route.
      if (isset($page_actions['page_actions'][$edit_route]) && $page_actions['page_actions'][$edit_route]['#access']?->isAllowed()) {
        $featured_page_actions[$edit_route] = [
          'page_action' => $page_actions['page_actions'][$edit_route],
          'icon' => 'pencil',
        ];
      }
    }
    return $featured_page_actions;
  }

I was not sure why this does not end up being featured, because the route IS entity.xb_page.edit_form which matches the core pattern and the pattern expected here. The entity.xb_page.canonical is the canonical view route, so it should get to the pattern match. Then I found that the local action name is not the same as the route name, so that is it. Once again a one line fix :D Will submit a MR to XB here for that.

The icon is harder I think since core just hardcoded the db icon.

More enticing title :P

NOT TRUE, my 5th drush rebuild worked and I created a simple two column table view of pages with Edit links with the one line change MR above.

uuid: 937af821-a7c8-4779-9130-8f725f57da4e
langcode: en
status: true
dependencies:
  module:
    - experience_builder
id: pages
label: Pages
module: views
description: ''
tag: ''
base_table: xb_page_field_data
base_field: id
display:
  default:
    id: default
    display_title: Default
    display_plugin: default
    position: 0
    display_options:
      fields:
        title:
          id: title
          table: xb_page_field_data
          field: title
          relationship: none
          group_type: group
          admin_label: ''
          entity_type: null
          entity_field: title
          plugin_id: field
          label: ''
          exclude: false
          alter:
            alter_text: false
            text: ''
            make_link: false
            path: ''
            absolute: false
            external: false
            replace_spaces: false
            path_case: none
            trim_whitespace: false
            alt: ''
            rel: ''
            link_class: ''
            prefix: ''
            suffix: ''
            target: ''
            nl2br: false
            max_length: 0
            word_boundary: true
            ellipsis: true
            more_link: false
            more_link_text: ''
            more_link_path: ''
            strip_tags: false
            trim: false
            preserve_tags: ''
            html: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: true
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_empty: false
          empty_zero: false
          hide_alter_empty: true
          click_sort_column: value
          type: string
          settings: {  }
          group_column: value
          group_columns: {  }
          group_rows: true
          delta_limit: 0
          delta_offset: 0
          delta_reversed: false
          delta_first_last: false
          multi_type: separator
          separator: ', '
          field_api_classes: false
        edit_xb_page:
          id: edit_xb_page
          table: xb_page
          field: edit_xb_page
          relationship: none
          group_type: group
          admin_label: ''
          entity_type: xb_page
          plugin_id: entity_link_edit
          label: ''
          exclude: false
          alter:
            alter_text: false
            text: ''
            make_link: false
            path: ''
            absolute: false
            external: false
            replace_spaces: false
            path_case: none
            trim_whitespace: false
            alt: ''
            rel: ''
            link_class: ''
            prefix: ''
            suffix: ''
            target: ''
            nl2br: false
            max_length: 0
            word_boundary: true
            ellipsis: true
            more_link: false
            more_link_text: ''
            more_link_path: ''
            strip_tags: false
            trim: false
            preserve_tags: ''
            html: false
          element_type: ''
          element_class: ''
          element_label_type: ''
          element_label_class: ''
          element_label_colon: false
          element_wrapper_type: ''
          element_wrapper_class: ''
          element_default_classes: true
          empty: ''
          hide_empty: false
          empty_zero: false
          hide_alter_empty: true
          text: Edit
          output_url_as_text: false
          absolute: false
      pager:
        type: mini
        options:
          offset: 0
          pagination_heading_level: h4
          items_per_page: 10
          total_pages: null
          id: 0
          tags:
            next: ››
            previous: ‹‹
          expose:
            items_per_page: false
            items_per_page_label: 'Items per page'
            items_per_page_options: '5, 10, 25, 50'
            items_per_page_options_all: false
            items_per_page_options_all_label: '- All -'
            offset: false
            offset_label: Offset
      exposed_form:
        type: basic
        options:
          submit_button: Apply
          reset_button: false
          reset_button_label: Reset
          exposed_sorts_label: 'Sort by'
          expose_sort_order: true
          sort_asc_label: Asc
          sort_desc_label: Desc
      access:
        type: none
        options: {  }
      cache:
        type: tag
        options: {  }
      empty: {  }
      sorts: {  }
      arguments: {  }
      filters:
        status:
          id: status
          table: xb_page_field_data
          field: status
          entity_type: xb_page
          entity_field: status
          plugin_id: boolean
          value: '1'
          group: 1
          expose:
            operator: ''
      style:
        type: table
        options:
          grouping: {  }
          row_class: ''
          default_row_class: true
          columns:
            title: title
            edit_xb_page: edit_xb_page
          default: '-1'
          info:
            title:
              sortable: false
              default_sort_order: asc
              align: ''
              separator: ''
              empty_column: false
              responsive: ''
            edit_xb_page:
              sortable: false
              default_sort_order: asc
              align: ''
              separator: ''
              empty_column: false
              responsive: ''
          override: true
          sticky: false
          summary: ''
          empty_table: false
          caption: ''
          description: ''
      row:
        type: fields
        options:
          default_field_elements: true
          inline: {  }
          separator: ''
          hide_empty: false
      query:
        type: views_query
        options:
          query_comment: ''
          disable_sql_rewrite: false
          distinct: false
          replica: false
          query_tags: {  }
      relationships: {  }
      header: {  }
      footer: {  }
      display_extenders: {  }
    cache_metadata:
      max-age: -1
      contexts:
        - 'languages:language_content'
        - 'languages:language_interface'
        - url.query_args
      tags: {  }

This looks good to me, the edit tab works as expected (opens XB). Visual will of course be different using the updated top bar and 📌 Integrate with the Navigation Top Bar Active but that is not in scope for this issue. The MR also is as simple as I expected :)

gábor hojtsy → created an issue. See original summary → .

wim leers → credited gábor hojtsy → .

gábor hojtsy → created an issue.

Lauri demonstrated this option to get into Experience Builder in Singapore.

Since 📌 [PP1] Show entity information on the Top Bar Postponed there is a nice Edit button (no other actions, such as Delete or other tabs are exposed anymore), and there is no entry point to XB anymore. Is this supposed to be already in place as before or that would be for this issue to figure out? I was assuming XB would "simply" take over the edit button?