I did a search through core 10.4.3 and came up with 475 different '#type' => 'textfield' instances. Some that I saw had maxlength set, but a lot did not, including fields for things like database names and URL paths in Views forms.
I don't know how many problems it would cause by removing the default limit, or by having the limit at 256 instead of 128. But it feels like having some default limit is a good idea. I can update the MR to increase the default limit to 256, instead of removing it, if folks are on board.
I see what you're saying. Another idea would be to use flood control, similar to what Acquia Search is using:
https://git.drupalcode.org/project/acquia_search/-/blob/3.1.x/src/EventS...
That wouldn't block bots from using the search path, but it could keep things from getting out of hand.
After some discussion, I'm going to close this in favor of #3507216 which addresses this need in a better way.
Current version will just take the JSON from Google and send it right to the endpoint.
Still needs tests written for it, but I'd like to settle on this approach first.
samlerner → created an issue.
samlerner → created an issue.
samlerner → made their first commit to this issue’s fork.
I like this idea. I'm actually looking into this problem for some sites I'm managing, as search bots are causing millions of additional hits each month on pages of search results.
My first attempt to solve this was to add a <meta name="robots" content="noindex,nofollow"/> tag on the URL for the search page. This seems like something easy to add as an option for the Drupal search page, if in fact it's a working solution.
@christian-deloach did you have any specific configuration options in mind?
I wonder if we could leverage what https://www.drupal.org/project/jsonapi_resources → is using to create a custom JSON:API endpoint, rather than our own custom endpoint. Not sure if search results translates well into JSON:API's structure, but it could be worth investigating.
If we wanted to keep it really simple, we could just pass along the JSON that Vertex gives us, without any transformation.
TimoZura → credited SamLerner → .
Created an MR that adds a new form page to upload an XML file exported from Google Programmable Search, and it will create new promotions.
This also adjusts some of the routing paths and names, to make a better hierarchy, and to stop abbreviating "Promotions" as "Promos".
SamLerner → created an issue.
Removed some redundant links, changed a small bit of formatting. Otherwise it looks good to me!
This patch works for me! Installed it on my Drupal 10.2.2 site running PHP 8.2 and the error went away when I applied the patch.
Closing as not needed, this was actually the result of an unnecessary patch file for 8.2 that was adding the extra code. Removing the patch fixed the issue.
SamLerner → created an issue.
@yivanov your patch works like a charm, I went ahead and made an MR from it.
SamLerner → made their first commit to this issue’s fork.
Moving to RTBC.
The patch in #9 worked for me as well, upgrading to 10.2 with PHP 8.1. Thanks!
SamLerner → created an issue.
I made a patch for the 4.x version. Same idea, just different lines. Works great!
I'd rather have used Gitlab, but I wasn't sure how to create a new branch from the 4.x version. Happy to do it if someone lets me know how.
Tested as well, works great!
@schiavone could we get this merged in? It's needed for upgrading to PHP 8.2.
Thanks! I find it extremely useful because when I'm going to export single configs, I usually know the machine name, as that's what's displayed on the Config Synchronization page at /admin/config/development/configuration. Trying to sort through hundreds of configs by was pretty time-consuming.
I'm having an issue where in layout builder, when I have a custom block with an image field, the alt text isn't being validated if it's empty. It's supposed to be a required field, but you can leave it blank and still save the block.
When you go to the block, you'll get an error when trying to save if the field is still empty. But during the initial block creation, the validation doesn't seem to be working.
SamLerner → created an issue.
The patch stopped applying, and since it's the year 2024, I created an MR and a pull request out of the patch. Looks to be working well, could use a review.
SamLerner → made their first commit to this issue’s fork.
@rené-nieuwenhuizen have you been able to determine if promoted results still show with a language parameter?
I was able to reduce the number of tags dramatically by updating the cache tag blacklist with all the options listed here: https://www.drupal.org/docs/contributed-modules/akamai/cache-tag-purging →
On some pages it reduced the number of tags from ~600 to ~100. Still a lot, but definitely an improvement.
Is there anything else needed for this issue?
I'm pretty sure this issue is fixed with beta3, can anyone else verify if this is still a problem with the latest version?
I can confirm as well, I'm using Block Visibility Groups 2.0.1 and Block Exclude Pages 2.1.0-beta2 on a Drupal 10.1.4 site, and when I create new patterns, the exclude pattern doesn't look to be having any effect. It seems to always return FALSE because if you say to show a block only on !/foo/bar it simply doesn't show on any pages.
I'm using the MR from 🐛 D10 Warning when enabling path with exclusion Needs review to be able to save the patterns on D10.
What's going on with this issue? I'm not familiar with the "Patch" status. There's an MR available, what do we need to get it into the module?
Made all the code updates and attached before/after screenshots.
I figured out the test block creation part by using BlockContentSaveTest::createBlockContent() as an example. Once I then figured out I needed to use $this->drupalPlaceBlock inside my setUp() method, I was good to go.
Adding the DependencySerializationTrait didn't seem to solve my issue, I either didn't put it in the right place, or it's not the same cause of the error. I'll keep looking and see if I can figure out where it's coming from.
There was another functional test that was checking config name labels, and it needed the id/label reversed. Updated that test and pushed up the changes.
Created an MR with the change to the dropdown, and a test to verify that the options are being sorted alphabetically. Hiding the patch file.
Yes, I was admittedly being lazy by attaching a patch. :) but now I'll make an MR so I can add tests.
SamLerner → created an issue.
I made a fork here before realizing the fix was better suited in the contrib module, not in core.
I added an MR to 🐛 D10 Warning when enabling path with exclusion Needs review that uses a hook to change the Condition plugin to a custom one in the module that allows for exclamation points.
I made a PR that adds a new custom Condition plugin to handle the leading exclamation point, and used hook_condition_info_alter to use it as the validation class. This works for me locally after clearing cache!
SamLerner → made their first commit to this issue’s fork.
SamLerner → made their first commit to this issue’s fork.
Never mind, this looks like it's an issue with a patch we're applying for https://drupal.org/node/2864027 that has the empty array. The 2.0.1 module code doesn't have this added array. I'll look into fixing things with the patch. Closing this issue.
SamLerner → created an issue.
I pushed an update that switches to using Standard::filterXss. I wasn't sure what filter format would make sense to test, since that could vary from site to site, so I just made a dummy one.
I'm seeing a similar issue on a Drupal 10.1.4 site, and I've narrowed it down to the Agreement module. Based on the comments that refer to the problem being with translating form errors, I think this code is the problem:
public function validateForm(array &$form, FormStateInterface $form_state) {
$storage = $form_state->getStorage();
$agreement = $storage['agreement'];
if (!$agreement->allowsRejecting() && !$form_state->getValue('agree') && !$storage['agreed']) {
$settings = $agreement->getSettings();
$form_state->setErrorByName('agree', $this->t('@agree_error', ['@agree_error' => $settings['failure']]));
}
}
If the form is getting serialized, and the error message is using t(), then it's possible this is where the database connection is getting serialized as well. I can't reproduce the issue locally, so I'm applying the patch in #15 and will verify when the change gets to production.
I am also curious about what should be done long-term if indeed DependencySerializationTrait is meant to be temporary.
Created a PR that removes the extraneous help text.
SamLerner → created an issue.
@mark_fullmer tested the patch in #19 and it fixed the problem I was having earlier. Thank you!
We'll keep our updated code, but this patch will save some poor souls from WSODs.
I just ran into this problem in my Drupal 10.1.4 site. Trying to add new menu items tries to load the linkit_profile slug in the autocomplete path, but it's named linkit_profile_id in some custom code we had. This triggered the following error:
Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("linkit_profile") to generate a URL for route "linkit.autocomplete". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 187 of core/lib/Drupal/Core/Routing/UrlGenerator.php).
Drupal\Core\Routing\UrlGenerator->getInternalPathFromRoute('linkit.autocomplete', Object, Array, Array) (Line: 300)
(...)
We can update our code, but it took us some time to figure out what was happening.
Thank you @AndyF for your update, it's a much cleaner solution. Looks like it's already part of CKEditorPluginBase on https://www.drupal.org/node/2940438 →
Tested your patch and it also works, thanks so much!
Putting back in RTBC since the update does the same thing as before, just without adding another service.
I tested !59 as well and it's working great for me on Drupal 9.5.10. Setting to RTBC.
@yashsk8 did you try cloning the repo and checking out MR !59 instead of applying a patch? After doing that and running drush cc drush I saw the content:export and content:import commands listed in the drush status.
This worked for me too!
Raising this to Critical because as jkamizato said, without this patch, you can't get this module working at all in D10. And we're only 2 months away from D9 being EOL.
We're two months away from D9 being EOL so I made an MR to update the info.yml file. @alex.tulbure @iuana could one of you merge this in please and make another release?
SamLerner → created an issue.
@tzura This looks like it's fixed in the 1.4.1 version, should we close this?
Filed an MR that lets highlightSearch take a null parameter, seemed faster than modifying the code in all the templates where it was being called. This method works if folks have overridden the templates as well.
SamLerner → created an issue.
Agreed, this came up as part of a security audit, so even if normal folks wouldn't find it and exploit it, other security scans might pick up on it.
I agree, I'd also like to know why we need a table to record how many invalidations a particular tag has. The cachetag table seems to grow endlessly, as pointed out in 📌 Cache tags grows endlessly Active
Could someone describe what the potential negative impact is to clear the entire cachetags table?
Or, how do you determine what tags are no longer in use? Check each one to see if it references deleted stuff? Could we use that to run a cleanup command on a regular basis?
I just pulled down this branch and it looks like the DRUPAL_ROOT and/or get->('PWD') solutions are replaced with things like
$grandparent_path = \Drupal::root();
Can we consider that issue resolved? I also went through the unresolved issues in the MR, and it looks like they were fixed weeks ago.
I recently tested the drush commands to export a page in Layout Builder with multiple uploaded images, and both the import and export worked like a charm on my Drupal 9.5.10 site. What needs to happen next to get this merged?
@timoz there hasn't been any updates from the bot in months, I think we're in the clear to close this.
Hooray! Thank you @LOBsTerr for your persistence in getting a release out!
This patch just updates the info.yml file to add version 10, marking as RTBC. Can we get this merged and into a new release? We're trying to upgrade to Drupal 10 in the next month and we need this functionality. Thanks!
Ah! We've been using 6.0.0-beta3 and I didn't notice that a 6.0.0 release was created 4 days ago on July 7th. Sweet!
Since that version is compatible with both D9 and D10, I don't know if we need to have it in the 8.x-5.x branch. I just needed a version that worked in D9 and is D10-compatible as well.
@LOBsTerr any luck becoming a maintainer of this project? I think at this point all we need is a stable release.
Added MR that adds options in the search page configuration to add aria-label text.
Also cleans up the config page text by removing redundant descriptive text and question marks.
Created an MR that doesn't call highlightSearch in the template, and adds some typing so it will catch these problems sooner.
SamLerner → created an issue.
@wxman you'd need a patched and working version of Embed to also get a patched version of Entity Embed working. Hopefully that gets resolved soon, lots of attention on it since it's DrupalCon. Once Embed is CKE5-compatible, this should quickly follow.
I tested this out and it works great. I cloned the MR and when I went to the Status Report, I saw this output:
SamLerner → created an issue.
@wxman I think you're looking for https://www.drupal.org/project/entity_embed/issues/3272732 ✨ Drupal 10 & CKEditor 5 readiness Fixed which has a patch that needs review.
Could get this into an official release? Thanks!
Review the update-info-files branch, not the updates to the 1.0.x branch.
SamLerner → created an issue.