How to properly apply WordPress's theme options to CSS and JavaScript in a page?

Most theme options were created and saved on PHP and I don’t know what is the proper way to apply those saved options to the CSS and JavaScript of the WordPress theme. Right now the CSS and JavaScript codes are all in the external files.

I was thinking of doing echo those options right away in the or block but maybe that isn’t a good practical way to do? :expressionless:

Please advise… :confused:

Thanks in advanced!

Don’t put the theme options in the header. It’s not a good practice and it will just increase your header without any good reason.

You should do those changes directly inside the css files(for colors, backgrounds, etc…).

We have an extra style.php file in which the options are echoed directly into the css. Make sure to only have the css that needs changing in that file, and to load it as last so it overwrites your default css rules.

Good luck :slight_smile:

redfactory said

We have an extra style.php file in which the options are echoed directly into the css. Make sure to only have the css that needs changing in that file, and to load it as last so it overwrites your default css rules.

Good luck :slight_smile:

+1. :slight_smile:

redfactory said

We have an extra style.php file in which the options are echoed directly into the css. Make sure to only have the css that needs changing in that file, and to load it as last so it overwrites your default css rules.

Good luck :slight_smile:

So, your style.php generate a style.css, right?

RubenBristian said

Don’t put the theme options in the header. It’s not a good practice and it will just increase your header without any good reason.

You should do those changes directly inside the css files(for colors, backgrounds, etc…).

Then how could I apply those css changes to the css files dynamically? I just a bit confuse at this point…

you would use the php file_open and write functions, this will enable the script to open the css file and save the contents to the file.

Gareth_Gillman said

you would use the php file_open and write functions, this will enable the script to open the css file and save the contents to the file.

Exactly! This is how i do it..

So nobody sets the headers for customstyles.php to

<?php header("Content-type: text/css"); ?>
, adding it as any other external CSS to the head?

To echo custom rules inside a style block of header is not a bad practice and also has absolutely zero impact on performances/load times while to write an external css file with custom values requires an additional server request which is far more costly in terms of resources.

BF

digitalimpact said

So nobody sets the headers for customstyles.php to

<?php header("Content-type: text/css"); ?>
, adding it as any other external CSS to the head?

I do something similar for theme styles.

And also for the editor: http://themeforest.net/forums/thread/add_editor_style-bug-in-v341/71574

pixelentity said

To echo custom rules inside a style block of header is not a bad practice and also has absolutely zero impact on performances/load times while to write an external css file with custom values requires an additional server request which is far more costly in terms of resources.

BF

so if i have 200 lines of custom css code, should i add it to the header of each file?

RubenBristian said

so if i have 200 lines of custom css code, should i add it to the header of each file?

yes.

that will still be way faster than loading another file.

I also use a dynamic style tag in the header for style options. Putting stuff in a special file (like the css.php example file )only complicates things because that means a new set of queries for wordpress to make to generate a new file + another file to request/load from server. Is not worth the cost, in my opinion.

For custom CSS styling I generate + minify css file and save it on server only when user clicks on ‘Save Changes’ button in theme options, so there are no additional WP queries made on each page view.

Hmm. It looks like a kind of trade-off between the two methods right?

At first, I thought echoing custom style block directly to the header may not be a good way because the page would look too messy and, you know, kind of unorganized way to do so. But I never realized the fact of the performance as @pixelentity mentioned. That’s very great to know.

I just tried the method of “special” style file like style.php and that works perfectly too.

This is quite questionable for which one is better…

pixelentity said

To echo custom rules inside a style block of header is not a bad practice and also has absolutely zero impact on performances/load times while to write an external css file with custom values requires an additional server request which is far more costly in terms of resources.

BF

Exactly what i wanted to say. STAY AWAY FROM EXTERNAL PHP FILES. They have huge impact on performance and if they have the folder wp-content set to 777 or any folder that is parent to the php file it will not execute on some servers. Trust me, we used it with fortune and three and we had issues, so we added the extra styles in the header, that loads faster and less support on the matter. In short - NO TO EXTERNAL PHP

Lion said

For custom CSS styling I generate + minify css file and save it on server only when user clicks on ‘Save Changes’ button in theme options, so there are no additional WP queries made on each page view.

+1, exactly

UXbarn said

I just tried the method of “special” style file like style.php and that works perfectly too.

i can hardly see any advantage in doing that.

with almost any server now supporting gz compression, a 8kb uncompressed css block would just add like like 1-2kb to the page.

BF

Lion said

For custom CSS styling I generate + minify css file and save it on server only when user clicks on ‘Save Changes’ button in theme options, so there are no additional WP queries made on each page view.

How many customers had issues with this? I can bet that many did not have the permission set for the file/folder and windows servers will bust the writing process + get_files_content restriction in effect, those are a few problems that i can say for sure that you have with this.