alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
I'll be updating this to work with Commerce 3.x this week.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → made their first commit to this issue’s fork.
alexandersluiter → created an issue.
@Marcus_Johansson My apologies, I was on vacation for a while as well. I just pinged you on Slack, let's chat there on how I can help move things forward.
I just created an issue 📌 Drupal Standards and Production Ready Active on the main module to start a refactor in a new 2.x branch. I think that's the best route. You've built up quite an awesome set of modules so far, I think getting it to Drupal best practices would really help for the module family's longevity and stability. My company is diving head first into generative AI integration, we are willing to help build this ecosystem out.
@Marcus_Johansson What timezone are you in? Maybe a conversation off the issue queue would be a good start to a 2.x path?
alexandersluiter → created an issue.
I have pushed the "simple" change in order to get image styles functioning as is. Take a look and let me know what you think.
@Marcus_Johansson Upon further inspection of the codebase, it looks like the plugin system is put together abnormally compared to a regular Drupal plugin system. It seems that the declaration class in the Annotation namespace is being used as the base class for all plugins. The plugins themselves should not extend the \Drupal\Component\Annotation\Plugin class as it is supposed to be used for declaration only. Ideally, all plugins should be built from the \Drupal\Component\Plugin\PluginBase class. This way all plugins can access their definitions, runtime configuration, and more.
I believe the best route forward is to do a simple implementation for image styles for the time being, and do a larger refactor into the more traditional Drupal plugin system that extends the \Drupal\Component\Plugin\PluginBase class. I would be willing to help with this if you'd like.
I was going to push what I have last night but it didn't feel elegant. I'll push soon and ping you when I do.
Lastly, I love what you've built here, thank you for building a solid foundation on Drupal for these game changing technologies.
@Marcus_Johansson Some of our product images can be upwards of 50MB+ in their original uploaded form. We don't deliver that to the DOM for normal visitors, we resize based many factors. After rough calculations, we would have to send at least 3TB across the wire and spend a lot of CPU time base64 encoding large images. Cutting them down on our side first makes sense in our use case.
That being said, after reviewing the code the changes would have to be made in the OpenAiBase class where images are derived and encoded. The way you have it currently written, there is no access to the field definition or interpolator configuration inside the getVisionImages() method. Take a look at my MR and let me know what you think. I believe passing either the interpolator configuration or field definition should be enough to derive the chosen image style to encode. Unfortunately, this would require a change in almost every OpenAi plugin. There may be a cleaner way to handle this using the base class only and allow plugins to declare their image requirements once.
This is correct. I will post a merge request or patch soon to handle all of it.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
Thank you! I've committed this to 2.x.
How does one keep the previous behavior via config overrides? Which configuration data needs to be overwritten?
alexandersluiter → made their first commit to this issue’s fork.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
This just happened to me as well. I believe #8 to be a correct assumption. Adding + parent::defaultSettings() to public static function defaultSettings() fixes the issue as well, though the patch above may be the better route since the default image settings are irrelevant to the Base64 formatter.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
alexandersluiter → created an issue.
This issue can be closed. I have failed to handle this with an MR via Composer. Steps to handle this "manually":
- Place the empty shim module in my own repository under the custom modules directory. This will be removed in my own applications next minor release.
- Remove Commerce Google Tag Manager completely via composer.
- Uninstall Commerce Google Tag Manager.
- Upgrade Google Tag Manager to 2.x via Composer
- Profit.
alexandersluiter → created an issue.
Will do. I'm trying to figure out which module is the offending one yet. Will create new issue here if it turns out to be this one.
I am having issues with this with the group_type condition provided by the Group module. Even with this MR, it is still coming back as a condition to check. Diving into it, more to come.
alexandersluiter → created an issue.
Merge Request 2 is ready to merge.
New features:
- Update available check in UI
- Drush commands for importing and deleting
- Configurable fields for Google id and path storage.
- Configurable URL to retrieve Google Taxonomy.
- Module works out of the box upon installation. Fields are installed automatically.
- Drupal 10 compatible
- 100% up to Drupal and DrupalPractice coding standards
- Use of BatchBuilder class instead of manual batch creation
alexandersluiter → created an issue.
alexandersluiter → created an issue.