Diving into the code, and I do not understand how this module should work.
* I have enabled features_permissions
* I have a Feature containing the permissions AND the roles
I enable the Feature.
This is what happens: PermissionManager::syncRoleToPermissions is called for each new role in the Feature. Below arrays are all empty.
$added_permissions = array_diff($permissions, $permissions_original)
End result:
* Roles are present
* Permissions are present
* No permissions are added to roles.
So indeed my $0.02 would be that features_permissions tries receives the events in the wrong order in my use case: it tries to add yet-to-be-imported Feature permissions to Feature roles.
My mistake.
I enabled the "Strip out user permissions." and now the role ymls do not have the permissions anymore.
So in my Feature, both the roles and (all) permissions are present. The role ymls do not contain permissions, the permission ymls contain roles. So far, so good. Nevertheless, the permissions are not added when I enable the Feature.
What strikes me: If I enable my Feature and perform a 'drush fim' afterwards, it asks me to import the roles defined in the Feature.
Could it be that for some reason, the roles are not imported yet at the moment the permissions get imported and hence, the permission assignment does not take place?
@justcaldwell: Thanks for your solution. I agree with your suggestion: menu items should have a unique reference for both their route and their location within the menu.
I ended up with using the 'href' as a pseudo-classname:
E.g to target 'Overview' in the 'Add content' sub menu:
.gin--vertical-toolbar .toolbar-menu .toolbar-menu .toolbar-menu li > a[href="/node/add"] {
border: 1px solid red !important;
}
koosvdkolk → created an issue.
Asked @solariel to dive into this:
"From what I see, CKeditor5 is to blame. If you disable Drupal's 'allowed_html', a CKeditor's will be used and it'll break media resize by not allowed data attributes it's using."
koosvdkolk → created an issue.
koosvdkolk → created an issue.
Please forgive me my ignorance, but why is the "Limit allowed HTML tags and correct faulty HTML" filter required for this module in order to work?
Any update on this? For us this is also a blocker.
koosvdkolk → created an issue.
+1
I really hate the auto-detect functionality: It brings more harm than good, especially now that Features should be used for (very) advanced use cases where Drupal's vanilla config management is too limited. Please just let the site admin decide what should go where.
P.S. Before I forget: Did I already give a HUGE THANKS for all the work that went into this great module? Thanks a lot guys!
koosvdkolk → created an issue.
For the time being will go for https://www.drupal.org/project/ckeditor_media_resize → , as mentioned in #17 ✨ Allow editing of Width and Height of embedded images Active by @s_leu.
Thanks!
Got it to work:
/**
* Implements hook_inline_entity_form_entity_form_alter.
*
* @return void
*/
function my_module_inline_entity_form_entity_form_alter(&$entity_form, &$form_state) {
if ($entity_form['#entity_type'] == 'my_entity_type' && $entity_form['#bundle'] == 'my_entity_bundle') {
$element_id = join('_', $entity_form['#parents']); // Obtain unique id for the wrapper
$entity_form['select_a']['widget']['#ajax'] = [
'callback' => 'my_module_form_select_update_ajax_callback',
'event' => 'change',
'wrapper' => $element_id,
];
$entity_form['select_b']['#prefix'] = '<div id="'. $element_id .'">';
$entity_form['select_b']['#suffix'] = '</div>';
}
}
/**
* Ajax callback.
*
* @param array $complete_form
* @param \Drupal\Core\Form\FormStateInterface $form_state
*
* @return array
*/
function my_module_form_select_update_ajax_callback(array &$complete_form, \Drupal\Core\Form\FormStateInterface $form_state) {
$select_a_form_element = $form_state->getTriggeringElement();
$selected_entity_id = (int) $select_a_form_element['#value'];
// Find select b in the form.
$form_part = NestedArray::getValue($complete_form, array_slice($select_a_form_element['#array_parents'], 0, -2));
$select_b_form_element = $form_part['select_b'];
// Get options.
$options = [];
if ($selected_entity_id>=0) {
// Add options here based on the entity id.
}
// Return new select b.
$select_b_form_element['widget']['#options'] = $options;
return $select_b_form_element;
}
koosvdkolk → created an issue.
<?php
if ($option_name !== 'replace' && empty($this->configuration[$option_name])) {
?>
seems to do the trick.
koosvdkolk → created an issue.
This is how my colleague got it to work in D10 (so without Composer):
- You download https://www.drupal.org/project/h5p/releases/2.0.0-alpha3 → and put is somewhere into web/modues manually
- You add "h5p/h5p-core": "1.24.4" "h5p/h5p-editor": "1.24.4" via composer
- You apply patch https://www.drupal.org/files/issues/2023-06-27/drupal.org_files_issues_2... →
- Go to web/modules/.../h5p/src/H5PDrupal/H5PDrupal.php:241 and replace
$cachedAsset = $optimizer->optimize($assets);
with this
$cachedAsset = $optimizer->optimize($assets, []);
- You install h5p and h5peditor modules
- Add an h5p reference field to any content type
- Select h5p editor widget (it will support both editing and uploading this way)
- It'll still throw warnings on uploads and deprecation errors
Thanks for the suggestion!
We considered something similar, but then you should at least ensure that (the correct) stuff is being deleted when the user eventually presses Cancel buttons...
koosvdkolk → created an issue.
koosvdkolk → created an issue.
It would be great indeed if this could be shown on https://www.drupal.org/project/book_blocks →
The blocks currently include:
1. Children: list of child pages for the current page
2. Navigation: Replicates the navigation links found at the bottom of the page.
3. Table of Contents: Book's table of contents that also includes a link to
the top page.
4. Edit: Includes a combination of navigation, table of contents and edit
links.
koosvdkolk → created an issue.
Very much in need of this.
We ended up creating a 'wrapper' node type, having an entity reference to our non-node content entity, and then all kinds of hackish code to mimic standard book behavior for the non-node content entity...
This module is exactly what we need! It would be great if you @droces could re-open the application!
Isn't this a Migrate module use case?
Here you go!
#3 works for me
Found bug in #2, new attempt.
First attempt. Written against 2.0.3
koosvdkolk → created an issue.
koosvdkolk → created an issue.