When applying this patch, I now get the same issue fixed in
🐛
Mismatched entity and/or field definitions Error when upgrading from 5.2.5 to 6.x
Active
.
Some issue within the update hook maybe?
Yep, I do have "chosen_field" module enabled and the "Chosen" widget selected for my field. Honestly I expected that to just handle it since it was an explicit widget choice!
I do think that improving this so it doesn't throw console errors for an empty selector would be a good idea!
Ah! That field is indeed empty (and was with my 4.x usage too).
I see that the default configuration (config/install/chosen.settings.yml) is meant to be the value 'select:visible'.
Setting that value back to the module's default, everything now works for me!
I'm curious why my empty selector ever worked in 4.x, so I assume something changed in that during the 5.x release.
Regardless, I think this can be closed unless anyone sees anything actionable for future updaters!
Created an MR based on the above, against 2.0.x.
Patch file created for folks who want that for Composer patches too.
Y'know, I think was wrong about the "new methodology". There are quite a few related issues to this, I thought this was solved in a different way!
Looks like this is the issue to follow going forward on this. [#3326104]
Lemme re-roll that patch again with the README.
Also, tagging this to 2.x since that's the recommended version now.
Attaching a new static patch file for folks that need it, similar to #11.
While MR!16 does apply cleanly (thanks for the MR!), this is also a duplicate of a subset of an issue in
🐛
The module is not compatible with Drupal 10.3.0
Needs review
.
Closing!
Confirming that tests are failing due to 📌 Support Drupal 10.3 SDC deprecation RTBC
Ran into a similar situation as above, with a site that was previously using the old patches. Need to upgrade that site to the "new" metatags/Search API methodology eventually, but not today haha.
I re-rolled this patch for Metatag 2.0.2 support, since #28 doesn't apply anymore.
I did not include the README edits, since this approach shouldn't be supported anymore anyhow.
Our team started encountering this after updating to 10.3.1 (and 10.3.2).
It seems fairly sporadic on when it happens so it's been tough to narrow down what combination of conditions happens to trigger this.
Reverting #3400485 seems to have fixed this for us. Hoping someone smarter than I can figure out what's happening here!
In any case, here's a patch reverting #3400485.
Opened a Merge Request for this against 2.x branch.
This is just a re-roll of patch #25 since folks seemed to be in favor of that approach.
+1 on this. Ran into this exact same issue on a handful of projects, and this fixed it for me!
Heck yeah, this is getting closer!
I think this just about solves it. The fieldset now appears so I can see the field settings that were previously hidden.
However, the "Add Another" button below that fieldset (<input data-drupal-selector="edit-field-storage-subform-settings-actions-add" type="submit" ...) still isn't appearing. I imagine it's just another tweak to the #states since they were the same underlying issue. 🐛
No dice, applying that change didn't seem to have any affect.
Once thing I do notice is on line 236 in that file, $sources always seems to be empty for me.
This makes the following if-check never pass, so that "clone" element doesn't exist, which then makes the fieldset + "add another" input also not display (since the #states mentioned in previous post)
https://git.drupalcode.org/project/custom_field/-/blame/3.0.0-alpha2/src...
I haven't dove into what that `getExistingCustomFieldStorageOptions` method actually does yet.
Screenshot attached with a few things:
- This one isn't "barebones Drupal", but exact same thing on fresh install too
- Applied the
#parentssuggestion from above - Applied the patch from above
- New field, only configured a single "Label" type to start
- Printing out
$has_data,$storage,$sources, and$elementfrom line 238 in file mentioned above.
Hopefully that helps with a bit of additional context!
Thanks for all the quick responses on stuff!
Prefacing all of this, I did just see the note in the 3.0.0-alpha1 release regarding the "Field settings". Seems like this is known wonkiness, so maybe this is an issue more about "how to interact with the field settings form in 10.2 right now" since it is buggy with this module.
https://www.drupal.org/project/custom_field/issues/3400256 🐛 Fatal error with Drupal 10.2.x Fixed
Field storage is working but due to combined storage/field settings in same form, the field will have to be reopened to manage field settings as there is currently not a method of keeping the 2 in sync in same form via ajax. That will have to be addressed in a later release.
--
Alrighty, I applied the patch you provided, but didn't fix! So I spent a bit of time on this today to try and replicate against a few cases, and then see what's actually happening in the UI.
Using completely fresh Drupal 10 installs (standard profile with Composer create-project), I tried both Drupal 10.1 and 10.2. For each, I installed their respective Custom Field versions (latest of each).
- Drupal 10.1.8: Works great, as expected.
- Drupal 10.2.3: Never able to add another "sub-field" of Custom Field.
Zero error logs or console logs on either of these
Diving into #2 above a bit more, here's what I've noticed and I think is the issue I'm seeing:
Both of these elements exist in the field settings form for my Custom Field instance:
<fieldset data-drupal-selector="edit-field-storage-subform-settings-items" ...<input data-drupal-selector="edit-field-storage-subform-settings-actions-add" type="submit" ...
Both of those elements have Drupal #states applied to them (I think in src/Plugin/Field/FieldType/CustomItem.php), only being visible with this condition:
'#states' => [
'visible' => [
'select[data-id="custom-field-storage-clone"]' => ['value' => ''],
]
],
However, that "custom-field-storage-clone" element doesn't exist on this form, so these elements never display!
So, if I simply inspect element in the browser and un-hide it, I'm able to add and modify fields!
So it seems like behind-the-scenes this is still all working correctly, but might simply be an issue of hidden fields when they shouldn't be hidden?
Thanks for the quick response. I'm on Drupal 10.2.3, but was experiencing it with 10.2.2 as well!
Yep, cache clears, cron runs, etc. No dice in fixing it!
Updating the issue summary with that info.
While this MR is a good start, I think there's a deeper issue of the lack of internals being exported.
This makes for extending or replacing elements with your own React components still quite difficult.
As an example: Say I wanted to create my own WebformDate.tsx file for customizing date fields.
While I can register my own React component to handle this, I'd immediately lose access to the internal withDefaultValue, withStates, withWrapper, and withAttributes helpers that are used in this package's version of WebformDate.tsx here https://git.drupalcode.org/project/next_webform/-/blob/1.0.x/src/compone....
It'd be great to enhance customization without losing out on all the other benefits this package is providing!
Aha, I think you're right with that!
That definitely confused me to start, because indeed the types are exported properly and configured in package.json, but just don't appear.
Looks like this commit from
this issue →
is what made the @todo note mentioned in the first post.
Upon further testing, the inclusion of patch #4 actually caused more issues with Drupal 10.1 for me.
Specifically, received the warning:
Warning: Undefined array key "#source_field_name" in/app/web/core/themes/claro/claro.theme on line 1487
Adjusting this patch further to just remove the entire if-check seems to have fixed this for me. I feel like the way this widget works has evolved over time and needs more thought into it outside of just this patch.
Still need more testing. Also setting this against 2.x-dev now.
We ran into two issues using Focal Point. Both this issue and #3088536 🐛 Warning - Theme hook focal_point_media_library_image_widget not found. Needs review
Those two patches conflict though, so here's an additional patch combining the two.
Whoops, had a typo in the installer-name.
New patch + interdiff with 10.
Updating patch #6 for compatibility with composer/installers:^2.2
Previous patch locked that to ~1.0
This also moves this library to the ckeditor.tabletoolstoolbar directory.
Patch + interdiff attached!
With the approach I took, there's nothing to patch in the Enitityqueue module itself as it's just using existing hooks.
That approach would be unique to your project's needs without further abstracting it into a standalone feature, which I don't think my approach is suited for. If something were to implement this with Search API/Entityqueue, I think it'd need to be more robust, such as writing a processor mentioned above!
Here's the code I used though, more-or-less. Looking at it now, this could definitely be improved:
/**
* Implements hook_form_alter().
*/
function YOUR_MODULE_form_alter(&$form, FormStateInterface $form_state, $form_id) {
// Only run when entity queue saved.
if ($form_id === 'entity_subqueue_YOUR_QUEUE_edit_form') {
$form['actions']['submit']['#submit'][] = '_YOUR_MODULE_entityqueue_submit';
}
}
function _YOUR_MODULE_entityqueue_submit($form, FormStateInterface $form_state) {
if ($form_state->hasValue('items')) {
// Get all Node IDs from items in EntityQueue.
$items = $form_state->getValue('items');
$queue_node_ids = [];
foreach ($items as $item) {
if (isset($item['target_id'])) {
$queue_node_ids[$item['target_id']] = $item['_weight'];
}
}
// Get all Node IDs of Nodes to consider.
$all_node_ids = \Drupal::entityQuery('node')
->condition('status', 1)
->accessCheck(TRUE)
->execute();
// Load all Nodes, set weight based on their existence in EntityQueue.
$all_nodes = Node::loadMultiple($all_node_ids);
foreach ($all_nodes as $node) {
$weight = 1000;
if (isset($queue_node_ids[$node->id()])) {
$weight = $queue_node_ids[$node->id()];
}
$node->set('field_weight', $weight);
$node->save();
}
}
}
Unfortunately, since this issue is quite old, I don't have the capacity to pursue approach that more robust processor at this time. Hopefully the above approach I took helps for you though! Maybe one day someone smarter than myself can help write some proper Search API/Entityqueue integration haha. 🤞
Hey all! It has been quite some time since I worked on something that needed this, so I don't have anything specific to share.
However, my last post above is pretty accurate for how I approached it at the time.
- "Weight" field on nodes that need it (probably just stored this as a number). Default value of something large.
- Hook into the entityqueue save and load/update the node "Weights" for all nodes in the queue so they match the "weight" of the queue
- Use that "Weight" field to sort in Views as needed
Likely better approaches now, but the above worked a-okay for me at the time.
drunken monkey above mentioned a different approach too that would likely be more robust.
Good luck!
Y'know, this might be a non-issue.
I uninstalled and re-installed the metatag module with the default configuration, and everything is working a-okay now.
Not totally sure what happened in my installation, but glad that it seems to be working now!
Gonna go ahead and close this.
There are indeed JS files (example in the 1.0.16 release, as there's no 1.x branch)
New patch derived from #65 to support CKEditor 4 now int Contrib.
Divided into two patches: One for Media in Core, the other for CKEditor in Contrib.
#43 is not applying for me for some reason, attaching a new patch that should be identical to #43.
Re-rolled Patch #41 with CKEditor 4 in Contrib
Patch #29 re-rolled to support CKEditor 4 in Contrib.
I did not re-roll the patch's tests. Looks like comment #31 mentions some good points, so maybe this patch isn't the best long-term going forward.
Re-roll of #19 from above against 8.x-2.x-dev.
8.x-2.6 just released a few days ago, so patch was incompatible. Also took care of a couple typos while I was in there.
I agree with #22 that ideally both would be supported in some capacity!