Still testing/reviewing the patch. So far so good.
The media field shows up in both languages, very cool.
Will have to test with a non-translatable media file just to make sure it doesn't spontaneously make it translatable.
@anybody, we upgraded to D11 in february and we're using layout_builder_st and recently updated layout_builder_st
Patch we're using (page manager compatibility bug fix)
"drupal/layout_builder_st": {
"3069964 - Null fix for moderation dashboard, otherwise WSOD on login": "https://www.drupal.org/files/issues/2025-08-27/layout_builder_st-3069964-41.patch"
},
Version of layout_builder_st:
{
"name": "drupal/layout_builder_st",
"version": "dev-2.0.x",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/project/layout_builder_st.git",
"reference": "ea9ed7ee77369f2be64b3e925ac4a7a454920b74"
},
"require": {
"drupal/core": "^10.2 || ^11"
},
}We've been using this with Drupal 11.1.8
@rajeshreeputra, please tag a new release for jquery_ui , it has been approximately 18 months since a tagged release!
tests came out bad, cancelling this ticket as works as designed.
joseph.olstad → changed the visibility of the branch 3546871-prevent-form-anomalies to hidden.
if you're on 2.0.x like me, I recommend 2.0.38 or newer 2.0.x
you'll likely want 2.0.38
🐛 Prevent form anomalies from resulting in multiple confirm dialogs Active
@ldenna , this is an eslint patch from the gitlab-ci automated pipeline that I've pushed into a merge request. Expecting no change to functionality. With that said, it is a patch that needs to be tested against moderated_content_bulk_publish 2.0.38
Hoping that you can help me test and review it.
Thanks ldenna for your assistance with this. It was a tough one to figure out.
Fix likely be ported to 3.0.x however too many merge conflicts to cherry-pick so I'm not going to do it until I start using 3.0.x more often or unless someone else pushes up a merge request then I will review it.
hmm, Tabbed mode no longer seems to work with Claro, probably should set the default to Inline mode.
Here's the patch for testing purposes. https://git.drupalcode.org/project/entity_translation_unified_form/-/mer...
very interesting @bzaher, I'll test it myself right now.
Where does this validation need to go? I'm also hitting this.
@nicxvan, I found your document, a reference to this should probably be included in all of the hooks documented in the 11.x api
@nicxvan , I just looked in the 11.2.x branch, 64 lines of code or comments with "modules_impelements_alter"
What exactly do you mean by 11.2.x "won't have this"?
@pefferen, would be good to release a version of v2 that is compatible with D11.
@digitalcatalyst, your build is not using the patch from the merge request above.
Line 140 from fontyourface/modules/local_fonts/src/Form/LocalFontConfigEntityForm.php
'FileExtension' => ['extensions' => 'woff'],
'FileSizeLimit' => ['fileLimit' => Environment::getUploadMaxSize()],
'FileNameLength' => [],
You should be using the diff from the merge request instead of whatever you're doing.
Are you able to apply patches with composer? Here's the patch: https://git.drupalcode.org/project/fontyourface/-/merge_requests/9.diff
The patch is to be applied to the head of 4.0.x
With that said, this merge request desperately needs to be merged and a new tagged release is needed.
@nicxvan, the API documentation for 11.x mentions that this hook will be removed in 12.0. It's not very clear what 11.2.x has to do with this. What exactly is changing in D11.2.x that would mean "won't have this?".
Example I just pulled up from one of my clients that has search_api and facets along with a custom bit of helper code in a module designed to combine two facet options as one.
My commit message for this module was squashed so I'm not even quite sure why I had the module_implements_alter however it's there and the module works as designed currently. The commit message was: "Combine article and landing_page into one single Type selection checkbox in the Content Type facet." , of course the module code is more than just the module_implements_alter.
/**
* Ensure our alter runs last.
*/
function xyz_facets_module_implements_alter(array &$implementations, $hook) {
if ($hook === 'search_api_query_alter' && isset($implementations['xyz_facets'])) {
$self = $implementations['xyz_facets'];
unset($implementations['xyz_facets']);
$implementations['xyz_facets'] = $self;
}
}
@nicxvan, since you mentioned 11.2 won't have this, can you please explain why the change to 11.2.x that you just mentioned is not mentioned in the api documentation? Where's the change record for this?
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension...
This hook will be removed in 12.0.0. It is not deprecated in order to support the "#[LegacyModuleImplementsAlter]" attribute, used for compatibility with versions prior to Drupal 11.2.0.
Also, is there some bit of reassurance that can be added to the api documentation saying that "if you change your approach to xyz that abc will continue functioning"? in this case the hook we're dealing with "search_api_query_alter" has not been changed and is a contrib hook.
Change this to 5.4.x since it's only affecting 5.4.x, 6.1.x already has fontawesome as explained above.
ok, thanks for that, I didn't actually LOOK at 6.1.x, would have helped haha. The project we were working on earlier this year was 5.4.x also and I see 5.4.x does not have this.
That explains why @jwlarson doesn't have it, he's using drupalwxt/wxt version 5.4.x
This fontawesome/fontawesome is only included in wxt 6.1.x
With that said, it's puzzling a bit because when I search for fontawesome/fontawesome in packagist.org there are no results.
However I found an explanation which is you added an entry to the repositories section of the drupalwxt/wxt project.
{
"type": "package",
"package": {
"name": "fontawesome/fontawesome",
"version": "6.4.2",
"type": "drupal-library",
"extra": {
"installer-name": "fontawesome"
},
"dist": {
"url": "https://use.fontawesome.com/releases/v6.4.2/fontawesome-free-6.4.2-web.zip",
"type": "zip"
}
}
}So this entry provides what packagist.org is not providing.
@jwlarsen, you can simply add a similar entry to the requirements section of your project and then after you upgrade to wxt 6.1.x you will no longer need it unless you require a specific version different than what wxt 6.1.x provides.
once you have the repositories entry to fake out the missing packagist.org entry you will need to require it so, assuming this:
composer require "fontawesome/fontawesome:^6.1"
@rajeshreeputra, please add credit to michelg. It was michelg that pointed this out in the related issue but he hasn't been credited here for the solution.
Example:
diff --git a/composer.json b/composer.json
index df696f3e..06208565 100644
--- a/composer.json
+++ b/composer.json
@@ -12,7 +12,8 @@
"drupal/modulename": "^1.0",
"drupal/abc": "^1.0",
"drupal/xyz": "^1.0",
- "drupalwxt/wxt": "6.1.x-dev"
+ "drupalwxt/wxt": "6.1.x-dev",
+ "fortawesome/font-awesome": "5.13.1"
},
"require-dev": {
"drupal/core-dev": "^10.4",
@@ -54,6 +55,12 @@
],
"scripts": {
"post-create-project-cmd": "rm -r -f behat.yml",
+ "post-install-cmd": [
+ "php scripts/fontawesome-library-setup.php"
+ ],
+ "post-update-cmd": [
+ "php scripts/fontawesome-library-setup.php"
+ ],
"quick-start": [
"composer install"
]
now for scripts/fontawesome-library-setup.php
// Define the path to the subfolder you want to move
$sourceSubfolder = 'vendor/fortawesome/font-awesome';
// Define the destination directory where you want to move the FontAwesome library
$destinationDirectory = 'html/libraries/fontawesome';
// Verify the css/all.min.css file and its checksum
$cssFile = $destinationDirectory . '/css/all.min.css';
$expectedChecksum = '61e37af38389d10e3ec44b0f5f05b10978c23768';
$install_or_reinstall = FALSE;
if (file_exists($cssFile)) {
$actualChecksum = sha1_file($cssFile);
if ($actualChecksum != $expectedChecksum) {
echo "Error: Checksum verification failed for $cssFile.\n";
echo "Expected: $expectedChecksum\n";
echo "Actual: $actualChecksum\n";
$install_or_reinstall = TRUE;
if (file_exists($sourceSubfolder)) {
deleteFolder($destinationDirectory);
}
}
}
// Perform the move operation
if (!file_exists($destinationDirectory)) {
$install_or_reinstall = TRUE;
}
if ($install_or_reinstall && file_exists($sourceSubfolder)) {
// Move the FontAwesome library using the PHP rename function
rename($sourceSubfolder, $destinationDirectory);
if (file_exists($cssFile)) {
$actualChecksum = sha1_file($cssFile);
if ($actualChecksum === $expectedChecksum) {
echo "FontAwesome library has been moved successfully to $destinationDirectory and verified.\n";
} else {
echo "Error: Checksum verification failed for $cssFile.\n";
echo "Expected: $expectedChecksum\n";
echo "Actual: $actualChecksum\n";
exit(1);
}
} else {
echo "Error: $cssFile does not exist. The library might be incomplete.\n";
exit(1);
}
} else {
echo "FontAwesome library 5.13.1 is already in place!\n";
}
function deleteFolder($folderPath) {
if (!is_dir($folderPath)) {
// Not a directory, do nothing or handle the error.
return;
}
$files = array_diff(scandir($folderPath), array('.', '..'));
foreach ($files as $file) {
$filePath = $folderPath . DIRECTORY_SEPARATOR . $file;
if (is_dir($filePath)) {
// Recursive call for subfolders.
deleteFolder($filePath);
}
else {
// Delete files within the folder.
unlink($filePath);
}
}
// Delete the empty folder after removing all files.
rmdir($folderPath);
}
Maybe there's a better way?
@smulvih2 , there's 6.7 million installs of fortawesome/fontawesome
@smulvih2 , jwlarson is correct, while it may work with a CDN, for many intranets and gc networks the cdn gets mangled and they rather want the fontawesome library which is from fortawesome/fontawesome which actually provides the library.
We had a discussion about this several months ago and you undid my composer require and removed it.
fortawesome/font-awesome is the namespace that is in packagist.
This should be brought in in a way that puts the library in the expected named folder which we'd have to take a closer look at it to know.
@jwlarson may have more suggestions for us.
@smulvih2, I suggest disabling/turning off the fontawesome cdn option in fontawesome and ensuring the theme also isn't bringing in the cdn, then re-test, you'll need the fontawesome library to be in the expected html/libraries/font-awesome or web/libraries/font-awesome folder.
@rajeshreeputra, michel.g pointed out something we missed here. I'll push it up now.
diff --git a/jquery_ui.libraries.yml b/jquery_ui.libraries.yml
index 46bb48d..78b2c49 100644
--- a/jquery_ui.libraries.yml
+++ b/jquery_ui.libraries.yml
@@ -19,3 +19,4 @@ locale:
dependencies:
- core/drupal
- core/drupalSettings
+ - core/jqueryjoseph.olstad → created an issue.
phpcs is passing with MR 22
@rajeshreeputra , appreciate your attention to this!
The Drupal 11 version of wetkit is https://www.drupal.org/project/wxt → (currently version 6.1.x)
@flyke, did this happen when you upgraded bootstrap? from version 3.xx to 3.xx+1?
What we need to solve this is steps to reproduce the issue. So far I have not been able to reproduce this issue.
So this occured in your DDEV? Any idea what makes the 20th project "special"?
joseph.olstad → created an issue.
Upgrading to jQuery UI version 1.14.1 was performed first. There was a conflict so I had to partially override. Should review this again
🐛
update to jQuery UI 1.14.1 and remove duplicate js/css files
Active
MR 10 has a lot of unneeded code.
MR 22 provides a solution and only has minimal changes to three files.
Anyone hitting this:
For a localized date picker , due to a 30+ month regression , you will want jq_ui, a drop in replacement for jquery_ui https://drupal.org/project/jq_ui
Easy replacement no patch required see instructions in the release notes. jq_ui includes a fixed copy of the jquery_ui module , I did a writeup on composer replace and fork https://a1.11pro.ca/en/public-documentation/drupalorg/dx-composer-replac...
Where there's a will, there's a way!
Creditting bnjmmn for his work on this from 30 months ago. I simplified the solution to only include the necessary changes. See the MR in the other issue
This works well! I rolled a simplified version in the related issue in the hopes that it eventually is merged.
@avpaderno, agreed, I'm a big fan of tags and releases!
Ok sure, just wanted to make everyone aware that there has been significant work done on the boost project and that there is a dev release available that is for current drupal.
I hope to see a tagged release soon. Perhaps an alpha or beta could be tagged which might bring more attention back to the boost project and lead to further development.
why would this be closed as "outdated"?
There's been a lot of work done and there is a dev release available for Drupal 10 and Drupal
It appears to me that there is a lot of code changes in the MR that are likely unrelated to "Retain last revision info when bulk unpublishing"
Would prefer that we focus only on the minimal amount of changes necessary for "Retain last revision info when bulk unpublishing" so that it's easier to review the changes.
Is it possible the MR is trying to do more than what this issue summary is about?
For those who are curious, 2.0.x supports archived for those using the out of the box 'editorial' workflow.
As for 3.0.x, it's customizable, perhaps an additional option is needed however I'm not sure as it's Eduardo that has done the work on 3.0.x. I'll review patches for either. Otherwise I'm relying on the community here.
Thanks @jastraat for your work on this, everything is good now in 2.0.x and 3.0.x so lets mark this as fixed and you've got credit for the fix.
THANK YOU! Tagged 3.0.0-beta18 , pushed release.
Confirmed this is working. Thank you for this!
I got tired of waiting for fixes so I forked jquery_ui which has a label
https://www.drupal.org/project/jq_ui →
For a better version of jquery_ui, please check the very simple replacement instructions here: https://www.drupal.org/project/jq_ui/releases/8.x-1.6 →
I had to revert this one in order to avoid a conflict with
🐛
update to jQuery UI 1.14.1 and remove duplicate js/css files
Active
Tired of waiting? I am.
I've created a drop-in replacement for jquery_ui called jq_ui.
I will credit the above for the work on this fix in a new issue and will tag a release.
https://www.drupal.org/project/jq_ui/issues/3543903 🐛 update to jQuery UI 1.14.1 and remove duplicate js/css files Active
joseph.olstad → created an issue.
I've forked jquery_ui into a drop-in replacement and I will fix this issue in the fork. See the related issue, and I will credit you all for this work.
Thank you very much.
🐛 update the package inside package.json to latest for security purpose Active
joseph.olstad → created an issue.
It's very easy, as described above.
I've also documented the process here:
https://a1.11pro.ca/en/public-documentation/drupalorg/dx-composer-replac...
https://a1.11pro.ca/fr/documentation-publique/drupalorg/dx-composer-repl...
So basically the crux is the line in the composer.json and a folder with a copy of the forked module. The foldername is the machine name of the module. Have a look at jq_ui.
https://www.drupal.org/project/jq_ui/releases/8.x-1.6 →
Drop-in replacement for jquery_ui.
Steps to replace jquery_ui:
Step 1) composer require drupal/jq_ui
Step 2) drush en jq_ui -y;
Step 3) drush cr;
Step 4) Sip from a marguerita
How is this possible you might ask? composer replace and a repaired copy of the jquery_ui in the jquery_ui folder inside of jq_ui!
And here it is: On a silver platter for everyone!
https://www.drupal.org/project/jq_ui/releases/8.x-1.6 →