A Views 1 argument array does not have a field index, so the current conversion script generates an error notice. Patch to follow.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | content-views-convert-444276-5.patch | 20.87 KB | JirkaRybka |
| #4 | content.views_convert.inc-444276-4_62.patch | 21.71 KB | darren oh |
| #3 | content.views_convert.inc-444276-3_62.patch | 21.58 KB | darren oh |
| #2 | content.views_convert.inc-444276-2_62.patch | 21.5 KB | darren oh |
| #1 | content.views_convert.inc-444276-1.patch | 3.51 KB | darren oh |
Comments
Comment #1
darren ohPatch attached.
Comment #2
darren ohI finished all the CCK field conversions.
Comment #3
darren ohNew patch to maintain uppercase in text argument titles.
Comment #4
darren ohFixed a couple of errors in the patch.
Comment #5
JirkaRybka commentedIt so happens that I'm converting my views now, and so I found this issue. Unfortunately, the patch still have issues, some of which I fixed in the attached new patch (which is just a minor change to the above, most of the patch is identical re-roll), some of which I don't know how to fix. (I quote *all* changes done to the patch below, so that you can see my points, and be sure about other code being not touched.)
My problems are with filters (exposed by the way) on text and number fields. I don't use other fields, so that part went untested on my part.
Filters on textfields (with list of allowed values based on the field's allowed values) are not converted - I have some views with a lot of these, and they all show as "broken/missing handler". That's because the handler changed from 'default' to 'many_to_one'. So, I added this bit to text.views_convert.inc:
This bit of code makes the needed change to 'field', which is later stored into the item by existing code some 8 lines below (the item still have the old ID with 'default' in the key string, which is nearly impossible to change this late in conversion, but it doesn't hurt - as far as I tested, all works well). But however, that "existing code below" didn't fire at all, because the $text_filters array only had the extras with "_like" added, not the basic versions without that (which are used if I add the filters manually on Views UI, so I believe they should be there). So even the corrected field didn't match. I added another line into the static fields/filters builder near top of text_views_convert(), to include the basic versions:
$text_filters[$text_field] = &$text_fields[$text_field];.Now my filters on textfields convert more or less fine - at least they are there (so I don't need to remove a bunch of broken filters manually, and add them again), they even remember they are Exposed filters. What they don't remember are defaults for Exposed filters, but that's beyond me and easy to fix manually.
Quite the same happens with filters on numeric fields. The handler 'default' no more exists, if I create a filter manually on Views UI, it's without any handler name appended. So similar code goes to number.views_convert.inc :
and
$number_filters[$number_field] = &$number_fields[$number_field];I suspect there's more to do, since the code (apart from omitting basic versions of fields from the $number_filters list) adds the old 'default' versions of fields, for which there's no handler now. But however, with these fixes (plus the hack mentioned below - more on that later) my filters import more or less OK (again, defaults for Exposed filters are not there, but at least I don't have to remove all filters and create them again by hand).
Additionaly, the whole thing with numeric fields just *doesn't work*, because the field data retrieved from the hook number_field_settings($op='views data') is just empty. The bit of code providing the data just doesn't run, because count($allowed_values) is zero (i.e. FALSE) - hey, what allowed values are supposed to be there for a numeric field, when I have no dropdown, and the values are typed into a form directly? As the code also adds the 'many_to_one' handler, I suspect this to be a kind of copy-paste from text.module? Anyway, only after I short-circuited the condition to be
if (count($allowed_values) || 1) {, only then *something useful* got returned, and number_views_convert() started to work. This part goes beyond me, someone else is needed here. My filters converted fine with this hack in place, but since it's ugly hack (more of a debug code, actually), and I don't really know what's going on in that bit of code, I *didn't* include this into the patch. So the ugly hack isn't in there - for now, you need to add that manually to make the conversion somehow work without further fixes.Although I believe I pushed this a bit further, this still needs work IMO. Also my changes need review.
Comment #6
JirkaRybka commentedHm, the defaults for exposed filters seems to be there after all, they are only just treated a bit differently in Views2, OR I don't remember them exactly (it's a horrible big view, really). All other points are still valid.