Wrong redirection when click on remove link and Path prefix is set on multilanguage

Thanks for reporting this and the patch but I think is better just to add the language in the l that is returned:

return l(
      t('Remove'),
      'commerce/coupons/order/remove/' . $coupon_id . '/' . $order->order_id,
      array('query' => array('destination' => $dest, 'token' => drupal_get_token('commerce_coupon_remove_checkout:' . $coupon_id . ':' . $order->order_id)))
    );

Or pass $dest through url using language

I have a similar problem

Sorry patch name is error.

destination variable for Remove link is wrong if form is returned via Ajax request. $GLOBALS['base_url'] already contains base path in it, so if site is located under subdirectory, then base path is added twice, hence the redirection back to the home page.

The attached patch fixes the destination for Remove link if form is served via Ajax call even if language prefix is present.

this also exist in 7.x-2.0-beta4 applying the patch manually fixes the issue....

reroll against current dev

Thanks,

worked for me, not getting a 404 anymore after removing a discount in a multilingual site

I don't have cases using Ajax call, but i have same issue without ajax.

+++ b/sites/all/modules/contrib/commerce_coupon/includes/views/handlers/commerce_coupon_handler_field_coupon_order_remove.inc
@@ -10,6 +10,8 @@ class commerce_coupon_handler_field_coupon_order_remove extends commerce_coupon_
       $dest = current_path();

Should use drupal_get_destination() instead of current_path().
May be this works for Ajax call to ?

The last patch seems to solve this problem. Committed to dev.

The code in dev version doesn't work.

I think

if (module_exists('language')) {

should be

if (module_exists('locale')) {

@harrrrrrr is right. The fix for https://www.drupal.org/node/2512894 which was released with rc2 breaks this again. As far as I can tell, there is no "language" module, so the check will always return false - it certainly does in my multilanguage sites. The function language_url_split_prefix is defined in includes/language.inc (part of Drupal core) which is loaded as part of the bootstrapping process in includes/bootstrap.inc:2682 (drupal_language_initialize).

Assuming, that the core guys know what they are doing, I would suggest that we test for the availability of the function the same way that they check if they have to load the include - using drupal_multilingual() function which in turn checks the variable 'language_count'.

Patch on #23 fixed it, drupal_multilingual() seems ok to see if there are more active languages

This seems to do the trick. Committed.