🇭🇺Hungary @Gábor Hojtsy

Is this still implemented as in the video in #10? That is not what the issue summary explains?

This does imply a UX change. Previously, if you went to the "Browse" tab, you'd get a whole Project Browser with all sub-tabs visible. Now, you won't. Each tab exposed by a source will link you to a single-source Project Browser page. If you want to see the whole Project Browser, with the sub-tabs, you'll need to explicitly go to /admin/modules/browse.

In the video, I think the Browse tab alongside the Recipes is confusing. "Recipes" is also browsing stuff. Also the Uninstall alongside the recipes is confusing, as you can't uninstall recipes, but you can uninstall some of the things from some of the other tabs :) At least I think browse would need to be renamed if that stays as the "Add extension" screen or so.

I think we do agree that a larger overhaul of what is the Extend section is in order, but it would be good to arrive at a little improved middle ground from what is on the video IMHO for the meantime.

xjm → credited gábor hojtsy → .

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

As a Drupal product manager, I think the feature makes sense as a directly working button.

Did not get into 11.1.

gábor hojtsy → made their first commit to this issue’s fork.

xjm → credited gábor hojtsy → .

@phenaproxima: I think a very brief installation section like as we have is a good idea here because some people will find it and would want to know. If there is an official install docs somewhere we can/should link there, but I don't think there is.

My main gripe is that we are including the RC1 link here, but would be good to not need to update it all the time :D

gábor hojtsy → changed the visibility of the branch 3491303-refine-ddev to active.

I think the leadership team was meant to be the "extended core committer team", so this structure. Started updating the text to this, but it definitely needs more work.

- **Project Lead**: The chief decision-maker for the project.
- **Leadership Team**: A team, including the Project Lead with varied skills who make decisions about the general direction of the project. Roles within the leadership team are:
  - **Product Managers**: Focus on user-facing features and Drupal's user experience.
  - **Framework Managers**: Focus on cohesiveness of Drupal's architecture, APIs, and developer experience.
    - **Backend Framework Managers**: are collectively responsible for PHP, bash, and database APIs.
    - **Frontend Framework Managers**: are collectively responsible for Twig, HTML, CSS, and JavaScript APIs.
  - **Release Managers**: Focus on processes to increase release stability, and on facilitating effective collaboration among contributors.
  - **Team Facilitator**: responsible for meetings within the core leadership team, with the Drupal Association, and with the community.
  - **Initiative Facilitator**: helps with multiple initiatives and assist individual initiative coordinators to work effectively with the core team and other initiatives.
- **Committers**: A subset of the Leadership Team. People who can commit changes to Drupal core itself.
- **Subsystem Maintainers**: Maintainers of one particular part of Drupal core, such as the Entity system or Comment module.
- **Topic Maintainer**: Subject-matter experts in a topic that spans multiple subsystems—Accessibility, Documentation, Performance, Testing, and Usability. These correspond to the [core gates](https://www.drupal.org/core-gates) which all proposed changes must pass.
- **Initiative Coordinator**: Community members appointed by the Project Lead to coordinate strategically important work. Initiatives are typically cross-functional in that they span different subsystems and different topics, and can affect both Drupal the product and Drupal the framework.

There seem to be contradictions in the current proposed text, where the leadership team is defined as people with commit access, while also defined separately as being wider than the people who are the core committers. I'll try to propose something.

Hm figured out that https://git.drupalcode.org/project/drupal_cms/-/wikis/Contributing-to-Dr... is not actually in the codebase so an MR cannot help there :D How can one contribute to the wiki? :)

gábor hojtsy → changed the visibility of the branch 3491303-refine-ddev to hidden.

gábor hojtsy → created an issue.

Updated top bar explanation based on discussion with @ckrina

Adding to highlights

gábor hojtsy → created an issue.

Re changing html_date in Drupal CMS, core's html_date is Y-m-d, which is to be used for HTML output, eg. datetime attributes and input elements for date input. See https://developer.mozilla.org/en-US/docs/Web/HTML/Date_and_time_formats, so I don't think changing that to something user facing is a good idea, browsers may not understand the updated format where it is actually used in the HTML source as intended.

In general we should stay away from messing with the html_... date formats, they are spec defined :)

So that leaves us with the long, medium and short date format in core, and all of them contain the time. I agree a date format in core for date only (without time) would be good.

Link to sample release schedule instead of outdated blog post

The default (failsafe) schema of YAML does not include !translate, however

All nodes with the “!” non-specific tag are resolved, by the standard convention, to “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” or “tag:yaml.org,2002:str”, according to their kind.

per https://yaml.org/spec/1.2.2/#failsafe-schema -- which I understand that tools are expected to resolve custom tags as sequence, map or string based on which syntax was used above them. So !translate followed by a string would/should be understood as string when applied to a string by a YAML tool following the failsafe schema.

At least YAML 1.2 allows for tags that allow us to define custom data types https://yaml.org/spec/1.2.2/#tags, then we would need to respond to the !translate type with wrapping it in translation at runtime and extracting it statically. Not sure how wide support for this is in tools.

key: 12
another: !translate This text will be translated

I think this makes sense, it fits into the philosophy we are taking Drupal core towards, being more of an enabler that other layers can rely on, not trying to be a complete solution.

Thanks a lot! Test looks good to me, I think this is fine :)

Updated the issue summary with that explanation. I think this makes sense.

Is there a straightforward way to add a test for this? :)

gábor hojtsy → changed the visibility of the branch 3443833-provide-a-way to hidden.

Hm how does the MR without the hooks solve the extensibility then?

We ran into this at ✨ Provide a Config Action to add/edit a component in a layout Active . This would be a much better way to resolve it than to add to the baseline there :D Such great diffstat also :)

Which MR is to be reviewed?

Hm, the current code in the 10113 MR seems to be moving the logic around but does not actually make it extensible yet? What am I missing?

The other MR adds a new hook and hook_alter.

Reached out to phpstan folks. Learned that 🐛 Add missing @return types for StringTranslationTrait::formatPlural() and ::getNumberOfPlurals() Active is in the way, until that lands, the phpstan baseline needs updating in the MR.

As a core product manager I think this makes sense. It allows us more flexibility in the future to possibly remove the big UI for example from core if we think its not an 80% use case even if content moderation or node preview is.

Only minor note is the description of the original module now does not reflect what it does? The module does not provide full site previews after this MR.

Allows users to stage content or preview a full site by using multiple workspaces on a single site.

This is minor IMHO but would be still useful to fix to make it easier to understand what's the relation between the two modules. But leaving needs review for more reviews as appropriate.

Although you are linking 📌 [META] Track 15: Proposal for media management Active , I believe the description of your intended result is on 🌱 Proposal for Media Management in early versions of Drupal CMS Active , right? Do you have a checklist/summary of how much did you implement from that in this MR?

The MR only seems to add the "add layout component" action, so I think its far that it only has tests for that. @phenaproxima indicated that these improvements to the tests would be good, that still looks like needs work:

• We need to be sure the region stuff works as expected, including when the default region is used, or the region can't be resolved.
• We need to be sure the position stuff is figured out correctly, every way it could be passed in.
• We need to be sure that the additonal key is preserved if passed.
• The test...isn't using config actions. That obviates the entire point of this MR. We need to test that we can accomplish the addition of the component using config actions. (We don't need to use a recipe, but we probably need ConfigActionManager::applyAction(...).

kristen pol → credited gábor hojtsy → .

Unassigning for now, since Matt does not have time anymore for this unfortunately.

gábor hojtsy → created an issue.

Are there specifics to update other than the outdated screenshot? :)

I somewhat share the default content concerns, although I believe it would be nice to have a way to automatically generate a default legal notice to start working with. However the current default content designates "Drupal CMS" as the responsible legal entity and is full of mentions of Drupal being responsible for stuff, so that is a no-go to ship with I think :) (On top of the grammatical issues in the text).

Data protection is of a particularly high priority for the management of the Drupal. The use of the Internet pages of the Drupal is possible without any indication of personal data; however, if a data subject wants to use special enterprise services via our website, processing of personal data could become necessary. If the processing of personal data is necessary and there is no statutory basis for such processing, we generally obtain consent from the data subject.

xjm → credited gábor hojtsy → .

I think text format editor, content type, taxonomy, etc. type of a recipe would not appear as a site or a kit, so at best it would be a subtype of a foundational recipe (if recipes want to do subtyping that is). Would be great to run the three types through the initiative meeting and get feedback there. Then move forward to codify this as it would help move with project browser's listing.

📌 Decide and update recipe naming and classification standards Needs review has a decent three legged proposal for types, let's discuss there if there is anything in the way to adopt that :)

@carsoncho: I like those three levels, we should codify the type naming for them, so that tools like drupal.org's API endpoint can properly expose them and Project Browser can offer a UI to find them (or hardcode filters for them). What's in the way to codify this?

Does this mean recipe types are not anymore intended to be documented? :)

Interface Translation (locale) in core uses the project and version identification feature of Update Status. (Also Upgrade Status and Upgrade Rector do the same as well as probably a bunch of other modules).

Indeed, good point! I think renaming the existing one's human readable name back to Update Status is a good way forward. Internally it reflects that naming already.

Update Manager sounds good and is in line with the rest of the core and contrib features in this area. Also with Package Manager.

Saving notes, thanks all!

Saving notes

Meeting parser fails at the celebrations thread. Need to figure out why, then can save the notes.

Fixing credit for James. Thanks all!

Thanks all!

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

Googling for that specific error message it comes up from https://www.drupal.org/forum/support/module-development-and-code-questio... → , looks like you either use that custom module or someone very strongly got inspired by that code (copy-pasted it). This would be output when that code is run (since it echos and dies). The container in this case is not yet initiatialized because the error happens in a global context while the codebase is being assembled. Look at your own site codebase to find this code.

Is this included in the error like this?

No! This is not for you! Your Drupal installation does not support utf8mb4. Have a fruitless look at https://www.drupal.org/docs/7/api/schema-api/data-types/encoding-collati → ... and then forget this module."

Released in https://www.drupal.org/project/upgrade_status/releases/4.3.6 → , please try there and let us know if the errors persist.

Thanks!

gábor hojtsy → made their first commit to this issue’s fork.

Merged the MR to report the fail from drush so errors are surfaced earlier and in a more useful way.

My comment in #4 still stands that this undoes the reporting that there may be deprecated API uses that cannot be detected because its not enabled, given the hasImplementations() will not find the hook if the module is disabled and thus the patched code will return no errors.

I added that category.

The module already had the Developer Tools category which I kept.

The tests pass fine on the simple ignore fix now I think given the core fixes. We can merge that in to stop the bleeding on older core versions too without changes needed to the tests.

Added some related issues.

I believe 📌 Twig Filter "spaceless" is deprecated Active is still outstanding but otherwise this is resolved in core and fixes were released in patch versions of core.

Merged the MR. Will release 4.3.6 with this and a couple other fixes soon.

The MR should remove the drupal_root from phpstan-drupal config. The other errors I don't believe come from Upgrade Status :)

gábor hojtsy → made their first commit to this issue’s fork.

xjm → credited gábor hojtsy → .

longwave → credited gábor hojtsy → .

You are right, I made Drupal CMS a lot more prominent on the project page, hope this helps :)

Add Drupal 10 end of life. Expand Drupal 7 end of life info.

We discussed this with Lauri yesterday as Drupal core product managers. We have no concerns. The added code does not have UI parts other than some error messages which seemed fine. Two modules already integrate well with it and we agree the product needs it for both. Being an API module, we accept the judgement of the framework managers on the APIs.

I created the Drupal 11 video with some of the above in mind (establish Drupal as a trusted name, highlight wide contribution, etc) and then get onto the benefits of Drupal 11 itself. I did not use a voiceover for simplicity.

I think if we want to have voiceover for this one, we want to have a video with music + voiceover. Is there a good distribution mechanism that is editable for this? Or we'll use one person's copy / computer to receive and edit the translated voiceovers in? Or distribute the music alongside the video for the local associations at least?

Those cards look great! I use Google for my searches and never seen that :) I agree adding this would be great, and I think @drumm already outlined that the Drupal 10/11 version of events could receive that later on :) The Drupal 7 version of the site is currently on life support.

Does core do the same? It does not help much if we parse those files, if core does not do it :)

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

Neither sample searches provided showed me event cards. How would those look like when they show up in Google?

bramdriesen → credited gábor hojtsy → .

bramdriesen → credited gábor hojtsy → .

bramdriesen → credited gábor hojtsy → .