🇦🇺Australia @nterbogt

larowlan → credited nterbogt → .

I ran this on a site with 31 entities and 1039 fields and it took 1.9 seconds on my local machine. I'm not sure this qualifies it as slow; it's certainly not slow compared to rebuilding node access as an example.

This has been merged and will be in the next release.

nterbogt → created an issue.

Merged. Sorry, forgot the commit message.
Will go out with the next release.

I agree with the sentiment behind this ticket; but not necessarily the implementation.

I'd like to see the code automatically leverage the cache `url.query_args` bubbleable metadata, so that implementing it correctly in a block or similar, automatically enables that argument in the page cache ignore.

I haven't quite worked out how to do that yet.

But both options have merit and it would be worth doing an analysis over which route should be taken (pun intended) :)

Merged and will be available in the next release.

nterbogt → created an issue.

nterbogt → created an issue.

Merged for next release.

nterbogt → created an issue.

This has been merged and will be available in the next release.

nterbogt → created an issue.

This has been merged and will be available in the next release.

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

This has been merged and will be included in the next release.

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

nterbogt → created an issue.

Merged to 1.x.

Merged to 1.x.

nterbogt → created an issue.

nterbogt → created an issue.

Is this still an issue? Can you confirm whether the fix recommended by pookmish solves the problem?

Closing this issue now.

Merged to 1.x.

Ready for review.

Ready for review.

Ready for review.

nterbogt → created an issue.

nterbogt → created an issue.

nterbogt → created an issue.

Can we update the target branch of the merge request to 2.x please? I'm not sure how to do it or I don't have permission.

Local testing had the number of fields go from 253 to 73 and now doesn't contain items that have empty bundles.

nterbogt → created an issue.

nterbogt → created an issue.

I believe this change exists in 10.2 already and can be closed.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/ajax.js?...

PR looks good to me :)

fubarhouse → credited nterbogt → .

This patch caused significant issues for us for non admin users. I'm yet to look into what is different in the HTML structure between admin and non admin users that might be affecting it.

nterbogt → created an issue.

nterbogt → created an issue.

I'm just going to bump this one to RTBC because it's a filename change and I ran it locally.

Can we merge this to 5.x too when it's released?

Thank you for you submission. Converted patch to merge request.

Now all this needs is tests.

Updating to 2.x-dev.

Fixed. Will be rolled out in 2.3.0.

nterbogt → created an issue.

Fixed. 2.3.0 release to follow.

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

This is a simple change, but will conflict with the other issue I put in review. I'll update whichever afterwards.

I decided to run all the tests again with the new entity_test_parent (no parent field) and entity_test (with parent field) as children.
Let me know if this is over testing.

nterbogt → created an issue.

Released in 2.0.0-beta2

Deployed in 2.0.0-beta1.

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

I'll roll a release shortly.

It's one and the same... I've been working on the code for the Children tab in 5.x quite a bit :)

Is this opt in? Slightly concerned it could break our 'Children' tab when we have a `5 / 70 / 10 / 6` type hierarchy. (format of child summary in views).

Ok, misunderstood the code. Back to passing now. (Note to self) Next time, just run the module in a sandbox with working tests... makes it easier :)

Tests failed. In theory there was no functional change from previous code. I'll look into it.

nterbogt → created an issue.

Sorry, forgot status change.

Updated with new method to get the list builder and tested locally.

The local task deriver changes were because I originally had another change in mind, but rejected it. The change only removes unused variables and uses constructor promotion, bringing it in line with other modernised code in EH 5.x. So decided to include it.

I think this is ready for a review. At least in terms of the functionality it provides. Happy to discuss specific implementation.

nterbogt → created an issue.

nterbogt → created an issue.

jibran → credited nterbogt → .

nterbogt → created an issue.

larowlan → credited nterbogt → .

Confirm this works for me too.

I believe this is the same issue that I'm seeing.

URL that comes in is /sites/default/files/2022-05/Vivid.jpg

Proxy request is stage_file_proxy.ERROR: Stage File Proxy encountered an error when retrieving file https://my.host///2022-05/Vivid.jpg

I gave this some thought and decided to just remove the reference to 'Test'. 'entity' is globally used and the other options considered were:

* Add the current content entity to the ChildEntityWarningBuilder and then pass it through to the ChildEntityWarning. And then render the current entity type into the message.
* Assume entities in the ChildEntityWarning->relatedEntities were always going to be the same type, so grab one and render the entity type into the message.

In both cases, does that added complexity actually add value to the user. Probably not... they are already on the edit page of what they want to edit.

nterbogt → created an issue.

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

This has been fixed and rolling release 1.0.0-rc1.

Can I please get a review of this. Phpstan throws only a couple of warnings on 10.0, but tests currently set to 10,1 which throws a Database::tablePrefix() issue.

nterbogt → created an issue.

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

nterbogt → created an issue.

nterbogt → created an issue.

Added a functional test for the settings form. Has a phpstan warning, but it's the same warning in a lot of other projects.

https://git.drupalcode.org/project/token/-/jobs/275660

The warning is documented here.

https://www.drupal.org/docs/develop/development-tools/phpstan/handling-u... →

I agree with the complex logic in the form, I'm also not really sure about a decent approach to test that. Do you have any recommendations?

A unit test that just checks the default values and possible options could work, but might not be what you're after.

This is causing significant user complaints for our site too. There are many people confused about what is happening and why.

I'm trying to get this to RTBC, but will have to come back a bit later.

I don't believe this needs to be optional / opt-in. I think it's clear it should be an admin route, next to 'View', 'Edit', 'Delete', 'Revisions', etc. I'm not sure there is any UX benefit to using the page theme and having it inconsistent with everything else.

It's also a duplicate of 🐛 The generate-preview-link page renders in the site's theme RTBC , which I know was created after. But might be easier to push the individual changes through rather than globbing them together.

I agree that this is a poor user experience. Run the change locally, working as expected.

This is ready for a review please.

I've redone the permission form configuration. Also moved it to a merge request.

I still need to implement the bundle configuration, but the rest is done, as far as I know.

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

Looks like this is actually fixed in latest release.

nterbogt → created an issue.

This appears to be an own goal. Sorry. Closing.

I'll investigate further before anyone should look at this. Might be a PEBKAC problem given my current week.

nterbogt → created an issue.