Een hart voor de Drupal Community

Bij make it fly geloven we sterk in Drupal en Open Source software in het algemeen. We maken dagelijks gebruik van vele open source componenten en de vele Drupal modules die beschikbaar zijn. We dragen actief ons steentje bij aan de community door zelf patches, modules en documentatie te voorzien, daarnaast zijn enkele teamleden ook actief in de Drupal User Group vzw.

Een overzicht van onze bijdragen aan de Drupal community vind je terug op onze Drupal.org pagina. Naast het actief meerwerken aan de Drupal community, zetten we ook andere ontwikkelaars op weg door vragen te beantwoorden op Drupal Answers.

  1. Abstract token usage

    Bram Goffings

    At the moment the token usage can't be found on streamed responses. Any guidance would be helpfull...

    See: https://www.drupal.org/project/ai_provider_openai/issues/3519302#comment...

  2. Abstract token usage support

    Bram Goffings

    I tested this and this doesn't crash anymore with the latest changes. But it also doesn't support streams as it doesn't contain the need info.

    :(

  3. Allow selection of which features to activate

    Sven Decabooter

    I created a MR to add this functionality. For the selectable prefill attributes for form elements I didn't add an option, as this needs to be configured per field widget manually anyway, AFAIK.

    Attached is also a patch version of the MR changes, for Composer based workflows.

  4. Allow selection of which features to activate

    Sven Decabooter

    Problem/Motivation

    To improve flexibility for people using this module, it would be good to allow the option to disable some of the features this module provides (although probably not recommended).

    For example, one could choose to disable the HTML5 validation that is added to all forms, and selectively decide which forms can have HTML5 validation (e.g. Webform module already provides a toggle for this - which is overridden by this module).

    Proposed resolution

    Provide a configuration schema and settings page to select which features to enable (defaults to everything enabled).

    Remaining tasks

    Create a MR with this functionality

    User interface changes

    An extra settings page would be added. No other UI changes needed.

    API changes

    /

    Data model changes

    /

  5. Translation of config actions

    Sven Decabooter

    That looks like a great approach to add translation options to recipes.

    I don't have strong feelings regarding the exact syntax, but personally prefer the options where the parameters are named explicitly (so 2nd or 3rd).

    I'm assuming the 3rd could also be written as

       form:
          '#type': email    
          '#title': !translate { 
            string: 'Feedback form email address', 
            context: 'Third context' 
          }
    

    As it would avoid having everything on 1 line, especially with larger strings you would need to do some horizontal scrolling in your IDE. Come to think of it, then I probably prefer the 2nd version, as it avoids the extra brackets as well..

  6. Similar module - co-maintaining and merging?

    Sven Decabooter

    Thanks for the notice. Since this module has more usage and already has some releases, I think it would make sense to deprecate your module, and provide its extra functionalities in this module. I'd be happy to review merge requests to get extra functionality in.

  7. Usability: let admin choose which email to send

    Sven Decabooter

    Sorry for the delay. Had a bit of time to review this now.

    This does allow the user to select the type of message to send, but only when the action plugin is triggered. When editing a user and clicking the button shown on the form, the old behaviour is still used. So that introduces 2 different behaviours, according to the path you take to trigger it.

    Also, would it be an option to reuse the functionality that now decides in code which mail to send, to provide a default value to the user? Some editorial users might not know which email is the most appropriate, so guiding them in the right direction would be good.

  8. Compatibility with PHP 7

    Sven Decabooter

    The next version of the module will no longer support Drupal 9, so marking this ticket as outdated.

  9. The website encountered an unexpected error. Try again later. TypeError: implode(): Argument #1 ($array) must be of type array, string given in implode() (line 74 of modules/contrib/layout_builder_iframe_modal/src/Form/LayoutBuilderIframeModalSettingsFor

    Sven Decabooter

    The value is expected to always be an array, either through import of the config via /config/install, or for existing sites, by running database updates. Specifically layout_builder_iframe_modal.post_update.php method layout_builder_iframe_modal_post_update_custom_routes_config() should make this an array, if it isn't already.

  10. Integrate with the Key module

    Sven Decabooter

    I have created a merge request that reworks this concept, as suggested by jcnventura. It adds a "credentials_provider" to the plugin configuration, that defaults to "config", which will just keep on storing the client_id and client_secret in the plugin configuration, as is the case currently. If the "Key" module is installed, an optional second credentials provider gets added to the dropdown list, and users are able to optionally select a multivalue key for retrieving the appropriate credentials.

    If the Key module is not installed, nothing changes. If the key module is installed, nothing changes by default, but you can opt-in to use a Key rather than providing the credentials inline.

    Thanks for reviewing this MR and considering whether this could be added to the module.

  11. Offering to maintain Fixed Path Alias

    Randal

    Hi Manuel,

    You're right, I have not yet been involved with issues thus far :) I'll get into that ASAP.

    I was hoping we could open a new branch for D10/11 compatibility (2.0.x), and immediately tackle all those issues. That way, 1.x could remain 'supported' but not maintained for D9, and we can go forward in 2.0.x with modern code (OOP hooks and other newer technologies).

    I'll keep you posted!

Sven Decabooter - Drupal Developer

"Onze teamleden bouwen zelf ook mee aan ons geliefde Drupal, en daar zijn we trots op"

Sven Decabooter
Drupal developer

Betrouwbare technologie, naadloze prestaties. Dat zijn onze Drupal-oplossingen.