tim-diels → made their first commit to this issue’s fork.
tim-diels → made their first commit to this issue’s fork.
I've created a MR for the patch in #32. It includes everything from #26 to #32. The comments before are a different approach or different error? It seems the htmlspecialchars is solved in another issue #3255637: Deprecate NULL values in Html::escape(), ::decodeEntities(), and FormattableMarkup::placeholderFormat() to make it easier to upgrade to PHP 8 → as described in #19, but i'm not sure as I didn't test this.
So best is to re-analyse what the issue is and clear this out in a comment so any further actions can be decided on that one comment.
tim-diels → changed the visibility of the branch 11.x to hidden.
tim-diels → changed the visibility of the branch 3301782-php8-deprecated-function to hidden.
tim-diels → made their first commit to this issue’s fork.
tim-diels → made their first commit to this issue’s fork.
I see in 2.x that there is a new approach taken. Additional flexibility is built in to that controller allowing developers to override it and customize the behavior/display in new ways. See https://www.drupal.org/project/section_library/issues/3505852#comment-15 ✨ Use view mode in 'import from library' and links template suggestion Active ... for an example.
This 2.x branch makes this adjustment obsolete. We wont go further with the approach from this issue. Therefor I'll close this issue. Thanks for the great work!
tim-diels → made their first commit to this issue’s fork.
I've tested this and was able to reproduce the error and the fix seems correct to me.
We should set the minimal D10 version to 10.2. For the rest it looks ok. I'll commit this.
Just adding the patch in a MR. Didn't test yet.
tim-diels → made their first commit to this issue’s fork.
But do we need this if the related issues are solved? I don't have the time to investigate the best way forward. But if anyone knows, please let us know.
Created a MR and going to hide all patch files.
Thanks for the reply, going to close this as it is not due to this module itself.
Hi weseze, thank you for creating this feature request!
Could you elaborate a bit more on the first paragraph? I'm not completely follow what you're doing.
On the second hand patches are generally not used anymore. The best way forward is to create a MR containing the patch and remove the patch. This will allow any maintainer to have a better overview of code change, rebases can be done easily and code checks and test can be run automatically.
Hi Ian, thanks for the issue. I’m one of the co maintainers of this module. I’ve had little time but I’m going to look into the issues. I’ll give an update to this issue. If any of the open issues can use a review, please be free to do so and mark it as reviewed. I’ll try to look at it as soon as possible
Hi Finex, thanks for the report. But can you explain in steps how to reproduce this error? So that someone can reproduce it and start working on a solution?
I would like to point you to the Drupal.org documentation about creating issues:
https://www.drupal.org/community/contributor-guide/reference-information... →
And more specifically:
https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... →
Can you please update the issue?
No problem. Thank you also for the work on this. I'll be working on a release this weeks.
It would be also good to see if the packs can be (visible) grouped so the end user knows the icons are in different packs?
MR provided.
I'll provide a Mr for this
tim-diels → created an issue.
Thanks for the issue report and the extra effort by providing good insights on what could be wrong. I'm not sure what the default situation could be. I'm not sure the edit for should be specified. As you suggest the module could try to look for the edit form if specified, otherwise fall back to the default? Is that maybe how Drupal core does it also?
Why changing status to needs work? Can you explain what the next steps would be, if any?
To me, this is still RTBC
This will need an update using the latest template.
tim-diels → created an issue.
IT would help if you provide more information in the issue summary so others don't have to look into the code to understand what the issue is about. The ticket template is there for a reason.
The MR is for 2.x
As there's a patch, this can be set to needs review.
Hi Plach, I created the issue before the biggest blocking issue was resolved.
I do understand that you are hesitated to allow other persons as maintainer. Force there is no big must at this moment to maintain extra modules. I just wanted to have the new release done. As that’s done, for me it’s ok to cancel this request.
I am already happy that the module exists and that there was a reaction.
I will do some contributions if needed, but no need to make me a maintainer if there’s follow up.
For me this can be closed.
Since the other issue is fixed. This can be reviewed also.
MR added.
Here we go, MR created.
Wrong button, oops
tim-diels → changed the visibility of the branch 3282292-support-for-entity to active.
tim-diels → changed the visibility of the branch 3282292-support-for-entity to hidden.
I'll add it to a MR
The patch from entity browser and this one together works for me. Thanks!
@arnaud-brugnon this doesn't work for me. The patch in #4 did work tho.
This needs to be in a MR.
@er.garg.karan , you opened a MR for 4.0.x but the branch is still 3.0.x. Can you please update that? I'm not able to do it for you...
I added patch from #8 to a MR. Hiding all patch files as not relevant anymore.
Credits go to zhaoyao@ciandt.com and Oscaner forthe work done.
Maybe we need to define next steps in how to proceed in this?
Hiding patch from #9 as the patch provided there is exactly the same as #8 except that the paths to the files are changed and incorrect. So lets add #8 as a MR to correctly follow up and let the pipelines run to see if there is still work to be done.
This will need more information to see what is wrong.
Can you verify if the correct packages repositories are included to fetch the modules from Drupal?
I added the patch as MR and manual testing seems to solve the issue and does not break on other parts. But maybe I'm not testing all cases.
Putting this to needs review for others to review aswel.
Added screenshot of error for direct idea of issue
I did not find a quick solution to have the messages in an own container. So for now I added them to the global container as we're going to use Toastify to print the messages in a better way. If someone wants to improve this, feel free to do so.
I added some console logs to make it clear what is happening. Also did a check on the address if not empty and then don't call the geolocation provider.
This can however be improved and show a message in the website itself. I was looking at https://www.drupal.org/node/2930536but → that will print the message on top of the webpage and is not ideally. The message should appear inside the fieldset? I would suggest on adding a message container in the fieldset and attach the messages there. But other ideas are welcome on how to tackle this.
I provided some code changes already to ✨ No visual message when geolocate returns nothing Active that handles this. Lets focus on the work done there to continue.
tim-diels → created an issue.
Added support for the module. Not sure if it needed to be in a submodule or just in the base. So didn't add any tests yet. But shouldn't be that difficult to add. But first would like a review of a maintainer on whether it needs to be a submodule or not.
tim-diels → created an issue.
tim-diels → created an issue.
tim-diels → created an issue.
tim-diels → created an issue.
tim-diels → created an issue.
This is required to get the module working.
tim-diels → created an issue.
As per last 2 comments, this will need some adjustments.
Hey Berdir, thanks for shiming in. I didn't feel like putting this on a status that is different then before without any reason given. So thats why I want back to the previous status as I didn't test it myself. But fair enough for me if you want to put it on RTBC. I did see indeed that the pipelines are failing on more MRs and are indeed not related.
@divyansh.gupta no need to double verify as this has been verified before. And setting something to RTBC when the pipelines fail is not correct. So setting this back to NW.
As there is a patch, this can be set on needs review.
Added the patch as MR and tested it out and it seems to work for what is described. The pipelines are failing, but after looking at them it seems unrelated to this change.
Let's create a MR for this so the pipelines are triggered and we can see if there is work needs to be done.