Has been fixed, and will appear in 2.0.3. Thank you to everyone who helped on this: @thomas kaisuka, @chrisolof, @ananya.k!
Hand merged into 2.0.3
heatherwoz → credited aklump → .
liberatr → credited aklump → .
@chrisolof This is a great idea and I'm in support of doing this.
Thank you @vaish and @amanbtr72 for solving this issue.
Thank you @chaitanyadessai for your contribution on this!
I really like the views_export module. When I wrote users_export I wanted to make it turnkey and not rely on other modules nor on much, if any, configuration. At that time views was not in core. Now that views is in core maybe relying on views and views modules is not a big deal. Thinking it through, I think your suggestion could be the better approach to take, rather than the serializers. If it can remain zero to low config on install for the site builder, then I'm all for it. There has always been the ability to get the user list out of Drupal by configuring modules together such as the views_export module, and users_export was trying to set itself apart as the most simple and quickest solution. I'd like us to keep that distinction and focus as we move forward. At least that's my 2 cents. Otherwise I don't think there's a reason for users_export to exist as views_export can simply be used on it's own. We have to make users_export easy or it's just duplication, IMHO.
Given the change in direction, would you like to proceed with that solution? My weekend is not looking as open as I was hoping.
BTW, thank you for all your energy you're putting into this. You've been doing a lot of work and I've noticed that. Thanks!
Aaron
Please see comment https://www.drupal.org/project/users_export/issues/3220028#comment-15405947 🐛 loft_data_grids library is deprecated Active regarding other export formats.
Hi @astonvictor I'm the author of https://github.com/aklump/loft_data_grids as well. It was written a long time ago and now there are much better solutions. At one point I was thinking that https://symfony.com/doc/current/components/serializer.html would be the way to go moving forward, such as now as you're working on the D10 release.
I may have time this weekend to take a look at converting the other export formats to this. Does that sound good to you, if I work on that, or have you already begun something along? Do you have any other thoughts to add about the other formats?
Aaron
Hello Aston, thank you for your interest. That plan sounds good. I will add you as co-maintainer and close this issue now. Sorry for the delay I was out for the holidays.
Aaron
You bet. Thank you for the quick turn-around. Take care.
I think that should do it. I've tested on a vanilla Drupal with only that custom module code that I zipped and uploaded. It will set up the scenario that exposes the issue.
Thank you for keeping the module going!
I've created a merge request that is working in my installation. Feel free to decline it if you think it's edge case. This may be a helpful reference: https://www.drupal.org/node/1727592 → .
BTW, great work on this module. Several of my clients have asked for this functionality and I was able to install it for them so they had what they wanted. Nice job!
Aaron
Copy that. I'm working on a patch. It's probably that some custom code created #attributes as an object, not an array. But I haven't tracked it that far yet. I'll see if I can nail it down better.
@pmagunia I haven't worked with CKE5, but from a quick search of the codebase I didn't see that variable in there anywhere, so I agree with your conclusion.