Fix Omega 4 support by using a different approach for selecting the messages div

Hi Juc1,

I had the same problem with a normal commerce (not kickstart) and omega 4. The problem is that omega 4 put the name of the class as 'messages--commerce-add-to-cart-confirmation' instead of 'commerce-add-to-cart-confirmation', so nothing works.

I have made a patch to solve this problem, but this patch is not valid for the module because it would break the rest of the themes that doesn't add that 'messages--' to the class.

Do someone knows which could be the right way to solve this problem? (maybe it's an omega 4's problem)

I hope it would be useful.

Hi Juc1

I had made the patch with the dev version downloaded with git. I think that the difference is that in the dev version we have:

$('body').append('<div class="commerce_add_to_cart_confirmation_overlay"></div>');

and in the rc2 version we have:

$('body').append("<div class=\"commerce_add_to_cart_confirmation_overlay\"></div>");
(the filter doesn't show the \", it's like this: class=\"commerce_add_to_cart_confirmation_overlay\")

You can change the patch with the right line before apply it. Anyway, if you need me to remake the pacth let me know.

Any developments with a suitable patch?

Hi,
Is there an upgrade for this patch?
It works partially in my case. I get the pop up window with all the info, but I cannot click on "Continue shopping" or "Go to check out" neither can i close the pop up window.
Thanks.

Attached is the patch file for version 7.x-1.0-rc2 (the latest atm).

@nightlife2008 That's a big patch isn't it?

Will this be commited to the module or left for Omega 4 users to patch as needed?

The patch works well on the Product Display page but on product list views pages, the confirmation does not show until you click away from the views page to an entity page.

Does anyone have any idea on how to rectify for product list views?

Update: After further digging, I've come to realize that this question is unrelated to this thread.

I think the best idea it's place status-messages.theme.inc in omega subtheme (mytheme/theme):

function mytheme_status_messages($variables) {
  $display = $variables['display'];
  $output = '';

  $status_heading = array(
    'status' => t('Status message'),
    'error' => t('Error message'),
    'warning' => t('Warning message'),
  );
  foreach (drupal_get_messages($display) as $type => $messages) {
    $output .= '<div class="messages messages--' . $type . ' ' . $type . '">';
    if (!empty($status_heading[$type])) {
      $output .= '<h2 class="element-invisible">' . $status_heading[$type] . "</h2>";
    }
    if (count($messages) > 1) {
      $output .= '<ul>';
      foreach ($messages as $message) {
        $output .= '  <li>' . $message . '</li>';
      }
      $output .= '</ul>';
    }
    else {
      $output .= $messages[0];
    }
    $output .= '</div>';
  }

  return $output;
}

There are a couple issues that keep this module from working on Omega 4: the messages-- prefix on the messages div class as previously mentioned but also, in my experience with an Omega 4 subtheme, the selector used to determine the parent element for the overlay div.

It's unfortunate that Omega adds the prefix it does to the class on the messages div, but it's equally unfortunate that this module is abusing the status type argument passed to drupal_set_message(). The API clearly states what the supported values are, and this module only gets by on a technicality, abusing the fact that it gets added as a class on the messages div to format itself.

The module should instead be using a different selector or different CSS to function properly.

For properly positioning the overlay element, I propose a fix whereby an alterable settings array is passed from the module code to JavaScript, so the module's JS has module configurable classes / selectors to use. Patch incoming.

Attached (and committed).

Moving back to "Active" so the module's abuse of the drupal_set_message() type parameter can be patched properly.

latest dev does not work with omega 4. It just adds the contents of a modal to the top of a page, where messages usually appears.

Found that!
You need to copy omega/theme/status-messages.theme.inc to your subtheme/theme/status-messages.theme.inc. Than open it, and change
$output .= '<div class="messages messages--' . $type . '">';
to
$output .= '<div class="messages ' . $type . '">';
save file and clear cache.
Thanks cosolom #12!

Assuming this is fixed as the patch has been committed.