Update: I also reported this to the maintainers of `simplesamlphp`, and they have identified a commit in the 3.1.2 release of `xmlseclibs` as the root cause. See https://github.com/robrichards/xmlseclibs/commit/158c73571e395d7e50b366e....
gravelpot → created an issue.
@themodularlab
I guess what I was really getting at was this -- since you said that it seems "more noticeable" on Acquia, that implied to me that there were other hosting environments where it seemed less noticeable to you. Is that actually the case?
@themodularlab, could you elaborate on "This is more noticeable on hosting platforms such as Acquia?"
We are hosted on Pantheon, and right now our limited testing doesn't show any noticeable difference on loading the node edit form on the same site running Twig 3.14.0 and 3.14.2.
Can you describe the testing you've done to indicate that it is _more_ noticeable on Acquia, to see if we can replicate on Pantheon?
Is there something specific you suspect about Acquia's architecture versus other platforms where you haven't seen this performance hit?
@la588 For the sites that are not experiencing this issue, check the `composer.lock` file to see what version of the Symfony libraries it is running. The problem was introduced in Symfony 6.4.8. Because of the way Drupal core specifies its own version requirement for Symfony as `^6.4`, you could have different sites running the same version of Drupal with different versions of the Symfony libraries.
Our sites started exhibiting the problem after an automated `composer update` process updated the sites to Symfony 6.4.8. No Drupal version changes occurred.
My guess is that if you ran `composer update` on the sites you have that are not experiencing the bug, they would update to Symfony 6.4.8 and then they _would_ experience the bug.
@berdir Thanks for that. We did report it to the simplesamlphp maintainers in their Slack workspace, and their response was similar -- this is a Symfony problem, you'll have to wait for a bugfix from them.
See https://github.com/symfony/symfony/issues/57316 for what appears to be the related issue in the Symfony project queue.
gravelpot → created an issue.
Hi @mandclu, just checking in to see if you would be willing to look at the newer patches above from @mark_fullmer? Thanks!
I agree with @mark_fullmer that there isn't a strong case to implement this interface option through Layout Builder Restrictions, since it is unrelated to the core functionality of the LBR module. While the benefit of this option would be highly relevant in the LBR context, it wouldn't only be relevant in the LBR context.
This may seem far-fetched, but I could see that if we did it here, it could even potentially conflict with other modules in the Layout Builder ecosystem if they also chose to implement that same option. Or even the Layout Builder module in Drupal core if at some point in the future they chose to implement a "collapse all categories" option on the ChooseBlock controller.
A few other possible paths forward I could see instead of adding this as an option in LBR, in addition to a site-specific alter to the ChooseBlock controller:
- Creating a new contrib module that just does this one specific thing (e.g. "Layout Builder Collapse All Categories")
- Proposing that this option be added to a more general-purpose Layout Builder ecosystem module, such as https://www.drupal.org/project/layout_builder_additions →
- Proposing that this option be added to the core Layout Builder module
I agree with @kreynen's input that PSE autocomplete is of questionable value given that Google will start offering autocomplete suggestions outside the scope of that particular PSE's configured search engines. But I also agree with @mark_fullmer's observation that since autocomplete is already available via the optional Google search input on the search results page, that horse has already left the barn.
So this issue isn't so much about autocomplete per se, but can be viewed as supporting direct placement of the Google search input as a standalone block. What exactly that facilitates and what value it provides is up to the site owner. In a Google PSE instance that is set to the default behavior of searching the entire internet, the autocomplete feature could be considered more useful. It seems counter-intuitive to the value of using Google PSE for "site search," but maybe there's a valid use case for that.
This seems like a pretty small lift to reinforce our goal in the 4.x rebuild of providing more direct access to all of the Google PSE core functionality, so I support it.
Hello, I'm here to add one more +1 in support of a D10-compatible release.
An alpha or beta release would be fine, just something other than a dev build, since we have recently run into a technical limitation using a dev
build based on a specific commit hash. We found that you can't rely on getting the same thing every time you do a Composer build without modifying the site's root `composer.json` file, which isn't an option for us with the architecture of our Pantheon custom upstream.
We are on schedule to upgrade ~100 sites from D9 to D10 in May, and this is one of the last remaining contrib modules in our standard distribution that does not have a D10 compatible release. I appreciate all the fine work folks are doing here, and hope this can get pushed over the finish line soon. Please let us know if there is any further labor that can be contributed to the effort in specific issues.
Good morning, I'm here to add my voice in support of a D10-compatible release. An alpha or beta release would be fine, just something other than a dev build, since we have recently run into a technical limitation using a dev build based on a specific commit hash. We found that you can't rely on getting the same thing every time you do a Composer build without modifying the site's root `composer.json` file, which isn't an option for us with the architecture of our Pantheon custom upstream.
We are on schedule to upgrade ~100 sites from D9 to D10 in May, and this is one of the last remaining contrib modules in our standard distribution that does not have a D10 compatible release. I appreciate all the fine work folks are doing here, and hope this can get pushed over the finish line soon. Please let us know if there is any further labor that can be contributed to the effort in specific issues.
Not sure why Drupal does not reimport default values during update, so re-install.
This is not an accurate way to characterize the expected behavior of module that has been installed on a site. For a module that has been installed, it should not need to be uninstalled and reinstalled to receive configuration updates. Instead, Drupal provides the hook_update() API to manage this process.
It is the responsibility of the module maintainer to use this API, when introducing changes that affect the database schema, to modify the database for an existing installation to match what the newly installed module would provide.
It is best practice to map any user-configured settings from new to old values so that no user involvement is necessary for the update. A good example of this can be seen in the Google CSE module, which provides database updates for sites using version 3 moving to version 4:
- In the .install file, the module implements hook_update() and calls a database mapping function: https://git.drupalcode.org/project/google_cse/-/blob/4.x/google_cse.install
- That function finds the module's v3 configuration in an existing site and re-saves it for use with v4: https://git.drupalcode.org/project/google_cse/-/blob/4.x/google_cse.modu...
Hi @edo88, thanks for doing work on this. We will test it out soon using our Drupal 10 sites and give you feedback.
One thing you should consider for this release is to make the transition away from the older "8.x-x.x" version number model and adopt the newer "Semantic Versioning" (semver) format. This would reflect a commitment to following Drupal development standards, and increase confidence in site owners considering adoption of your module.
Here is an explanation of the switch:
https://www.drupal.org/node/3108648 →
Here are some guidelines for module maintainers on making the switch to Semver:
https://www.drupal.org/node/1015226#semver-transition →
You are required to increment to a new major version number when you switch to semver, so this D10-compatible version would need to mark the transition to a 3.x branch.
@mandclu Thanks for the update, I'll try to get some time to look at the new patch this week.
Would you indulge me in sharing the URL to the calendar for your photography club? Assuming they haven't updated it since you encountered that problem, I would like to look at their ICS file structure to better understand why your calendar behaved the way it did.
gravelpot → created an issue.
@mandclu Happy new year! Just bumping this to see if you've had time to consider whether you would accept another developer from our team here at the University of Texas at Austin testing and marking this issue as RTBC, as long as we affirm that the review is being done independently?