Where is Suffusion trying to write to?

The options themselves are stored in the DB, but the generated CSS is stored on the file system, under wp-content/uploads/suffusion. If yours is a multi-site installation, it will try to write to wp-content/blogs.dir/<id>/files/uploads/suffusion, where <id> is the id assigned to each user by WP at the time of creation.

Of course, you could circumvent the whole process of writing the file by going to Suffusion Options → Back-end → Site Optimization → Auto-generate CSS file for customization options, and picking any of the other options such as “Auto-generate the CSS and print it in the HTML source”.

@markpea the other thing you should probably do is to use a child theme, network enable that child theme, and network DISABLE the main Suffusion theme.

A basic child theme consists of:

/*
Theme Name: Suffusion Child
Theme URI: https://aquoid.com/news/themes/suffusion/
Description: Suffusion Child
Version: 1.0.0
Author: Sayontan Sinha
Author URI: https://mynethome.net/blog
Template: suffusion
*/

@import url("../suffusion/style.css");

and place it in a subdirectory under Themes like any other. This will prevent users from intentionally or inadvertently doing anything to the Suffusion base, but still give them access to its full potential.

Wow the response to this forum is fantastic. My situation is a wee bit complex because I’m not in control of the whole process from test to production. I install, configure and test things out on a sandbox server (on which I have sudo privs) and the System Admin copies the code to the production server and update the database there. The production server has a fierce firewall and security.
So, with that in mind, here’s what I’m finding:

1. A directory called suffusion is not created in wp-content/blogs.dir/<id>/files/uploads/ (neither is ‘uploads’ created for that matter) with the default Site Optimization settings even though permissions for files/uploads is set to write access for the web server (nginx not Apache). I think that this is why no CSS settings are saved by default.
2. However, configuring the Site Optimization as suggested by @sayontan above does work and some settings get saved. I use
3. Under ‘Skinning’ I can choose a different skin — I really like these options and I chose the orange/dark theme. The settings save (at least it seems to) but the skinning only half works — the orange highlights are there but the background is the default. Strange. Take a look at https://epress.earlham.edu/balkanicons/

I have been using @gcaleval ‘s suggestion of a child theme for suffusion. The contents of the son-of-suffusion directory is a single file, style.css, which has a single line @import url("../suffusion/style.css");. Also following his suggestion I network disable ‘suffusion’ and network enable ‘son-of-suffusion’, the child theme.

Now, here’s a funny thing. I’m still trying to figure out why the CSS for the skin I desire doesn’t get fully implemented. So, on a hunch, I network enable the main Suffusion theme and activate that. Two things happen:

1. the skinning now both saves and executes correctly. So I can chose the dark background and it works!
2. on another hunch, returning to Back end -> Site Optimization I reset the Auto generate CSS file to the default setting (include as a linked file), and lo and behold it does not give the same behaviour as before (ie no prompt to FTP) and the settings seem to be saved.

So, it looks like my implementation of the child theme is at fault here, though I’m not what to do to fix it.

Thank you for your patience guys!
Mark

So, it looks like my implementation of the child theme is at fault here

True. This is the problem:

The contents of the son-of-suffusion directory is a single file, style.css, which has a single line @import url("../suffusion/style.css");

Get rid of the @import line, and things will work fine. Basically WP tutorials on child themes assume that your parent theme has precisely one stylesheet, while it is very possible for themes to use multiple stylesheets for skinning purposes. Suffusion takes care of all the dependencies at its end, so putting the superfluous @import line only serves to override the skinning CSS files. So the simplest solution is to remove the line in your child theme.

Of course, the traditional approach recommended by WP tutorials works too, but for that you have to go to Suffusion Options → Back-end → Child Themes → Inherit Styles, and make the appropriate selection.

I’m not clear on one thing.

If one follows your method Sayontan, does it require the main Suffusion theme to be network-enabled? In @markpea’s case this may not matter given his site is going to live in a fiercely protected environment and he may only be offering a single thematic choice.

But in other cases, for example using child themes to build 10 variants of Suffusion, having only those 10 network enabled seems to make sense. I chatted with an op who created a separate child for each of four faculties in a school which is why it connected for me here.

As your own tutorials taught me, keeping with traditional practice is as simple as addinga line to import the appropriate skin css file, no?

My skinning selection is not over-ridden and my child has the @include lines.

I’m also unclear about the apparent resolution of

on another hunch, returning to Back end -> Site Optimization I reset the Auto generate CSS file to the default setting (include as a linked file), and lo and behold it does not give the same behaviour as before (ie no prompt to FTP) and the settings seem to be saved.

The only time I’ve come across that is when there are permission issues with where Suffusion is trying to save the linking file. My system is set to stop any attempt to create a new directory in the Uploads directory and any file outside the date tree. Which naturally blocked the saving the of the suffusion css file. Hence I use auto-generate in html.

But if I understand your answer, it wasn’t saving the file because it was being overwritten by the child’s include statement?

If it is not due to overwriting — and I’m skeptical because I have a similar setup and do not have that issue — then it’s due to something else that could come back to haunt if it is not identified on the front end. The prompting for FTP credentials also suggests the failure was caused by something beyond having an include statement in the child theme’s sheet.

Regardless, this topic has given me something new to experiment with <smile>.

If one follows your method Sayontan, does it require the main Suffusion theme to be network-enabled?

No, being network-enabled has nothing to do with what I am suggesting.

Even if you are using a child theme for a network-disabled parent theme, the original parent theme hooks are running. So all stylesheets will get enqueued just as normal.

As your own tutorials taught me, keeping with traditional practice is as simple as addinga line to import the appropriate skin css file, no?

My skinning selection is not over-ridden and my child has the @include lines.

I will have to take a look at your site to determine if anything is being overridden or not.

But if I understand your answer, it wasn’t saving the file because it was being overwritten by the child’s include statement?

No! The saving of the file is due to the WP_Filesystem. It is a useful, safe and recommended approach for saving files in the WP ecosystem, and it needs to ensure that the files are written by your user account, and not by the web server account, hence the FTP prompt. Why @markpea’s original configuration was not letting the files get saved, I cannot tell, but it typically happens due to the files belonging to different users.

I suggested the removal of the child theme’s @import statement to prevent overriding, not overwriting (which isn’t an issue here).

Many thanks for your help @sayontan and @gcaleval.
So, I commented out the single @import line in son-of-suffusion/style.css. Now there is no active content in style.css.
The result was that the skin only half works as before — light green background, skin colours. Moreover, switching to the Suffusion parent theme resolves the skinning issue and the selected skin is displayed correctly.

it needs to ensure that the files are written by your user account, and not by the web server account,

So, as a consequence of the necessity of writing file via the user account the directory wp-content/blogs.dir needs to have world write access, correct? Currently it has group write access where the webserver is part of the group, and world read access (ie chmod 775).

Thanks for all the help with this. I just want to ensure that when one user selects a Suffusion skin and then customizes it, this won’t be overwritten by another user (or a different blog site owned by the same user) in the system.
Cheers
Mark

The result was that the skin only half works as before — light green background, skin colours.

Sorry, I can’t help you here without a URL.

There are no risks of overwriting, since each user’s file is written to a different folder. The folder under blogs.dir is unique for each added site, so by consequence the custom-styles.css file is written in different folders.