Theme development - CSS caching annoyance

Hi - we have been using Elgg since 1.0 and are just now upgrading our test system to 1.5. I want to apply our own theme to 1.5 (in it's own plugin of course), but it is taking me much longer than anticipated as every time I make a change to my plugins CSS file, the changes are not shown unless I disable then re-enable the plugin.

As you can imagine, this is adding a huge amount of time to the task and wondered if there was a workaround for it? I presume this is to do with some caching features that have been added to 1.5 as it was not an issue in previous versions?

Anyone else struggling with this?

  • GoDaddy !!! ahaaaa !!!

    I do not trust their server(s) - I suspect they may be proxy'ing -- which stuffs everything up 10x.

    If you have another host - try test there...

  • I use CSS development software that actually shows changes in a browser preview window as I type code... instantly... no refresh. Type a new background color (or whatever) in your CSS code and the preview window instantly updates. You don't even have to hit save. Just code away. It's amazing. And that's not even half of what this amazing software does.

    However, since ELGG has decided to use PHP-generate CSS files instead of actual CSS files (ARGH!!!)... I now have to refresh to see every change. It makes theme development a major pain in the a**. I should be able to by-pass this by hacking the header.php file... but I shouldn't have to hack core system files just to make CSS files load.

    In my opinion, using css.php files is poor practice. Keep PHP out of your CSS code and use W3C-valid CSS code that does not depend on server-side processing. It's just good practice.

  • A simple plugin will change the header so that it points to a css file.

    The advantage of using php to create the css in Elgg is that each plugin can extend the css so that you don't end up with 20 or 30 css files per page load. I believe that is the only thing the php code is used for by default. I've seen others use it to allow users to customize color schemes but there doesn't see to be much server side processing.

    The tradeoff, of course, is that it is difficult to interactively edit the css. I currently use Firebug for this when working with Elgg. A little clunky. I edit until I am happy and then move my changes to the php file.

  • Thank you so much Cash. I really appreciate your help.

    So are you referring to a specific existing plugin or suggesting I code something up simply?

    I've tried duplicating the "default" view and turning it into a plugin as a starting point. But the header.php in my plugin doesn't seem to override the default header.php. Other "page_elements" files override just fine... but not header.php. So I hacked the default header.php file to point directly to a CSS file but that breaks a few things (like the collapsible panels on the dashboard). So I'm not sure what's going on. I'm new to Elgg obviously.

    Personally, I think the plethora of CSS files and having them generated via PHP is poor practice. With good semantics and well thought out cascading... you shouldn't need a CSS file for every plugin. I've been a WordPress fan for years and it's a joy being able to change an entire site with one CSS file and a handful of templates all in one directory. Elgg is a little overwhelming at first. And it seems to me that theme development is going to be a little labor intensive. But I'm committed... because Elgg looks pretty great otherwise.

    p.s. FYI... I'm using CSSEdit on the Mac. Great development tool. You see your design change as you type CSS code without having to save or refresh.

  • I meant your own plugin. The best way to debug your issue is to use the System Diagnostics tool available under Administration. It outputs a log file that captures the state of your Elgg install - everything from php configuration to what views are registered to language strings.

    Definitely agree on better base CSS meaning less need for plugin CSS. I've brought this up on the core developers mailing list but didn't get a response from any of the Curverider developers (it was two weeks before the 1.5 release so maybe I should try again). I don't think we'll ever get away from some CSS view extending because the plugin system of Elgg is so powerful, but we should be able to get to the point where 95% of the plugins just use elements inherited from the base theme.

  • That would be nice... yes. I was rather horrified when I started trying to theme yesterday and discovered that almost every plugin had it's own "css.php" file :( If they were all actual CSS files it wouldn't be so bad because I could just click on an element in the preview window of CSSEdit and use the "inspector" to see a list of all declarations across all CSS files that are affecting that element.

    I guess the other difference with WordPress is that all of it's basic functionality is "baked in" whereas Elgg seems to use plugins for just about everything. Which is great. Very powerful as you say. But all those CSS files. Ugh. Makes things ugly for an interface guy like me.

    Thanks again for the help Cash. Ideally what I would like to do is create a theme plugin that uses logic to override all "php.css" files with "screen.css" files. I would just rename all the various "php.css" files to "screen.css". Not sure how I'd do that... so I guess the low tech solution is just to link to every individual screen.css file in the header. Ugly... inflexible... and kind of a pain to build all those links... but it'd work. I could just switch back to PHP files once the site is ready for production.