Why cant the WP Filesystem API read googlefonts.json?

by

I’ve inherited a site built with a theme by Highgrade (southcentral) which is built using the Redux framework.

I’m seeing the following error in the frontend and admin panel:

Warning: Invalid argument supplied for foreach() in /Volumes/Data/Users/me/Sites/reference360.eu/wordpress/wp-content/themes/southcentral/highgrade/framework/inc/fields/typography/field_typography.php on line 772

I’ve tried altering permissions and ownership on googlefonts.json but to no avail.

The problem seems to be within the Redux framework – see this thread on github

I’m debugging in the typography.php class :

 if (!isset($this->parent->fonts['google']) || empty($this->parent->fonts['google'])) {
            $this->parent->fonts['google'] = json_decode($wp_filesystem->get_contents(ReduxFramework::$_dir . 'inc/fields/typography/googlefonts.json'), true);
            var_dump(ReduxFramework::$_dir . 'inc/fields/typography/googlefonts.json');
            var_dump($wp_filesystem->get_contents(ReduxFramework::$_dir . 'inc/fields/typography/googlefonts.json')); exit;
            $this->parent->font_groups['google'] = array(
                'id'        => 'google',
                'text'      => __('Google Webfonts', 'redux-framework'),
                'children'  => array(),
            );
            foreach ($this->parent->fonts['google'] as $font => $extra) {
                $this->parent->font_groups['google']['children'][] = array(
                    'id'    => $font,
                    'text'  => $font
                );
            }
        }
    }

Anyone got any idea what might be causing this? The file exists and is at the path specified. Development environment is OSX Mavericks.

UPDATE:

changing the ownership of the entire wordpress directory to _www:_www resolves the problem but is obviously not a great solution.

4 Answers
4

It is not necessary to use the WP_Filesystem for every little thing, and in this case, the correct solution is to use the normal file_get_contents.

The WP_Filesystem is a wrapper around various ways to interact with the filesystem in a safe manner… but it’s not meant for everything.

Fundamentally, the WP_Filesystem code was created to allow WordPress to update itself.

When doing such a thing, file ownership is a rather big deal. A lot of servers run as “www” (for example) instead of as the actual owner of the PHP files. If WordPress were to write a file directly in such a case, the resulting file would be owned by “www” as well, not by the true and correct owner. This can lead to security issues, especially in shared hosting.

So, the WP_Filesystem abstracts the file operations. It can read and write files in ways that will preserve file ownership. If it can write directly and the ownership remains, then it will do so, but if it cannot, then it will instead need credentials for some method like FTP. By using credentials, it can log in via that route and write files using the proper owner of them.

What this means is that before you use the WP_Filesystem, it has to be set up. A test has to be performed, and if the test fails, then credentials must be obtained from the user. Without those credentials, it can’t function.

In your case, since “changing the ownership of the entire wordpress directory to _www:_www” fixed the problem, this is what is happening to you. The test of it trying to write a file and getting the proper ownership fails. By changing the owner of the existing files, you’re changing the conditions for that test.

Now, the truth is that in this case, there’s no reason to use the WP_Filesystem at all. He’s reading a file. He can read that file directly. Ownership doesn’t matter here. So, really, just use file_get_contents. Using the WP_Filesystem for this makes no sense.

More on the WP_Filesystem, from a how-to-use-it perspective:
http://ottopress.com/2011/tutorial-using-the-wp_filesystem/

Leave a Comment