Could you provide more details about this ? Why do you need it in the module?
Unfortunately this how it works by design. The dialog is provided by drupal core. You would need to apply your own styles to dialogs.
I think this is great idea, I added this to the module.
I would like to take over maintainership. This module is being used by one of our clients and needed an upgrade and Drupal 11 support.
We need this one for D11.
Maybe this should be a configurable option for decoupled sites.
Can this be added to the next release of the 2.x version ?
There is not much we can do with the dialogs. The dialog component itself is a Drupal core component. The admin dialog module is only enhancing it by providing ability to add it to different parts of Drupal. If you see issues with it its most likely issue either with the theme or the core.
I will look into this.
This is also an issue in one of the websites that I maintain. For now I am considering adding a separate field that's only visible when in non-published mode that will override URL alias on node save with the moderation state set as published.
I think all module updates should happen locally or dev site first because you would still need to capture configuration changes.
Enabling a module would change core.extension.yml config so if you have CI workflow the next deployment would override config and disable the module.
scott_euser → credited minnur → .
The work is in progress for the AI module integration.
minnur → created an issue.
Unfortunately we don't have much control over dialog's behavior because the module is using dialogs provided by Drupal core.
New caching option added to the settings form.
The Hubspot API module still using legacy PHP SDK https://github.com/HubSpot/hubspot-php so at this time I won't be adding it as dependency. Lets get back to this when the module is up to date and when it will support both legacy API and access token.
@DimaS11 if you have time please review refactored code and see if we still need your patch. From what I see in code at the moment is similar logic to yours. I feel like it works exactly the same way, but I could be wrong.
you should be able to configure it in the module. See https://stackoverflow.com/questions/47281439/http-header-to-forbid-ifram...
Makes sense. I removed recommendation from the status page.
The feature is available for testing in 3.0.x-dev. Get it here https://www.drupal.org/project/http_response_headers/releases →
I feel like administrating HTTP headers is a very important feature and should be on the same level as the main administrative features. If more people ask for this we can revisit this issue.
This is fixed in the latest release.
Closing this. Duplicate of https://www.drupal.org/project/http_response_headers/issues/3316677 🐛 Error 500 - MissingMandatoryParametersException Fixed
Yes I am considering using it. No ETA on it yet.
@datbin latest version now provides a way to get JSON. iI the processor configuration form enable "Store API response as JSON" option.
Document OCR Data entity stores the data.
@datbin latest version now provides a way to get JSON. iI the processor configuration form enable "Store API response as JSON" option.
Document OCR Data entity stores the data.
I am looking into this. I might create a separate rest resource for users to be able to pull the data.
Probably this ticket is outdated. Closing it.
Unfortunately this is not supported and probably won't be unless you could provide a patch.
this is not possible with the current state of the module.
Latest release needs more work.
styles can be overridden in custom themes.
is this still relevant ?