IMHO Null and empty string mean two separate things, how can we denote that a value is not set?
To me the alternative would be to not set the config key if the value is null (much like lots of modules would accidentally do when introducing config without a post_update function).
An example of why null is important:
- **Config key not present** = Use the fallback/default from the next level in the hierarchy (override not set → use global, global not set → feature off)
- **Config key = NULL** = Explicitly disabled at this level (stops hierarchy lookup)
- **Config key = 0** = Show on all levels
- **Config key = 1** = Show only on level 0 (top-level)
- **Config key = 2** = Show on levels 0-1
- etc.
The key advantage of this is that I don't need to know how many levels there are and this gives us three distinct states where missing config keys use static defaults.
Thoughts?
Do you have a better open ended design pattern that we could use that does not include NULL?
@erutan Another alternative to adding static patches (because you don't want changes to the merge request to be pulled into your site without consent) is to use gitlab snippets https://git.drupalcode.org/-/snippets/new.
My recommendation for merging this would be to take the following steps:
1. Create a new 3.0.x branch from the default branch (7.x-2.x) https://git.drupalcode.org/project/jquery_jstree/-/branches
2. Set the 3.0.x branch as the default branch.
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →
3. Merge this merge request into 3.0.x
4. Create a new tag 3.0.0-alpha1 https://git.drupalcode.org/project/jquery_jstree/-/tags
5. Create a release with these release notes:
<h2>jQuery jsTree 3.0.0-alpha1</h2>
<p>This is a complete rewrite of the jQuery jsTree module for Drupal 9+. This release is <strong>not compatible</strong> with the Drupal 7 version (7.x-2.x branch).</p>
<h3>Major Changes</h3>
<ul>
<li><strong>Drupal 9+ Compatibility</strong>: Rewritten for Drupal 9, 10, and 11</li>
<li><strong>Bundled Library</strong>: jsTree 3.3.17 is now bundled with the module (no Libraries API required)</li>
<li><strong>Simplified Architecture</strong>: Library-only module - provides jsTree JavaScript/CSS without custom form elements</li>
<li><strong>Multiple Library Options</strong>: Local (bundled) and CDN versions, both with light and dark themes</li>
<li><strong>Modern Drupal Standards</strong>: Uses <code>.libraries.yml instead of hook_library()
Breaking Changes from 7.x-2.x
- No Libraries API dependency: The module now bundles jsTree directly
- No custom form element: This alpha release does not include the
#type => 'jstree'form element from the D7 version. Developers should attach the library and initialize jsTree directly in their JavaScript - No
hook_library()orhook_theme(): Library definitions are injquery_jstree.libraries.yml - Minimum Drupal version: Requires Drupal 9.0 or higher
For Developers
Attach the library to your render array and initialize jsTree in your JavaScript:
$build = [
'#markup' => '<div id="my-tree"></div>',
'#attached' => ['library' => ['jquery_jstree/local']],
];
// Then initialize in your JavaScript:
// $('#my-tree').jstree({ /* config */ });
Available Libraries
jquery_jstree/local- Default light theme (recommended)jquery_jstree/local.dark- Dark themejquery_jstree/cdn- CDN version with light themejquery_jstree/cdn.dark- CDN version with dark theme
Installation
Simply enable the module. No configuration required. The jsTree library files are bundled, so no additional downloads are needed.
Known Issues
None at this time. Please report any issues in the project issue queue.
Links
- jsTree Documentation: https://www.jstree.com/
- jsTree Version: 3.3.17
- Project Page: https://www.drupal.org/project/jquery_jstree →
Really we should take over this module namespace https://www.drupal.org/project/jquery_jstree →
And merge this merge request: https://git.drupalcode.org/issue/jquery_jstree-3559080/-/compare/7.x-2.x...
Then update entity_reference_tree to use it.
I've added a proof of concept implementation with jsTree and a Tugboat configuration for easy review.
To test in Tugboat:
1. Log in with username: admin, password: admin
2. Navigate to /admin/config/user-interface/taxonomy-manager-settings to view/change the tree library setting
3. If you change the setting, clear cache (drush cr)
4. Go to /admin/structure/taxonomy/manage/tags/overview to see the taxonomy tree in action
5. Test both jsTree (recommended) and Fancytree (legacy) options
The implementation:
- Adds jsTree as a modern alternative to Fancytree
- Maintains full backward compatibility
- Allows switching between libraries via admin settings
- Includes CDN fallbacks for both libraries
- taxonomy_manager_merge module works with both libraries via custom events
trackleft2 → made their first commit to this issue’s fork.
Thanks for taking this on, please add a note to remove the entire function once the minimum supported version of Drupal for the module is 11.2 or greater and link to the change record as well. https://www.drupal.org/node/3496788 →
2.0.0 released https://www.drupal.org/project/term_merge/releases/2.0.0 →
trackleft2 → created an issue. See original summary → .
See the failing test only changes run https://git.drupalcode.org/project/date_ap_style/-/jobs/7280802
See the passing test with the one change on 2.1.x https://git.drupalcode.org/project/date_ap_style/-/jobs/7280801
3.0.x is unaffected by this bug because it does not have the problematic trait that was removed. The trait is hijacking the viewElements method in 2.1.x resulting in no output.
trackleft2 → changed the visibility of the branch 3557715-dates-no-longer to hidden.
Hi there, thank you for creating this issue. I've added a merge request that resolves the TypeError issues caused by strict type declarations.
**Changes made:**
1. **Type casting for timestamps**: Added explicit `(int)` casts in `ApStyleDateFieldFormatter` and `ApStyleDateRangeFieldFormatter` when passing timestamp values to `formatTimestamp()`, since these values come from the database as strings but the method requires integers.
2. **Type casting for boolean options**: Added explicit `(bool)` casts in `ApSelectFormatterBase` when processing form settings, since checkbox values are stored as 0/1 integers but the formatter methods expect boolean types.
**Testing:**
I've added PHPUnit kernel tests (`FieldFormatterStrictTypesTest`) that cover:
- Timestamp fields with string values
- Datetime fields with integer boolean settings
- Date range fields with string timestamps
- Views integration with integer boolean settings (includes a fixture that reproduces the original TypeError)
All tests fail without the fix and pass with it, confirming the issue is resolved. The changes are minimal, backward-compatible, and don't alter any public APIs.
trackleft2 → made their first commit to this issue’s fork.
trackleft2 → changed the visibility of the branch 2.x to hidden.
trackleft2 → changed the visibility of the branch 3556714-improve-deprecation-pattern to hidden.
trackleft2 → changed the visibility of the branch 3556714-improve-deprecation-pattern-2-1-x to active.
trackleft2 → changed the visibility of the branch 3556714-improve-deprecation-pattern to active.
trackleft2 → changed the visibility of the branch 3556714-improve-deprecation-pattern to hidden.
trackleft2 → changed the visibility of the branch 3556714-improve-deprecation-pattern-2-1-x to hidden.
So far I've only added 1 of the proposed changes because I am looking for guidance from the maintainer on what direction they suggest.
trackleft2 → created an issue.
trackleft2 → made their first commit to this issue’s fork.
Features has a Drupal 11 release., so I've updated the merge request. Adding a static patch for your testing convenience. If the patch works for you, please mark as Reviewed and Tested by the Community.
One other thing to note about the functionality of this module.
This checkbox can effectively add or remove the permission set as well, so we might want to mention what
Choose which form modes you would like to exclude from being processed by the Form Mode Manager.
means exactly.
This has been finished see https://git.drupalcode.org/project/form_mode_manager/-/blob/3.x/.gitlab-...
Added as part of 📌 Automated Drupal 10 compatibility fixes RTBC
trackleft2 → made their first commit to this issue’s fork.
trackleft2 → made their first commit to this issue’s fork.
trackleft2 → created an issue.
trackleft2 → changed the visibility of the branch 2.x to hidden.
Tested on Drupal Core 10.2 and 10.3.
Field formatters were not selectable in the display configuration interface in Drupal Core 10.2 but they were, useable in 10.3
Hey there @anicho01 I've updated the merge requests, however it is difficult to test without a Drupal 11 compatible version of features...