Group activity

  • skotmiller replied on the discussion topic 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...
    • 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.

  • DhrupDeScoop replied on the discussion topic 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...
    • 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.

  • Deon replied on the discussion topic 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...
    • 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.

  • Steve M replied on the discussion topic 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...
    • 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.

  • Kevin Jardine replied on the discussion topic 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...
    • 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.

  • jededitor replied on the discussion topic 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...
    • 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.

  • Steve M replied on the discussion topic 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...
    • 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.

  • Steve M added a new discussion topic 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...
    • 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.

  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • jededitor replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • jededitor replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • Thomas Day replied on the discussion topic Updating a theme to v1.5
    I've heavily modified a theme to suit my purposes and somethings are as expected not falling straight into place now I've gone to v1.5   I wonder if somebody with the required knowledge might give us a guide to where the main areas of change...
    • Hi everybody,

      I tried to upgrade my green rounded based theme to 1.5, but i have some problems with the topbar : the dropdown menu Jquery works, but without css style, like a simple list. Other links (Settings, administration,...) are in the body page. How can i fix this problem? Thanks for your help. ;)

      P.S. : If you have already convert this theme, please send me it, i will be very recognizing ;)

    • @gpx18 "the dropdown menu Jquery works, but without css style"

      Have you included the new/updated css? instructions here:
      http://docs.elgg.org/wiki/Upgrading_themes

    • Hi there,

      please ignore my previous statement about a connection between caching and the Javascript problems I'd encountered. Recently we installed 1.5 on a new server and the problem reappeared. So we had to look into it again and found out that it was connected to the order of plugins in the list. Our theme was last in the list and we had to move it before embed and tinymce that we also utilise. So the disappearance of the problem on 1.5rc2 and the deletion of the cache files merely coincided. One of my colleagues had disabled the above plugins at about the same time the cache files were deleted.

      Cheers
      Jens

  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • jededitor replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • jededitor replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • DhrupDeScoop replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...
  • jededitor replied on the discussion topic Changing theme width
    Hi everyone, I posted a message in theme topic, but maybe you don't read it often, so I'll write here. My original message text is: "mmm, can anyone tell me how to make notebook theme less wide? On owner screenshots it looks ok, but on my site is...