I've mentioned this issue in docs in two places:
-
https://www.drupal.org/docs/develop/standards/css/css-file-organization →
Diff: https://www.drupal.org/node/1887922/revisions/view/13469196/13569583 → -
https://www.drupal.org/docs/develop/theming-drupal/adding-assets-css-js-... →
Diff: https://www.drupal.org/node/2216195/revisions/view/13563347/13569585 →
Added a note to indicate that SMACSS groups cannot be interlaced between modules and themes. I.e., loading a normalize.css in a theme's "base" SMACSS group will appear in the CSS cascade in the HTML (and aggregated files) only after all styles defined in core or contrib modules (even those defined in higher SMACSS groups like "component" or "theme").
See https://www.drupal.org/project/drupal/issues/3046636 🐛 LibraryDiscoveryParser overwrites theme CSS group ordering Active
Added a note to indicate that SMACSS groups cannot be interlaced between modules and themes. I.e., loading a normalize.css in a theme's "base" SMACSS group will appear in the CSS cascade in the HTML (and aggregated files) only after all "component" and "theme" styles defined in core or contrib modules.
See https://www.drupal.org/project/drupal/issues/3046636 🐛 LibraryDiscoveryParser overwrites theme CSS group ordering Active
Agree this is fairly frustrating and more than slightly nonsensical that there is no way to define a "base" SMACSS in a theme and make it appear first before module code and even before other SMACSS groups from the same theme.
Even stable9 theme in Drupal core suffers from this exact issue out of the box:
Given the following three examples...
stable9.libraries.yml:
css:
base:
css/core/assets/vendor/normalize-css/normalize.css: { weight: -20 }
core.libraries.yml:
internal.jquery_ui:
css:
component:
assets/vendor/jquery.ui/themes/base/core.css: { weight: -11.8 }
theme:
assets/vendor/jquery.ui/themes/base/theme.css: { weight: -11.8 }
system.libraries.yml:
base:
css:
component:
css/components/ajax-progress.module.css: { weight: -10 }
One would expect normalize.css to be the first CSS file in the HTML, but in fact, it shows up last.
Expected result:
/core/themes/stable9/css/core/assets/vendor/normalize-css/normalize.css
/core/assets/vendor/jquery.ui/themes/base/core.css
/core/themes/stable9/css/system/components/ajax-progress.module.css
/core/assets/vendor/jquery.ui/themes/base/theme.css
Actual result:
/core/assets/vendor/jquery.ui/themes/base/core.css
/core/themes/stable9/css/system/components/ajax-progress.module.css
/core/assets/vendor/jquery.ui/themes/base/theme.css
/core/themes/stable9/css/core/assets/vendor/normalize-css/normalize.css
jwilson3 → created an issue.
jwilson3 → created an issue.
jwilson3 → created an issue.
I've made a few updates to ddev config for the latest version of Ddev 1.23.0, including the following changes:
--create-docrootis no longer required--project-type drupal10is deprecated in favor of more generic--project-type drupal, which works for Drupal 8, 9, 10, 11+
See ddev 1.23.0 release notes for more info https://github.com/ddev/ddev/releases/tag/v1.23.0
jwilson3 → created an issue.
@binoli-lalani: Please change the title of the MR back the way it was. This issue has nothing to do with fixing missing hyphens for prefixes - Words starting with "de"
The title should be:
Issue #2720109 by Spokje, kndr, sharma.amitt16, maacl, felribeiro, Neslee Canil Pinto, yogeshmpawar, quietone, zeuty, joey-santiago, Brian-C, ranjith_kumar_k_u, seppelM, jenny.cha, kiwimind, NikLP: maintenance-page--offline.html.twig is not picked up when system is offline
Agreed. But your comment might be better served on the other issue ✨ CKEditor 5 support for Content Templates Needs review .
The problem I can foresee is training non-technical users to understand the difference of when and when not to enter the hash when creating anchors, and links to the anchors. Technically this is already an issue, but would be exacerbated by the new Hash icon in some ways.
Think of the common use case of creating a Table of Contents with URL fragment links to anchors down the page on a really long page.
Users will need to grok this:
- when you create an anchor you'd click the # icon, and NOT ENTER a # inside the popup.
- when you create a link to an anchor you'd click the 🔗 icon and ENTER a # plus the anchor name inside the popup.
The fix would be to improve the UX in the popup itself, to include the hash sign before the input field, so users get trained not to enter it manually on the anchors.
I could be wrong, but my understanding is that they added the UI because they're updating the architecture to use entities which facilitates admin UI's more or less for free. Also, consolidation and reducing overlap and module soup is – in general – a good thing in the Drupal ecosystem.
Previously, this module recommended using ckeditor_templates_ui (there is a link still present on the project page). The work on this issue includes all of the UI features from that module, plus more, at slightly different URLs in the Admin > Configuration section.
Currently, the module does nothing to tell the user there are two UIs, and we hit this issue and ended up super confused.
Therefore, I'm setting this to NW to add an hook_update_n to uninstall ckeditor_templates_ui if it was previously installed on an older version of the module, and still present after an upgrade to the latest 8.x-2.x branch.
I've created a separate issue 📌 Remove ckeditor_templates_ui from Project page Needs work to cover the docs task.
ckeditor_templates_ui maintainer is not interested in flagging this for folks. Therefore, lets take a different approach. I'm reopening and moving this to the ckeditor_templates issue queue as a documentation task to update the project page, and include accurate release notes that indicate that ckeditor_templates_ui should be uninstalled once ✨ CKEditor 5 support for Content Templates Needs review lands. There may even need to be an update hook added to automate uninstall the module as part of #3273358.
Follow. Hash or, you know, an actual Anchor, arrr matey.
You might need a custom hook breadcrumb implementation to load the view, grab the result, and apply the token correctly.
In our case, we had our view page displays configured like this:
page_1:
title: Blog
url: /blog
page_2:
title: Blog for [current-page:url:args:value:1]
url: /blog/%year
page_3:
title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]
url: /blog/%year/%month
page_4:
title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]-[current-page:url:args:value:3]
url: /blog/%year/%month/%dayThis worked for the H1 Page title, but didn't work for the window title, which was still showing the raw tokens.
The trick is to use Metatag Views, and copy the same title token configuration into the Metatag Window Title token.
When you enable Metatag Views submodule (included with Metatag), you get some additional field configuration on your views to customize the metatags.
page_1:
title: Blog
url: /blog
page_2:
title: Blog for [current-page:url:args:value:1]
metatag title: Blog for [current-page:url:args:value:1]
url: /blog/%year
page_3:
title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]
metatag title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]
url: /blog/%year/%month
page_4:
title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]-[current-page:url:args:value:3]
metatag title: title: Blog for [current-page:url:args:value:1]-[current-page:url:args:value:2]
url: /blog/%year/%month/%dayThis fixes the issue. The reason this works is because the default token for metatags is: [view:title] | [site:name] and unfortunately since the view title contains tokens, metatag cannot interpolate nested tokens-within-tokens, so the raw token is shown for window title.
I'm not sure I understand the justification of how this is marked fixed. No docs updates were made, no mention on Project summary page of the fact that the features of this module are being included into the main CKEditor Template module with the work going on in ✨ CKEditor 5 support for Content Templates Needs review .
Re: #40:
At the moment, it's not obvious which one is the canonical one that should remain so figuring that out is the first step.
I propose docs/develop/local-server-setup → as the home for DDEV.
My reasoning:
- Since many pages will be linking here and we want the page to be discoverable from high-level new users, the canonical URL should be fairly short and located in a high-level folder on the URL structure. Of the URLs listed in the issue summary, the highest-level candidate I see irrespective of its actual content on page is the "Local Server Setup" page. Of course the URL and page title itself could change a little bit in order to accomodate the IA, but in general it would remain inside the /docs/develop section, which is a sensible parent location.
- Others have already said that this page is confusing and hard to navigate. This page and the pages that it links to in its sub-section are currently written in a way that would need a significant structural overhaul to remove legacy options anyway. The page as currently structured with various equally-weighted subpages is diametrically opposed to the purpose of this issue and must be updated, with the goal of getting to the tl;dr faster, with real actionable steps and cli commands in front of users first, and then link to secondary/tertiary/other options as subpages. Since this content overhaul would have been required anyway to comply with point #1 in the Proposed Resolution section of the issue summary (quoted below) it makes sense that this page becomes the new landing page.
1. One page/section on Drupal.org for setting up a local development environment that recommends DDEV, it could also mention Lando, quickstart with PHP server and other modern alternatives so that people know they exist, but should not mention effectively defunct tools like XAMPP.
The way I see the next immediate steps would be:
- Receive feedback on proposed landing page, have others propose alternates if no consensus.
- Write down what needs to happen to fix the information architecture.
- Write down the plan of attack to fix the various docs' pages content to best reflect the new architecture.
Something like this could be added to IS (if others agree).
- Decision: Use the "Local Server Setup" node at /docs/develop/local-server-setup as the home for the top level Ddev docs page.
- Fix the Information Architecture:
- Update the Node title and URL alias to something even shorter. E.g. /docs/develop/ddev-local, ensuring redirects from old alias is working.
- Move off most of the existing content of the page to another page at /docs/develop/other-local (or similar).
- Move the menu item within the "Develop" section (eg sidenav on /docs/develop page) to the very top of the list. This is because one of the first things you think of when developing is getting your local environment setup.
- Prioritize down the "Develop on Windows" link on the /docs/develop "Development Tools" page and instead add the link to the new Ddev docs page high on the page ideally in the "Development Tools" section.
- Fix the docs content to reflect the new architecture:
- Rewrite the top-level page in the most practical and brief way possible to keep the page short. Get CLI commands in front of users earlier rather than later. Avoid breaking it into sub-pages if at all possible. Decide how many "cli commands" to include. Do we duplicate content from Ddevs own Quick Start guide docs page? or link to it? https://ddev.readthedocs.io/en/stable/users/quickstart/#drupal
- Decide if XAMPP and others should be removed or left on the "Other" page for posterity, backward compatibility, and edge cases.
- Consider a rewrite of the "Develop on Windows" page to prioritize Ddev over the other solutions as an integral part of setting up on Windows, instead of as a kind of afterthought. Replace links to XAMPP with a link to the "Other" page.
- Create a list of required changes ordered by complexity on the rest of the docs pages listed above (complexity levels might include: page delete, body copy overhaul, paragraph rewrite, single sentence rewrite, or link destination update, etc).
- Execute the list of changes.
I think I just consider each page distinct, but it sounds like you are considering them states of a single page.
I haven’t used the ordered list formatter very much
Anecdotally, I've had the need for this several times over the years. So much so that I decided to revive this issue and share my work. I use ordered lists on paged search results, where yes each page in the search results is part of a larger context. This fix is also really helpful when using "Views Load More" or "Views Infinite Scroll" module, where new results are loaded into the current page via ajax without a round trip to the server.
Keep in mind, I'm implementing designs from UX teams with limited knowledge of Drupal, and this pattern of incrementing the index of give search results across pages just makes sense intuitively. It is also worth noting that this issue was closed 16 years ago by Earl, the original author of Views, which could also explain why not more people are subscribed to this issue. The fact that there were 10 comments on the issue after it was originally closed is a decent indicator that there is a need, however small, for this fix.
I rely on the method in #11 (the Twig template override) as the go-to solution on many projects because it is more semantic and properly announced and easily navigable by screen readers, as opposed to having to go with the "views result counter" approach in #15 inside each row and using the "Unformatted" Views display format, which then requires more theming effort to restore basic formatting styles that you get for free with an <ol> and <li>.
I'm having trouble making it all the way to your side to re-classify this as a feature request instead of a bug. (I'd honestly be very interested to see a use case where it makes sense to start ordered, paged output back at 1 on each subsequent page load.) That being said, it is a valid point that this should probably be refactored to be optional, and on by default for new new views, but off by default for existing views, so folks can make a decision whether to opt in on a case-by-case basis.
I don't think this is feasible to implement for Autoban because User Agent is not something tracked in the watchdog table.
Autoban only has access to:
type- the module name where the log message originated.location- the request URI.referrer- the URI that referred the user to the site.hostname- the user's IP address.message- the raw message string passed to t() function.variables- the serialized php array of arguments passed to t() function.
This would be better achieved in .htaccess file (to avoid the performance impact of loading Drupal), or by writing a custom module.
If you have access to alter .htaccess you might consider checking out Ng Firewall (blog post) - FYI, I am not the author, I just threw it up on Github, because the author doesn't use git apparently.
In the Drupal 8+ versions at least, the query hits both the messages and the variables table, so what am I missing?
I see the same user names (often well-known at stopforumspam.com, or obvious ones like "Administrator") again and again, and I would be happy to block these IPs with a Threshold of 1.
You could setup a rule with a REGEXP query for
user.*Administratorwhich would hit against the variables table. It is ashame that the the module doesn't let you specify a search query containing one part for themessagecolumn and the other part for thevariablescolumn.If you try this, you'll want to test heavily for false positives, with either Autoban rule test feature, or with SQL queries:
SELECT * FROM watchdog WHERE `variables` REGEXP 'user.*Administrator'
I think I see your issue.
The Autoban module is more for scanning Watchdog log messages for behaviors that seem like repeatable patterns.
The message column for "page not found" errors in watchdog logs don't actually contain URLs like /topic. They contain a PHP "placeholder" string like @uri. Additionally, the variables column contains a PHP serialized array like a:1:{s:4:"@uri";s:9:"/topic";}. Autoban RegEx and LIKE queries both run against the raw database column contents (before placeholders are filled), therefore it will never match ^/topic.
One workaround would be to use the colon and double quote characters used in the serialized string to indicate the first part of the URL: Eg, :"/topic which will turn up a match against the variables database column. This needs testing.
On the other hand, if you want simple regex style banning from any request to specific URLs that doesnt involve scanning watchdog logs, try the Perimeter Defense module, which does exactly this. →
When you say domain name source, do you mean referrer?
If so, then Autoban supports creating a rule based on a specific "referrer" domain. But since Autoban module works by scanning watchdog log messages. The user would have had to have triggered some kind of watchdog message with a repeatable pattern (eg a 404 message, or something) for the referrer logic to even work.
It seems like what you're asking for would be better done by a different module, maybe a sub-module of Autoban, because it requires checking every single access request against a list of referrers.
This can also be done in an .htaccess file, which is maybe less desirable because you have to do a code release when you want to make a change, but on the other hand, its not requiring a Drupal bootstrap, database query to do the Referrer string comparison, and therefore requires less memory and resource impact. See https://www.drupal.org/node/243579 → for how to do this.
Finally, there is already a patch for Drupal core to handle referrer banning, but it was not accepted: #27787: Add Referrer Banning →
While we're at it, we should also fix capitalization consistently for Autoban. The best practice is to use lowercase. (Note that Perimeter module also doesnt follow this best practices, but at least they're consistent and use Uppercase everywhere).
I totally agree, and would like to bump this issue.
If you compare Autoban watchdog log messages with Perimeter Defense module's watchdog log messages, you see room for improvement.
Some improvements I suggest be implemented here include:
- Each IP gets its own log message, instead of a generic message stating a Total of 3 IPs were blocked. This is unhelpful information.
- Explain which Rule was triggered for the ban action.
- Provide any additional context and info like from the code snippet in the issue summary above.
#9 is a great proposal. But it needs a lot more work to flush out because you'd want to support forward slashes, hashes, and other non-ascii characters in the "$word" variable. So you'd need a more solid way to encode/escape $word for use inside a regex.
Example's you'd want to support in banned words:
- wildcards -
oneword*anotherthe asterisk needs escaping for regex. - slashes -
/path/to/thingyslashes (and backslashes) need escaping for the regex. - periods - Eg, I want to block
some.xmlbut not all things that have xml extension. periods need escaping for regex. - dashes -
thing-thing-thing</li> <li>brackets - <code>fq[]=thingor
some{$malicious_code}square and curly brackets need escaping for regex. - probably many many more
Then, there is also the complication of an upgrade path from the current Regex Based solution to a non-regex based solution. I'm not certain one exists, because you can do things like [a-zA-Z0-9-_] in a regex that you'll never be able to do with a simple word match. Therefore you'd want to leave the regex capability there, but collapse it inside a <details> container and mark it as "Advanced RegEx Matching"? And rewrite the default examples for the simpler case. No migration needed. New installs benefit from the simpler UI with default examples, Existing installs can manually migrate and simplify their regexes.
A `reason` column would be a fantastic and helpful feature, along with a `timestamp` column, for the ban module bundled with Drupal core. Then manual bans entered by admins via the UI can explain why something was banned. And modules like Perimeter Defense and Autoban can supply a reason eg (a ban rule) along with their ban request.
Having this info can be helpful for admins to do analysis to see why they were banned, in case they get emailed to unban, incase it was a false positive. Plus, having a reason column makes it easier to alter the ban message shown in the browser and cater the message to the user. Which is a bit better UX and friendlier than the terse "XXX.YYY.ZZZ.AAA has been banned" message.
Since the Troll module appears to not have a D8+ branch or release, and there hasn't been movement on this in years, I'm thinking it might make sense to switch this issue over to core issue queue and repurpose it.
Does anyone object?
For now I'm using a workaround to ignore these settings with config_ignore, but this really shouldn't be necessary:
+++ b/config/sync/config_ignore.settings.yml
@@ -3,6 +3,7 @@ _core:
mode: simple
ignored_config_entities:
- acquia_connector.settings
+ - 'autoban.settings:*_last'
- 'contact.form.*'
- 'new_relic_rpm.settings:api_key'
- purge.logger_channels
jwilson3 → created an issue.
Even GoogleBot has gotten confused by faceted search interfaces and crawl a basically infinite number of pages very fast on an otherwise small site and other bots (for example AHRefsBot and SemRushbot) have brought sites down repeatedly until they get blocked when there is no Crawl-delay in place.
We're seeing this exact case right now. Is there an issue for it somewhere on D.o to address this by other mechanisms inbuilt to facets/search_api?
The 'bypass access' permission is not an uncommon pattern found in Drupal core and contrib.
For example, it is also used in node, file, and ECK modules:
- 'bypass eck entity access'
- 'bypass file access'
- 'bypass node access'
jwilson3 → created an issue.
jwilson3 → made their first commit to this issue’s fork.
Closing as outdated since IU Framework is deprecated. Issue queue cleanup.
Issue queue cleanup. Drupal 11 is now out.
Issue queue cleanup.
Closing this as outdated.
Issue queue cleanup.
lauriii → credited jwilson3 → .
I'm bumping this to critical because the bug here renders the module useless.
This is fantastic. Thank you so much for your responsiveness here and for introducing the new hook as a solution to alter the charts.
Unfortunately there were other changes we were hoping to make to the edit forms as well. It seems like it's still impossible to alter the form presentation to do things like collapse the chart details element wrapper when data is already provided.
jwilson3 → created an issue. See original summary → .
I'm seeing another error when running security_review, it seems like it could be related to one of the lines of code on the MR here, so thought I'd mention it here.
Symfony\Component\Filesystem\Filesystem::makePathRelative(): Argument #1 ($endPath) must be of type string, bool given, called in /var/www/html/docroot/modules/contrib/security_review/src/Plugin/SecurityCheck/PrivateFiles.php on line 48 in Symfony\Component\Filesystem\Filesystem->makePathRelative() (line 448 of /var/www/html/vendor/symfony/filesystem/Filesystem.php). Drupal\security_review\Plugin\SecurityCheck\PrivateFiles->doRun() (Line: 75)
Drupal\security_review\SecurityCheckBase->run(, Array) (Line: 151)
Note: I am not using the MR, because it no longer applies to stable version 3.0.0.
The source branch is 6 commits behind the target branch.
Needs a reroll I assume.
I found the core issue here 🐛 Allowed type text is duplicated in the back end of image field Active
Affects both svg_image and svg_image_field.
🐛 Duplicate allowed types help text Active
This is related to the deprecation and syntax changes of the file validators. See the related CR file_validate and related functions are deprecated and replaced with file.validator service and Constraint plugins → .
Example code snippets exhibiting the error from SVG Image Field module.
/**
* Plugin implementation of the 'image_image' widget.
*
* @FieldWidget(
* id = "svg_image_field_widget",
* label = @Translation("SVG image"),
* field_types = {
* "svg_image_field"
* }
* )
*/
class SvgImageFieldWidget extends FileWidget {
//...
/**
* {@inheritdoc}
*/
public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state) {
$element = parent::formElement($items, $delta, $element, $form, $form_state);
$field_settings = $this->getFieldSettings();
$element['#upload_validators']['file_validate_extensions'][0] = 'svg';
}
// ...
}
If this syntax change is a deprecation in a minor version of Drupal core, then the old method using `file_validate_extensions` should still work (and still have working tests in core) and not introduce the duplicate allowed types text.
Thanks for the report. I agree that a fix is required in the module to ensure we support both methods (before and after the deprecation).
However, the duplicate text seems to be a bug in core. Just because they deprecated it doesn't mean the old method should show up twice. Is there a core issue for this?
You're totally right. My apologies. I was rushing through my issue queue reviews and didn't connect the dots even though I was looking right at it. 🤦♂️
Leaving in needs review because it needs to be manually tested, with screenshots, etc. Can't guarantee I can get to this level of testing at the moment, so I'm happy to have help from anyone else following this issue.
jwilson3 → created an issue.
Just wanted to come back around and say that this feature is fantastic. Thanks for implementing it. 👏 🎉
Is there a chance we could add more examples that display the variants when same_day_omit_duplicate_ampm and/or zero_minutes_omit are set to TRUE, on the main listing page at /admin/config/regional/daterange-compact-format ?
Note there is a module called Drupal Perimeter Defence → that does something very similar to what you want. Might be worth a look, and a comparison about what differs to make sure efforts are not duplicated and feature sets don't overlap too much.
Thanks for fixing that @mxr576. From what I've seen (on several higher-ed Slack forums) this change has bitten several people recently. Every small change helps.
the install info could be on the module page
Agreed.
Code changes are okay, but marking NW to think through and address the second question on #3.
If the region does not exist in the layout it is in, remove the block from the data before saving, and alert the user that the block was removed and needs to be re-added and or, the data is invalid and cannot be saved.
Would it be less harmful/destructive to first try moving the block to the first valid region that is defined, and warn the user. If there are no valid regions defined, I guess alert the user that the Layout needs a region in order to be saved (if we're not doing this already).
jwilson3 → created an issue.
Spent +1 hour on this for a client. Disappointed to see no issue credit awarded. :-/
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
IMHO the CR should be expanded with some hints on how to fix the lack of the codec or of the binding of libavif.
The avif contrib module leverages the lib_avif dependency, maybe the CR could point people to the issue I linked above if they're not able to affect how PHP is compiled with avif support enabled on their hosting environment. ✨ Add an AVIF conversion image styles effect Active
I agree with @apaderno. Once someone opens an MR, work must continue there.
After trying several things, this was my last attempt before giving up and writing up this ticket.
I don't know if this was on the right path or not, but we ran out of time and budget to keep pushing on this at the end of the sprint.
THIS CODE DOES NOT WORK.
<?php
use \Drupal\Core\Form\FormStateInterface;
/**
* @file
* Primary module hooks for My Module module.
*/
/**
* Implements hook_field_widget_single_element_WIDGET_TYPE_form_alter
*
* @param array $element
* @param FormStateInterface $form_state
* @param array $context
* @return void
*/
function MY_MODULE_field_widget_single_element_chart_config_default_form_alter(array &$element, FormStateInterface $form_state, array $context) {
$element['#after_build'][] = 'MY_MODULE_field_element_after_build';
}
/**
* Processes the settings element.
*
* @param array $element
* The form element.
* @param \Drupal\Core\Form\FormStateInterface $form_state
* The form state.
*
* @return array
* The element.
*
* @throws \Drupal\Component\Plugin\Exception\PluginException
*/
function MY_MODULE_field_element_after_build(array $element, FormStateInterface $form_state) {
if (
!empty($element['config']['type']['#options'])
) {
$valid_chart_types = ['donut', 'pie'];
if ($default_type = $element['config']['#default_value']['type']) {
$valid_chart_types = array_unique(array_merge($valid_chart_types, [$default_type]));
}
if($current_type = $element['config']['type']['#value']) {
$valid_chart_types = array_unique(array_merge($valid_chart_types, [$current_type] ));
}
foreach ($element['config']['type']['#options'] as $key => $value) {
if (!in_array($key, $valid_chart_types)) {
unset($element['config']['type']['#options'][$key]);
}
}
$form_state->setRebuild(TRUE);
}
return $element;
}
jwilson3 → created an issue.