Thx for testing! This is huge :)
I also replaced the iframe-resizer script since this one now requires a license to open iframe resizer https://lemick.github.io/open-iframe-resizer. It has less features but for the basic resize this should be a good replacement.
I alos dropped the throbber when resizing, since the resize seems to be faster then the throbber beeing displayed.
We need to decide where to set the QuerySelector, otherwise this looks pretty feature complete to me :) Great work!
Thx!
Hi @van.dordafog! I cant reproduce this issue. Can you provide more information on how to reproduce this?
Hi @bencurio, sorry for the lack of response on this.
Is this issue still happening? I tried this on a clean install with the current versions of gin, gin_login and gin_everywhere and could not reproduce the behavior from your screenshot.
Can you test and make sure this still happens to you and if so, can you provide more information about your setup?
Hm this looked pretty simple to me. ECA indeed already has an integration into Gin like I explained. For some reason I can't tell anymore, we resetted the $routes passed to the alter hook, which is the root cause of this issue. It will just remove the previously defined routes which breaks the bpmn UI with Gin.
This looks good to me
Hi! I think this might be a misunderstanding. The documentation page does not belong to this module, instead it belongs to a D7 Sandbox Project which seems to have a similar Name: https://www.drupal.org/sandbox/bjpritch/2411053 →
Besides that we should definitely add a documentation page there for this module.
The patch looks ok to me. I would have used #access property on the render array to make this a bit more cleaner to read but thats just by gusto:
$form['layout_settings']['layout_builder_lock_info'] = [
'#markup' => '<p>' . t('Locks can be configured when the section has been added.') . '</p>',
'#weight' => 100,
'#access' => \Drupal::currentUser()->hasPermission('manage lock settings on sections'),
];
Maybe form decorator approach would make this even cleaner https://www.drupal.org/project/form_decorator → but this would be out of scope of this issue for sure.
hydra → made their first commit to this issue’s fork.
Thx! Will make a release with that change.
We should have another look at this when the new settings api lands.
Thx
hydra → made their first commit to this issue’s fork.
Changes are looking reasonable. Can we get the pipeline warning fix?
Feel free to re-open if interested exists in working on this.
Lets get this in :)
I addressed both issues:
- No config dependencies should be getting added when interacting with paragraph blocks to the fake block_content bundles. Instead we should rewrite them to proper dependencies of the underlying paragraph configs.
- Since paragraph blocks are no real blocks, there is no sense in creating content_translation configs for them. With the first fix, those configs won't break config import anymore, but since they are useless I removed them from the form entirely to have better UX.
This won't fix existing, broken config. This will only apply for new config.
The config edit form does this by default. I believe it's for creating the "default value" form. I think the provided fix does the trick here, let's just gently ignore that this can happen...
Thx
hydra → made their first commit to this issue’s fork.
@drupatz It looks like this service is not even used by this service. So I think removing the dependency would be the better move here.
johannes stahl → credited hydra → .
Done
I'd like to postpone that till the new SiteSettings API is implemented. This will require a new solution for that.
This will be covered by the new SiteSettings API
For those cases it is possible to implement the applies method like this:
/**
* {@inheritdoc}
*/
public function applies(): bool {
return
in_array('form_group_type_edit_form_alter', $this->getHooks($this->inner), TRUE)
|| in_array('form_group_type_add_form_alter', $this->getHooks($this->inner), TRUE);
}
This working example shows how to alter the group edit and group add form at the same time.
For me it looks like Jürgen already integrated ECA perfectly with gin, so gin_everywhere maybe should just ignore the ECA Entity Type forms?
Thx!
thx!
This LGTM, but it needs of course to be added on the other side as well :)
Okay I found out that this is actually working in ckeditor, when the image_sizes/core library gets loaded. For some reason this is not happening when embedded via ckeditor, therefore I added it as a dependency when adding media. It might happen that it gets loaded reasonless, but that was the best I could come up with.
As of #3515950
Can you please review this with the current RC5 version - I tested this with stage_file_proxy and it seems that the original issue is not happening anymore. It's actually failing right now and removing the stage_file_proxy check did already solve the problem for me @drupatz
I am not that deep into the magic of the component, but I tested it and it fixed the issue without creating new ones - so I guess its a good fix :) Thx!
Nice, thx for the fix!
hey thx for testing! This has already been merged to 1.x
Rly nice, thx for the idea adoption!
@all who are using this patch already, pls make sure to adjust your code. Harlor updated the issue summary with an up-to-date documentation.
LGTM
Nice! I'll gonna test this as well in a project and give feedback :)
@woldtwerk Any news on this?
Hi @mohammad faqeh thx for your report!
I see that issue but I don't think we should solve this specifically for media. It is theoretically possible to make some of those fields that belong to the advanced section visible with media and even more important I thin, is that this is actually happening on other entity forms as well (like path_alias for instance and possibly more).
I am totally into fixing this, but I would prefer a solution which would fix that issue in general. Haven't had the possibility to think about a solution yet, I am not even sure this is possible, but before excluding media entities I would suggest trying it :)
So thx again for pointing this out and starting the discussion :)
Yeah just did not have the time yesterday. 1.2.3 is out containing the hotfix.