#DX (Developer Experience)

A Slack conversation started here: https://drupal.slack.com/archives/C3E9QDZ5M/p1745499507960159
Where I have also shared this link that lists all contribs hosted on Drupal Git with DDEV enabled: https://git.drupalcode.org/search?group_id=2&scope=blobs&search=filename...

Yes, most of this is auto-genarated code at the moment of DDEV and necessary DDEV addons (if any is necessary) configured for the project. The benefit of committing these files that they drastically speed up contribution to projects, because whoever has DDEV installed - the official Drupal development tool for Drupal and contribs as far as I know - could just git clone the project and run ddev start and start contributing. They do not need to follow manual steps and ensure the right set of dependencies are installed, because the committed "last known good" configuration is in the version controlling system already.

Ignoring these configs from artifacts of course is a must, because when you install a module from an artifact you most likely do not need the bundled DDEV config.

It looks like I didn't close this.

Thanks a lot for suggesting this improvement!
I must admit I’m not too familiar with DDEV so am a bit overwhelmed by this MR.
Could you please tell me some examples of other modules that have already done this? Do you have links to some issues that discuss this change?
Adding a whole new folder with 19 files seems like a pretty big change. What exactly is the advantage of doing this, seems like most of this is auto-generated? (In fact, could you please tell me which parts are not auto-generated? Is it just the first few lines of .ddev/config.yaml? If so, wouldn’t DDEV be able to generate the rest anyways, without us including it in the repository?)
Also, what exactly is the use case for which this is needed? Is this for including Search API in any website project, or just for testing Search API on its own in a test environment?
Finally, why did you choose MariaDB and specifcally version 10.11? Isn’t hard-coding that in our module repo a problem?

There is no response to the request for more information. The error message in the issue summary was removed in 📌 Deprecate RendererInterface::render()'s sole $is_root_call parameter Needs work . Based on that I am closing this issue.

Since there hasn't been confirmation, in the past 9 months, that this still needs to be done. I am closing this issue.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

I am closing this according to the last comment.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

I think this is safe to close, there is no rollback method that is mentioned in the issue summary, a different solution was committed.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

FYI: with this done, I think it's time to re-assess 📌 ServerClientConversionTrait Active and friends, aka make a decision on whether to keep ClientServerConversionTrait because it is good enough, or whether to transition to something else/better.

wim leers → credited larowlan → .

As a byproduct, the TestDataUtilitiesTrait that @tedbow introduced in 📌 Convert test cases to use PHP arrays instead of JSON strings where possible Fixed to ease test development pain during initial development of XB, will largely be obsolete — that's what I asked for in #13, and which @phenaproxima almost completely finished! 🤩

In fact … since I'm feeling under the weather and my mind doesn't allow me to tackle anything complex right now, I just persevered and refactored it away: TestDataUtilitiesTrait is GONE! No more need to remember to wrap an array in a ::encodeXBData()! 🥳 All thanks to the one crucial insight by @phenaproxima! 👏

So: we'll not only make interacting with XB config less painful for site builders/XB users, but also for us developing XB, and hence improve development velocity slightly :)

P.S.: I'd still don't like that ->getValue(), TRUE has 7 matches in the codebase, but that's far better than the hundreds this MR removed. So, for the sake of iterative progress, didn't expand scope to that. Also: once 📌 Allow field types to control how properties are mapped to and from storage Needs work lands, XB won't have to work around that flaw in Drupal core anymore. If somebody wants to take that on: see attached PoC patch to get you going.

Bumping to per ✨ Create a schema for "allowed_html" which provides a better config diff Needs work .

I just did a workaround for this problem over at 🐛 ContentEntityDenormalizer uses the field map, and so is unaware of bundle fields Active .

I think our end-to-end test coverage should be focused on the end user's experience. React's <StrictMode> is wonderful for development, and you're right that if it makes our app behave differently, that's most likely a bug. The kind of problems <StrictMode> potentially surfaces during development, we should fix and verify at the unit testing layer using Vitest, which we recently introduced in 📌 Compile Tailwind CSS globally for code components Active .

@sandip There's a round of feedback on that MR, and there's also 🐛 Create loadAutoSave() helper function Active 😄

Thanks, @jatingupta40! Not passing tests yet, but a great start!

Just ran into 🐛 Layout builder doesn't support bundle computed field Closed: duplicate

I think we should take this out of key/value.

We could have field module implement similar logic in it's bundle field info hook instead maybe.

@wim leers, Thanks for the issue:) I noticed someone has already taken care of this issue before me. Appreciate the opportunity. I'll keep an eye out for more tasks like this 😊

Thanks!

Next up for anyone following along is 📌 Pass RenderContext around in the Renderer Active .

Committed to 11.x - thanks!
Published the change notice.

larowlan → closed merge request !10795

Putting back to RTBC because all the changes from my last review where I changed the status were either trivial or reverted.
I manually confirmed we still have the bubbling check from the other point.

Given the changes here would have been fine for catch to self RTBC I think it is OK for me to commit this still.

🥳

Please review the changes

This will eventually end up unblocking 📌 [PoC] Introduce a `ContentTypeTemplate` config entity Active , because for that (and for performance reasons) we'll need to do that 3rd bullet point.

@sandip If you're interested in doing more of this valuable work: 📌 Rename `FieldForComponentSuggester` to `StructuredDataSourceSuggester` Active 😊🤞

Thanks so much, @sandip, this feels way better! 😄

Automatically closed - issue fixed for 2 weeks with no activity.

It has been quiet here for 9 years, indicating no interest in pursuing this idea. I am going to close this now.

If that is wrong and there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.

I have rename all the SdcProp usage but still some tests seems failed. I am not getting why it is so. @wim leers and @ larowlan can you please take a look into it.

Left some questions on the MR

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

MR !7432 applies successfully to Drupal 11 and solves the WSOD on pages with many content/nodes/taxonomies displayed.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

smustgrave → credited effulgentsia → .

smustgrave → credited hchonov → .

Closed 🐛 Move entity preparation from form controller to entity class: "last changed" timestamp not updated and "create new revision" setting not respected when updating entities via Entity API Postponed: needs info with overlap to this.

wim leers → credited larowlan → .

Tests are still failing.

Thanks @larowlan for the feedback.. I am working on rename rest of the SdcProp usage.

Tagging for colleagues as this is a bug bear for the Pinto work Mohit has been doing

I think this is less urgent.

I have verified the changes related to renaming SdcPropToFieldTypePropMatcher to JsonSchemaFieldInstanceMatcher and SdcPropJsonSchemaType to JsonSchemaType.
1) Old class names (SdcPropToFieldTypePropMatcher, SdcPropJsonSchemaType) have been completely removed from the codebase.
2) New class names (JsonSchemaFieldInstanceMatcher, JsonSchemaType) are being used consistently throughout the module.
Everything looks good

Please review the changes

I am looking into it

Even if we'd only support composer, there are still things like submodules that have their own dependencies.

Indeed. While 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active is done, 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active is not. So I agree there’s still value in locking this down.