Nice! I think that's all of them
We'll also need to update the info file for D11 core compatibility
You'll want to be targeting the 2.0.x branch for D10+
If you tried 2.0.x, how did it behave?
There isn't a permission regarding that, but perhaps your markup is different between anon & auth, check that whatever class(es) you're targeting are accurate for anon.
This appears to have been an issue at a different level. The ticket referenced in #4 describes it.
Packagist has made an update to create dists for Drupal's Gitlab (as I understand it).
I don't want to close the ticket for you, but the problem has been resolved for me and likely any others that may have experienced this.
https://www.drupal.org/project/project_composer/issues/3464712 β¨ Regression: RC releases have empty dist information Needs work
That cleared up all of our issues as well.
Found this thanks to alex. I'm here to share the results of some testing based on the conversation.
I added the domain to my composer.json:
"gitlab-domains": "git.drupalcode.org"
composer show -a drupal/rat --no-cache
still does not show a dist, and in the case of my work computer behind a proxy, it also only shows the -dev version (it is type: library, not drupal-module which I think is related to the issue).
I then added a personal access token to let it try and get the unstable/dev version, and that failed with 403.
That asterisk is problematic I believe.
Look at other projects to compare, they do not show like that second entry in the versions:
line
* 1.0.0,
jwjoshuawalker β created an issue.
@Gomez_in_the_South
It is in the 3.0.0 release. There are no steps required to upgrade from the 2.x to 3.x series, it is safe to switch.
Awesome!
Clever. Have you experienced the behavior if the temp store expires? It has been a long time since I used it, and even then I was using a patch to customize the expiration time.
Is the default temp store time long enough for very large files? We were dealing with 500gb files when this module was first developed.
Nice work with the various patches! I hope TUS is serving your needs well.
This is a major code undertaking and is unlikely to happen.
There are other modules that provide some of the mentioned features like adding files from a Remote URL; though not for the Uppy widget.
This one needs to be re-rolled. There's only been minor other changes, but sadly this no longer applies.
I may tackle it later. Note that it is now targeting 3.0.x branch for D10.
Applied on new branch 3.0.x
Sorry, for some reason I did not see this issue until now.
Merged and release 2.1 created.
Fixed in: #3443531
Odd that the merge in Gitlab didn't do it.
Nice catch btw. The automated code upgrader did some weird things.
The MR is against the wrong branch (8.x-1.x instead of 2.0.x); and I think we want to keep $this->t
but add using StringTranslationTrait.
Feel free to open if this is still relevant.
Merged - minus minor changes for the jquery once() compatibility.
jwjoshuawalker β made their first commit to this issueβs fork.
Handled in π Remove jquery.once dependency. Active
Pushed!
Just want to chime in and say we were experiencing this issue as well.
Very serious problem! Users would go through all the steps of a very lengthy test and at the end it wouldn't record the score in the opigno_learning_path_achievements
table as 'completed', but left it stuck in a 'pending' state.
(It also caused it to fail setting the completed date in that table).
The proposed patch is simple, has anyone from Opigno seen this thread?
I just want to say, thank you @kanchamk - for all these patches across all the opigno sub modules with broken .install upgrades.
You went around and patched each one and deserve a medal for saving so much headache :D
jwjoshuawalker β created an issue.
Does anyone here know how to add the patch / pull request in Drupal's GitLab so that the merge can be done here?
I am away from the office for a while and there's a few issues for this project with patches posted, it is much easier to use that new system.
Great addition. No doubt there are some options we should expose in the field widget settings form for easier access.
Here is the list of options for anyone stumbling upon this:
https://uppy.io/docs/dashboard/#options
jwjoshuawalker β made their first commit to this issueβs fork.
I'm seeing the core/once transition mentioned as a D10 upgrade step.
When was that library introduced / what Drupal version did it become available? I'm having trouble finding that information.
If it is ^D10, then we may have to create a new major version number of the module.
I understand, thank you for the explanation.
Why not add the UI widget to settingsForm() ?
I might add that later if there isn't an important reason.
Thanks for the contribution!
I'm confused on the wording. It looks like this patch is adding field validation to ensure that it obeys max upload size settings, is that correct?
While reading, I initially interpreted this as "let's just ignore max upload settings"; and I don't want to take that control away from site administrators.