volkswagenchick → credited dalin → .
I've been mentoring @kwolford121 throughout the day. All the remaining names related to middleware are renamed. @kwolford121 is creating a follow-up issue for non-middleware renaming.
Since Package Manager is a requirement for Project Browser, we should list it as a hard dependency (in the .info.yml file) now that it is included in Drupal Core.
dalin → changed the visibility of the branch 2699565-replace-drupal-with to hidden.
dalin → changed the visibility of the branch 11.x to hidden.
I'm at DrupalCon Atlanta2025 and I tried to sit down with a novice, but it turned out to be a bit much. I'm going to remove the Novice tag because this requires first understanding unit tests, dependency injection, and the difference between kernel tests and functional tests. Even though in the end we'll only be changing a few characters.
dalin → created an issue.
mradcliffe → credited dalin → .
Gotcha!
Oh interesting place for that bug. But if I understand this correctly (tell me if I'm wrong), the bug is not specific to Drupal CMS. If someone installs Trash on any other site, they'll run into the same bug. In that case, shouldn't the fix go into Trash module and not Drupal CMS?
> It's working for us on... gin 4.0.x-dev
Hmmm, not for me. I can't get this to apply to dev _or_ 4.0.2. I think it needs a rebase, but there are conflicts in `src/GinContentFormHelper.php`. That's beyond my current GitLab skills.
We should also run through the full suite of tests in #10 so that we review all the different ways that the workflow widget can be configured.
Your solution worked great. Thanks.
dalin → created an issue.
Here's my first attempt at an issue fork.
* Changed to "Null Coalescing Operator" because that's what previous patch was trying to do, but with way more complexity.
* Also fixed another similar warning in removeItem()
I was only experiencing PHP warnings, but the OP reported being completely unable to add multiple items on a media field that allows multiple items. In that case Drupal would be outright preventing you from what it's supposed to, so I'm upping to High priority.
@geoffreyr
Interesting.
While your approach is fundamentally different than the original thrust of this issue, I can see how a back-end hook could be useful (though probably as a different issue on d.o). Some thoughts:
* It should probably only re-save the crop if the values have changed.
* To create a whole system of plugins on top of Focal Point (that can interact with its hooks and add additional settings) might be overkill if Focal Point was just awesome out-of-the-box. Typically you shouldn't create the abstraction layer until you have 2–3 use cases with valuable divergence.
Oops. We launched a significant new feature without release notes or a change record (that I could find, sorry if it's actually there somewhere).
Also, this new feature is mostly only useful for no-code sites. I created a follow-up issue to allow this to be disabled on enterprise sites (still our largest audience): ✨ Allow CKEditor 5's table properties and cell properties to be disabled Active
@danreb
That's great info.
So it sounds like what we need is
drush search-api-pantheon::postSchema --help to output something like
Arguments:
[server_id] Search API Server ID to post schema for.
[path] Path to schema files (Leave empty to use default schema). The default is /code/web/modules/contrib/search_api_solr/jump-start/solr8/config-set/
and drush search-api-pantheon::postSchema to output something like
Successfully posted schema files from /code/web/modules/contrib/search_api_solr/jump-start/solr8/config-set/
Please wait 5 minutes for the changes to take affect before attempting to index content.
and /admin/config/search/search-api/server/pantheon_solr8/pantheon-admin/schema to output something like
Successfully posted schema files from /code/web/modules/contrib/search_api_solr/jump-start/solr8/config-set/
Please wait 5 minutes for the changes to take affect before attempting to index content.
@danreb,
But back to my original bug report:
> I do have the option of manually giving it a file path. But what's the format? relative to the webroot, code root, or absolute?
Also, it would be helpful to show what path it will attempt to use if I omit the default.
> Adding -vvv in the drush search-api-pantheon:postSchema command, should normally show you a successful upload of the configuration like in this screenshot:
ahh, okay I missed that. I was just moving too fast in a bit of a panic.
> Note also that there is a 5 minutes window time after the new configuration to take effect, this mean, you need to wait for a few minutes and then you can reset the index tracker and re-index the site.
So this might've been the core problem. Is this documented anywhere? Ideally after I run `postSchema` either via Drush or the GUI.
> if you --help the drush command, it will show you the format, e.g.
> drush search-api-pantheon:postSchema --help
It doesn't on the versions that I'm using:
I think this issue is the most important thing that we could do to make Drupal more competitive with WordPress. WP requires much less effort to maintain long-term. Even with the relatively smooth transition that Drupal has with D10 to D11, WP is still much less. WP's approach of "backwards compatibility forever" has not caught up with it yet (and maybe never will).
While we've done so much to make Drupal major upgrades smooth, I think we still need to do more to remain competitive.
In regards to WordPress...
Organizations might choose WordPress because they perceive it as easier to use for content editors, or because they believe they can achieve their goals with less complex development work compared to building a custom solution with Drupal Core.
Bigger than any of these reasons, I think people see WP as requiring much less effort to maintain long-term. Even with the relatively smooth transition that Drupal has with D10 to D11, WP is still much less. WP's approach of "backwards compatibility forever" has not caught up with it yet (and maybe never will).
When it comes to comparisons with WP, we mostly rely on the fact that no serious engineer would choose WP due to its inferior architecture. That can only take us so far.
While we've done so much to make Drupal major upgrades smooth, I think we still need to do more to remain competitive. We already win in terms of superior content editor UX, and superior project governance. We need to beat them on another pillar in order to gain ground.
@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.