🇦🇺Australia @elimw

elimw → changed the visibility of the branch project-update-bot-only to hidden.

@jeremy1606, could you please make the relevant changes to https://www.drupal.org/project/browsersync/issues/3523729 📌 Support object oriented hook implementations Active instead? I'm going to close and hide your merge request as this issue is only for D11 compatibility fixes.

Pushed changes, added a .gitlab-ci.yml and all tests are passing.

The changes in the merge request don't fully work for me. I still get this error on every odd click which selects an entity type.

@heddn, there's no pipelines currently configured for this project.

My plan is to do that as part of https://www.drupal.org/project/browsersync/issues/3523729 📌 Support object oriented hook implementations Active .

Thanks @chrisfromredfin, I've tested the changes and they work for me.

elimw → created an issue.

Hi @gedvan,

I updated the automated patch yesterday and our changes to BrowsersyncTest.php are exactly the same.

Could you please update browsersync.info.yml in the automated patch issue 📌 Automated Drupal 11 compatibility fixes for browsersync Needs review ?

Closing this issue due to it's age and the fact that Ajaxify doesn't seem to be actively maintained.

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

@dydave, I've added a PHPUnit test for the change and all tests are passing. I hope this is what you were after?

Sorry it's taken me so long to get around to doing this.

@loze, turns out my redirect issue was fixed by configuring reverse proxy.

I've been testing this patch and noticed that while top-level comments are added to the bottom of the top-level thread, replies are added to the top of reply thread.

Is it possible to append replies to the bottom of the reply thread?

@loze you were right, I had Display Suite installed and configured for the comment field. Once I created my own preprocess hook to copy across the pre-processed elements in your patch into `$variables['items'][0]['content']`, everything worked.

On a separate note, is there an alternative way to rebuild the form in AjaxController without using `$this->entityFormBuilder()->getForm()`? This particular form builder is throwing an `EnforcedResponseException` exception and my staging environment is having issues processing the subsequent redirect. If there isn't an alternative way to rebuild the form, is it possible to wrap all calls to `$this->entityFormBuilder()->getForm()` with a try-catch and rebuild the form from there?

I applied the latest patch and my field for adding a new comment and replying are no longer an AJAX field.

When I add a new comment, the page is reloaded. If I reply to a comment, I'm taken to a page showing the comment's thread. I did some debugging I can see the new ajax_comments.lazy_builders:renderForm being attached, but the original CommentLazyBuilder class is being called instead.

elimw → created an issue.

Re-rolled the patch at #2 and updated deprecated code.

I added a commit to resolve this error that I got when a comment field didn't have any comments or, I assume, not enough to generate a pager:

Error: Call to a member function getCurrentPage() on null in ajax_comments_entity_display_build_alter()

I also couldn't apply the patch from the merge request diff and ended up creating a local patch by doing a diff against origin. I think the fork just needs to pull in the upstream changes.

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

Closing this issue as I realised that this error was caused by a patch in another issue.

https://www.drupal.org/project/ajax_comments/issues/3113225 ✨ Don't rebuild the entire comment field/thread when posting a comment Needs work

elimw → created an issue.

@ljwilson, for me, the issue wasn't related to an uninstall page, but I tried your fix and it worked for me.

Could you refactor your fix into an update hook?

@dydave, @vistree, I've created separate MR which checks if a savepoint with the same name already exists before pushing a transaction.

I have pushed a change to fix the issue I was encountering.

Rather than having to explicitly check if we should wrap a query in a savepoint before calling "Connection::addSavepoint()", wouldn't it be better to do the check inside of "Connection::addSavepoint()" instead?

I updated Group contrib to 2.3.1 and noticed this issue. I applied patch #37 and even updated Core to 10.4.1 but neither fixed the issue.

elimw → created an issue.

elimw → created an issue.

PR reviewed. More work needed to conform to Drupal coding standards.

Please make all changes to "Issue fork browsersync-3335994" rather than the old patch file method.

Please address the comments I have left in the PR.

Rather than calling the class "BrowsersyncConstants", please rename it to "BrowsersyncHelper" and remove the "final" keyword from the class declaration.