This looks great, and thanks for the hard work everyone, but this sort of change really should have some tests to make sure we're not breaking things for existing sites, and that the new settings work correctly etc. so setting back to needs work.
I had this issue on a Drupal 7 site that was sort of close to going over the limit, the following code sorted it out:
db_add_index('queue', 'temp', ['item_id']);
db_drop_primary_key('queue');
db_change_field('queue', 'item_id', 'item_id', array(
'type' => 'serial',
'size' => 'big',
'unsigned' => TRUE,
'not null' => TRUE,
'description' => 'Primary Key: Unique item ID.',
), [
'primary key' => ['item_id'],
]);
db_drop_index('queue', 'temp');
I imagine this sort of approach could be adapted very easily for Drupal 11.
@chetananemade thanks for the updated patch. We should try to get this into a MR instead of using patches.
Yeah, field templates do not apply to the exports that VDE is doing, this as as-designed.
Use the hooks instead as suggested in #5
I would strongly suspect that as explained in #2 there is something else not quite working with your Drupal install.
Given the time since this issue was opened, I'm going to close it down.
Hmmm...I don't think it's correct that we ever allow specifying a view mode, so yeah, we should clean this up and not allow selecting one.
I wonder if you clone another display that uses an entity view mode, does VDE secretly store that and not allow you to remove it?
Hmm...is this an issue with our string, or the export that Drush produces?
Yeah, so at the moment there's no interface for us to check to see if this method is there, see: 🐛 Views style plugins with the `attachTo` method should implement an interface Needs work
But until then we can probably do a simple method_exists check and that'll stop the WSOD you were seeing.
Hmm...I suppose that it's nice to make this opt-in and won't break any existing export flows, but is there a reason to make this optional? Wouldn't you always want VDE to reflect the sorting options that the user has used?
Either way, this could do with some tests.
Closing this as a duplicate of 🐛 JSON is invalid when multiple batches are needed Active
As per 🐛 Batch XML export with multiple root nodes Closed: duplicate this is an issue for XML too.
I don't think we must have solved this issue long ago, so closing this one out.
Let's open a new MR with PHP CS enabled.
Actually, let's continue here!
Let's continue this in 📌 Phpcs Drupal coding standard issue Active .
Let's continue in 📌 Fix the issues reported by phpcs Needs review rather than having 2 issues.
Thanks for the work on this, much appreciated.
Thanks very much!
steven jones → made their first commit to this issue’s fork.
Thanks for this, looks great.
steven jones → made their first commit to this issue’s fork.
I think we should validate that the filename has been set, rather than working around it.
Duplicate of 🐛 Deprecated call to setCellValueByColumnAndRow Active
Yeah, this looks like a solid improvement, thanks!
steven jones → made their first commit to this issue’s fork.
@vasyok I don't think you want the public:// prefix on the filename.
I'm not sure we support migrations, maybe re-open this issue and change it to the views_migration module?
Needs work as per #7
Confirmed, yeah, that's totally broken eh?
I'll admit that it's a bit odd that we're generating absolute URLs for the attachment links. I'm not sure why we need to do that, does anyone in this thread know? They could be relative links and then things should work fine.
Equally, if Drupal doesn't know it's running behind https, you should sort that issue out with your setup, it's not on VDE to sort that out.
I'm going to close this out, since if you have a correctly configured Drupal, VDE generates a link correctly, even if it does generate an absolute link.
Thanks for the bug report, were there specific export types that exhibit this issue, or is it all of the text based ones?
Looks like this is a duplicate of 🐛 Problem with action path for embedded forms Needs work then
Yeah, deffo a duplicate of #2957085: "No route found for the specified format html" with 8.5.1 →
Hmmm...I think this might be a core issue, we'll keep this one around, but it's probably Views' job to not send us a URL with the default contextual filter in.
There's nothing malformed about having a download attribute with no value.
This is a bug with the translation import process, is this in Drupal that you're seeing this error?
Can we change to a Merge Request please, also:
+++ b/src/Plugin/views/display/DataExport.php
@@ -668,7 +668,12 @@ class DataExport extends RestExport {
+ \Drupal::request()->request->add($query_parameters);
It should be fine to simply change to using this version in all cases? I don't think we need to detect anything here.
I can't reproduce this using the latest versions of everything. Feel free to re-open if you can, with detailed steps, and maybe a config export of the view that's causing the problems.
Yeah, as @ryanrobinson_wlu says the issue here is that you need to manually select an output format, but the module doesn't enforce that, and it should. Let's add that and then this error will go away.
Thanks for the patch, but I don't think we'll be adding this to the main module.
This seems more like a feature request to me.
I've done this today, with the latest versions of Drupal and modules, and don't see this issue, feel free to re-open with more details if you're still seeing this issue.
I've done this today, with the latest versions of Drupal and modules, and don't see this issue, feel free to re-open with more details if you're still seeing this issue.
@Aurel60 hmm...I'm not keen that Views Data Export skips access checks by default, but the views UI does give you the option to do this for specific views if you really need to do so, but it would be better to get the access checks brought in by your Views Custom Table module sorted instead. Likewise @jahanaras with Drupal commerce, either allow access to the data you need, or don't :)
@uberengineer I think that's another issue, but I can't see why it would be anything other than a boolean, but yeah, the strict type checking does seem a bit over the top.
As @gold has said, you can already do this with the CSV encoding, but not json encoding. So, closing this issue out.
This needs converting to a merge request, and a test I reckon.
I think that's a bug in your theme rather than this module then.
Looks like this issue is a duplicate of the core issues then, closing out.
Not sure why that would matter, or why it would matter to Views Data Export specifically, anyway, closing this one out.
Closing as the consensus seems to be that that isn't an issue any more.
Thanks @ghost of drupal past!
I've applied your patch to a MR, and we'll merge that in if all existing tests pass.
steven jones → made their first commit to this issue’s fork.
Hmmm...sounds like something really weird is going on there!
Feel free to re-open including an export of your view that's causing the issue, so that we can take a look to see if there's anything obviously going wrong there.
I'm not sure we have a TXT export in Views Data Export 8.x, do we?
I'm not sure this is a bug. An empty file is correct if there's no data to export.
Is this an issue with the differences in rendering when doing batched/non-batched exports maybe?
Please re-open if that's the case.
Please re-open if this is still an issue, but try to provide an simple config export of a view that has this problem, if you can, thanks!
Hmmm...they shouldn't get shifted.
Feel free to re-open with more details to reproduce this issue, ideally an export of the config of your view that's causing the issue you are seeing.
We should probably switch to using a renderInIsolation call instead of the renderRoot
Seems like this is the same as the error in 🐛 Export using date tokens is not working - cache metadata error Closed: cannot reproduce ?
If you can give the steps for reproducing, then we can take a look.
I can't reproduce this using the latest versions of Drupal and Views data export. I'm assuming that this was a bug in views or something and has since been fixed.
That's very strange, I'd assume it's something special about your environment specifically, maybe something like the max-allowed-packet being too small?
Looks like your filesystem wasn't writeable, and Drupal was unable to create a directory early on in the process of building up the export.
Have a look at the Media => File System page in the Admin UI and see if there are any errors on that page.
Marking as a duplicate of 🐛 Batch mode does not allow other modules to alter query Needs review
This works fine for me in the latest version of Drupal and Views Data Export.
Feel free to add more steps for reproduction to this ticket and re-open if you can reproduce it.
There's an option in the views UI to specify the export filename, and if you use that, then you can set the filename that's used.
I can't reproduce this with the latest version of Drupal and Views Data Export, the combined filter was working just fine for me.
Please re-open with more information if you can reproduce it, and provide an export of your configured view, if possible.
Reckon this is a duplicate of #3160900: Entire view is deleted on module uninstallation after depending display is deleted →
Wow, yeah, this seems like quite a big oversight. This should be relatively easy to add a test for too.
Confirmed, this is broken with batched exports. This is a prime candidate for adding some tests.
Sorry you never got a response to your issue, I'm trying to be better in the future!
Going to mark this is cannot reproduce, as the module has been working fine for others for years at this point.
Feel free to comment with further information.
Yeah...this is the tricky thing with Drush: you need to tell it the URL of your site if you want it to know it.
You have already found one way, you can use Drush aliases, or set environment variables in dev/staging/live etc.
But yeah, this is a Drush issue, not a VDE one, and not really a bug either.
You'd have the same issue for example if you execute cron without passing in the URL, or if you were to request a login link etc.
Sorry, the 6.x versions are not supported.
As @fjgarlin says in #5 this is kind of by-design, but yeah, is a bit weird.
I'm going to close as a 'works as designed' but if anyone has a decent suggestion of what to do differently here, feel free to suggest it.
I'd humbly suggest that this is a job for a field formatter: to remove the extra characters that you don't want. If however, that it's specifically that the Excel exported that is mangling the data, then maybe comment here and move the issue over to the XLS Serialization issue queue.
There's a 'strip HTML' option for the CSV stuff, that might help you out?
I can't seem to reproduce this issue with the latest versions of VDE, sorry! Please post more information if you have it.
I wonder if we need to set the authentication method at all, and if it's worth investigating removing that configuration option from data export, or at least moving it so that people don't change it often, and are then warned if they do.
I think we should be able to produce a test fairly easily that confirms if this is a genuine issue or not and then we can look to resolve it.
This looks like it _might_ still be an issue as 🐛 Problem with action path for embedded forms Needs work remains unfixed. We'd need to write a test to confirm I think, and I'm still not sure of the exact conditions that trigger this bug. I'm going to mark as closed, but feel free to post updated information and we can re-open!
I've just tried this out with the latest code, and this works fine, if a field is marked as 'exclude from display' it is not rendered, and if not, then it's rendered. Note that this does not effect use in tokens in other fields, it'll still get rendered there, that's the whole point of that functionality.
Changing to a MR based on the patch in #9
Committed the change to the readme.
steven jones → made their first commit to this issue’s fork.
I've updated the project page with information relevant for the Drupal 8.x version rather than the 7.x version.
I've added this information to the project page now.
Thanks very much for the nudge. I got out a Drupal 11 compatible release, and will be working on getting some of the RTBC tickets into the module and released soon too.
We got Drupal 10 support, so this is basically done, going to close this one out.
At the moment, we don't need to rethink things from the ground up, we need to maintain what we have, so closing this one out (for now)
Sorry that you didn't get a response, I hope you worked it out.
Closing as this issue is very old and mostly about EOL'd stuff.
I don't think you can currently do this, no, but there's no reason why we can't make this a feature request.
So we only allow picking a single export format per display because we're using the URL to 'negotiate' the response format, whereas the REST export base is using other means to determine that.
I should think you'd be able to provide a KML style plugin to export to that particular format, and then provide another class that (almost) trivially extends it to do the zipping for the KMZ format.
See https://www.drupal.org/docs/develop/creating-modules/building-a-views-di... → for documentation on how to do this.
How odd, do you maybe have some custom theming on the view that's not outputting the icons properly? Or are you sure that you're looking at the display that the export view is attached.
No, not at the moment this isn't possible beyond using standard views filters, and then 'selecting rows' that way.
I.e. you could add a role filter to a view of users, and export all the users with particular roles, but there's no way to pick the 3rd, 6th and 11th row of a view and get a CSV of those using this module, sorry!
Yeah, this looks like a duplicate of that issue, which is much closer to resolution so closing this one out.
This was requested in 💬 CSV - how to remove header row? Closed: duplicate and as #11 says this looks like a great patch and improvement, we should get this in!