Kirki: Server Requirements for Kirki

[dillonbailey]

Issue description:

When working with the LetsBlog theme on local environment, kirki-style.css writes as styles are changed in customizer. When working on the server, the stylesheet is not written.

Version used:

Stable tag: 0.8.2

Using theme_mods or options?

n/a

Code to reproduce the issue (config + field(s))

n/a

We would chase this up with the theme authors, but as it's working on local environment but not our production server we feel it's probably more likely an issue with Kirki itself?

We've checked error/server logs to look for any conflicts when Kirki attempts to write to write a new stylesheet, nothing is apparent. We've tried opening up the file permissions to 777, no luck.

We've tried allowing and disallowing file mods without any luck.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[aristath]

Hey there!

Kirki does not write anything to your filesystem.
Is your theme perhaps using a compiler of some sort?

[dillonbailey]

Ok, interesting!

The reported behaviour on local development is that a file "kirki-style.css" is updated each time the theme customiser options are changed with the updated styles.

It does appear composer (php) is being used by the theme developer, but no front end compilers.

What else can I provide that may be helpful?

On 3 Apr 2016, at 10:13 PM, Aristeides Stathopoulos [email protected] wrote:

Hey there!

Kirki does not write anything to your filesystem.
Is your theme perhaps using a compiler of some sort?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[aristath]

can you please send me a copy of your theme?

[dillonbailey]

I've just sent you an email with the theme zip!

Thanks again!

DB

[aristath]

The version of the theme you sent me is 1.1.7. From what I can see on the theme's page they are currently on version 1.2
Perhaps this has already been fixed in a more recent version of the theme?

The Kirki version included in there is 0.8.4 and the theme author has modified the enqueue_styles method (you can see the original one here: https://github.com/aristath/kirki/blob/0.8.4/includes/Styles/Frontend.php#L16-L18 to look like this:

    public function enqueue_styles() {

        // Early exit if we're not using output
        if ( ! $this->uses_output() ) {
            return;
        }

        if(is_writable(get_template_directory() . '/modules/kirki/assets/css/kirki-styles.css'))
        {
            //Writing into file instead
            global $wp_filesystem;
            $wp_filesystem->put_contents(
              get_template_directory() . '/modules/kirki/assets/css/kirki-styles.css',
              $this->styles_parse(),
              FS_CHMOD_FILE
            );
        }
        else
        {
            wp_add_inline_style( Kirki::config()->getOrThrow( 'stylesheet_id' ), $this->styles_parse() );
        }

    }

You can simply revert the changes to that file and make it the way it originally was:

    function enqueue_styles() {
        wp_add_inline_style( Kirki::config()->getOrThrow( 'stylesheet_id' ), $this->styles_parse() );
    }

I would strongly advise you to contact the theme author though and inform them about this... checking with is_writable() is not enough for the $wp_filesystem.

I guess something like this would be better and would work:

    public function enqueue_styles() {

        // Early exit if we're not using output
        if ( ! $this->uses_output() ) {
            return;
        }

        global $wp_filesystem;
        // Instantiate the Wordpress filesystem.
        if ( empty( $wp_filesystem ) ) {
            require_once( ABSPATH . '/wp-admin/includes/file.php' );
            WP_Filesystem();
        }

        $path   = wp_normalize_path( get_template_directory() . '/modules/kirki/assets/css/kirki-styles.css');
        $styles = $this->styles_parse()

        if ( is_writable( $path ) ) {
            // Try writing to the file
            if ( ! $wp_filesystem->put_contents( $path, $styles, FS_CHMOD_FILE ) ) {
                // write failed, add inline.
                wp_add_inline_style( Kirki::config()->getOrThrow( 'stylesheet_id' ), $this->styles_parse() );
            }
        }
    }

Please note I did not test the above function, but it _should_ work a lot better than the existing one.

[Vishal-Deshpande]

@aristath could have just said that its not kirki issue and closed the ticket. But the amount of time and effort he has put in investigating and explaining the issue for which he is not going to receive any monetary return is really amazing. I always wonder how some guys in open source community are so passionate about their work and travel that extra mile easily while the premium theme and plugin authors struggle to do it. @aristath and for open source community +1

[dillonbailey]

@aristath the solution of reverting the module to the original intended design as per https://github.com/aristath/kirki/blob/0.8.4/includes/Styles/Frontend.php#L16-L18 fixed it without any stress.

Thank you sincerely for your help, this saved me big time!

[aristath]

@PlayerThemes @dillonbailey always a pleasure to help!