This is a long shot, but since the cache situation acts differently, could it be that some caches persist or are cleared, depending on environment? See ✨ Support rebuild of all caches, including APCu, via the browser Active .
Yes, I see that as well. I am adding details in the Issue Summary, to reproduce it.
And you're correct @avpaderno, it is unpredictable, and for example did not happen to me just now, after leaving a comment in 🐛 Seeing "1 new" on /user/#/track after own issue comment Closed: duplicate . "1 new" is not shown, it's odd ...
Thanks @greggles, you're right -- I did a search for "new" I believe to check for an existing issue, but missed that one.
+1 for this improvement, thanks for creating it @dcam! I am not a coder, so cannot comment on the code, or choice of method, but support the initiative :)
Thanks everyone for working on fixing this. I see high levels of dogged persistence by several contributors to replicate the bug, and will just mention that here is an even more demanding one to verify, with a lot more steps. But wouldn't it be great to fix it?
✨ Support rebuild of all caches, including APCu, via the browser Active
At least getting a verification whether there truly is a problem, would be awesome.
Adding the ReservedPathChecker service proposal in the Issue Summary.
Thanks @eric.vvf, a ReservedPathChecker service is a great idea! And like you suggest, it could be useful elsewhere, but adding it first here, and then moving it later to a central position makes sense.
I tried the new patch, but I am allowed to create a Page with the path /modules, which should be blocked.
Fantastic to see the two Drupal core HTMX Change Records today!
@fathershawn commented April 2025 in #3520723-35: Add HTMX dependency to core → :
I would recommend that not this child issue, but 📌 Process attachments (CSS/JS) for HTMX responses and add drupal asset libraries Active carry the change record. My reason is that although this adds the library, without the ability to bring in dependent CSS/JS it's not really usable yet.
So perhaps the great news that HTMX is usable in Drupal core could be shared by someone with a blog on Planet Drupal → ?
Maybe add the great news on the project page https://www.drupal.org/project/htmx → as well?
Great catch @berdir, and suggesting that it should be fixed here. I updated the MR.
Fantastic news, thanks for building it @protitude!
And you're probably right, that adding it as a Honeypot submodule might not be the right method, since after taking a closer look at Honeypot, it doesn't have any submodules .... Also, since your module does not rely on Honeypot, perhaps creating it as a stand-alone module on drupal.org under https://www.drupal.org/project/facets_honeypot → makes most sense?
By having it as an official project on drupal.org it will get much more exposure, and more users, and it will surely become quite popular, since it solves a problem, which is only growing bigger every day, for more and more web sites. So feel free to add it here if you agree, it would be a fantastic addition! On the other hand, if you prefer to not create a new standalone project, a Honeypot submodule would also work fine.
PS: I actually tried and failed to update to Facets 3, to transition from links to checkboxes (see 📌 Update project page with new branch details Active ). I think many others will also stay on Facets 2 with Facets as links, until those blocking AJAX and Block placement issues are fixed. Perhaps Facets Honeypot could eventually also offer links as traps for bots? But we can always revisit that later :)
Thanks @anirudhsingh19, that looks great!
About placing the "Masquerade as" at the top, I was wrongly assuming that fields would be placed above the button. But I now tried creating a few fields, and they are placed below the bottom, so it's fine as it is. Thanks for creating a solution which solves the task, have a nice day.
Thanks for adding that plugin @chriswinger, it's an impressive list!
Strike that. Adding row like that adds too much padding elsewhere, resulting in an ugly horizontal scrollbar. Maybe I need to just use media query?
Add link to the great article https://www.john-brandenburg.com/blog/building-firewall-your-drupal-appl....
Great that you got it fixed! But it's strange ... I just did a fresh install, and it's right there ... maybe yours got deleted by mistake?
It looks like the structure might have changed, but basically clicking the "Edit" button on /admin/config/people/accounts/fields should get you there:
Home > Administration > Configuration > People > Account settings
Thanks @weseze! Adding as reference, to connect the issues. Still, it would be great to hear from the maintainer @adamps as well.
Thanks @anirudhsingh19, that looks great!
Though, the .masquerade-as-user-link:hover CSS class doesn't seem to be in effect ... Perhaps the change could be that the white text turns slightly light-grey, to acknowledge the hovering?
Also, what do you think about my suggestion about placing the button at the top? Would that be difficult?
Also, the link gets inserted at the bottom of the page. Perhaps placing the link at the top of the page, under "Status messages" or at the very top of "Main page content" could be worth considering?
As an extra thing I didn't mention, the "Unmasquerade" is also a bit hidden, as a regular link in the menu. I wonder if that could be shown as a button as well, like "Masquerade"? If it's too difficult, it's not super important.
Thanks!
Add tip in the intro, about the different strategies and methods to change Drupal's mark up.
Link to www.drupal.org/docs/develop/theming-drupal/twig-in-drupal/debugging-twig... instead of sharing old method.
It is a common SEO method, so please remove it.
See also https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →
Perfect @grevil, I am eternally grateful to you guys at DROWL.de, for all the projects you maintain!
There are so many, that I suggested a new feature to help find the most important ones in
✨
Add metadata for projects under Projects maintained
Active
:
If a user maintains a lot of projects (like +100) and you only want to check out some of them, it would be great to be able to immediately skim for those most installed and Drupal 10 ready.
Wouldn't that be a great little feature and quite useful? Have a great day!
Thanks for maintaining this great module @pookmish!
Maybe review the contribution records (https://new.drupal.org/contribution-record/10201196) for this issue (and some of the other recent ones), since it looks like some of the users -- including yourself -- helped solve those issues, but didn't get credited ... Thanks.
https://www.drupal.org/project/soundcloudfield → works well for SoundCloud: You can simply enter a URL to a song, and it immediately shows the embedded media player to the user, with the song ...
So since SoundCloud is covered by the SoundCloud Field module, perhaps the Audio Embed Field module could consider adding support for BandCamp, since that's lacking in modern Drupal?
I think it would be nice to alert potential Facets 2 to 3 updaters that some features are not yet ready, to prevent them from wasting time needlessly ... I spent quite some time re-building a solution, only to hit dead ends.
Priority for the Drupal core issue 🐛 Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page Needs work required to fix 💬 Works with AJAX enabled? Active was just elevated to Major, so hopefully it can be fixed soonish ...
I just discovered these hidden fields ... You may need to use this module to get support for placing "Facets exposed filters" somewhere else than above the form in a View (the standard position), and prefer to have each filter in an individual block, to support https://www.drupal.org/project/collapsiblock → . This method works well in Facets 2.
In Facets 3 you need this module to place "Facets exposed filters" somewhere else than above the form in a View. But if you have 20 "Facets exposed filters" in individual blocks. Then, for each filter, there will be 19 hidden filters ... This can generate a lot of unused HTML, making the page quite heavy, since there will be 400 filter instances, of which 95% will be hidden.
Hiding filters seems to me a fragile construction ... wouldn't it be a more robust solution to simply not output the filters instead by default, and not use the hide method at all?
Thanks for working on this! In Facets 3, placing AJAX-supported "Facets exposed filters" anywhere else than above the form in a View (the standard position) is not supported, since you have to use https://www.drupal.org/project/configurable_views_filter_block/ → to place filters for example in the sidebar regions -- but 💬 Works with AJAX enabled? Active is waiting on this Drupal core issue ...
This could be holding back many users from upgrading to the new and improved Facets 3, so should the Priority for this issue be raised to "Major", to help give it a nudge?
Thanks for clarifying that @strykaizer. It looks like currently, if you need AJAX support, only the default placement of facet filters above the View form is supported, since the https://www.drupal.org/project/configurable_views_filter_block → does not yet support AJAX ( 💬 Works with AJAX enabled? Active ).
Thanks for fixing this! I just tried to update to Facets 3, and couldn't quite get there ... Perhaps the https://project.pages.drupalcode.org/facets/exposed_filters/ page could get a caveat under "Should I upgrade?" along these lines, to warn the users?
Most things work in Facets 3, but some features are not possible, like placing Facets somewhere else than above the form in Views (the standard) and have AJAX support, since you need to use https://www.drupal.org/project/configurable_views_filter_block/ → which does not yet support AJAX ( 💬 Works with AJAX enabled? Active )
The intro text ("You can update from Facets ...") is not quite right .... I just tried to update Facets 3, and some crucial features are not quite ready, unless you have very few Facets, and you are all right with the default placement above the form. If you want to place a Facet somewhere else, you need to use https://www.drupal.org/project/configurable_views_filter_block/ → but AJAX doesn't work ...
You can update from Facets version 2 to 3 with these steps. Note that most things work, but some features are not possible, like placing Facets somewhere else than above the form in Views (the standard) and have AJAX support, since you need to use https://www.drupal.org/project/configurable_views_filter_block/ → which does not yet support AJAX:
The issues for AJAX support (Configurable Views Filter Block issue, and the needed Drupal core issue):
- 💬 Works with AJAX enabled? Active
- 🐛 Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page Needs work
There are also these tasks, which are in the making for Configurable Views Filter Block:
Yes, this would be great! In Facets 2 there are helpful hooks, like <!-- THEME DEBUG --><!-- THEME HOOK: 'facets_item_list__checkbox__coast' -->. On the other hand, it might be a job for better Exposed Filters? ¯\_(ツ)_/¯
If you have more than one Filter block, they are all named the same, like "Exposed form: map-map" ... and you can't tell which filters are inside. This is extra annoying, if you have a lot of filters in individual blocks, since you need to open them all, to check which one it contains.
So I wonder what is blocking this issue from proceeding?
I thought about this recently, and thought that I'd experiment with it at some point, but haven't yet done it. I found https://www.hojtsy.hu/blog/2013-jun-19/drupal-8-multilingual-tidbits-4-h..., but perhaps the best bet is to create a Drupal core issue → (Component: "Language system"), and ask there as well?
Thanks for the update @nick hope, I checked Umami, Starshot, and Commerce "One Click Demos" recently, and they work now.
ressa → changed the visibility of the branch 3489516-implement-drush-12 to hidden.
Thanks @xpete! The new method is to use GitLab MR → 's (it supports test, better reviewing, etc.) so I created a new branch based on your diff.
Thanks for the encouraging comment @jwilson3!
Your description of the situation between Facets 2 and 3 is correct, and a great summary, so I added it in the Issue Summary. I also now see I use Facets 2, in the intro text, where it really should be Facets 3, so great to get that corrected as well.
Thanks for sharing your custom solution for Webform. I am in the middle of upgrading from Facets 2 to 3, and will assess the situation, and if needed try to adapt the code. If I can get it to work, I can add it to a doc page, maybe https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → ?
Thank you very much for making me aware of this issue in ✨ Honeypot Facets 3 submodule? Active @jwilson3. I don't know if pursuing more flexible form config here, or adding support in submodules for individual modules, such as Facets 3, Webform, etc. is the best solution.
But whichever lands first, will probably be used a lot, with the barrage of bots lately ...
And thanks to everyone here who created and updated the MR!
Thanks, I have subscribed to 🐛 Doesn't like !project_page nor !project_issue_queue Active , and will follow it.
Nice digging, thanks for sharing! I am curious about the issue, maybe you can share a link?
I think it would be nice if the suggested steps for updating from Facets 2 to 3 were listed, since I wasn't sure how much updating to version 3 would change, and what a recommended method could be ... Perhaps add something along these lines? (Feel free to re-write)
[...]
Facets 2
Facets 2 works with Drupal Core Search and Search API.
It is kept available for existing projects using Facets 2 + Ajax as there is no upgrade path for this setup. Updating from 2 to 3 without AJAX support is possible.Updating from Facets 2 to 3
You can update from Facets version 2 to 3, and everything stays the same, except for no AJAX support for "Facet blocks". These are the suggested update steps:
- Update to Facets 3
- Rebuild, using View Filters, and not the classic method via the Facet UI
- Delete old Facet UI filters, and their individual blocks
I don't use cPanel, but I saw https://www.noreiko.com/blog/drupal-cpanel-confusion-pain-and-never-endi... on Planet Drupal → the other day. Maybe there are some tips?
For shared hosting, there's also https://www.drupal.org/docs/getting-started/system-requirements/relocate... → .
About Drupal on cPanel, I saw https://www.noreiko.com/blog/drupal-cpanel-confusion-pain-and-never-endi... on Planet Drupal → the other day. Maybe there are some tips?
For shared hosting, there's also https://www.drupal.org/docs/getting-started/system-requirements/relocate... → .
That's fantastic -- it's great how versatile the structure of Drupal is, thanks for the update!
Great list! If anyone hear of Search API presentations since 2019, they should feel free to add them :)
You probably want to remove the user name and domain when you paste input on the internet.
Add link to ✨ Support rebuild of all caches, including APCu, via the browser Active under "You moved the module inside your Drupal installation".
Great that you found that cause.
Now I wonder why there was a folder called smtp_Orig ... was it an old, renamed copy ofsmtp?
If you rename or move a module, you probably need to rebuild the caches very thoroughly, see https://www.drupal.org/docs/administering-a-drupal-site/troubleshooting-... →
Of course, the best method would be to never manually change the content of modules/contrib (assuming that's what took place) but let Composer handle that 100%.
See also
✨
Support rebuild of all caches, including APCu, via the browser
Active
which may make changes via Composer (such as composer require) rebuild all required caches automatically. Sadly, the issue seems to have stalled, since it requires a fair bit of steps to replicate ...
... yes, and sharing the composer.json would also be great.
Nice @joelpittet, great to see your improvements on the DDEV tools got included! And impressive how fast the Stylelint issues got sorted out and committed. The Drop is truly always moving :)
Looks great, thanks!
I now see another D7 link (under "Tutorials and screencasts") that perhaps could be updated as well, now we're at it?
Tutorials and screencasts
The Getting started → documentation page and the external material available → for screencasts, etc. might provide a good introduction to the module.
I found two links for the D7 archived page, the last I think :)
-
Hence, the growing number of additional contrib modules → [...]
-
Please also add your module to the list of extension modules → once it's finished, if it is generally useful.
Could be linking here instead: https://www.drupal.org/docs/contributed-modules/search-api/extension-mod... →
Thanks for the positive approach, I very much appreciate it! And I do agree -- it's more of a "nice to have, than a need to have" -- and since it will take some effort to build, more user interest would probably be great, before spending resources on this.
I have attempted to expand the issue Summary, based on your feedback, feel of course free to correct anything. Thanks!
Thanks for the clean up @drunken monkey. It's crazy how many Search API modules there are in the Ecosystem modules for Search API → .
About adding new modules, perhaps module maintainers and users could get a gentle nudge on the project page, to add relevant Search API modules? Also, the link points to an archived (D7) version.
Maybe something like this?
Other available backends and extensions
Please see the list of Search API Ecosystem modules → and curated list of Extension modules → . If you maintain or encounter a great Search API module, feel free to add it.
That's better, thanks! And adding that new section was easy, since you explained it so well in that issue :)
You're welcome @drunken monkey, thank you for maintaining Search API so well, and expanding it with new features. You're doing a stellar job!
I misunderstood then, I thought you suggested to shorten the lists under https://www.drupal.org/docs/develop/development-tools/development-tools-... → ...
But then, let's keep everything as it is? :)
I do agree, it is a long page ... your proposal sounds like a good solution, so feel free to go ahead with that.
I do think an overview page, listing the options has its place. But the links to the dedicated pages for each IDE were easily missed, placed at the end of a list ... I moved them from the list, and placed them on separate lines.
Does that work better, or do you still think it should be replaced with a link?
PS. I also moved EOL projects Drupal Console and Druml to the bottom of the page, since they are not so relevant any more.
Thanks for raising these questions @maxilein. Perhaps creating a dedicated Drupal core issue to answer these questions would get more participation?
This module looks stalled ... I tried https://www.drupal.org/project/audiofield → which also has jPlayer support, and works well ... See 🐛 drush audiofield:download fails with error Active and how to get the library.
I am seeing this as well:
$ drush audiofield:download jplayer
In FileSystem.php line 408:
The specified file '/var/www/html/web/libraries/jplayer/jPlayer-2.9.2' could not be moved to '/tmp/temp_audiofield'.
Failed to run drush audiofield:download jplayer: exit status 1
Also, if I go to /admin/reports/status I get a WSOD and this error, so raising priority:
The website encountered an unexpected error. Try again later.
Drupal\Core\File\Exception\NotRegularDirectoryException: /var/www/html/web/libraries/jplayer/dist/skin/ is not a directory. in Drupal\Core\File\FileSystem->scanDirectory() (line 659 of core/lib/Drupal/Core/File/FileSystem.php).
_audiofield_list_skins() (Line: 20)
audiofield_library_info_build()
call_user_func_array() (Line: 407)
Drupal\Core\Extension\ModuleHandler->invoke() (Line: 419)
Drupal\Core\Asset\LibraryDiscoveryParser->parseLibraryInfo() (Line: 157)
Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension() (Line: 87)
[...]Also here. I tried the two EXIF modules for modern Drupal, but they didn't help ... neither https://www.drupal.org/project/exif_orientation → nor https://www.drupal.org/project/exif_removal → .
My problem was that the thumbnails were shown correctly, but the large displays in PhotoSwipe were rotated. Editing the images, and rotating and saving without EXIF-data fixed it.
Oh yes, I agree -- it's very much possible, it just takes an effort, and I think it should be easier. There's a reason https://www.drupal.org/project/empty_front_page → exists ...
Also, new Drupal users can end up spending a long time understanding how it all works, and try many things and fail ... I think simply allowing to delete /node would be a very nice gesture to those new users, and all those who don't need it -- it would also be the easiest method, I believe. Alternatively, add a "Disable default front page" checkbox.
Though, it would be nice with data on how many think it's great, that setting a "Default front page" is required. I mean, if many, many users are doing their individual little workarounds, why make it mandatory in the first place?
So I don't see this as a feature, but an attempt to make Drupal easier to use, and more user friendly.
This would be a great feature! We could all use more, time to work on Drupal, but if you have time at some point, perhaps it's most likely to get done, if you implement the changes you suggest in comment #107 @geek-merlin?
Add link to Securing file permissions and ownership → and move "Security and audit" section to the top, since it can be considered most important step.
Great that you got it solved! Usually, if I follow the guidelines on https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → after moving files, things normally work.
Feel free to add [Solved] first in the title, like
here →
.
Great suggestion @sonfd! I saw today that a doc page for the Disclosure Menu → module exists, so based on bits and pieces from this page, I have created How to create a responsive menu → .
Feel free to give it a look over, and correct mistakes, clarify where needed, etc. Thanks!
Great idea, I created a new page, about adding a responsive menu:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
I missed that there was already, so I accidentally created this page, which I hope the documentation admins can delete:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
The page looks great, so maybe it could be linked to from the project page?
Can someone with the right permissions please delete this guide? It already existed:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
But it wasn't added to the menu (the bane of my existence), so I missed it.
The frontpage would then be empty. I personally use Blocks, they work well.
Thanks for the feedback @jannakha, I totally understand -- you maintainers need to limit the number of features, to keep maintenance burden reasonable. I have updated the Issue Summary, and added a workaround. Thanks for maintaining Bootstrap5 in Drupal, it's a wonderful theme!
I agree @lendude, a dynamic list would be better. The Issue Summary included this sentence, but at the end of the last item, so a bit hidden, and not totally clear:
If possible scan the web root folder and list the actual paths? Because they may change ...
I have updated the Issue Summary to emphasize that a dynamically built list would be best.
I checked Charts → and Viewer → modules, but they seem to require backend access, to upload CSV-files and define chart settings ...
But I am glad to report, that https://www.drupal.org/project/easychart → fits the bill. As a user, you can easily create "Chart" nodes, using the Highcharts charting tool.
Since this is Drupal, it ought to be a trivial task to set a "View own" permission, but it actually requires a module such as https://www.drupal.org/project/node_view_permissions → (see 📌 Introduce entity permission providers Needs work ).
Adding workaround in Issue Summary:
Until this gets committed in Drupal core, Node view permissions → module enables permissions "View own content" and "View any content" for each content type on permissions page as it was on Drupal 6.
Based on comments in ✨ Access Control with View Own Content / View Own Entity in Core Closed: duplicate , thanks @pameeela and @anybody!
I just remembered the Viewer module by @minnur, which may work?:
Key Features
This module does not import file structure into Drupal entities but rather works with file itself and display data on the fly (cached).
- Import CSV, XLSX and other file types manually or automatically from different locations (FTP, SFTP, HTTP or system path).
- [...]
Great that there are alternatives, though https://archive.today/ seems to be gone and https://ghostarchive.org/ seems somewhat lacking in content ...
I didn't think about the copyright angle ... and that deep link story is both crazy and frightening, at the same time.
A strategy, instead of serving the pages right now, could be to save a copy of all the captures into a private web/sites/default/files/wayback_captures folder. The capture copies should simply sit there and wait, ready for the day archive.org vanishes.
When that happens, the individual site owners can decide whether to resurrect the links, by using their own local copies of the captures, or not.
But I do understand your decision: All seems well now (until a day when archive.org is suddenly gone ...) but most importantly, the resources or even desire, to build such a feature, may not be there. I thought about setting to Postponed (in case someone else wanted to run with it) but in case you prefer a "clean" issue queue, I am closing it :)
This is very much the place to ask such a question :)
Like @jaypan suggests, it's easier for us to help you, if you briefly describe your use case, in everyday language, without trying to use Drupal terms.
Also, to see what's possible, I suggest you read this article, and try these two modules (and please use DDEV):
Adding Workaround https://www.drupal.org/project/empty_front_page → module in the Issue Summary.
Yes, it would be great if 8.x-1.x was made the default branch on GitLab.
Currently, it looks abandoned, with this content on https://git.drupalcode.org/project/empty_front_page:
Initial commit
Patrick Fournier authored 25 Nov 2011Name Last commit Last update README.txt Initial commit 13 years ago empty_front_page.info Initial commit 13 years ago empty_front_page.module Initial commit 13 years ago
I am also sorry, since I can now see that my comment was ambiguous. But great that we are on the same page now :)
And I do agree with you, that Composer info may not belong on this page, and am actually in favour of deleting the Composer section, since:
- This page is about "Using Git to contribute to Drupal > Working with patches > Applying a patch in a feature branch" (like you noted)
- Patching with Composer is already well documented under https://www.drupal.org/docs/develop/using-composer/manage-dependencies#p... →
So maybe we can simply mention this option at the top of the page, with a single sentence something like this, linking to the doc page? I went ahead and deleted the "Composer" section, and updated the intro to this. Would that work?
You can also use the Drupal.org CLI tool to create an issue branch and apply the patch, as well as apply a patch with Composer → .
Thanks for a fast answer, but I am not sure I understand what you mean ... I merely attempted to use a local file, instead of a URL as patch, in the Composer example.
Perhaps you can clarify a bit more which changes I made, that were not to your liking? Thanks!
Thanks @briat, great additions! I think it would make more sense to use the recommended local patch file format. What do you all think about this update?
Adding example of a problem this MR fixes in Issue Summary.
That's a great method, laying out the multitude of options available to solve this challenging task, thanks!
Though I did add a caveat about blocking via .htaccess, so a link to the main doc page https://www.drupal.org/docs/administering-a-drupal-site/security-in-drup... → could be considered instead? I will attempt to keep it up to date, with the latest developments in this ever evolving space:
- [...]
- Using other modules or strategies to block or throttle bots →
- Or considering further approaches based on this blog post from @smustgrave
Oops, I forgot to add a MR back then ... It's now ready for review again :)
PS. I just re-read the great article Building a Firewall in your Drupal Application, which has an awesome list of paths for Perimeter.
Should we consider adding a doc page for Perimeter module under https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → with basic info about the module? Because then the rules from the article could also be shared there ...
Fantastic article by @smustgrave, I somehow missed it on Planet Drupal, so thanks for sharing it! I added a link to it in the Forum post, and added it to the Bad Bots doc page → as well.
I will totally use the article as a blueprint for my future strategies. I do note that @smustgrave seems to believe that switching from facets as links to checkboxes has made a difference ... I am encouraged by that observation.
About the Honeypot approach, you're right that there could be accessibility issues having hidden form fields, but then won't the Honeypot → module have that problem? I created ✨ Honeypot Facets 3 submodule? Active , let's see if it's possible :)