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?
Hm, I am told that the text may refer to the saved sections themselves being possible to change/update later, not that their placements being editable separately from each other. Either way I think "Unlike components" are still very confusing. The only way users can customize components is by editing props and slots and that is always per copy of component, not global. So I don't understand what "unlike components" is supposed to mean here.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
Noticed some Drupal 7 and 6 related content that I could not resist to remove :D RTBC should still stand IMHO.
One more title update to reflect difference from 📌 Use Drupal Core Leadership terminology in MAINTAINERS.txt Active .
gábor hojtsy → created an issue.
Correct title. Subsystem maintainers are also maintainers.
This looks perfect to me! Let's get it in? Will send to the leadership team for the 2 week veto period :)
@joseph.olstad: how long would be LTS in your definition? We announced how core LTS is happening in November 2023 at https://www.drupal.org/blog/drupal-10-will-be-supported-until-the-releas... → , that provides at least 18 months of support for a major Drupal version after the next major version is released.
Drupal Infra:
🐛 drupal.org error 500 page twitter widget is unusable Active is the specific page about the 500 error page, it goes back a bit. I think that in line with @jr_kthor above, that would need to be moved off of not embedding an X feed anymore for sure. Since Drupal infra is on mastodon too, please post any easy ways to embed that feed there in that issue :)
Drop is moving
I manage @dropismoving on these social medias. These are current follower counts:
- Bluesky: 93 (only been running for 2 months, I ran it earlier for a year, but did not work out, trying again now)
- Mastodon: 216
- LinkedIn: 423
- X: 2362
So only looking at this may make people believe X is super valuable. At the same time X engagement has been going down rapidly either way. Eg the Drupal 11.1 announcement looks like this:
It has not really been replaced by Mastodon sadly. Eg. the same post on Mastodon:
Bluesky is even less. What I found working REALLY WELL for Drop is Moving is LinkedIn. Same post there:
Not sure if the same is true for other types of Drupal social media, but this is how Drop is Moving works. I would not remove the account from X as per above to keep the namespace / pointer, but it has not been providing much value for a couple years now either way.
I think https://www.drupal.org/project/drupal_brand → is a great idea to collect all the things and manage issues against it. Thanks for the figma version!
@catch wrote this:
So if I'm reading correctly this would be adding a direct-write mode when a flag is set, but only for project browser. The idea being you can composer require new dependencies and the simple act of doing so won't blow up your site, whereas update might.
Overall that sounds great I think.
I agree. There is already the package_manager_change_log
entries that document what package manager requested and then separately logged what actually happened in composer, which helps providing a paper trail of what it did.
I also think we can trust composer itself probably better to not leave your composer.json/lock
and vendor files in a half applied state than our own code that copies that over from the composer staging, so I don't see added risk there.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
On visual review, the feature looks and works great.
However there is a range of screen width where the dialog goes out of the viewport, even though the page content (eg. toolbar, messages, etc) are not. This is odd on the type selection, but one can still move forward. However not purely inconvenience after that, because the form buttons to go forward are not visible. There is no scrollbar to get to them either, so one can only tab to them and attempt to press blindly :)
Minor note (don't spend time on fixing this to get it in IMHO) but I think the "Choose a type of field" label looks very odd. It is tiny compared to the massive selection options under it (I do realize this is the standard label size). The whole dialog does not look like a form (it does not even have a button), so the red asterisk feels out of place (those belong on forms :D). Also this label does not add anything to the dialog, we already know we are adding a field, I don't think the label clarifies anything about the selection below. Either way, I don't think it is worth debating this part at least not to holding up anything :)
The responsive behaviour would be good to fix though IMHO as it makes it impossible to use the feature on certain screen sizes.
The fact that they are in separate issues could still mean they are to be done before this or after :) Can you clarify that answer? Thanks!
This was posted as an idea 12 years ago, then nobody jumped on it or expressed a need, so I think it is safe to consider this not needed :)
The remaining tasks in the issue summary are all in other issues, does that mean they are followups or pre-requisites? This would be important to make it clear :)
Also, there are no outstanding review comments on the MR, anything in particular to review or just looking for general feedback?
Finally, the MR tests were failing, but a spot-check lead me to believe they are unrelated. The file download PHPUnit test and the a CK5 image test was failing. Sent for a retest.
@pameela: why would it not be deployable? Either Project Browser / Package Manager could gracefully degrade in non-writable environments or the host can suggest/include config_split to exclude the UIs that are not going to work on prod environments or they can suggest/add UI affordances to tell users about the workflow to use (involving going to their hosting UI or embedding part of the hosting UI) for the least inconvenience.
@phenaproxima/@greg.1.anderson: wow, good finds, a core bugreport would be great with a fix :)
surabhi-gokte → credited gábor hojtsy → .
Plan looks good, but it would be good to make sure to have rock solid info in 📌 Remove UI and routes for the ability to update modules and themes via update.module and authorize.php Active , such as lack of composer support, potential conflicts of dependencies, we believe people don't use it, etc. :) When ultimately people who are missing the feature will come :)
I bought Bluehost's cheapest plan today. They install WordPress in every single plan automatically. It takes a lot of care to find where to install Drupal but one can go to their Hosting page, then find the "Cpanel" link (I know this, but not sure general people would know what Cpanel is). Then scroll all the way to the bottom. Drupal is not listed there. CMS/Portals is a category that is offered, and THAT lists Drupal 11.
This is on a software called Softaculous that is embedded in CPanel. It has 3 Install buttons for Drupal, one does not do anything, the second only switches to other install options, the real one is placed near a "Send instructions in email" field, which is strange and I was ready to receive the instructions in email. But it did attempt to install. It cannot install because .htaccess and index.php were present (from WordPress). It offered to replace them or for me to pick a subdirectory. It would not replace the whole of WordPress, just those files, so I went with a subdirectory. It installed SUPER FAST then. Now I have a Drupal 11 site inside my WordPress site.
Not sure we can suggest Bluehost by any means (even once/if Softaculous offers Drupal CMS too). That said, it did install Drupal 11 in a matter of seconds, so Softaculous has it figured out very well apparently :)
thejimbirch → credited gábor hojtsy → .
gábor hojtsy → created an issue.
jjchinquist → credited gábor hojtsy → .
Does this mean that package signing is practically all rolled out?
This is now ready: https://packages.drupal.org/8/metadata/
Making title more explicit for sharing :)
I think there are some extra considerations for Drupal CMS, due to the size of shipped packages especially with Experience Builder (which was an issue for Drupal Forge for example recently). Also memory requirements, and similar things. But otherwise I think the testing is similar indeed.
However I think ultimately we would want documentation about Drupal CMS running on shared hosts, so from that perspective, running the process with Drupal CMS itself would be best.
Adding automatic updates hosting test issue, where I tested Dreamhost and Siteground. Those test issues are at https://www.drupal.org/project/issues/search?issue_tags=hosting%20test →