It's been a while since I touched the project I posted his about, but as I recall, we are using a modified version of the Webform Quiz → module, and just providing different feedback options based on the "min point value".
I was re-examining this today trying to understand why I was running into the issue in the first place. Confusingly, after removing the lines I mentioned in my previous comment, and the lines mentioned in comment #4 in 💬 Error loading class 'solr.ICUCollationField' Fixed , I saw that my local solr was still automatically creating the collection instead of running into the error from before. I believe the only difference was that I had updated my config set. Looking at the git log, I saw that I had replaced versions of the module dir settings - e.g. these lines - replacing versions that looked more like the jump start templates
I'm not certain how I ended up with the jumpstart version of the config set rather than what's in the template, but this is something to be on the watch out for, as I'm thinking that the environment variable fix isn't necessary if you are using a config set generated from the correct templates.
#40 solved it for me. Specifically:
environment:
- SOLR_MODULES=extraction,langid,ltr,analysis-extras,scripting
Was all that I needed for my ddev environment. Specifically using the latest ddev/ddev-solr.
You know, I kind of assumed that's what
!$requestEvent->isMainRequest()
Was doing in the event subscriber, but I should confess, I didn't know exactly what was included in that. I'm happy to adjust if needed.
Apologies for the delay in responding. I've been a bit swamped and doing some traveling lately. I'd appreciate any patches if you have that available.
I don't have the opt in security advisory coverage → role myself, but I have submitted an application 📌 [1.0.x] Facet Bot Blocker Active for it, using this module as the example. If anyone is willing to review the module code, and post in that issue, that may expedite the process. I haven't had the capacity to participate in the review bonus program, as I've been pretty swamped lately myself.
I was running into this error, and it resolved after I went into the module settings, selected a font, and saved. It seemed as if there weren't any selected. Not sure how it got into that state.
I just tried dropping a break point in the PreviewLinkTasks::getDerivativeDefinitions(), to see what calls that. interestingly, in the stack appears the Webform module's implementation of hook_menu_links_discovered_alter() where it calls::
\Drupal::service('plugin.manager.menu.local_task')->getDefinitions().
I wanted to see what would call that if webform wasn't there, and added a return statement at the top of webform's hook. It seems that the next in line to call getDefinitions is in LocalTaskManager, but tat is only prompted by BlockViewBuilder in what seems to be well into the rendering process.
I'm not too sure what the overall Drupal philosophy is for rebuilding caches, but at face value, this does seem very bespoke to the instance of when/how/where a cache is being cleared, and I can see room for plugin definitions being loaded in different ways that might lead to this situation of dynamically generated routes not propogating.
I am wondering if we are seeing the same issue in 🐛 \RouteNotFoundException: Route "entity.node.vmd_preview_list" does not exist. Active , it seems that conditions exist that allow dynamically defined routes via "DeriverBase" classes to be passed over before the available plugins list is cached.
I feel like this must be some sort of core race condition bug. I just had this happen again today, albeit with a route from a different module. This one was from the Preview Link module, and the error was:
Exception 'Symfony\Component\Routing\Exception\RouteNotFoundException' with message 'Route "entity.node.preview_link_generate" does not exist.' in /code/services/drupal/web/core/lib/Drupal/Core/Routing/RouteProvider.php:211
The common traits between these routes is that they are not defined in a normal *.routing.yml file. Instead they are dynamically generated via a "Derivitive" class. Berdir even comments there may be a race condition in his comment here → . My guess is that there is a path that allows Drupal to cache it's list of available plugins without calling these dynamic Route providers via Derivitive classes.
Not sure if Crawler Rate Limit → is on your radar, but it seems like that can meet this feature request easily enough. I'm using the module myself on a number of sites, and my main wish with that is that it had some sort of reporting on how much traffic it actually blocks. While I use it, I can't tell if it's effective or now. In fact that was the inspiration to create a dashboard for the Facet Bot Blocker module.
I just came across this doing some testing on my own, discovering that Perimeter doesn't actually work when using fast404. While I like the idea of banning IPs that are probing my site for vulnerabilities, I suppose it's nice that they are still getting the treatment that minimizes demand on my infrastructure.
I did come checking, and I confirm that the core module's BanMiddleware::handle(), which seems to do the checking for banned IPs, does also run before the fast 404 event subscriber, so there should be some added optimization making these modules compatible.
I tested the patch in the merge request locally, and can confirm that the order changed to run Perimeter's event subscriber before Fast 404's.
Is that good enough for RTBC?
That is a good point. I think it's very feasible to set these to expire after a minute, or even slightly longer.
Just as another general note to the group, I recently posted on my blog on "Building a Firewall in Drupal" for those without access to a proxy WAF tool.
So with the Facet bot blocker module, I sort of intentionally didn't track hits by individual IP as was worried about this data filling up the available memcache/redis cache space - though I haven't measured what this might be in one of my sites experiencing unusual bot traffic issues. Instead I just track some basic metrics, like number of blocks, number of passes (so I can provide a ratio), the latest IP/user agent blocked. That sort of thing.
I suppose we can make it configurable, and have that as a feature to turn on/off, and people with more control over their architectures can dedicate a separate memcache instance if we used it's own cache bin. Not sure if this is over-engineering...
Hello, It is I, who brought you the Facet Bot Blocker → module. I just wanted to share that I've created a new module also focused on stopping bots, simple called Bot Blocker → . I literally just published it, and would be happy to hear any feedback before tagging a 1.0 release.
Hello,
I just wanted to let you know I've just created a new module at Bot Blocker → , which handles blocking requests with specific substrings in user agents (i.e. crawling tools), and very old versions of browsers as identified by their user agent strings. I'm going to mark this as closed won't fix, and we can discuss any feature enhancements over in that queue.
Looked good to me. Merged.
Thanks, yeah, it crossed my mind while I was putting it together, but thought it would save some minor compute cycles to just check for the presence of the limit than anything else. I suppose the MR is reasonable though. Will merge later.
My agency uses Pantheon mostly, but we work with a variety of hosting options for sites. Pantheon does not allow ssh access, and logs are stored in separate app containers. Acquia allows ssh, but that doesn't allow much more than running drush commands, and logs are similarly stored somewhere else. It's a bit of a complicated situation, and I don't want to make assumptions in documentation about what people are running on.
That seems like some good info, but not specific to this module per se, and presumes you have more control over your server than you might in a host like Pantheon or Acquia.
I do like that idea of using a more general namespace for the module. I do think it's important to keep a separation of concerns. Will keep this issue active until I, or someone else creates "bot_blocker"
Apologies @avpaderno, I saw @vishal's first two comments, but I suppose I missed that I had to set the status in response to their last one. I still wish to pursue the opt in status if that works for you.
Also, when I export the config after that, it adds an empty directives key:
@@ -2,6 +2,7 @@ _core:
default_config_hash: o4-eDkmTmVdUICtL1VxWD3S9Ze8kNq_lHj6DskF8U8o
report-only:
enable: false
+ directives: { }
reporting:
plugin: none
enforce:
It seems I was able to to it id I enable the report-only, enable one of the directives under that, add my new directive to the enforced section, save, then disable the report-only directive, and save again.
I am also experiencing this, with the 1.0.6 version of this module, and 2.0-beta10 of viewsreference → . In my case, I have views reference fields in a paragraph type, which are loaded from a general paragraph field with unlimited cardinality.
For one, I think it we can make the code safer in ViewsRefFilterUtility::loadView() by checking that it's not null/empty later after we try to load the view when we detect that it's empty. Since we declare that variable static right before this line, I think it would always be true since it will be "set", but in this case, seems to have no value.
Adding a "&& !empty($view)" right before
$view = $this->viewsExecutableFactory->get($view);
to resolve the error for me. Though I'm still not sure why it's happening. After running some tests in xdebug, I do see that subsequent attempts to add an additional view embed field via paragraph type appears to try to load the view with the Human readable label instead of the view's machine name. e.g. $view_name = "My View" instead of "my_view"
This is a bit complicated, but the problem seems to be somewhere in ViewsReferenceTrait::itemCurrentValues() in the viewsreference module. This seems to be where we sometimes get the view label in lieu of the machine name, around here:
$input_values = NestedArray::getValue($form_input_values, $value_parents, $input_value_exists);
Great, I'm going to close this, since the feature can be satisfied by the permission, which is a better practice anyway.
Thanks for reaching out. The short answer is there isn't a way to distinguish bots from humans. At least the ones this module intends to block. The only real way is to pick a facet "limit" that seems higher than most real humans would likely use. While looking at log data on this topic, I've seen requests using 20+ facet filters. I'm certain that was a bot stuck in a faceted search page, but otherwise, the recent trend we are seeing is these bots do not identify themselves as bots in their user agent string in the http header. They are also using browsers capable of running javascript, so we can't just load these links asynchronously.
Without a lot of options, the approach in this module is what I came up with. Companies are coming out with tools to deal with the issue, Like Cloudflare Labrynth. But, this module caters to websites who don't have a WAF like tool available to them. It is a simple approach, and it's been a huge help to the sites I've installed it on, who were at risk of exceeding their rate limits.
You can modify the responsive message however you like, including creating a version of an access denied page as a basic page, copying that markup, and pasting into the field (be sure to disable aggregation if you do). The default is rather simplistic. The idea was to minimize any processing Drupal needs to do if the site is being overrun by bot traffic. We are taking a similar approach as the Fast404 module. So I'm not sure what a redirect would mean in this context. a generic basic page would still serve as a 200, which would count towards your rate limit on platforms like Acquia.
I'd be open to ideas, and perhaps this could be configurable. But I do want to keep in line with the intention of serving these sorts of bot requests as cheap as possible for site hosts.
I've tagged a release for this, (1.0.1).
Thanks, and my apologies. I had created the module in a project with a different name, and clearly I copied some code, and didn't fully rename it before pushing it here.
Thanks, I may have fat-fingered that version option. With some more testing, it seems there are actually different error handlers for thrown exceptions versus other fatal errors. Calling this_does_not_exist() will be handled by the code referenced in my patch file, but exception handling seems to be managed by Symfony, I poked at it for an hour or so, and don't see any way to get symfony to do the same as what we are trying here yet.
And a 10.4.x version of the patch for those who want to try it out on that version.
Just uploading an example patch to show how straightforward this could be.
I see, ok, I checked the box in the issue to grant you credit. That seems to have updated your profile. Apologies for the misunderstanding!
@vivek, That is done by the MR https://git.drupalcode.org/project/facet_bot_blocker/-/commit/3c5cc15e69...
and shows in the git history.
Thank you, This was on my list of TODOs!
I just made a push to the 1.0.x branch that adds a permission to bypass the block altogether. We can look at separate values per role in the future.
Right now, we use a very early event listener, and try to minimize database reads to deal with the performance issue if these faceted pages being bombarded with requests. So I'll have to think about what can be done here. We could certainly look for the SSESS cookie, allow a bypass of the initial block, and do another proper role/permission check once Drupal is more bootstrapped. I'm definitely open to this feature.
Hello all, while this continues to be an issue, and I'm uncertain on the state of the patches to the facet module to create a "Linkless" version, I've created a small module, called Facet Bot Blocker → which serves as a stop-gap measure. This takes some inspiration from the "Fast 404" module, and allows site administrators to configure a maximum number of facets that may be used at a time. This is based on the presence of a URL parameter that matches the configured limit. So, for example, you can have it block the 4th position facet (you start counting at 0). and any page requests that include an "f[4]=" parameter will be blocked.
This has become a huge problem for my colleagues and me at our agency, and the problem has evolved from where it was a few years ago. In fact, I'm the author of one of the articles slejnej included in his comment. All those things are still valid, but the problem has evolved, and we are seeing more aggressive crawlers hitting sites, and not respecting directives in robots.txt, or rel="nofollow" links. They also seem to be coming from many unique IPs, and do not have user agent strings that clearly identify themselves as bots. They seem to use older versions of some browser and OS, usually Chrome+Windows. It's been on my mind lately, and I just wrote a KM article in our confluence. I'll provide the highlights from that.
What Ultimately addressed the issue (albeit in a temporary way), was placing a Cloudflare block on any URL with facet parameters that exceeded some number. Bascially, a faceted search URL builds an array of filters, right? so "f[0]=", "f[1]=", "f[2]=" and so on. Real humans are less likely to use a lot of these, so we just added a ban to any URL with the string "f[3]=" in it. You might need to do this via the URL encoded version "f%5B2%5D%3D"
After having this up for a few hours, the traffic went from 1.5k requests per minute (those are the ones getting past cloudflare) to ~300 - which is more what I expected for this site. The RPM actually peaked at about 2k, but one of our first moves was to add a Cloudflare bot challenge for all non-US traffic, and that brought it down significantly, but still not enough.
I think there are many other ways to mitigate. But nothing is absolute fix.
Modules:
-
Ban → - Core module, allows you to ban individual IP addresses.
-
Advanced Ban → - Similar to Ban, but allows you to ban IP ranges, and other features.
-
Antibot → - Form spam protection
-
Honeypot → - Form spam protection
-
Captcha → / ReCaptcha → - Form spam protection
-
Also, if you are using Cloudflare, consider Turnstile →
-
-
Crawler Rate Limit → - Rate limit by IP. - Probably won't help though if requests are from many IPs.
-
Fast 404 → - Make rendering 404 pages less resource intensive.
-
Perimeter → - Automatically ban IPs which are probing for vulnerable URLs.
Optimize cache purging: If you use the Purge module, with the core tags queuer, I'd looks at the Queuer configuration. you may be sending Purge requests to your CDN way more often than you need to.
Optimize performance: Do some profiling on your site, and try to find ways to make rendering a page easier. One thing I'm looking at is improving the render cache for an exposed form we use as our search input, which is in the header of every page on the site. I asked over in Drupal answers here.
I agree with OP, this module feels like "throwing spaghetti at the problem". I use it because it's there, but I have no metrics on how many requests it's blocked, and I'm not able to adjust the settings on the fly as everything is hard-coded in settings.php. It would be great to see these things.
And yes, I'm seeing a trend in my own sites of bots getting caught up in endless combinations of facet links. The solution for that for me was to block requests that contained a certain number of facet query parameters. e.g. a faceted search URL might look like this:
/search?f[0]=filter0&f[1]=filter1&f[2]=filter2&f[3]=filter3
If you block the "f[3]" via your WAF rules like in Cloudflare, you can stop a large amount of this traffic, but allow normal human traffic to use some of the faceted search feature. I'm working on a list of mitigation approaches around this problem. But this was the one that addressed the last issue I was having around this.
Other things I'm using as well are the Perimeter module to block probing for vulnerable URL paths. Not that I'm worried about these attempts finding a vulnerability, but I was seeing a lot of traffic like this, which also serves un-cached pages. Also, Fast 404 (to make rendering 404 pages less resource intensive), and Antibot, and Honeypot to block spam form submissions.
So the exclude list, paired with the "Purge Queues" module does seem pretty effective at reducing the number of items in the purge queue. There seem to be a large number of tags that can be added here that likely aren't relevant for most content focused sites. e.g. user: redirect_list, webform_submission_list. A lot of more back-end focused tags, that aren't really relevant to purging CDN caches for tag-based invalidation. I'm just checking in on it every once in a while, and adding more that don't seem relevant for external caches. Although, that's not always a clear call. e.g. is "redirect_list" only for the admin redirect UI page? I am assuming so right now, but if I have any problems around redirects, I might remove that from my config.
I've been running into issues of bots crawling sites that don't seem to respect the rel=no-follow directives on facet links. This has affected nearly all of my projects. This would be one step towards improving the issue. I am researching how this can be more thoroughly addressed however.
Second @chaseontheweb, I upgraded to the latest release thinking it would fix the error, and it did not. I still need to apply the patch in #4
At 20K installs, Workbench is a very common module. It doesn't seem ideal to require a specific configuration to make this work when using the Gin theme.
I'm talking specifically about the block provided by the Menu Block → module. But now that you mention it, the breadcrumb isn't showing correctly on the page I'm looking at either. I assume this have a similar root issue, where these systems, where internally, Drupal doesn't recognize the Preview Link path as the canonical path for the page, so it renders the menu block, and the breadcrumb as if it weren't.
I've been poking at this most of the morning, and didn't really get anywhere on it. Perhaps someone who has a more in-depth knowledge of the routing and menu trail systems can chime in.
Awesome to hear @jdruery, I'll get a release tagged soon, there are a few other items floating around here I'm hoping to also include.
Thank you for your work on this. I'll need to do some testing though. I don't remember if $this->themeFunctions() was doing something in the background that we needed. We obviously didn't need it in a render array, if we weren't returning it. It's been a bit since I've dived deep into this code, and I've had an aspiration to just tear this whole thing down and rebuild it from scratch for a while now.
Works for me. I'll merge it as soon as I get a chance to test it myself.
Hello, I am a colleague of @azinck, and working on the same project with the Brandfolder integration. I was working on routine module upgrades, and looking at the Brandfolder 6.x version. It seems that the 6.x release notes state:
New, decoupled asset browser to enable better UX, better separation of concerns, better performance, better DX, new features, etc.
The new UI looks powerful, but it brings with us a couple of issues. The one in scope of this is that I'm not seeing any significant performance improvement in 6.x Vs. 5.x. In fact, requests to Brandfolder seem to be taking 13-15 seconds each for me (maybe less that 20s Aaron mentions, but my observations were fairly anecdotal, but in any case, both are a bit extreme for a normal fetch/read operation). Also a side note, the "Fetching assets" text is a bit unclear that it's doing anything, it might make it more clear if the ellipses had a little animation or something.
Looking at the module, it seems we are still hitting a lot of these endpoints for every request, and a short TTL cache could go a long way here.
That's exactly what I was trying to do, bit it was giving me an erro:
$ git push --force-with-lease views_ical-3465114 views_ical-3465114/3465114-deprecated-function-creation
Total 0 (delta 0), reused 0 (delta 0)
To git.drupal.org:issue/views_ical-3465114.git
! [remote rejected] views_ical-3465114/3465114-deprecated-function-creation -> views_ical-3465114/3465114-deprecated-function-creation (deny updating a hidden ref)
Also with a plain --force
$ git push --force views_ical-3465114 views_ical-3465114/3465114-deprecated-function-creation
Total 0 (delta 0), reused 0 (delta 0)
To git.drupal.org:issue/views_ical-3465114.git
! [remote rejected] views_ical-3465114/3465114-deprecated-function-creation -> views_ical-3465114/3465114-deprecated-function-creation (deny updating a hidden ref)
error: failed to push some refs to 'git@git.drupal.org:issue/views_ical-3465114.git'
I admit being a negligent maintainer has lead to me being out of practice with the Drupal gitlab.
It wouldn't let me merge the PR with another commit in the upstream, and I couldn't figure out how to get the bot to rebase it's branch, so I just went ahead and manually bumped the core compatibility on 8.x-1.x. to 11.
Not tested per se.
Changing back to needs work, to actually write tests.
Thank you, merged.
Apologies I've been a bit MIA as a module maintainer. Work and life just seem to get in the way. Thanks again on your contribution to this and other tickets.
And as I was investigating this prior to starting to module and core updates, I run those, and now I get even more entity mismatch issues with these:
Taxonomy term
The Publish state field needs to be installed.
The Unpublish state field needs to be installed.
I did run the core database updates, and they finished without any issues, so I'm just a bit confused why these are showing up.
I'm looking at this " Mismatched entity and/or field definitions → " module, but it seems like that just provides a UI for the drush command that this module provides. So again, it's just confusing what site maintainers are supposed to do about these warnings.
Reading my entity warning more carefully:
File type field
It's pointing to the field that the file entity module adds to the managed_file table. Did some more research, and it looks to be related to #3056070: Mismatched entity and/or field definitions updating from 8.6 to 8.7 → . Yes, this is an older site that was originally built in D8 using file_entity. I had a ticket to handle the migration at one point, but looking back, it seems that was closed in error.
bburg → created an issue.
@sonfd
Ultimately, while my steps appeared to work in the dev environment, it didn't in production. I ended up getting Pantheon support to rebuild the solr server on the back-end for me. Updating to the latest release of the Search API Pantheon → module should be the fix now as I understand.
So immediately after posting my last comment, I saw that there was a new 2.3.1 release, and a release note to re-run the update hook → . I did so, and it seems to be working now with the patch.
I have a view, which isn't returning any results, and seems like it is matching the issue described here as I have two relationships (Group, and Group content user). However, I do not get a resolution with the patch. When logged in as a user, on the page with the view, (/admin/group here), I don't get any results, when logged in as an admin, and in the view editor, if I add the user ID as the contextual filter argument, I do get results. The only filter I have is "Group relationship: Group relationship type". This did previously work in Group 2.2, but breaks on upgrading to 2.3.
I also tried dropping an xdebug breakpoint on the lines the patch added, and I don't see stopping on those lines at all. I haven't narrowed down if the view is actually getting results out of the query, or if they are being stripped some other way. That's a task for the morning.
Updated patch to work with 2.0.0
So patch in #3 does not actually fix the issue. I may have inadvertently replaced the original csv I was testing with.
So after some investigation, I think this is all that's really needed is adding this in MigrateSourceUiForm::submitForm(): to pass the updated configuration with a reference to the new file while instantiating the migration instance instead of the passing the config to MigrateBatchExecutable
$migration = $this->pluginManagerMigration->createInstance($migration_id, $options['configuration']);
Patch attached. Full disclosure, this was developed with assistance from ChatGPT.
Steps to fix the index via drush, with a Pantheon focus.
1. Get the list of the servers to get IDs
drush search-api:server-list
2. Run these commands to clear the Search schema schema from the API.
drush sapi-sd SERVER_ID
drush sapi-se SERVER_ID
drush solr-reload SERVER_IDNote: the search_api_pantheon_admin module must be enabled for this command
drush search-api:clear
drush search-api-pantheon:force-cleanup SERVER_ID
Note: Use server ID in step 1
3. Repost schema and re-enable the server
drush search-api-pantheon:postSchema SERVER_ID
drush sapi-ena SERVER_ID
4. Queue all content for re-indexing.
drush search-api:reset-tracker
5. Run the reindex.
drush search-api:index
Credit goes completely to mattdanger →
I was just looking into this issue and found that this is a duplicate to 🐛 Error: Attempt to assign property on array in WebformLibrariesCommands->setComposerLibraries() Active .
I updated the example in my previous comment to use a version starting from composer create-project per the documentation in
https://www.drupal.org/docs/develop/using-composer/manage-dependencies →
instead of my own starter version.
I still get the error as before.
This one has more boilerplate than it probably needs, but I do get the error. Just run site install, enable webform. and run the drush webform-composer-update command.
{
"name": "forumone/drupal-project",
"description": "Project template for Drupal projects with composer.",
"type": "project",
"license": "GPL-2.0-or-later",
"repositories": [
{
"type": "composer",
"url": "https://packages.drupal.org/8"
},
{
"type": "composer",
"url": "https://asset-packagist.org"
}
],
"require": {
"composer/installers": "^1.10",
"cweagans/composer-patches": "^1.7",
"drupal/core-composer-scaffold": "^10",
"drupal/core-recommended": "^10",
"drupal/core-vendor-hardening": "^10",
"drupal/libraries": "^4.0",
"drupal/webform": "^6.2",
"drush/drush": "^13.2",
"joachim-n/composer-manifest": "^1",
"npm-asset/select2": "^4.0",
"oomphinc/composer-installers-extender": "^2.0",
"rvtraveller/qs-composer-installer": ">=1.1",
"vlucas/phpdotenv": "^4.0",
"webmozart/path-util": ">=2.3"
},
"require-dev": {
"dealerdirect/phpcodesniffer-composer-installer": "^1.0",
"drupal/coder": "^8.3",
"mglaman/phpstan-drupal": "^1.1",
"phpspec/prophecy-phpunit": "^2",
"phpstan/extension-installer": "^1.2",
"phpstan/phpstan": "^1.9",
"phpstan/phpstan-deprecation-rules": "^1.0",
"squizlabs/php_codesniffer": "^3.7"
},
"conflict": {
"drupal/drupal": "*"
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"sort-packages": true,
"platform": {
"ext-gd": "1.0.0",
"ext-opcache": "1.0.0",
"ext-pdo": "1.0.0"
},
"allow-plugins": {
"cweagans/composer-patches": true,
"composer/installers": true,
"drupal/core-composer-scaffold": true,
"drupal/core-vendor-hardening": true,
"drupal/console-extend-plugin": true,
"dealerdirect/phpcodesniffer-composer-installer": true,
"joachim-n/composer-manifest": true,
"phpstan/extension-installer": true,
"rvtraveller/qs-composer-installer": true,
"oomphinc/composer-installers-extender": true
}
},
"autoload": {
"classmap": [
"scripts/composer/ScriptHandler.php"
],
"files": [
"load.environment.php"
]
},
"scripts": {
"install-codestandards": [
"PHPCSStandards\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run"
],
"php-stan": [
"./vendor/bin/phpstan --memory-limit=1024M"
],
"phpcs": [
"./vendor/bin/phpcs"
],
"phpcbf": [
"./vendor/bin/phpcbf"
],
"build-assets": [
"composer install --optimize-autoloader --no-dev"
],
"lint": "find web/modules/custom web/themes/custom -name '*.php' -exec php -l {} \\;",
"code-sniff": [
"./vendor/bin/phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/modules/custom",
"./vendor/bin/phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/themes/custom",
"./vendor/bin/phpcs --standard=DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/modules/custom",
"./vendor/bin/phpcs --standard=DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md --ignore=node_modules,bower_components,vendor ./web/themes/custom"
],
"unit-test": "echo 'No unit test step defined.'",
"pre-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"pre-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::checkComposerVersion"
],
"post-install-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles",
"@install-codestandards"
],
"post-update-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
],
"post-create-project-cmd": [
"DrupalProject\\composer\\ScriptHandler::createRequiredFiles"
]
},
"extra": {
"composer-exit-on-patch-failure": true,
"patches-file": "composer.patches.json",
"patchLevel": {
"drupal/core": "-p2"
},
"drupal-scaffold": {
"file-mapping": {
"[web-root]/CHANGELOG.txt": false,
"[web-root]/COPYRIGHT.txt": false,
"[web-root]/INSTALL.mysql.txt": false,
"[web-root]/INSTALL.pgsql.txt": false,
"[web-root]/INSTALL.sqlite.txt": false,
"[web-root]/INSTALL.txt": false,
"[web-root]/LICENSE.txt": false,
"[web-root]/MAINTAINERS.txt": false,
"[web-root]/README.md": false,
"[web-root]/UPDATE.txt": false,
"[web-root]/USAGE.txt": false
},
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library",
"type:bower-asset",
"type:npm-asset"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
]
},
"installer-types": [
"bower-asset",
"npm-asset"
]
}
}