Contextual filter does not work when 'Transform dashes in URL to spaces in term name filter values' is selected [#1788832]

The transformation is applied in the wrong place: i.e. AFTER the term in the original language has been found.
But at that time, the search in the locales_target has already failed because the argument contains the dashes. Furthermore, if the query is successful, then the transform must not be applied another time.

The proposed applies the transform also in the localized search adding a new argument to the function i18nviews_locale_source.
Then, if the search is successful, put the transform flag to false, because we already have the term without the dashes.

See the attached patch.

NOTE: this patch already contains the one proposed in http://drupal.org/node/1786876

Comment	File	Size	Author
#10	transformed-contextual-filter-fix-178832-10.patch	2.53 KB	pmusaraj
#1	fixed-1788832-1.patch	2.41 KB	mperrando
	patch.patch	3.13 KB	mperrando

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mperrando CreditAttribution: mperrando commented 19 September 2012 at 10:51

File	Size
fixed-1788832-1.patch	2.41 KB

The proposed patch contains modifications to the info file. Sorry.

This is the same patch with only the correct files.

Comment #2

apemantus CreditAttribution: apemantus commented 22 January 2013 at 13:35

Status:

Patch (to be ported)

» Reviewed & tested by the community

Works for me and fixed a problem that was caused me all sorts of bother.

Comment #3

tYb CreditAttribution: tYb commented 4 June 2013 at 06:55

thanks for the patch, saved my day!

Comment #4

hass CreditAttribution: hass commented 13 June 2013 at 07:15

Status:

Reviewed & tested by the community

» Needs work

From reading the patch I believe this cannot correct. Drupal is already utf8. There cannot be a need to convert strings to utf8.

Comment #5

dscutaru CreditAttribution: dscutaru commented 13 June 2013 at 07:54

@hass locales_target.translation is of type BLOB, see more details in #1786876

I'm using this patch and it is working. It would be nice to see it committed, so there will be one less patch to worry about.

Comment #6

hass CreditAttribution: hass commented 13 June 2013 at 16:11

Converting an UTF8 string to UTF8 is waste of time from my point of view as it gives us nothing than extra DB load for nothing. I do not say this patch does not work, I'm only saying it's not proper coding.

(lt.translation using utf8)

Comment #7

dscutaru CreditAttribution: dscutaru commented 13 June 2013 at 16:50

Actually it is converting BLOB to utf8 string. This conversion makes comparison to be case insensitive and is the patch from #1786876 as said in the NOTE.

Comment #8

hass CreditAttribution: hass commented 13 June 2013 at 21:20

CLOB is for text. Maybe the field definition is wrong. Aside from this we normally use nvachar(max) in such cases as it's a lot more flexible. These SQL statements look also not DB independend. It may not work on pgsql, sqllite, mssql, oracle and others. Have you tested it on all of these db's?

Comment #9

dscutaru CreditAttribution: dscutaru commented 14 June 2013 at 07:28

I totally agree with you about that. Although there is no CLOB in mysql, TEXT can be used and I guess it will require some more changes. It would be nice to hear an opinion from this module maintainer.
This patch so far assumes your are using mysql(as most of us do), you ran into this problem and need a fix right now.