David Lewis

Send private message

You must be logged in to send a private message.

Friends

No friends yet.

Activity

  • David Lewis replied on the discussion topic Moving the Top Bar in the group Elgg Technical Support
    I've been trying to do this for months.... I know it's something so simple and stupid. How do I move the TopBar below the Header? That's it... I tried pageshell, styles.css, everything I have alot of plugins, but I wanted to see what the most...
    • Two things:

       

      1. The <div> holding the top bar is positioned absolutely
      2. It's parent is <body>
      So to put it below your header, I'd say you'd have to move the #elgg_topbar div inside the #page_wrapper div and remove it's positioning so it just becomes relatively to #page_wrapper. I don't know exactly what you're going for... and I'm not playing with the actual code myself to test anything I'm saying... but it could be as simple as reversing the order of the includes in the pageshell.php file... i.e.
      change

      <?php echo elgg_view('page_elements/header', $vars); ?> <?php echo elgg_view('page_elements/elgg_topbar', $vars); ?> <?php echo elgg_view('page_elements/header_contents', $vars); ?>

       

      to

      <?php echo elgg_view('page_elements/header', $vars); ?> <?php echo elgg_view('page_elements/header_contents', $vars); ?> <?php echo elgg_view('page_elements/elgg_topbar', $vars); ?>

       

      and removing the absolute positioning from #elgg_topbar in the main css.php file.

       

    • p.s. The WYSIWYG editor here is a little nasty... adds whitespace and empty <div>'s etc... sorry for the messy post above. I did my best.

    • sounds about right ;-)

      might want to make the header absolute while you're at it..

  • David Lewis replied on the discussion topic Moving the Top Bar in the group Elgg Technical Support
    I've been trying to do this for months.... I know it's something so simple and stupid. How do I move the TopBar below the Header? That's it... I tried pageshell, styles.css, everything I have alot of plugins, but I wanted to see what the most...
    • Two things:

       

      1. The <div> holding the top bar is positioned absolutely
      2. It's parent is <body>
      So to put it below your header, I'd say you'd have to move the #elgg_topbar div inside the #page_wrapper div and remove it's positioning so it just becomes relatively to #page_wrapper. I don't know exactly what you're going for... and I'm not playing with the actual code myself to test anything I'm saying... but it could be as simple as reversing the order of the includes in the pageshell.php file... i.e.
      change

      <?php echo elgg_view('page_elements/header', $vars); ?> <?php echo elgg_view('page_elements/elgg_topbar', $vars); ?> <?php echo elgg_view('page_elements/header_contents', $vars); ?>

       

      to

      <?php echo elgg_view('page_elements/header', $vars); ?> <?php echo elgg_view('page_elements/header_contents', $vars); ?> <?php echo elgg_view('page_elements/elgg_topbar', $vars); ?>

       

      and removing the absolute positioning from #elgg_topbar in the main css.php file.

       

    • p.s. The WYSIWYG editor here is a little nasty... adds whitespace and empty <div>'s etc... sorry for the messy post above. I did my best.

    • sounds about right ;-)

      might want to make the header absolute while you're at it..

  • David Lewis replied on the discussion topic Theme development - CSS caching annoyance in the group Theme Development
    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...
    • 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.

  • David Lewis replied on the discussion topic Theme development - CSS caching annoyance in the group Theme Development
    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...
    • 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.

  • David Lewis replied on the discussion topic Mac users: reduce image file sizes a lot, very easily in the group Theme Development
    Open a folder with some images/photos. View the folder in list mode. Open one of the images/photos up in preview. Keep the folder behind visible. Goto Tools select adjust color. Make a change, any change, small or big. I usually click auto levels....
    • Depends on what you're starting with. If you've already save web optimized images from Photoshop... they won't get any smaller by opening them in Preview and re-saving.

  • David Lewis replied on the discussion topic Theme development - CSS caching annoyance in the group Theme Development
    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...
    • 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.