Closed (fixed)
Project:
Video
Version:
6.x-4.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
3 Aug 2010 at 15:00 UTC
Updated:
27 Jan 2011 at 11:24 UTC
Jump to comment: Most recent file
when do I disable and uninstall the module, all settings are kept in the database
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 872700_video_delete_vars_during_uninstall_v2.patch | 1.02 KB | senpai |
| #4 | 872700_video_delete_vars_during_uninstall.patch | 1.01 KB | senpai |
Comments
Comment #1
hypertext200Comment #2
elektrorl commentedI have the same problem.
Comment #3
elektrorl commentedThat is the problem as it appears in my setup:
I installed several versions of the video module, some are standard, other dev. Since then I have uninstalled and installed the latest version, so the 6.x-4.1-rc6.
The 3 tables video have been deleted from the database.
After reinstall, all options have been kept, but the biggest problem is that it does not accept my API key for Zencoder. I tried "restore default" but it always tells me this message:
You must AGREE terms and conditions.
You must enter an email address.
I still paid Zencoder an account, so it's the latter that I want to use. Tell me if the problem exists in your configurations, and what are the tables set up by the modules other than the three listed above?
Comment #4
senpai commentedHere's a patch to address this @TODO. It looks up all variables that have a "video_" in their name, then runs a variable_del() on each one if the variable begins with the word "video" (namespaced). In testing, I see that this patch deletes 46 of the 49 variables containing the word "video".
It leaves behind three variables, though:
* ffp_video_upload
* ffp_video_field_video
* ffp_video_field_video2
As you can see, each one of the remaining three are not namespaced for the video module, so I'm assuming that they should remain behind, right?
Comment #5
elektrorl commentedthanks I found the ffp tables. But it does not help.
Comment #6
hypertext200Patch is good, but if other module uses the same namespace for any other purposes, what will happen?. I know we are using lot of variable and its very difficult to track all them and delete.
Comment #7
senpai commentedThis patch purposely deletes *only* those variables which begin with the 'video' string. In my testing, it did not delete vars from the 'ffp_video_upload' module, nor did it delete any vars from the 'ffmpeg_wrapper_' module. I've tried to keep it rather narrow in scope and reigned in. If we want to delete the variables from other modules inthe Video suite, such as the Video Upload or Video FTP modules, then each one of those modules should have their own similar patch.
Say the word and I'll roll one for each. Or you can copy/paste this patch. :)
Comment #8
senpai commented[followup to my own #7] Oh, I think I see what you're saying! If the video.module makes vars such as video_variable_settings and the video_ftp.module makes variables such as video_ftp_variable_settings, then uninstalling the video.module will also delete video_ftp_variable_settings stuff because is starts with 'video_'.
Dude.
Ok, so what if I make it parse for and ignore known strings such as "video_ftp_", "video_upload_" and the like? The only drawback to this proposed approach is that plugins such as video_zencoder.module would have to begin using "video_*" namespaced variables rather than the
<?php variable_get('zencoder_api_key', ''); ?>it's doing now.Comment #9
ccardea commentedI just found some other variables after running the patch:
node_options_video
form_build_id_video
skinr_settings_video
content_extra_weights_video
no_of_video_thumbs
Should these also be deleted, even though they are apparently created by other modules?
Comment #10
senpai commentedIt's a best practice to allow each module to handle only those DB items which they created, so I'd say a resounding NO to this. Let's stick with the "Don't mess with other people's data", because once you start down that road, you have to monitor each of the other modules to see what they're doing with those variable...
Too much work. :)
Comment #11
hypertext200@Senpai nice work around, adding to dev, and fixing the zencoder plugin variable with Namespace video_zencoder*
Comment #12
kscheirerThis is a good idea, but you might catch a few unintended variables.
in
SELECT name FROM {variable} WHERE name LIKE '%video_%'you'll get anything that contains the string video_. If you remove the first%you'll just get things that start with video_ instead.and the
strpos()call check for variables that start with "video", which could match "videocustom" or some other module name. Use "video_" here as well instead?Comment #13
hypertext200@kscheirer but it will effect to other module, so better to keep name space video_ for every variable and remove them.
Comment #14
senpai commentedI think Karl is right on both counts. I'm gonna roll a followup patch against HEAD that changes the strpos() matching to look for 'video_' instead of 'video' and thus it will only delete our namespaced video_variables and not also delete the videogallery_variables from the videogallery module. Yes, I know. It'd be stupid, dumb, against the rules and all that if someone were to make a videogallery.module without using an underscore between the two words, but to prove that this stuff actually happens, look no further than the naming of the *logintoboggan.module. :0
(*inside joke)
Comment #15
senpai commentedThis followup patch (v2) modifies the SQL query to only look up variables which begin with "video_", and then only deletes those variables which have "video_" at the very beginning of their name.
I've tested it locally, and it deleted all the video_example variables, but did not delete a videoplayer_example variable nor an example_video_example variable. This is a Good Thing.
Comment #16
kscheirerLooks like a good improvement to me!
Comment #17
kscheirerComment #18
hypertext200Added to dev