I've been doing some testing to post in the "Performance Benchmarks" issue que and I stumbled across a possible incompatibility.

If you run the Parallel's Module it essentially turns off this module.

With CSS Embed and w/o Parallel http://www.webpagetest.org/result/100313_5Y7P/1/details/
With CSS Embed and w/ Parallel http://www.webpagetest.org/result/100313_5Y92/1/details/

If we can get these two working together it would be a killer combination.

I should mention in both the above tests I am also using both Boost and Javascript Aggregator as well as server side GZIP compression.

Parallel Module http://drupal.org/project/parallel

CommentFileSizeAuthor
#8 css_emimage-741454.patch1.11 KBphilbar

Comments

mikeytown2’s picture

mikeytown2 commented

subscribe; open to ideas

kentr’s picture

kentr commented

Is it an issue of module weight (the order in which they're firing)?

bryancasler’s picture

bryancasler commented

I suspect, but I wouldn't know how to change it.

I am also encountering another problem where all styling is lost. What I think is happening is that this module is creating the aggregate css file, then boost is creating the cached page linking to that css file, and then this module deletes that css file and generates a new one, thus leaving boost's cached pages pointing to a non existent styling sheet.

Not sure if it's related, but figured I should mention it.

philbar’s picture

philbar commented

Shouldn't be the same fix as the bug with CSS Gzip? Just add the following right before the gzip fix:

    // Move parallels' preprocess function after ours.
	if ($key = array_search('parallel_preprocess_page', $theme_registry['page']['preprocess functions'])) {
      unset($theme_registry['page']['preprocess functions'][$key]);
      $theme_registry['page']['preprocess functions'][] = 'parallel_preprocess_page';
    }

My host is having some problems, rendering my site unusable, so testing will need to wait.

philbar’s picture

philbar commented
Version: 6.x-1.0 » 6.x-2.x-dev
Status: Active » Patch (to be ported)

I can confirm the above fix work for version 6.x-2.x-dev.

The only issue is that the IE hacks are not rewritten by the parallel module. I'm not sure if that is a big issue.

mikeytown2’s picture

mikeytown2 commented

IE hacks are usually stored in the template page.tpl file, I would have to run an output buffer like I use on boost to capture the entire page & then process the entire html structure. Granted that would give me a lot of control, but it might be overkill... then again I think i'm already doing this so I can grab the recolorable css files.

I think I really should make a hook_alter_html module; it's functionally that I already have in boost, but it could be used elsewhere: CDN/Parallel, html beautification, ect...

bryancasler’s picture

bryancasler commented

I'm using Conditional Styles http://drupal.org/project/conditional_styles would it be effected by this?

philbar’s picture

philbar commented
StatusFileSize
new css_emimage-741454.patch1.11 KB

Attached patch

jcarnett’s picture

jcarnett commented
Status: Patch (to be ported) » Fixed

The root of the problem is that this and other modules, including Parallel, include code in hook_theme_registry_alter() to move their page preprocess function around so it runs last because page preprocess functions are not ordered by module weight. This seems really dirty to me and I'd like to find a more reliable solution to avoid adding one-off exceptions any time a new module touches the CSS. I'm just not sure if there is a good general solution or a better approach in Drupal 6.

Rather than adding a fix specifically for Parallel, I slightly loosened the pattern matching on the style tags so Parallel's addition of the "//cdn1.domain.com" prefix won't cause CSS Embedded Images to skip those files. At least in this case it avoids any issues with the preprocess function order, but that will probably come up again with some other module.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.