Wrong css attached if executing mail via other theme and the mimemail theme specified does not define mail.css

Let me check this.

This can be easily a duplicate of #1349728: Possibility to configure the theme that will render the email.

@Amitaibu
Has the dev version you have installed that patch applied?

I've been checking about the css and it works with cron too, so if in case you have a dev version with that issue, could you describe exactly how to reproduce?

Ok, talking to @amitaibu in IRC I've found the problem.

The css attached to the email, when no mail.css is declared, is generated using the current theme not the specified in the setting.

I'm going to work on this.

I think this is the best way, I have some other things in mind about the general aproach of theming mails with non-current themes but I would like to discuss with @berdir, @pillarsdotnet and @sgabe.

I'm caching the results to improve performance, maybe it would be good to do the same with template_preprocess_mimemail_message in the generation of the output css, but probably better in another issue.

Let's see if this works.

Was this ever included in the release?

I don't think so because the problem still seems to exist. Even when using mail system the problem seems to occur.

Does the patch solve the issue?

Perhaps this problem has a connection to #854342: HTML not being rendered "randomly". I did not test the patch yet, because it is quite old and I want to make sure first, that I can find the deeper reasons to the problem. Anyway #854342: HTML not being rendered "randomly" seems closer to the problem in my case, so I will first have a look there.

FYI this patch does not work in the latest module (7.x-1.0-beta4).

Before, when I explicitly set the 'Theme to render the emails' to my custom theme 'foo,' it still uses the admin theme ('Seven'), even though I've set my default theme to 'foo' as well.

After this patch, it doesn't attach *any* CSS.

I'm running cron using the admin menu as a logged in admin.

Updating issue status.