Fixed the phpcs failure but this definitely needs work on tests, don't have time for that at the moment.
Oh I didn't realise, I should have checked the home page, thanks for that, I've rebased.
darvanen → changed the visibility of the branch 2958658-permission-reorder-terms to active.
darvanen → changed the visibility of the branch 2958658-permission-reorder-terms to hidden.
Closing as a duplicate of 🐛 Taxonomy Term List page is broken when users don't have permission to edit/create terms Active
That approach works for me 😊
This is very interesting @mparker17, I see there hasn't been much discussion and I wonder if you feel like that is blocking progress?
We use this module with a very large dataset, I'd be happy to try out any protoypes.
fubarhouse → credited darvanen → .
I would love pass2 to inherit the attributes of pass1 with an override capacity… but I suspect that will break a great many sites.
I’m not sure getting the pattern right in this instance is worth the pain we’re likely to cause for a small heap of intermediate site builders.
Hi @sirclickalot,
This module is for enabling tokens in filtered text fields. It does not have any effect on views rewriting, they do not use the filters you find at /admin/config/content/formats.
I had a quick look and didn't see any modules which do affect that part of views but there are plenty which are more adjacent than this one.
I'm sorry, you'll need to find something more specific to your needs, or perhaps even write it.
Ah, got it.
Doing this to the test form does demonstrate the problem. wasn't sure if I should push the change though
Index: core/modules/system/tests/modules/form_test/src/Form/JavascriptStatesForm.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/core/modules/system/tests/modules/form_test/src/Form/JavascriptStatesForm.php b/core/modules/system/tests/modules/form_test/src/Form/JavascriptStatesForm.php
--- a/core/modules/system/tests/modules/form_test/src/Form/JavascriptStatesForm.php (revision 62764410c50313e7fd0068cde2f5f78e8c846d23)
+++ b/core/modules/system/tests/modules/form_test/src/Form/JavascriptStatesForm.php (date 1740698679180)
@@ -773,7 +773,9 @@
];
// Ajax trigger.
$form['ajax_reload'] = [
- '#type' => 'checkbox',
+ '#type' => 'select',
+ '#options' => [0 => 0, 1 => 1],
+ '#default_value' => 0,
'#title' => 'Check me to reload elements with the states_ajax_test_wrapper',
'#ajax' => [
'callback' => '::buildAjax',
@@ -818,6 +820,7 @@
'#states' => [
'enabled' => [
':input[name="checkbox_trigger"]' => ['checked' => TRUE],
+ ':input[name="ajax_reload"]' => ['value' => 1],
],
],
];
Yes that means there is a dependent/dependee pair that share both ajax and states relationships. It comes into play (at least for us) when ajax is used to update large sections of form that can have portions which use state to manage visibility based on the ajax trigger. And the form in question *did* work in 10.2
I was unable to get the test form to repeat the behaviour I'm seeing - possibly because it uses a checkbox as the ajax trigger rather than a select element, however I did discover the cause of our issue. The trigger events needed to be namespaced so that other events weren't stripped off along with them.
I have pushed a very small amendment to that effect.
Commenting out line 624 of the adjusted states.js stops the ajax event from being removed.
I applied the changes in MR9300 to a site running 10.4.3 and now an element that has both ajax and states dependees only runs its ajax handler once. I'm going to keep digging but if that sparks any ideas please let me know.
darvanen → created an issue.
An alternative (for maintainers only) if you don't want to mark an issue as fixed because it was solved elsewhere - is to use the username search box in the crediting section of the solved issue to credit users from the first issue.
Marking it fixed is easier though :)
The button label doesn't get overridden *there*, but it does get overridden in \Drupal\webform\Element\WebformActions::processWebformActions
// Apply custom label.
$has_custom_label = !empty($element[$button_name]['#webform_actions_button_custom']);
if (!empty($element['#' . $settings_name . '__label']) && !$has_custom_label) {
if (isset($element[$button_name]['#type']) && ($element[$button_name]['#type'] === 'link')) {
$element[$button_name]['#title'] = $element['#' . $settings_name . '__label'];
}
else {
$element[$button_name]['#value'] = $element['#' . $settings_name . '__label'];
}
}
@zoeblair is this an actual problem with the module? If so can you provide some steps to reproduce?
I think this goes beyond the remit of the module, sorry @ressa.
There are just so many different ways one might want to alter what happens when elements are clicked.
I really think you're getting into business-logic territory - i.e. that specific use-case would not be wanted by more than a tiny percentage of user of this module. I recommend you do that as part of your own theme where desired.
Feel free to continue the discussion despite the status change, or you can ping me on Slack, the #contribute channel is probably suitable.
Looking pretty good @bobi-mel, please update the schema and settings keys and labels to be more like the updated form.
Additional commits look good to me and the proof is in the green tests. However standard review procedures prevent me from marking this RTBC. Thanks for the update @keszthelyi.
Good start @vinayakmk47, thanks. Unfortunately the Drupal docs system doesn't support markup though.
This module has been 11.x compatible for a while, this automated task is no longer needed.
No activity for years and Drupal 7 is now out of support. Marking out of date.
No activity for years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 6 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
As there has been no reply for a few months I think we can close this. Please feel free to reopen if you have further related questions.
Thanks for the information @jvogt, I'm sure it will help others in this situation.
As this ticket is for 7.x and Drupal 7 is now out of support I am closing this ticket as outdated.
No activity for years and Drupal 7 is now out of support. Marking out of date.
No activity for years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No activity for many years and Drupal 7 is now out of support. Marking out of date.
No action for many years and Drupal 7 is now out of support. Marking out of date.
No action for many years and Drupal 7 is now out of support. Marking out of date.
No action for many years and Drupal 7 is now out of support. Marking out of date.
As there has been no answer for nearly 3 months I am closing this as I believe I have answered your query.
Please feel free to re-open if that is not the case :)
7.x is now out of support.
Later versions will most likely not be able to use this patch.
#8 sounds about right, thanks @victonator
I'm going to postpone this ticket on that unless someone comes back with evidence otherwise. Not closing it in case there's follow-up to do once that ticket is resolved.
Awesome, thanks @danrod, here's a followup for ESLint: 📌 ESLint - enable pipeline and fix errors Active
darvanen → created an issue.
Thanks @vinayakmk47 and @jvbrian, some issues:
Enabled modules:
Webform (v6.2 or later)
Advanced Email Validation (v2.0.2 or later)
Integration Steps
Install and Enable Required Modules
Ensure the necessary modules are installed and enabled. You can use Drush to enable them:
drush en webform advanced_email_validation -y
drush cr
Are the enabled modules a prerequisite or an instruction? Pick one.
In general I'm in favour of the structured formatting in #7, but:
- Use code formatting where appropriate (drush commands for instance)
- Don't use unordered lists to provide a label and a value like in 3.1 (6.1 is better)
Finally, please do as the ticket asks and put this documentation on the documentation page that is waiting for this content. As this is specifically about setting up webform it should probably be a sub-page of the stub mentioned in the IS, which will need filling out too.
This ticket is for providing credit when a substantial amount of work has been done, such as @vinayakmk47 writing out all the steps (thank you, credit applied), all discussions of the content of the documentation should happen in the documentation system please.
Well, the yml is now compatible, but the tests are all broken. I had a go at repairing the dependency scanning job using https://docs.gitlab.com/ee/user/application_security/dependency_scanning... but I think I would need maintainer access to do it fully.
The audit fails because there's an old dependency on rollup:2.57.0 which is brought in by test-runner among other things:
a11y_autocomplete % yarn why rollup -R
└─ @drupal/autocomplete@workspace:.
├─ @web/test-runner@npm:0.13.22 (via npm:^0.13.22)
│ └─ @web/dev-server@npm:0.1.24 (via npm:^0.1.24)
│ ├─ @web/dev-server-rollup@npm:0.3.10 (via npm:^0.3.10)
│ │ └─ rollup@npm:2.57.0 (via npm:^2.56.2)
│ └─ rollup@npm:2.57.0 (via npm:*)
└─ rollup@npm:2.60.1 (via npm:^2.60.1)
The tests don't run with the current set up dependencies because pnp is complaining about short circuits. I tried adding the explicit shortCircuit: true return parameters in resolve and load but then it failed on webpack (only). (didn't commit)
This needs someone who understands this setup to give it an overhaul, I'm out of my depth :(
False alarm, package hasn't been published yet. This is now postponed on 🐛 Gitlab yml is out of date Active
darvanen → created an issue.
#3472938: define CSS exports in package.json → is in, which means this can now be reviewed
We might need to prod the maintainers of https://www.drupal.org/project/a11y_autocomplete →
I've had to find another way to support SDCs in my project. I've created an MR to show this functionality though as I still think it is better that an override is absolute rather than relative.
I can no longer do without this because SDCs cannot designate their own manifest path as far as I can tell.
#64: The documentation → as such indicates that tel: should be supported and #11 is correct that PHP's native parse_url is not fit for purpose here. I think we need to either revive the custom approach or do another scan to see if there's a library out there now which supports this requirement.
There is a contrib module that provides this service → , should we close this ticket?
Yes, that is what it is does and what it is for. I think it might help with the #frontend-bundler-initiative I've been working on but it needs more work.
Specifically it needs to respect vite: false on individual assets, and it would be really nice if I could find a way to reset the inputs when those library files are altered (or added/removed).
I have been using https://www.npmjs.com/package/vite-plugin-watch-and-run to run drush cr when twig files are added/removed, I might be able to find something in there.
darvanen → created an issue.
.... so I've come full circle on this.
Not sure it needs a vite plugin, but here's my vite config at the moment that basically does what's in the IS:
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import { globSync } from 'glob'
import yaml from 'js-yaml'
import { readFileSync } from 'fs'
export default defineConfig(({ mode }) => {
const env = mode === 'production' ? '"production"' : '"development"'
return {
build: {
cssCodeSplit: true,
manifest: true,
rollupOptions: {
external: '[Drupal, once]',
input: getInputs()
},
},
css: {
devSourcemap: true,
preprocessorOptions: {
scss: {
api: 'modern',
quietDeps: true,
},
},
},
define: { 'process.env.NODE_ENV': env },
plugins: [react],
scss: {
api: 'modern',
},
}
function getInputs() {
const inputs = []
// Use glob to find all relevant YAML files
const libraryFilePaths = globSync([
'./app/modules/custom/**/*.libraries.yml',
'./app/themes/custom/**/*.libraries.yml',
])
// Iterate through each library file path
for (const filePath of libraryFilePaths) {
try {
// Read the file contents
const fileContents = readFileSync(filePath, 'utf8')
// Parse the YAML contents
const libraryConfigs = yaml.load(fileContents)
// Iterate through each top-level library configuration
for (const [libraryName, libraryConfig] of Object.entries(
libraryConfigs,
)) {
// Check if the library configuration has a 'vite' key
if (libraryConfig.vite) {
// Process CSS sources
if (libraryConfig.css) {
const cssSources = Object.keys(libraryConfig.css)
.filter(key => typeof libraryConfig.css[key] === 'object')
.flatMap(key =>
Object.keys(libraryConfig.css[key])
.filter(
subKey =>
typeof libraryConfig.css[key][subKey] === 'object',
)
.map(subKey => subKey),
)
inputs.push(...cssSources)
}
// Process JS sources
if (libraryConfig.js) {
const jsSources = Object.keys(libraryConfig.js)
.filter(key => typeof libraryConfig.js[key] === 'object')
.map(key => key)
inputs.push(...jsSources)
}
}
}
} catch (error) {
console.error(`Error processing library file ${filePath}:`, error)
}
}
return inputs
}
})
Hi @vinayakmk47, did you check the issue linked in the issue summary? I believe your answer is there.
Alright, that looks a lot better, thank you for the guidance.
I'm so confused, when I open the MR it shows 14 changes, but if I use the dropdown to choose "against latest" which it already has in place, it just shows my changes.
I'll just nuke this one and start from scratch, clearly I've corrupted something.
I should be making the MR against 11.x?
Target was wrong, sorry, should be easy to read now, just a two-line change.
Holy cow, ok I'll have a look, sorry
MR created
darvanen → created an issue.
Have made a few comments on the MR, of particular concern is the removal of some of the logical structures.
The most common procedure I have seen on other modules has been to just have this issue turn on CI then create follow-ups for all of the issues arising from the tests. I suggest we do that here too.
Oh, I wasn't logged in to GitLab - MR created.
I've been thinking about this - and perhaps there is a use-case for this module if it were to protect different routes (or sets of routes) with different credentials? Seems a bit edge-casey though.
Hi @sayan_k_dutta, welcome to the community, I see you're fairly new :)
The purpose of the PHPStan test is to ensure that the code we write is as type-safe as possible.
Can you explain why you made the change you did? Keep in mind that the error is pointing to a potential problem - the goal here is to fix any potential problems, not just to "remove" the error.
Seems I am unable to create an MR. Have pushed my requested change.
darvanen → created an issue.
Thanks @ressa
@bobi-mel yes, I agree with the approach outlined in #30, let's get *something* happening now and then worry about expanding the scope.
darvanen → created an issue.
Sure.
Nice logo! Thanks :)
Please confirm I have done this correctly and I will commit it.
darvanen → made their first commit to this issue’s fork.
So... you're saying we should remove the 'Developer Tools' category? 'Content Editing Experience' is already selected, has been for some time.
Please advise why this change is requested.
No activity for 5 months, closing as "works as designed"
I think we can close this now, Drupal 11 has been out long enough.
Tests are green based on work that I folded into other issues
Backported to 4.2.x