Multisite Issue

[djwd]

Hi there, thanks for your awesome plugin.

I'm requiring it for my next theme, but now an issue arose with a multisite install when setting up demos.

The compiler runs each time a the "Save" button is hit in the Customizer, updating the theme.css file.

Since all sites are using the same theme, each time a visual setting is changed on one site, changes reflect to all sites of the network.
I guess I need the output to be something like theme_[blog_id].css in order to fix this.

Letting the plugin enqueue the file didn't fix it, hence I guess multisite is not supported?

Do you have any hint on how I could approach this without editing plugin files?

Thank you

[brrn]

If you set the name of your scss file to theme_[blog_id].scss, that's the name the compiler will use for the css file.

[djwd]

Sorry I'm not sure I got it. Would you mind providing more details or an example? Thx

[garrettw]

The best solution I can recommend is for you to make a child theme for each site. That way, changes that should affect all sites will go in the parent theme, and changes that should only affect one site go in that site's child theme.

[djwd]

Actually no change should affect all sites.
Thanks for the advice but that would be a hassle to set up and maintain 5-10 sites, each with its own child theme. Also would mean my theme wouldn't support multisite. I'd rather use a different compiler, or integrate it in the theme (which I'd really wanted to avoid) instead of using child themes.

[garrettw]

I think I may have misread your original post.

The Customizer stores all of its settings in the database. It shouldn't be changing anything in a CSS (or even SCSS) file, so I would think that hitting Save, which makes it recompile, shouldn't be a problem, because wouldn't the CSS output just be the same?

If your Customizer settings are getting propagated from one child site to all the rest, it seems to me that you have a bigger problem going on.

[djwd]

Well hitting the 'Save' button does change something in the .scss file, what would be the point of recompiling then? :)

I pass CSS related options (like colors and backgrounds) as variables to the .scss file, so I get as an output a customized version of theme.css

The problem is kind of simple actually:
Since all sites refer to the same theme, therefore the same theme.css file, all sub-sites using same the same theme (and same .css file) get affected.

Actually your child-theme hint is the best solution so far, as I'm able to copy the .scss file under a different name (e.g theme_1.scss) and enqueue the resulting theme_1.css instead, in child theme's functions.php

Although this solution is far from being ideal.
What would be ideal instead, unless I'm missing something obvious, would be simply to consider multisite setup in this function:

public function enqueue_files($css_folder) {

      foreach( new DirectoryIterator($this->css_dir) as $stylesheet ) {
        if ( pathinfo($stylesheet->getFilename(), PATHINFO_EXTENSION) == 'css' ) {
          $name = $stylesheet->getBasename('.css') . '-style';
          $uri = get_stylesheet_directory_uri().$css_folder.$stylesheet->getFilename();
          $ver = $stylesheet->getMTime();


          wp_register_style(
            $name,
            $uri,
            array(),
            $ver,
            $media = 'all' );

          if(!$this->style_url_enqueued($uri)){
            wp_enqueue_style($name);
          }
        }
      }
  }

by checking if is_multisite() and adding $blog_id to the file name before generating the .css file and enqueing it.

Hope it makes more sense now :)

[garrettw]

I pass CSS related options (like colors and backgrounds) as variables to the .scss file, so I get as an output a customized version of theme.css

Ah, ok. This is the problem. Your theme should be pulling in the Customizer settings from the database and generating inline CSS. If it did that, multisite would work the way it's intended to.

[djwd]

Yeah the whole point is not to load dozens of lines of code on each page overriding other dozens of rules in the main CSS file. This system is way more efficient without affecting user experience as Live changes still work through JS.
Even though I'd love to discuss this further, that's not really the point of the issue.

[garrettw]

("Way more efficient" is debatable; while it may reduce unnecessary CSS, having a small bit of extra CSS is not likely to make a noticeable performance impact in the end user's browser.)

Anyway... as your preferred way of doing this is definitely unconventional, I don't think enqueue_files() should be modified like that in the source here. I'd say either change the plugin source on your site, or go the child theme route. Sorry.

[djwd]

Fair enough although to debate it you should also point out some cons of this approach, what you said still makes it (a lot or a little) more efficient over the old method.

Anyway, again, the way I (and many other premium theme's authors) use a built-in compiler isn't the point really.
The same scenario would happen for anyone using the same theme on a multisite setup. If they edit .scss source files for a site, their changes would affect all sites.
An issue easily fixable that would not bring any disadvantages, so I don't really get your point.

If this is also not a real/common case scenario then I don't understand what's the point of this plugin to exist in the first place.

ps: are you the plugin's developer? I'm not quite sure I got this

[garrettw]

My point is that WordPress is set up to do certain things in a standardized way, even if it isn't always the most optimal solution. The way most devs expect WordPress to work is that no part of WordPress changes any files except for the updater, the uploader, and the editor. Plugins do sometimes change files, but they usually only do it when they have a compelling reason to do so, and it's usually clear that files are being changed.

The Customizer is expected to write settings to the database for the theme to use later, and not to change any files. Any visual settings that would be different on each sub-site should (1) be changeable in the Customizer and (2) be saved from there to the database, which allows WordPress to consistently load the right settings for each site into your theme without affecting the other sites.

The point of this plugin is very simple - it lets you use SCSS files in your theme rather than just CSS. That's it. It has nothing to do with the Customizer, just like most theme's CSS files have nothing to do with the Customizer.

If I were the plugin developer (which I'm not), I would say that the plugin should be written for a general audience, and what you're after is definitely not a normal usage.

I've made my point -- it's up to the developers as to what they want to do.

[brrn]

I know this thread is old, but @djwd if you want to submit a pull request, we'd be happy to review it.

[skulky]

I was looking for a solution to this multisite problem as well.
Why not add a blog_id value as a directory in your CSS location field (i.e. /css/1/ /css/2/) for each multisite.
It's not pretty on its own as you have to create these folders when creating new sites, but with some WP hook magic it can become autonomous.