🇺🇸United States @dustinleblanc

Can confirm pegging the version to 2.0.0-alpha5 allows for updates to run on a D10 site for me.

annnnndd as usual, turns out saving the form is giving us issues because we customized the form...ignore that part.

Yeah @pfrenssen I tried that hook and could not really see anything change. I tried running a dump and die inside the hook but could not get that to trigger.

In the end I did end up doing what @owenbush suggested and I just swapped the no op plugin in, because our use case all of the date for the recurring events are always custom, and therefore we never want the reconciliation to run. Now I am just dealing with the fact that the warning still pops up when someone saves any of the event series, and if I run the hook to remove the date customizations, it stops that warning from showing but doesn't allow for the user to actually save the series. That is where I am stuck right now.

I've tried implementing this but nothing seems to be changing. I took at look at EventInstanceCreatorPluginManager and it looks like it calls this:

   $this->alterInfo('eventinstance_creator_info');

Which I think would make the hook hook_eventinstance_creator_info_alter() based on the docs in the default plugin manager docblock:

  /**
   * Sets the alter hook name.
   *
   * @param string $alter_hook
   *   Name of the alter hook; for example, to invoke
   *   hook_mymodule_data_alter() pass in "mymodule_data".
   */
  protected function alterInfo($alter_hook) {

I trieded messing with the hook naming but nothing seems to be changing at all. Do we have any test cases of this working in the wild?

@bmelvin1 I've created a fix for this, you can pull the dev version to check it out, I'll be releasing it soon.

Thanks for your patience greenskin, finally got a chance to test out the changes you've made and confirmed they work, merged.

dustinleblanc → made their first commit to this issue’s fork.

Okay looking into this and it looks like we can make the route vary so it accepts both the bare and .txt versions, working on that now

We'd have to hardcode the routes, not parameterize them, and just ensure both routes load the same controller method. I don't know if route paths can be kind if "regex-d" so they respond to a pattern, but we'd be very specific to these two cases and not answer any other requests. If we can't sort of regex it, we could probably just do two route entries that both point the same controller method. Then the only other side of this is to make sure the upload form works for both extensionless and txt extension files.

We could also perhaps just have a text box and store the value in the state system....hmmm

Okay those references are enough to convince me that we need to support .txt extensions both in the upload and in the display. When I have the space to work on this, I certainly can, or I would accept a merge-request/patch that provides that functionality while still supporting the extensionless version.

I'd definitely want to see those references out in the wild, I just checked on my personal site that is wired up via Stripe and it is still validated with Apple Pay using the module as is. I'd double check some other things like:

I imagine that swapping iDonate to testing with something like Stripe is probably not an available option for you. I just tried to look up iDonate and I don't see their documentation anywhere.

A possible non-destructive change might be to change the controller route to accept both the bare route and the route with a .txt file, and if we can conclusively document that the .txt file is a real Apple thing now, I'd be inclined to go that way, and move forward with stripping out the extension check alltogether in favor of some other file validation techniques.

Hi @bmelvin1!

This does not match my experience with Apple's APIs, did they recently change? The way I am used to setting this up is via Stripe, and the path has never required an extension in the past, and the file I have downloaded from apple has never had an extension. Can you do the following for me:

1. Provide more information about what you are actually seeing. Do you have an explicit error message?
2. Can you find a reference to the requirement for the txt extension anywhere in Apple's documentation that you can link me?
3. Provide details about the process you are taking. For instance does the file download with a .txt, or did it get a .txt after opening it on your computer? Where are you downloading it from? Are you using Stripe, Apple directly, something else?

There is an existing open issue on the repo about file extensions that is sort of the opposite problem of what you are reporting here. It would seem adding verification around properties/details on the file upload would be good in general, but I am seeing incosistent reports of what issues folks are having, and none of them match what I am seeing on a regular old PHP VPS run through Forge.

Let me know what else you can find out, I'd love to be able to reproduce this issue so I can work through fixing if needed.

Hey @radheymkumar, sorry for taking so long to address this. Your patch contained some additional changes that weren't targeted to the issue, which caused me to stumble when first looking at it and then I forgot to come back and resolve it. I've created a merge request with just the issue you've described and made sure to credit you in the commit message. Once that passes CI I'll get it merged, thanks!

dustinleblanc → made their first commit to this issue’s fork.

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.