@devdits
Thanks for the re-roll.
> Could not update MR
Do you see a green "Get push access" button at the top of the page near the info about the fork?
> Rebased MR on latest 8.x-3.x.
In this latest reroll I'm seeing some elements bumping together.
This is happening at all screensizes.
Also, I'm not sure why many of the screenshots here don't include the words "Save as" or "Change to" because there isn't really a way to turn them off:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/conte...
Oooph. Let's say you've got a site with hundreds of content editors that had this bug for about a year while the site was on D10 but before it got to 10.3. You've now got hundreds of busted script and style tags. (Yes that was bad to have from the start, but we inherited this site created by a vendor who doesn't do Drupal anymore). Now we've got to write an update to clean this up. something along the lines of:
1. Get all base fields that accept formatted text.
2. Run a query on each table to get all rows containing <script or <style
3. Put the content through a DOM parser. Process all the script and style tags. Get their text.
4. Do some regex search/replace. Maybe something like
$count = 0;
$clean_content = preg_replace(['/&(amp;)*lt;/i', '/&(amp;)*gt;/i'], ['<', '>'], $dirty_content, -1, $count);
if ($count) {
// Write the clean content back to the database.
}
Some questions:
1. Is this cleanup something that should be in Core, since this caused data corruption over a long period of time between 10.0.0 and 10.2.10 inclusive (i.e. this issue probably should've been marked as Critical, not Major)?
2. If not, should it at least be tracked here (or in a new issue) so that others can find it?
Closing in favour of 🐛 Preview results in Error: Call to a member function getDefinitions() on null Active which has more details, more conversation, and more thorough fix.
Love this. Overall it's a huge improvement!
Some first-impression thoughts:
* The stock photography feels like a mismatch with the Drupal brand. Any thoughts about getting real Drupal people? But I know that's a challenge with showing something representative, and to get permission. And we don't want a single person (or even a small group) to be "the face of Drupal".
* The lack of page margins feels like a mistake. Especially with the second component "Flexible by design". On my monitor the 4th option wraps to a second line. This results in only 16px of padding on the left, and about 300px on the right.
* As others have mentioned, the first component seems too big. I don't even see all of the first sentence on my screen.
tonypaulbarker → credited dalin → .
+1 RTBC
That still feels a little bit hidden. In this MR I added a link in the field description.
Updated information on safely storing the LDAP password.
dalin → created an issue.
I did some Git sleuthing. This code was added 4yrs ago when IEF support was originally added. There's no ticket referenced in the commit
https://git.drupalcode.org/project/gin/-/commit/ee156d8cf5b300ac0da811e2...
This is a much needed feature! It's what Paragraphs Browser → module is trying to do.
The existing patch is a great proof-of-concept. But as-is it introduces a new problem of the screenshot on existing paragraphs is either too small to see, or if we make it big enough to see then it's a misleading representation of the content. What we really we need is a separate icon and screenshot. Show both in the modal, but only show the icon on existing paragraphs.
So I'm setting this to "needs" work to add a separate field.
This very old issues was trying to do a lot of things:
* Show each paragraph with its icon. The was added to Paragraphs via other issues many years ago.
* Show icons for the paragraph "actions". This part is still doable, but would need updated designs for the modern Paragraphs interface.
Since the designs included in this issue thread are so outdated I think it's probably best to create a new issue so that the old comments don't cause confusion.
At first I wrote this about images, but it applies to all media bundles; video and files too.
Much better!
On my M2 Mac the install took 12min (plus the 4mins that I didn't realize that it was asking me a question about which recipes to install).
I'll close this up.
I ran into this but it was only happening on the live site (Pantheon, but I don't think that matters). If I cleared the cache, some of the domains worked but not others. If I cleared the cache again, then a different set of domains started working. I attempted to deploy the attached patch to get more info. But simply the act of deploying seemed to kick it into gear and it started working for all domains.
Ack, we just hit this problem again. Just like @mqanneh the site in question is using v3.0 and patch #12.
I think we'll have to uninstall the module until this is resolved.
Also adding attribution.
I attempted to give a few words of inspiration at the end.
I'm mentoring @joelstedman@gmail.com on their first contribution at Portland2024. We'll work on this issue for 1hr.
I'm mentoring @aronm on how to contribute to their first d.o issue.
I'm at Portland2024 with @tderego and @ptkoroma and we're going to test this merge request within the next hour.
@kopeboy We try to keep issues as small and self-contained as possible. I suggest creating a new issue.
I've updated the ticket description with what I think are the remaining tasks. Including a new one: Rewrite the tests to not use an .sql.gz file and remove it from the patch.
@mrshowerman
There are a few places in the codebase that could throw an exception. Here's some examples:
- https://git.drupalcode.org/project/entity_reference_purger/-/blob/1.0.x/...
- https://git.drupalcode.org/project/entity_reference_purger/-/blob/1.0.x/...
- https://git.drupalcode.org/project/entity_reference_purger/-/blob/1.0.x/...
If I brought this up in my IDE it would probably tell me there are even more uncaught exceptions.
Let's say that our code in hook_node_delete is running. We're processing the deletion of a node that is referenced by 50 other nodes. An exception is thrown when processing the first node. Currently code execution will stop, and the other 49 nodes won't be processed. What should we do instead? Maybe just skip it and continue on through the list of nodes.
@mrshowerman
I think this issue should stay open. I don't see any try/catch statements in the codebase.
We are migrating a D7 site to D10 that has 1000s of webforms. It is causing severe scalability issues where a full cache rebuild takes >1 min to complete. I was hoping to come here and find some tips. We'll report back if we find anything.
Hi @gnikolovski
Writing good issue descriptions takes time. Could you share an issue credit with me?
Upping to critical since the site basically goes down when this happens.
I'm not sure if this is a thing, but I've seen the error on two high traffic sites. We also run this module on smaller sites, and they haven't seen an issue.
One idea: Since the 4.x branch is largely around CKEditor 5, the new format, and the migration path, and since paste-from-word seems to have stalled out, could we move forward with a 4.0 release and add paste-from-word in some future release?
While this patch makes things better, I'm experiencing some significant UX issues:
1. Create an OL
2. Use Entity Embed button to insert a document
3. Try to add another LI. There's no way to put your cursor after the embedded document and press . The CK5 "type around" buttons are misleading since they only add soft line breaks (i.e. keep you within the current LI)
4. You might eventually figure out that you have to put an empty line break after the UL, and then click the OL toolbar button.
I don't know enough about the inner workings here, but I suspect that this should be a follow-up issue.
Since the related Drupal Core issue was critical (because it results in data loss when upgrading from CK4), this issue should also be.
Added info on how to Migrate from Video Embed WYSIWYG to Drupal Core Media.
dalin → created an issue.
Getting this on a different site too, though here thankfully it isn't an empty fieldset
IMO we should still show something for menu items that the user doesn't have access to. They should be included in the total count, but in the list we should show "access denied" or something similar.
I've discovered that this also includes a menu entity delete. Updating the description accordingly. I updated the remaining tasks.
IMO we don't need to do anything special if there are lots (a hundred?) direct children. The list will be long. So be it. But this will almost never happen in real life.
The code was added a few months ago in this commit:
https://git.drupalcode.org/project/smart_date/-/commit/011d5ddc3d3f4ccf1...
Which is from this issue:
https://www.drupal.org/project/smart_date/issues/3322456
🐛
The "Add another item" button does not work with a single click
Fixed
It sounds like the solution for that problem needs to be more specific.
Upping to Major since this is a major WTF for content editors.
Follow Mozilla's guidelines and support inline images with “data:image/*” unless it’s “data:image/svg+xml”.
I recommend we go the other way and use a whitelist of known safe mimetypes. Who knows what the future brings. Or if I intentionally mangle the format to be something like "data:image/_svg" can I get the web browser to still render this as an svg?
It's probably worthwhile to take a look and see what Gin's preprocess hook is doing. Is it important? Should we instead switch to a different (less likely to be overridden) implementation like maybe hook_process()?
@joaopauloc.dev
I like how you moved to ContentEntityDeleteForm.php so that this will apply to all content, not just nodes. But I'm not sure that getQuestion() is the right place for this. There's several returns in that function, and you've just added one more. The original MR used buildForm(), and that might be a better choice. Especially since we want to also use a list.
First, the warning message will be displayed only for a node that has a menu item as a parent? or should we warn users since the content has any kind of reference in menus?
Only warn when an entity is being deleted, and that entity has a menu item, and that menu item has child menu items.
In Drupal 11 the menu link is also deleted if the content is deleted. We need to update the message, I thought something like: This page has 3 menu children. These menu links will be deleted too if you continue.
Yes, the menu item being deleted is what causes the problem that this ticket is trying to solve. But are you saying that in D11 the _children_ menu items are also blindly deleted??? I can't get https://simplytest.me/ to build D11 so that I can confirm. But if that's the case, then that's a separate critical issue of content destruction. I'm guessing that's _not_ happening.
I've updated the ticket description to have clearer messaging. Can you take a look?
Setting to "Needs Work" because
* the latest patch seems to have lost the tests from #7
* the latest patch doesn't apply on the 1.x branch, but should probably just go on the 2.x branch anyway.
Upping to "normal" because the module is not doing what it says that it's going to do.
dalin → created an issue.
dalin → created an issue.
Just noting since it's possibly related: When I ran
composer create-project fourkitchens/sous-drupal-project [PROJECT-NAME]
Then I too see the big warning in that you shouldn’t use https://deb.nodesource.com/setup_X to install Node.js anymore. but a little further after that there's an error without any info:
Unpacking nodejs (16.20.2-deb-1nodesource1) ...
Setting up nodejs (16.20.2-deb-1nodesource1) ...
ERROR ==>
And then it continues on with some Lando stuff.
If the work on this ticket fixes that, then great, otherwise let's spin up a new issue.
Also, this patch still needs a functional review.
Here's a workaround to ensure that we don't alter the same query twice, but figuring out the root of the problem is beyond my skillset.
The problem is that \Drupal\group\QueryAccess\EntityQueryAlter::doAlter() is run twice on the same query, for each entity in the View.
I don't think the MR can work yet. We still needs some changes mentioned in #7:
- remove the included files from these libraries in
jquery_once/lib - the files will then be at
/libraries/[library]sojquery_once.libraries.ymlwill need to be adjusted - add some documentation (a README.md?) pointing people to https://asset-packagist.org/ because you need to add a few snippets to your root
composer.json - bonus: add a
hook_requirements()to check if the library is where we expect.
Gave a better test query that also shows status and last login.
Why not require "npm-asset/jquery-once": "^2.2" rather than jQuery? It lists jQuery as a dependency, so it'll sort it out (especially if you have a specific version of jQuery required in your root composer.json).
Also, this commit would need to remove the included files from these libraries, and add some documentation pointing to https://asset-packagist.org/
@Utkarsh_33
This isn't about when menu items are deleted. It's about when nodes (or I guess other entities too) within the menu are deleted.
I spun this up on https://simplytest.me Mostly, this is great! Better than what I had mocked up as an interim back-end solution by just reordering some things. Here's some screenshots from using just Drupal Core:
If I switch the moderation widget to "text field" then it's okay, but the field is too big:
And if I adjust my screensize we get some problems with things bumping together, or blocking the title. It's not too terrible, but should be cleaned up before we commit this.
Code looks awesome. I don't have a chance to do functional testing right now. Once someone can do that, then this can be RTBC.
Thanks for picking this up @GuillaumeG ! This is going to be great. Just needs a few tweaks.
Before I found this d.o issue I did a mockup of a better state. I'm not sure how much overlap this has with what's already been done on this issue.