The problem with making a CSS only Reboot is that a child will always revert back to the parent if something isn’t present. So the child stylesheet would have to be basically 100% complete, and every call to a PHP variable would have to be overwritten with CSS. That should be enough but it would be a lot of work.

Of course you’d also have plugin .spcss files, the mobile and RTL which contain PHP calls (not sure on the RTL would have to double check actually).

Seeing as you’d have to replace all these PHP calls with CSS, you wouldn’t need to remove the overlay theme support as the stylesheet shouldn’t be looking for them any more.

Sorry if I’m off the mark there, I think I see what you are suggesting. I will certainly discuss the potential for a CSS only Reboot, consider it noted, I wonder how useful others would find it..

Hopefully Andy could enlighten us as to how resource hungry the whole child theme setup is..

Ike said
I will certainly discuss the potential for a CSS only Reboot, consider it noted, I wonder how useful others would find it..

Thanks!

It sounds like in the mean time, if I wanted to bypass all the PHP style calls, I might as well create a custom theme instead of trying to do it with a child theme. Is that what you might siggest @ike ?

Well logically thinking, removing all the PHP from the stylesheet, replacing it with CSS and using it as a child stylesheet sounds right, but – and it’s possibly a bit of a snag – the ‘get overlay’ call is at the top of the parent stylesheet, so ideally I’d like confirmation from Andy or Steve if it would work, or if the overlay is just going to be loaded and not used.

I’d rather make sure before committing you to all that work 🙂

Thanks again… just hoping to find out A) Which method creates less overhead when loading pages, custom theme or child hacks; and B) Which will cause fewer headaches when parent theme is updated.

I will gladly wait for input from all, and am also interested to see if anyone else has thumbs up for a CCS Only Reboot.

the time to load the overlay and process it is going to be very, very small…  much less than the php that is loaded and run just to load any wp page…

but you could certainly just copy the generated css file loaded on your page (ie load the css php file directly) and stick it in a css file… 

but that is going to be a custom theme that you woldnt want overwritten on updates…

if there is no php in the main css file (ie reboot.php) in this custom theme, you can remove the overlay call…  you also need to set the file type at the top to not be php…  might be couple other…  is it worth all the work?  I would be very surprised if the loading time difference was even noticeable…

Mr Papa said

the time to load the overlay and process it is going to be very, very small… 

Understood. But we’re multiplying that by up to 100 users online at a time some evenings, all who like to open multiple tabs, loading lots of forum pages…

but you could certainly just copy the generated css file loaded on your page (ie load the css php file directly) and stick it in a css file… 

Thanks for this tip!

Not to change the subject, but look at what I get when directly loading:

../wp-content/sp-resources/forum-themes/reboot/styles/reboot.php

Warning: include(/problem-with-post-edit-buttonome/tripawds/public_html/wp-content/sp-resources/forum-themes/reboot/styles/../..//styles/overlays/.php) [function.include]: failed to open stream: No such file or directory in /problem-with-post-edit-buttonome/tripawds/public_html/wp-content/sp-resources/forum-themes/reboot/styles/reboot.php on line 25

Warning: include() [function.include]: Failed opening ‘/problem-with-post-edit-buttonome/tripawds/public_html/wp-content/sp-resources/forum-themes/reboot/styles/../..//styles/overlays/.php‘ for inclusion (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /problem-with-post-edit-buttonome/tripawds/public_html/wp-content/sp-resources/forum-themes/reboot/styles/reboot.php on line 25

It looks like there may be an extra / in there…here is reboot.php:23-25

# load the selected color overlay stylesheet

$overlay = dirname(__FILE__).’/../../‘.$_GET[‘theme’].’/styles/overlays/’.$_GET[‘overlay’].’.php’;

include($overlay);

I’m surprised my overlay is even working, but then I am using a Child theme where I have a modified overlay…

but that is going to be a custom theme that you woldnt want overwritten on updates…

So it sounds like the best way to do this, if I deem it necessary, is to create a custom CSS only version of Reboot, and not bother attempting via the Child Theme?

if there is no php in the main css file (ie reboot.php) in this custom theme, you can remove the overlay call… 

From spFunctions.php, I presume.

you also need to set the file type at the top to not be php… 

As in just remove the opening/closing <?php tags, right?

might be couple other… 

Couple other files to edit, you mean. So I just review all the files and look for any PHP I can replace with hard-coded styles? OK.

is it worth all the work? 

Exactly my question. Just tossing it out there as my mission these days is to eliminate any and all unnecessary PHP and SQL queries. SimplePress and its theme are just one front I’m attacking since that is where the vast majority of our traffic is generated.

Thanks again for all the feedback and direction!

No, I dont think there is an extra /…  what is happening is you are missing the $_GET[‘theme’] variable… in other words its blank…

are you running the latest SP?  and reboot?

perhaps go to forum – themes – theme list and try resaving your current theme selection…  pick another theme or overlay, save, then go back to what you want…

it seems perhaps your theme options record is not up to date…

Mr Papa said

are you running the latest SP?  and reboot?

Yes, and yes.

perhaps go to forum – themes – theme list and try resaving your current theme selection… 

Warnings persist at top of generated css when calling reboot.php after selecting different overlay, updating, selecting preferred overlay and saving again.

Warnings still persist, even after I select Reboot (parent) as the active theme.

FYI: I also re-saved theme and overlay for all device views, desktop, phone and tablet. Warnings are still there when viewing file:

<br />
<b>Warning</b>:  include(/problem-with-post-edit-buttonome/triblogs/public_html/wp-content/sp-resources/forum-themes/reboot/styles/../..//styles/overlays/.php) [<a href='function.include'>function.include</a>]: failed to open stream: No such file or directory in <b>/problem-with-post-edit-buttonome/triblogs/public_html/wp-content/sp-resources/forum-themes/reboot/styles/reboot.php</b> on line <b>25</b><br />
<br />
<b>Warning</b>:  include() [<a href='function.include'>function.include</a>]: Failed opening '/problem-with-post-edit-buttonome/triblogs/public_html/wp-content/sp-resources/forum-themes/reboot/styles/../..//styles/overlays/.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in <b>/problem-with-post-edit-buttonome/triblogs/public_html/wp-content/sp-resources/forum-themes/reboot/styles/reboot.php</b> on line <b>25</b><br />
/*
# --------------------------------------------------------------------------------------
#
#    Simple:Press Template Reset CSS
#    Theme        :    Unified
#    Author        :    Simple:Press
#
#    This is the reset and common class CSS file for the SP Unified theme.
#
# --------------------------------------------------------------------------------------
*/

it seems perhaps your theme options record is not up to date…

So… putting my CSS only theme project aside, how might I go about getting rid of these warnings?

we need to understand why your query argument is missing… will take a look but not sure how or why…  might need Andy to weigh in since he coded that up…

one thing… look in your db, table sfoptions, option name sp_current_theme and see what is listed there…

Mr Papa said
we need to understand why your query argument is missing…

Thanks! You can load my php stylesheet directly here, if that helps. I get no warnings on our site, and the theme seems to be functioning fine. The warnings also do not appear in the SP Error Log, only when calling the file directly.

look in your db, table sfoptions, option name sp_current_theme and see what is listed there…

sp_current_theme

a:5:{s:5:”theme”;s:9:”rebootkid”;s:5:”style”;s:13:”rebootkid.css”;s:5:”color”;s:11:”light-matte”;s:6:”parent”;s:6:”reboot”;s:5:”icons”;s:9:”lightpack”;}

sp_mobile_theme

a:9:{s:6:”active”;b:1;s:5:”theme”;s:9:”rebootkid”;s:5:”style”;s:13:”rebootkid.css”;s:5:”color”;s:11:”light-matte”;s:6:”parent”;s:6:”reboot”;s:11:”usetemplate”;b:0;s:12:”pagetemplate”;s:22:”template-fullwidth.php”;s:7:”notitle”;b:1;s:5:”icons”;s:9:”lightpack”;}

sp_tablet_theme

a:9:{s:6:”active”;b:1;s:5:”theme”;s:9:”rebootkid”;s:5:”style”;s:13:”rebootkid.css”;s:5:”color”;s:11:”light-matte”;s:6:”parent”;s:6:”reboot”;s:11:”usetemplate”;b:0;s:12:”pagetemplate”;s:22:”template-fullwidth.php”;s:7:”notitle”;b:1;s:5:”icons”;s:9:”lightpack”;}

and I assume rebootkid is the proper name of your child theme?

maybe post your child theme spTheme.txt file…

I don’t mind weighing in on the topic but I seriously question the point of what you are doing. At least – I question the way you seem to be going about it. Nor – to be totally frank – can we really support it in any sensible way.

You say you get this error when you ‘load the file directly’. I am not sure what you actually define by ‘directly’ but the bottom line is that the code is engineered to be called in a specific way with specific query arguments and you are clearly not supplying those arguments. So you either need to supply them or cut out their expectation from the themes php file.

There are much, much easier ways to generate the CSS from one of our php/overlay based themes but I also agree with Steve when he said earlier that the performance saving will be unnoticeable.

I do not know what you have done but I would suggest you start again! The first question has to be: are you unable to use the combined/compressed CSS option we offer? I do know some servers seem to disallow it although we have not yet found out why. Is yours one of them,? If not – why are you not using that?

Yellow Swordfish said
I do not know what you have done but I would suggest you start again!

I have not done anything, yet.

I originally started this topic, simply to inquire how I might go about generating a CSS Only version of Reboot to remove the PHP overlay color calls.

Steve suggested I load the reboot.php file in my web browser to generate the CSS stylesheet, that I could then use in the theme:

…you could certainly just copy the generated css file loaded on your page (ie load the css php file directly) and stick it in a css file… 

So, let’s start over indeed…

My child theme appears to be functioning fine with the provided parent’s combine/compressed CSS and my edited overlay. I do not get the errors above in the SP Toolbox or my server logs. I only noticed them when I loaded the php generated stylesheet in my browser as suggested here. Are those errors appearing in the browser when loading reboot.php in a browser then to be expected? If so, great!

Then back to my point, which is to remove the PHP overlay calls I don’t need. I only asked if that could be done via the child framework. Replies so far lend me to believe no, I would need to create a custom version of Reboot. I know there is a CSS Only version of the Default theme, so I just wanted to inquire about doing the same for Reboot.

I do understand the results may be negligible, but there must have been a need or reason to do it for the Default theme in the first place.

Hopefully this clears things up. Thank you!

That does  make more sense.  So yes – you should expect errors if you try and just run the reboot.php file in the browser.

Yes – you would need to hive off the CSS and make it into a custom theme completely. I can talk you through a method for doing that if you really need to but then there are updates….

If the combined/compressed cache is working for you then this is actually even better than anything else. It means, apart from the initial load and any subsequent resets due to changes, you are loading pure CSS nicely compressed with all the spaces etc., removed. You can’t really get better than that! And it means you can easily change it and absorb updates from us to the parent.

If you do not already use it then using the Script cache is also to be recommended as long as it causes no issues.