Thanks @Peacog! I've merged and created a new release. This is the first time I've done a MR and release on Drupal.org, let me know if you have any problems pulling the new version.
dustinleblanc → made their first commit to this issue’s fork.
I do a decent amount of work with Laravel as well as Drupal, and I've always enjoyed the developer experience of their environment setup. They have a global function called `env()` that wraps `getenv()` and provides a second argument to provide a default value when no environment variable exists, as in `env('SOMEVARIABLE', 'default_value')`. I see @mfb's warnings that $_SERVER is more reliable. That _does_ seem to be the way most hosts set things, but in the wild, I've always found `getenv()` to be more reliable across the board. It seems to have the most chance of picking up the variables regardless of how they are set. That's anecdotal for sure, but just my two cents. However the feature gets implemented, better env variable support would be great!
I managed to figure out that this issue was created by forgetting to call parent::tearDown() in our test base class, I think we can close this as user error.
Thanks Moshe, I'll see if I can tinker with that to confirm the issue outside of the site in question and then work through the red->green on fixing it.
dustinleblanc → created an issue.
dustinleblanc → created an issue.
@greenSkin I had some time to come back and think about this more, I read some Drupal core issues and did some interweb searching, and came across this: https://drupal.stackexchange.com/questions/87146/upload-text-file-withou...
I think what we really want is just to ensure the file uploaded is a text file, and maybe confirm it's size isn't enormous, and then we can just remove the extension check altogether because by default, this file will have no extension. I also don't recall if I included a permission in the module, but we probably want to have an explicit permission for accessing this form that is only given to trusted users.
I think I'll look at adding a validator plugin that does what we want (only text, file not huge) and then add that. What do you think?
Nevermind, the API docs refer to this: https://www.drupal.org/node/3363700 →
That looks like exactly what you have here
@greenSkin looking ahead for deprecations does sound like a good idea. Are you able to send me the API doc that specifies this new method? I just saw this deprecation notice so I see that is what you're referring to. I just can't locate the documentation how this is supposed to work. The file that gets downloaded from stripe has no extension by default, so however we configure this, I think that is the use care we should support.
Sorry for the late reply on this, I must have missed the notification in my inbox.
@greenSkin I tried to replicate this issue this weekend with a file named `apple-developer-merchantid-domain-association` and I had no issues uploading said file with no extension. Are you able to replicate this issue on a site with no additional modules or filesystem config/restrictions? While I do want to ensure the functionality works with the widest range of supported configurations, I want to be able to replicate the initial issue before merging a fix for it.
Thanks for the issue and MR @greenSkin!
The merge request code doesn't raise any red flags to me, so I'll look at testing this out and if I can confirm the original bug and the fix, we'll go ahead and merge it. Might be a good case for the first actual tests for the module too (if only to satisfy my desire to write some). I appreciate this, as soon as I have a a little time to look at this more in depth I will.
Just realized this is a dupe of https://www.drupal.org/project/commerce_registration/issues/3382143 🐛 Null argument exception in cart after deletion of product variation Fixed , I'll see if I can install the dev version and I'll close this issue, sorry for the noise!
dustinleblanc → created an issue.
hestenet → credited dustinleblanc → .
One more just came up during sprint retro: Demo content
We have a pretty solid system for reading YAML files and inserting them into our database during test runs, and I know that there is a general concept for demo content in Drupal, but the process is quite slow and manual to create demo content. I am sure many members of our product/management team would love to be able to scaffold out a bunch of entities and click an export button or something like it to dump all that content to fixture files that we could include with new site spin ups (similar to Umami).
We're going to probably end up re-purposing our test seeder code / fixtures to solve this problem, but worth thinking about a non-dev friendly way to maintain that kind of thing.
The most difficult part of maintaining our distribution (Conversion Engine) is sifting through the configuration changes whenever we export configuration from a development site to add/update a feature of the distribution.
Our workflow is generally:
1. composer install
2. Create symlinks / scaffold Drupal dev site
3. Run the installer
4. Do the hacking, commit the codes, export the config to a specific config directory (we use $REPOROOT/active_config)
5. Run a robo script that first copies the active config directory to the profile config/install directory, and then strips the UUIDs and _core section of the config files. We use a .gitignore file, and some exclusion code in our robo script to exclude files we never want to distribute.
Things work really well, except that step five ends up constantly producing much larger diffs than we actually care about. We get keys in config files that are not even changed, but are in a different position, we get extra config keys that we have no idea why they changed or where they're coming from, hunting through the diff carefully to select just the items we intentionally changed is very doable, but it makes the process tedious and more error prone for devs less familiar with the install profile.
The next most difficult thing is probably the fact that we can't seem to install our distribution on hosting grade hardware, it needs to be done via Drush on a developers system due to the time it takes to install (around 6-7 minutes). We then just push the resulting database to the host. We used to have a problem with memory consumption in this case too, but judicious removal of modules that didn't _need_ to be installed on every new site spin up and some removal of config the distro doesn't need to control helped. For solutions, I can only think of a more configurable installer that does smaller sections of the site installation at a time so the requests are shorter, which I think would avoid timeouts / memory issues.
We also have a bit of difficulty with testing pre-release versions of the profile on client sites and coordinating feature testing on those sites for work in progress, then getting everything together to release, but I don't see how that can be helped at the Drupal level, thats an org issue.
Overall the experience feels good, additional tooling around config management and an installer than can handle bigger module/config loads on lower end hardware would be my two wish list items.
dustinleblanc → made their first commit to this issue’s fork.