From mevans at ecsnet.com Tue Jan 1 09:58:19 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Tue, 01 Jan 2008 08:58:19 -0600 Subject: [geeklog-devel] JavaScript Libraries Message-ID: <477A550B.5090303@ecsnet.com> Happy New Year! I wanted to get everyone's opinion and thoughts on the various JavaScript libraries that are available. There are several good libraries out there, MooTools, JQuery, Prototype, etc... One thing I've found is they don't always play nicely together. Before I get too carried away with implementing features in Media Gallery and Chameleon, I thought it might be worthwhile to discuss future directions for both Geeklog and plugins. Currently, I have one major feature in Media Gallery (Lightbox slideshow) that is using MooTools. I was playing with some JavaScript tooltips for the Forum and other areas and found a nice DHTML/JS tooltip package by Walter Zorn (wz_tooltip), but quickly discovered that it was incompatible with MooTools (breaks the Lightbox slideshow). I decided it would probably be best if I continued to use MooTools based solutions, but if Geeklog and / or other plugins are planning on adopting another library, we may have some issues. Since I only have one released feature using MooTools, changing is an option now. But I would like to implement some additional features in the next Media Gallery - Accordian Menus - JS/SWF based uploaded - Image Zoom View - Additional JS slideshows - Various image display tricks All of this can be done using MooTools, but I'm sure I could accomplish it with another library as well. Has anyone else already implemented or planning on implementing a different JS library? Pros / Cons of the various libs? I would love to see us come to an agreement on a specific toolset so we can all move in the same direction, help each other and leverage each others work. Thanks! Mark From joe at ThrowingDice.com Tue Jan 1 12:59:29 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Tue, 01 Jan 2008 12:59:29 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/sql/updates mysql_1.4.1_to_1.5.0.php, 1.37, 1.38 In-Reply-To: <20080101175156.A2E6610FE14@qs1489.pair.com> References: <20080101175156.A2E6610FE14@qs1489.pair.com> Message-ID: <0JTZ006RE8NTRD30@mta5.srv.hcvlny.cv.net> At 12:51 PM 1/1/2008, Dirk Haun wrote: >'cid' and 'pid' need to be 32 characters (for backward compatibility) > > > $P_SQL[] = "ALTER TABLE {$_TABLES['linksubmission']} ADD > owner_id mediumint(8) unsigned NOT NULL default '1' AFTER date"; > $P_SQL[] = "ALTER TABLE {$_TABLES['linksubmission']} CHANGE > category cid varchar(20) NOT NULL"; >! $P_SQL[] = "ALTER TABLE {$_TABLES['links']} CHANGE category >cid varchar(20) NOT NULL"; > $P_SQL[] = "INSERT INTO {$_TABLES['linkcategories']} (cid, > pid, category, description, tid, created, modified, group_id, > owner_id, perm_owner, perm_group, perm_members, perm_anon) " > . "VALUES ('site', 'root', 'Root', 'Website root', '', > NOW(), NOW(), 5, 2, 3, 3, 2, 2)"; >--- 366,370 ---- > $P_SQL[] = "ALTER TABLE {$_TABLES['linksubmission']} ADD > owner_id mediumint(8) unsigned NOT NULL default '1' AFTER date"; > $P_SQL[] = "ALTER TABLE {$_TABLES['linksubmission']} CHANGE > category cid varchar(20) NOT NULL"; // <<------------------------------- >! $P_SQL[] = "ALTER TABLE {$_TABLES['links']} CHANGE category >cid varchar(32) NOT NULL"; > $P_SQL[] = "INSERT INTO {$_TABLES['linkcategories']} (cid, > pid, category, description, tid, created, modified, group_id, > owner_id, perm_owner, perm_group, perm_members, perm_anon) " > . "VALUES ('site', 'root', 'Root', 'Website root', '', > NOW(), NOW(), 5, 2, 3, 3, 2, 2)"; Shouldn't the linksubmission cid also be 32? ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From dirk at haun-online.de Tue Jan 1 15:15:40 2008 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 1 Jan 2008 21:15:40 +0100 Subject: [geeklog-devel] Config GUI issues Message-ID: <20080101201540.1705656633@smtp.haun-online.de> Just a couple of issues I've run into with the config GUI (no systematic tests - just things I noticed while using it): - The entries for the menu_elements are coming out in reverse order. For example, I have 'plugins' as the last entry in the config, but plugins are listed first in the site's navigation bar. - Mail Settings[auth] is a Boolean, so this should be a dropdown. Since all the Mail Settings are in an array, this doesn't seem to be possible, though. Or am I missing something? - When setting error_reporting(E_ALL) I'm getting this: 8 - Undefined property: config::$ref @ /my/path/to/geeklog/system/ classes/config.class.php line 458 bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ From mevans at ecsnet.com Tue Jan 1 15:24:25 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Tue, 01 Jan 2008 14:24:25 -0600 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080101201540.1705656633@smtp.haun-online.de> References: <20080101201540.1705656633@smtp.haun-online.de> Message-ID: <477AA179.8020902@ecsnet.com> Please don't forget these items I reported a month or so ago: THEME -> MENU ELEMENTS This should be a drop down of allowed values. If I put 'Home' in there, nothing happens, but if I enter 'home', it will place the Home link in the menu. Since this is a static list of valid values, make it a drop down. This will cut down on support issues. TOPICS AND DAILY DIGEST -> TOPIC SORT METHOD This should also be a drop down selection. There are only 2 valid options for this field. Again, makes it more user friendly and will cut down on support issues. TOPICS AND DAILY DIGEST -> WHAT'S NEW If possible, use something besides seconds for the time entry, use minutes or hours and convert on save. Seconds are very confusing, it is difficult to know just how long is 172800 seconds. But, something like 48 hours is pretty clear. USERS AND SUBMISSIONS I don't think this is the right place to set the advanced editor options. I would create a new tab for editor specific items. Actually, I think the entire organization should probably be revisited and mapped a little differently. I understand this was the format of the config.php file, but if you are planning on improving the overall configuration, a better organization might be worth looking into. CONFIGURATION -> THEMES Why not make the Theme field a drop down, there is already a function, COM_getThemes() that returns a list of available themes. This would make it a bit more user friendly and keep someone from mis-typing a theme name. CONFIGURATION -> MISCELLANEOUS HTML Filtering: In Geeklog v1.4.1 there was an option in the config.php that defined additional HTML elements that would be merged with the 'admin_html' element if the advanced editor was enabled. I don't see these in 1.5's configuration option. I'm wondering if these should be part of the default for the Admin HTML? Finally, this one is not specific to the configuration, but it should be addressed: UTF-8 SUPPORT There is no method on installation or through configuration to make a site UTF-8. I have tried manually changing siteconfig.php but still I can't get UTF-8 support to work. Thanks! Mark Dirk Haun wrote: > Just a couple of issues I've run into with the config GUI (no systematic > tests - just things I noticed while using it): > > - The entries for the menu_elements are coming out in reverse order. For > example, I have 'plugins' as the last entry in the config, but plugins > are listed first in the site's navigation bar. > > - Mail Settings[auth] is a Boolean, so this should be a dropdown. Since > all the Mail Settings are in an array, this doesn't seem to be possible, > though. Or am I missing something? > > - When setting error_reporting(E_ALL) I'm getting this: > > 8 - Undefined property: config::$ref @ /my/path/to/geeklog/system/ > classes/config.class.php line 458 > > bye, Dirk > > > From devel at portalparts.com Wed Jan 2 08:26:08 2008 From: devel at portalparts.com (Blaine Lang) Date: Wed, 02 Jan 2008 08:26:08 -0500 Subject: [geeklog-devel] JavaScript Libraries In-Reply-To: <477A550B.5090303@ecsnet.com> References: <477A550B.5090303@ecsnet.com> Message-ID: <477B90F0.1010803@portalparts.com> I have been using the YUI library in projects for possibly 2 years since it was first released and have not been disappointed. It's continued to grow and is actively supported. It is a very rich set of components and one item in the YUI class that really has interested me for GL and theme control are the CSS/Grid/Layout/Menu classes with their graded browser support. I have also used the Walter Zorn tooltip library as it is one of the best lightweight JS libraries for this function. Some of the very best UI components are from Jack Slocum who released the EXT library just 1 year ago and has rapidly gained incredible community support and recognition. We used his first version of the GRID control based on YUI for a large project and it worked very well. Another developer had released an excellent Accordion menu/window control based on EXT but it now looks like that is being rolled into the EXT library. I expect Jack will have even more to show us in 2008. I have plans to implement more AJAX functionality to the forum plugin and will be using the YUI class for that. I've often used ny own Javascript but it's far nicer to code with the YUI library. The YUI library is setup as multiple library files and has lightweight versions if your not using the more advanced methods of any single library. Additionally, you can load versions of the compressed libraries from Yahoo's own servers to speed up browser load times. They have probably the best online documentation. I have recently used both prototype and YUI without any issues as I needed a special rating UI component but I'd vote for YUI and EXT with a few other smaller independent libraries as needed. Blaine Mark R. Evans wrote: > Happy New Year! > > I wanted to get everyone's opinion and thoughts on the various > JavaScript libraries that are available. There are several good > libraries out there, MooTools, JQuery, Prototype, etc... One thing > I've found is they don't always play nicely together. Before I get > too carried away with implementing features in Media Gallery and > Chameleon, I thought it might be worthwhile to discuss future > directions for both Geeklog and plugins. > > Currently, I have one major feature in Media Gallery (Lightbox > slideshow) that is using MooTools. I was playing with some JavaScript > tooltips for the Forum and other areas and found a nice DHTML/JS > tooltip package by Walter Zorn (wz_tooltip), but quickly discovered > that it was incompatible with MooTools (breaks the Lightbox > slideshow). I decided it would probably be best if I continued to > use MooTools based solutions, but if Geeklog and / or other plugins > are planning on adopting another library, we may have some issues. > > Since I only have one released feature using MooTools, changing is an > option now. But I would like to implement some additional features in > the next Media Gallery > > - Accordian Menus > - JS/SWF based uploaded > - Image Zoom View > - Additional JS slideshows > - Various image display tricks > > All of this can be done using MooTools, but I'm sure I could > accomplish it with another library as well. > > Has anyone else already implemented or planning on implementing a > different JS library? Pros / Cons of the various libs? > I would love to see us come to an agreement on a specific toolset so > we can all move in the same direction, help each other and leverage > each others work. > > Thanks! > Mark > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From tony at tonybibbs.com Wed Jan 2 09:20:26 2008 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 2 Jan 2008 06:20:26 -0800 (PST) Subject: [geeklog-devel] Web Services minutia (and some story stuff) Message-ID: <62604.81441.qm@web707.biz.mail.mud.yahoo.com> Why not just include an optional param in the call to get a story that lets the caller decide if the hit counter should be incremented? ----- Original Message ---- From: Dirk Haun To: geeklog-devel Sent: Friday, December 28, 2007 10:09:35 AM Subject: Re: [geeklog-devel] Web Services minutia (and some story stuff) Joe Mucchiello wrote: >So anyone writing a theme override of siteFooter probably >doesn't call it either. Hmm. So how many themes even use the COM_siteFooter override? And how many of those do count the hits? Anyone want to venture a guess? Sounds like it would be safe to call COM_hit (now that we're really using it ...) before calling a theme-provided siteFooter function. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Wed Jan 2 12:22:27 2008 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 2 Jan 2008 18:22:27 +0100 Subject: [geeklog-devel] Webservices: Logins and speedlimit Message-ID: <20080102172227.1919583801@smtp.haun-online.de> I'm struggling a bit with the logins and the speedlimit for the webservices here. Let me explain ... Every Atompub client that I've seen so far tries to do things first without logging in. So even when you give them the proper login credentials - they don't use them until the server says "Authentication required". I'm not sure where this behavior is coming from (I don't see it in the RFC), but I guess if they're all doing it, we will have to live with it. So an Atompub client does a request for, say, all the stories on the site. Let's assume I'm a (Story) Admin, using an Atompub client. I want to be able to see stories that haven't been published yet (aka drafts) or those that are only visible to certain users. But since the client will do the request without logging in first, it will only get a list of the public stories. That's not what I want and so I think we should simply require a login for any action via the webservices / Atompub. So far, so good. Now, of course, the client will send every request twice: Request list of stories, "Authentication required", send request again with login credentials. And of course those will both count against the login speedlimit. And the next request (whatever that may be - let's say to change the story) will do the same thing and again count twice. A human may already run into the speedlimit easily, but automated clients (like appfs or the APE) will certainly run into it. So it looks like our standard approach for speedlimits doesn't work here. I've come up with the following, somewhat inelegant (IMHO), solution: - An Atompub request without any login credentials will count as one failed login attempt. - An Atompub request with the wrong login credentials will count as two(!) failed login attempts. - If the login succeeds and we have only one failed attempt on record, the speedlimit is reset. This was done because: - Resetting the speedlimit after every successful login could be used for dictionary attacks (try one, login to reset, try another, ...). - Some Atompub clients (e.g. the APE), when used without any login credentials, will try over and over and over again. So those need to run into the speedlimit eventually. I don't like it too much, but it works. Anyone have a better idea? bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From tony at tonybibbs.com Wed Jan 2 13:29:27 2008 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 2 Jan 2008 10:29:27 -0800 (PST) Subject: [geeklog-devel] Webservices: Logins and speedlimit Message-ID: <242898.63017.qm@web707.biz.mail.mud.yahoo.com> Did you already add a security group for Atompub? My assumption is that the Web Service implementation isn't meant for non-admins. If that is right the admins will need the admin privilege they need (link, story, etc) and be given explicit privilege to use the Atom client. I like this because a) nobody can really use the Atompub without explicit approval which, to me, seems acceptable and b) if you have this privilege you can have a separate speed limit. --Tony ----- Original Message ---- From: Dirk Haun To: geeklog-devel Sent: Wednesday, January 2, 2008 11:22:27 AM Subject: [geeklog-devel] Webservices: Logins and speedlimit I'm struggling a bit with the logins and the speedlimit for the webservices here. Let me explain ... Every Atompub client that I've seen so far tries to do things first without logging in. So even when you give them the proper login credentials - they don't use them until the server says "Authentication required". I'm not sure where this behavior is coming from (I don't see it in the RFC), but I guess if they're all doing it, we will have to live with it. So an Atompub client does a request for, say, all the stories on the site. Let's assume I'm a (Story) Admin, using an Atompub client. I want to be able to see stories that haven't been published yet (aka drafts) or those that are only visible to certain users. But since the client will do the request without logging in first, it will only get a list of the public stories. That's not what I want and so I think we should simply require a login for any action via the webservices / Atompub. So far, so good. Now, of course, the client will send every request twice: Request list of stories, "Authentication required", send request again with login credentials. And of course those will both count against the login speedlimit. And the next request (whatever that may be - let's say to change the story) will do the same thing and again count twice. A human may already run into the speedlimit easily, but automated clients (like appfs or the APE) will certainly run into it. So it looks like our standard approach for speedlimits doesn't work here. I've come up with the following, somewhat inelegant (IMHO), solution: - An Atompub request without any login credentials will count as one failed login attempt. - An Atompub request with the wrong login credentials will count as two(!) failed login attempts. - If the login succeeds and we have only one failed attempt on record, the speedlimit is reset. This was done because: - Resetting the speedlimit after every successful login could be used for dictionary attacks (try one, login to reset, try another, ...). - Some Atompub clients (e.g. the APE), when used without any login credentials, will try over and over and over again. So those need to run into the speedlimit eventually. I don't like it too much, but it works. Anyone have a better idea? bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From dirk at haun-online.de Wed Jan 2 13:43:41 2008 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 2 Jan 2008 19:43:41 +0100 Subject: [geeklog-devel] Webservices: Logins and speedlimit In-Reply-To: <242898.63017.qm@web707.biz.mail.mud.yahoo.com> References: <242898.63017.qm@web707.biz.mail.mud.yahoo.com> Message-ID: <20080102184341.391684537@smtp.haun-online.de> Tony Bibbs wrote: >Did you already add a security group for Atompub? My assumption is that >the Web Service implementation isn't meant for non-admins. It's not there yet, but eventually I would like to allow submissions via Atompub. Ramnath even had comments mostly working at one point (but we decided to scrape that and finish the stories and the plugin API first). So generally speaking, I don't think it should be restricted to Admins. It's probably something some people would want to do, though. I'll check to see if that can be made an option. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From dirk at haun-online.de Thu Jan 3 17:11:36 2008 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 3 Jan 2008 23:11:36 +0100 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080101201540.1705656633@smtp.haun-online.de> References: <20080101201540.1705656633@smtp.haun-online.de> Message-ID: <20080103221136.1705296133@smtp.haun-online.de> Dirk Haun wrote: >- The entries for the menu_elements are coming out in reverse order. For >example, I have 'plugins' as the last entry in the config, but plugins >are listed first in the site's navigation bar. Apologies - this is not an issue with the config GUI. It's an issue with the stylesheet. I was just making a theme where I wanted the menu elements left-aligned, so I changed .header-navigation-container li{ float:right; to .header-navigation-container li{ float:left; and then they're in the correct order. Can one of our resident CSS gurus suggest a way to get the menu elements right-aligned and in the correct order? bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From geiss at midnightforce.com Thu Jan 3 19:26:21 2008 From: geiss at midnightforce.com (=MF=Geiss) Date: Thu, 03 Jan 2008 17:26:21 -0700 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080103221136.1705296133@smtp.haun-online.de> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> Message-ID: <477D7D2D.6030307@midnightforce.com> I'm sure most of you already know this, but for those subscribing to the list that might not be aware... Since the styling is applied to the generated markup, I'm not sure there is a way using the float property for both instances. The PHP spits out the list as Item1, Item2, Item3, etc... As the browser parses the code, it will take the first "Item1" and push it either left or right, then follow it with "Item 2". So the list floated left would look like: Item1 Item2 Item3 ... and the list floated right would look like: ... Item3 Item2 Item1 The only way I can think of is to reverse the order in PHP, and include a left or right alignment radio button, dropdown, etc., and in the PHP switch the list order output accordingly, or give each menu item a position variable (perhaps like the block up/down image links) to make for easy sorting via clicking to move a link up or down. If you are going to go that far, you might as well include support for dropdown (parent/child) menu creation. Mark and I are working on this for the Chameleon plugin, and I don't see any reason why we can't standardize on a common function. (Chameleon really is about skinning the menu anyway...) but since there is a feature freeze, I'm not sure you want to go down that route. I know there is Blaine's premium glMenu plugin, and while we aren't trying to step on any toes, we do feel that a free multi-level menu solution for gl is badly needed. ...just my 2 cents. :-) Hope this helps! Eric Dirk Haun wrote: > Dirk Haun wrote: > > >> - The entries for the menu_elements are coming out in reverse order. For >> example, I have 'plugins' as the last entry in the config, but plugins >> are listed first in the site's navigation bar. >> > > Apologies - this is not an issue with the config GUI. It's an issue with > the stylesheet. > > I was just making a theme where I wanted the menu elements left-aligned, > so I changed > > .header-navigation-container li{ > float:right; > > to > > .header-navigation-container li{ > float:left; > > and then they're in the correct order. > > Can one of our resident CSS gurus suggest a way to get the menu elements > right-aligned and in the correct order? > > bye, Dirk > > > From devel at portalparts.com Thu Jan 3 19:57:51 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 19:57:51 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477D7D2D.6030307@midnightforce.com> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> <477D7D2D.6030307@midnightforce.com> Message-ID: <477D848F.4030603@portalparts.com> Eric, Not sure if you have tried the latest CVS (since this weekends updates) but I have implemented a new CSS menu like the one being used on my site for the header. The glMenu plugin can create these menu's dynamically but there is much more to glMenu then just the CSS (which is one mode it supports). The new online config manager in 1.5 will create the menu on the fly as needed and I think the new dropline CSS menu works well. The new version is better then the navbar used initially which was fine for the base devel release. Dirk: where you after having the top level menu elements align to the right or the dropline elements or both? It's possible to do both but will require a few CSS changes - let me know which or both you were looking for and I can create a version. Blaine =MF=Geiss wrote: > I'm sure most of you already know this, but for those subscribing to > the list that might not be aware... > > Since the styling is applied to the generated markup, I'm not sure > there is a way using the float property for both instances. The PHP > spits out the list as Item1, Item2, Item3, etc... As the browser > parses the code, it will take the first "Item1" and push it either > left or right, then follow it with "Item 2". So the list floated left > would look like: > > Item1 Item2 Item3 ... > > and the list floated right would look like: > > ... Item3 Item2 Item1 > > The only way I can think of is to reverse the order in PHP, and > include a left or right alignment radio button, dropdown, etc., and in > the PHP switch the list order output accordingly, or give each menu > item a position variable (perhaps like the block up/down image links) > to make for easy sorting via clicking to move a link up or down. > > If you are going to go that far, you might as well include support for > dropdown (parent/child) menu creation. Mark and I are working on this > for the Chameleon plugin, and I don't see any reason why we can't > standardize on a common function. (Chameleon really is about skinning > the menu anyway...) but since there is a feature freeze, I'm not sure > you want to go down that route. I know there is Blaine's premium > glMenu plugin, and while we aren't trying to step on any toes, we do > feel that a free multi-level menu solution for gl is badly needed. > ...just my 2 cents. :-) > > Hope this helps! > > Eric > > Dirk Haun wrote: >> Dirk Haun wrote: >> >> >>> - The entries for the menu_elements are coming out in reverse order. >>> For >>> example, I have 'plugins' as the last entry in the config, but plugins >>> are listed first in the site's navigation bar. >>> >> >> Apologies - this is not an issue with the config GUI. It's an issue with >> the stylesheet. >> >> I was just making a theme where I wanted the menu elements left-aligned, >> so I changed >> >> .header-navigation-container li{ >> float:right; >> >> to >> >> .header-navigation-container li{ >> float:left; >> >> and then they're in the correct order. >> >> Can one of our resident CSS gurus suggest a way to get the menu elements >> right-aligned and in the correct order? >> >> bye, Dirk >> >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From ajdeeley at telus.net Thu Jan 3 19:43:44 2008 From: ajdeeley at telus.net (Alford Deeley) Date: Thu, 03 Jan 2008 16:43:44 -0800 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477D7D2D.6030307@midnightforce.com> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> <477D7D2D.6030307@midnightforce.com> Message-ID: <477D8140.1050400@telus.net> have you tried floating the list right while floating the items left? works for me. alf on 03/01/2008 4:26 PM =MF=Geiss wrote: > I'm sure most of you already know this, but for those subscribing to > the list that might not be aware... > > Since the styling is applied to the generated markup, I'm not sure > there is a way using the float property for both instances. The PHP > spits out the list as Item1, Item2, Item3, etc... As the browser > parses the code, it will take the first "Item1" and push it either > left or right, then follow it with "Item 2". So the list floated left > would look like: > > Item1 Item2 Item3 ... > > and the list floated right would look like: > > ... Item3 Item2 Item1 > > The only way I can think of is to reverse the order in PHP, and > include a left or right alignment radio button, dropdown, etc., and in > the PHP switch the list order output accordingly, or give each menu > item a position variable (perhaps like the block up/down image links) > to make for easy sorting via clicking to move a link up or down. > > If you are going to go that far, you might as well include support for > dropdown (parent/child) menu creation. Mark and I are working on this > for the Chameleon plugin, and I don't see any reason why we can't > standardize on a common function. (Chameleon really is about skinning > the menu anyway...) but since there is a feature freeze, I'm not sure > you want to go down that route. I know there is Blaine's premium > glMenu plugin, and while we aren't trying to step on any toes, we do > feel that a free multi-level menu solution for gl is badly needed. > ...just my 2 cents. :-) > > Hope this helps! > > Eric > > Dirk Haun wrote: >> Dirk Haun wrote: >> >> >>> - The entries for the menu_elements are coming out in reverse order. >>> For >>> example, I have 'plugins' as the last entry in the config, but plugins >>> are listed first in the site's navigation bar. >>> >> >> Apologies - this is not an issue with the config GUI. It's an issue with >> the stylesheet. >> >> I was just making a theme where I wanted the menu elements left-aligned, >> so I changed >> >> .header-navigation-container li{ >> float:right; >> >> to >> >> .header-navigation-container li{ >> float:left; >> >> and then they're in the correct order. >> >> Can one of our resident CSS gurus suggest a way to get the menu elements >> right-aligned and in the correct order? >> >> bye, Dirk >> >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > From devel at portalparts.com Thu Jan 3 21:52:03 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 21:52:03 -0500 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager Message-ID: <477D9F53.7040903@portalparts.com> With GL 1.5 and the online config manager, plugins that want to use it have to do things a bit different and I've re-worked the staticpages plugin installation and upgrade code to support loading the online configuration. What's needed now is peer review to see if this is the best way as it would likely be copied into other plugins. A few notes about the changes: - Need to have an upgrade function that will create the online config records and use the existing plugins config.php settings as defaults - Once upgraded to 1.5, we don't want to load the settings from the config.php. It really is not needed once upgraded or if a fresh install performed - If upgrade is executed, the config.php file is renamed - Added some new language defines for extra upgrade error messages and online config manager menu labels - Install script does not include the config.php now - Added a new file - install_defaults.php, so that initial defaults for online config records can be defined and not in the install code - Added a new function in the install.php -> plugin_load_configuration() Blaine From devel at portalparts.com Thu Jan 3 22:29:38 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 22:29:38 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080103221136.1705296133@smtp.haun-online.de> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> Message-ID: <477DA822.2070301@portalparts.com> Dirk Haun wrote: > Apologies - this is not an issue with the config GUI. It's an issue with the stylesheet. When you mentioned the config GUI, I initially thought the issue you were describing was related to the online config manager menu. I've updated the CSS now to retain the menu item order. I floated the UL element right and made the LI items float left. It appears to work now as expected in IE and FF. Blaine > Dirk Haun wrote: > > >> - The entries for the menu_elements are coming out in reverse order. For >> example, I have 'plugins' as the last entry in the config, but plugins >> are listed first in the site's navigation bar. >> > > > > I was just making a theme where I wanted the menu elements left-aligned, > so I changed > > .header-navigation-container li{ > float:right; > > to > > .header-navigation-container li{ > float:left; > > and then they're in the correct order. > > Can one of our resident CSS gurus suggest a way to get the menu elements > right-aligned and in the correct order? > > bye, Dirk > > > From devel at portalparts.com Thu Jan 3 23:11:14 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 23:11:14 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477AA179.8020902@ecsnet.com> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> Message-ID: <477DB1E2.3030904@portalparts.com> Mark R. Evans wrote: > THEME -> MENU ELEMENTS > This should be a drop down of allowed values. If I put 'Home' in > there, nothing happens, but if I enter 'home', it will place the Home > link in the menu. Since this is a static list of valid values, make it > a drop down. This will cut down on support issues. > > TOPICS AND DAILY DIGEST -> TOPIC SORT METHOD > This should also be a drop down selection. There are only 2 valid > options for this field. Again, makes it more user friendly and will > cut down on support issues. Agree this would be better and will look at extending the UI Javascript methods to add a select type element for the 'Add Element' feature. This may have to wait to see if we move the config manager to use AJAX as now the DHTML has to be more generic. The 'Add Element' is a generic UI JS function and this would require it be unique to add a select that has a unique set of options. Easy to do with AJAX but not sure I want to break the UI code now to add this feature. > > TOPICS AND DAILY DIGEST -> WHAT'S NEW > If possible, use something besides seconds for the time entry, use > minutes or hours and convert on save. Seconds are very confusing, it > is difficult to know just how long is 172800 seconds. But, something > like 48 hours is pretty clear. I think the change would need to be made to the COM_whatsNewBlock as we have no specialized handlers in the config class. We can certainly make the setting be hours and change the COM function - Dirk? > > > USERS AND SUBMISSIONS > I don't think this is the right place to set the advanced editor > options. I would create a new tab for editor specific items. I would prefer we not create any more tabs as the core->menu was already longer then I wanted. We need to ensure the menu does not wrap on narrower browsers. Using the dropline menu has regained space but if we do any more significant restructuring it would be something considering. This option effects more then just the editor so it may be better placed on the Site Tab - thats easy to do. > > Actually, I think the entire organization should probably be revisited > and mapped a little differently. I understand this was the format of > the config.php file, but if you are planning on improving the overall > configuration, a better organization might be worth looking into. I've looked at the organization a few times while trying to see if I could eliminate one of the tabbed sections to reduce the size of the Core->submenu and it may be just that I've been using GL too long and it's the config optons are too familiar now to me but I am not seeing any clear restructuring. I think it's actually far easier to find a setting now then it ever was in the config.php > > CONFIGURATION -> THEMES > Why not make the Theme field a drop down, there is already a function, > COM_getThemes() that returns a list of available themes. This would > make it a bit more user friendly and keep someone from mis-typing a > theme name. Possible but would require extending the class or adding a new config value type. Worth considering if there are more config settings to use that feature. Blaine From geiss at midnightforce.com Thu Jan 3 23:34:47 2008 From: geiss at midnightforce.com (=MF=Geiss) Date: Thu, 03 Jan 2008 21:34:47 -0700 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477DA822.2070301@portalparts.com> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> <477DA822.2070301@portalparts.com> Message-ID: <477DB767.1070307@midnightforce.com> Initially, I thought Dirk was referring to the header's top menu, by his use of "menu_elements". But now, referring specifically to the Config Menu, Blaine yes, I prefer the dropline menu over the old tab menu. Alford, thanks for sharing that insight into CSS, I hadn't thought of that for lists. :-) While we are discussing menus in general, specifically site header menus, please take a look at http://geiss.getmyip.com/gl15x and click on the Advanced Search button to see a triple level very clean menu. Blaine, this may just be my preference, but I like this one over the one at Portal Parts because visually, its cleaner, and you don't have to use additional tags, just a pure UL, with a class for parent links. It is based on this article: http://www.htmldog.com/articles/suckerfish/dropdowns/. I know that most of this is personal taste though, so YMMV. :-) Thx! Eric Blaine Lang wrote: > Dirk Haun wrote: > > Apologies - this is not an issue with the config GUI. It's an issue > with the stylesheet. > > When you mentioned the config GUI, I initially thought the issue you > were describing was related to the online config manager menu. I've > updated the CSS now to retain the menu item order. I floated the UL > element right and made the LI items float left. It appears to work now > as expected in IE and FF. > > Blaine >> Dirk Haun wrote: >> >> >>> - The entries for the menu_elements are coming out in reverse order. >>> For >>> example, I have 'plugins' as the last entry in the config, but plugins >>> are listed first in the site's navigation bar. >>> >> >> >> >> I was just making a theme where I wanted the menu elements left-aligned, >> so I changed >> >> .header-navigation-container li{ >> float:right; >> >> to >> >> .header-navigation-container li{ >> float:left; >> >> and then they're in the correct order. >> >> Can one of our resident CSS gurus suggest a way to get the menu elements >> right-aligned and in the correct order? >> >> bye, Dirk >> >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From devel at portalparts.com Thu Jan 3 23:42:40 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 23:42:40 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477DB767.1070307@midnightforce.com> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> <477DA822.2070301@portalparts.com> <477DB767.1070307@midnightforce.com> Message-ID: <477DB940.1050306@portalparts.com> =MF=Geiss wrote: > While we are discussing menus in general, specifically site header menus, please take a look at http://geiss.getmyip.com/gl15x and click on the Advanced Search button to see a triple level very clean menu. Blaine, this may just be my preference, but I like this one over the one at Portal Parts because visually, its cleaner, and you don't have to use additional tags, just a pure UL, with a class for parent links. Your site menu requires javascript vs pure CSS that my site header and the online config manager are using. JS will certainly allow more control and jazz. I've investigated 100's of different menu's as part of my glMenu project and there are always great new ideas - it's and endless search :) The most flexible JS menu is still Milionic albeit not really free. For pure CSS based menu's I've not really seen better then on Stuart's cssplay site - he's a CSS menu guru. http://www.cssplay.co.uk/menus/ Blaine > Initially, I thought Dirk was referring to the header's top menu, by > his use of "menu_elements". But now, referring specifically to the > Config Menu, Blaine yes, I prefer the dropline menu over the old tab > menu. > > Alford, thanks for sharing that insight into CSS, I hadn't thought of > that for lists. :-) > > It is based on this article: > http://www.htmldog.com/articles/suckerfish/dropdowns/. I know that > most of this is personal taste though, so YMMV. :-) > > Thx! > > Eric > > Blaine Lang wrote: >> Dirk Haun wrote: >> > Apologies - this is not an issue with the config GUI. It's an issue >> with the stylesheet. >> >> When you mentioned the config GUI, I initially thought the issue you >> were describing was related to the online config manager menu. I've >> updated the CSS now to retain the menu item order. I floated the UL >> element right and made the LI items float left. It appears to work >> now as expected in IE and FF. >> >> Blaine >>> Dirk Haun wrote: >>> >>> >>>> - The entries for the menu_elements are coming out in reverse >>>> order. For >>>> example, I have 'plugins' as the last entry in the config, but plugins >>>> are listed first in the site's navigation bar. >>>> >>> >>> >>> >>> I was just making a theme where I wanted the menu elements >>> left-aligned, >>> so I changed >>> >>> .header-navigation-container li{ >>> float:right; >>> >>> to >>> >>> .header-navigation-container li{ >>> float:left; >>> >>> and then they're in the correct order. >>> >>> Can one of our resident CSS gurus suggest a way to get the menu >>> elements >>> right-aligned and in the correct order? >>> >>> bye, Dirk >>> >>> >>> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://eight.pairlist.net/mailman/listinfo/geeklog-devel >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From devel at portalparts.com Thu Jan 3 23:52:36 2008 From: devel at portalparts.com (Blaine Lang) Date: Thu, 03 Jan 2008 23:52:36 -0500 Subject: [geeklog-devel] lib-layout.php Message-ID: <477DBB94.6000000@portalparts.com> I was looking at how we could make it easier to create theme specific siteHeader and siteFooter functions - specifically with Chameleon but I've also had to create theme specific functions in the past. It's not hard - copy/paste and modify but 90% of the code or more is the same as in the lib-common functions and these functions evolve every release. Chameleon has moved some of the code from COM_siteHeader into COM_siteFooter (theme versions) but still it's mostly restructuring of code chunks. I was thinking that it may be a good idea to create a set of functions which take the &$template variable which would be called by the header and footer related functions. This way the code to set the siteheader menu could be called in the header or footer function, same for the code to generate the left or right blocks etc. Reason to consider this now is for easier ongoing support of custom themes. Is this a new feature or a change (not sure) Is it worth doing as part of 1.5 - thats the ? Blaine From joe at ThrowingDice.com Thu Jan 3 23:39:36 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Thu, 03 Jan 2008 23:39:36 -0500 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager In-Reply-To: <477D9F53.7040903@portalparts.com> References: <477D9F53.7040903@portalparts.com> Message-ID: <0JU300CMSSS1ZYZ0@mta4.srv.hcvlny.cv.net> site_enabled still needs to be removed from the list of configuration options since once you set it to false, you can't login to reset it. Moving it to db_config is the least painful option. At 09:52 PM 1/3/2008, Blaine Lang wrote: >With GL 1.5 and the online config manager, plugins that want to use >it have to do things a bit different and I've re-worked the >staticpages plugin installation and upgrade code to support loading >the online configuration. What's needed now is peer review to see if >this is the best way as it would likely be copied into other plugins. Peer review now is a bit late in the game. Where was the design document's peer review? I have a related question. Where do the configuration pages for the plugins reside? I can imagine the configuration tab being extremely confusing if it is a mixture of core tabs and plugin tabs. Especially if complicated plugins need 4-5 tabs themselves. I'm not sure the config class should be written as a singleton. There should be a core config object and each plugin should create its own. That way when you go the staticpages admin page, one of the top menu items would "configure". I also notice you have to be in 'root' use the config gui. That makes sense for options in the old config.php but by moving the configuration to a GUI, it should be more flexible. At 11:11 PM 1/3/2008, Blaine Lang wrote: >I think the change would need to be made to the COM_whatsNewBlock as >we have no specialized handlers in the config class. This is a huge design flaw. There's also no validation code. Suppose I have a field that can be between 1 and 100. My only choice is to make a ridiculous dropdown box. Or go with a number field and handle out of bounds values "gracefully". At a minimum, the "selectarray" field should be able to handle other simple validations: if type = number, selectarray contains a two-element array of lower and upper bounds (or is empty if all values are allowed). Special handlers would work if the class was a real class and each plugin could subclass it for maximum effect. Maybe the config manager isn't ready for 1.5. It still needs a lot of testing. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From joe at ThrowingDice.com Fri Jan 4 00:22:30 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 04 Jan 2008 00:22:30 -0500 Subject: [geeklog-devel] lib-layout.php In-Reply-To: <477DBB94.6000000@portalparts.com> References: <477DBB94.6000000@portalparts.com> Message-ID: <0JU300ALOTMEOD31@mta4.srv.hcvlny.cv.net> At 11:52 PM 1/3/2008, Blaine Lang wrote: >Is this a new feature or a change (not sure) I'd like to see a lot of internal functions made extendable. Anything that would reduce the necessity for patches would be great. If I can go way out there, how about a function database table. gl_function (function_id, override_name, override_owner)? There'd be a global array: $_FUNCTIONS = array($function_id => $override_name, ....) which would be loaded in lib-common.php. Then all the overridable functions would start: function COM_whatever(...) { global $_FUNCTIONS; if (array_key_exists($_FUNCTIONS['whatever']) && is_callable($_FUNCTIONS['whatever'])) { return call_user_func_array($_FUNCTIONS['whatever'], func_get_args()); } // rest of function } In theory the only overhead is the call to array_key_exists() when the function has not be overridden. This would be a lot simpler than the CUSTOM_ stuff all over the code. >Is it worth doing as part of 1.5 - thats the ? No. Add the template caching library which is working, debugged and has no real downsides before **__STARTING__** an overhaul of COM_siteHeader/Footer. Geez, I just notice the title was lib-layout.php. Heck, why not call it layout.class.php and do it right? ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From mevans at ecsnet.com Fri Jan 4 00:28:17 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Thu, 03 Jan 2008 23:28:17 -0600 Subject: [geeklog-devel] lib-layout.php In-Reply-To: <477DBB94.6000000@portalparts.com> References: <477DBB94.6000000@portalparts.com> Message-ID: <477DC3F1.8090804@ecsnet.com> If you look at what Chameleon does, it actually duplicates 99% of the code in COM_siteHeader() and COM_siteFooter(). The 1% I left out was the logic on whether the left / right blocks are built in the header / footer. We had to add a lot of code to do things the new CSS based way as well. Chameleon renders the full page in COM_siteFooter() which is very different from how the stock functions work. Originally, all I had COM_siteHeader() do was set the global variables for the parameters passed. It wasn't until I realized that some plugins don't buffer the COM_siteHeader() call or their output that I created a new template, htmlheader.thtml and now send the HTML headers in COM_siteHeader(). The rest of the heavy lifting is all done in COM_siteFooter(). The #1 goal of this approach is to render the content first, then the left / right if enabled. Unless I'm missing something, the only way to do it as Geeklog is currently designed is to do it in the COM_siteFooter() call, along with a little PHP magic to force the buffering of plugins / Geeklog's content. From the perspective of the Chameleon approach, adding a set of functions with the template handle as a parameter won't give me the control I need to accomplish what we're doing. I can certainly see some value for themes that continue to use the table based structure. It would add the ability to easily add or modify certain aspects of the templates. Personally, I would just remove COM_siteHeader() / COM_siteFooter() completely from lib-common.php and put it in the themes functions.php. Generally the first step in creating a new Geeklog theme is to copy Professional over and start hacking. I don't see the functions.php as any different than a specific template file. This would give each theme full control over the functions without having any duplicate or unnecessary code sitting around. Obviously this would have to be a staged approach. Maybe in v1.5 you have if (!function_exists('COM_siteHeader')) ... so it is duplicated in both places (lib-common and function.php), but it gives a safety net for folks with custom themes to just make the necessary template changes after upgrading. Then in 1.5.1 or 1.6 or whatever is the next major release, they come out of lib-common.php completely. If they stay in lib-common and are enhanced by new functions in lib-layout.php, I would ask that the ability to override by the theme not be removed. Thanks! Mark Blaine Lang wrote: > I was looking at how we could make it easier to create theme specific > siteHeader and siteFooter functions - specifically with Chameleon but > I've also had to create theme specific functions in the past. It's not > hard - copy/paste and modify but 90% of the code or more is the same > as in the lib-common functions and these functions evolve every > release. Chameleon has moved some of the code from COM_siteHeader into > COM_siteFooter (theme versions) but still it's mostly restructuring of > code chunks. > > I was thinking that it may be a good idea to create a set of functions > which take the &$template variable which would be called by the header > and footer related functions. This way the code to set the siteheader > menu could be called in the header or footer function, same for the > code to generate the left or right blocks etc. > > Reason to consider this now is for easier ongoing support of custom > themes. > > Is this a new feature or a change (not sure) > > Is it worth doing as part of 1.5 - thats the ? > > Blaine > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > From blanks at mit.edu Fri Jan 4 00:33:40 2008 From: blanks at mit.edu (Aaron Blankstein) Date: Fri, 4 Jan 2008 00:33:40 -0500 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager In-Reply-To: <0JU300CMSSS1ZYZ0@mta4.srv.hcvlny.cv.net> References: <477D9F53.7040903@portalparts.com> <0JU300CMSSS1ZYZ0@mta4.srv.hcvlny.cv.net> Message-ID: <2a1a3bb50801032133q53a337ep501e9f8fcfe5aa45@mail.gmail.com> On Jan 3, 2008 11:39 PM, Joe Mucchiello wrote: > site_enabled still needs to be removed from the list of configuration > options since once you set it to false, you can't login to reset it. > Moving it to db_config is the least painful option. > > At 09:52 PM 1/3/2008, Blaine Lang wrote: > >With GL 1.5 and the online config manager, plugins that want to use > >it have to do things a bit different and I've re-worked the > >staticpages plugin installation and upgrade code to support loading > >the online configuration. What's needed now is peer review to see if > >this is the best way as it would likely be copied into other plugins. > > Peer review now is a bit late in the game. Where was the design > document's peer review? > > I have a related question. Where do the configuration pages for the > plugins reside? I can imagine the configuration tab being extremely > confusing if it is a mixture of core tabs and plugin tabs. Especially > if complicated plugins need 4-5 tabs themselves. A complicated plugin with 4 or 5 of it's own tabs will be only one tab in the top level, that's why a two-tier menu is being used. > I'm not sure the > config class should be written as a singleton. There should be a core > config object and each plugin should create its own. That way when > you go the staticpages admin page, one of the top menu items would > "configure". > The situation you describe does not require an object for each class. The class being a singleton prevents over querying the database which I think is a beneficial quality. I also notice you have to be in 'root' use the config gui. That makes > sense for options in the old config.php but by moving the > configuration to a GUI, it should be more flexible. > I agree. > At 11:11 PM 1/3/2008, Blaine Lang wrote: > >I think the change would need to be made to the COM_whatsNewBlock as > >we have no specialized handlers in the config class. > > This is a huge design flaw. There's also no validation code. Suppose > I have a field that can be between 1 and 100. My only choice is to > make a ridiculous dropdown box. Or go with a number field and handle > out of bounds values "gracefully". At a minimum, the "selectarray" > field should be able to handle other simple validations: if type = > number, selectarray contains a two-element array of lower and upper > bounds (or is empty if all values are allowed). > > Special handlers would work if the class was a real class and each > plugin could subclass it for maximum effect. PHP4 and PHP5 simultaneous compatibility makes using subclasses extremely difficult here. -- Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From geiss at midnightforce.com Fri Jan 4 00:36:01 2008 From: geiss at midnightforce.com (=MF=Geiss) Date: Thu, 03 Jan 2008 22:36:01 -0700 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477DB940.1050306@portalparts.com> References: <20080101201540.1705656633@smtp.haun-online.de> <20080103221136.1705296133@smtp.haun-online.de> <477DA822.2070301@portalparts.com> <477DB767.1070307@midnightforce.com> <477DB940.1050306@portalparts.com> Message-ID: <477DC5C1.9080301@midnightforce.com> That's misleading. The core menu requires JS only in the instance the browser is IE6 or below. The animated slideout JS is just additional candy. The core JS is only 15 lines, vs. a whole slew of conditional comments in the markup, not to mention a larger css file if IRC. I might be wrong though there, I can't remember. Still, I think it boils down to personal preference. I've spent a lot of time at Stu's site as well. :-) I'm not knocking it, just not the solution in that instance that I would embrace. :-) Eric Blaine Lang wrote: > =MF=Geiss wrote: > > While we are discussing menus in general, specifically site header > menus, please take a look at http://geiss.getmyip.com/gl15x and click > on the Advanced Search button to see a triple level very clean menu. > Blaine, this may just be my preference, but I like this one over the > one at Portal Parts because visually, its cleaner, and you don't have > to use additional tags, just a pure UL, with a class for parent > links. > > Your site menu requires javascript vs pure CSS that my site header and > the online config manager are using. JS will certainly allow more > control and jazz. I've investigated 100's of different menu's as part > of my glMenu project and there are always great new ideas - it's and > endless search :) The most flexible JS menu is still Milionic albeit > not really free. For pure CSS based menu's I've not really seen better > then on Stuart's cssplay site - he's a CSS menu guru. > > http://www.cssplay.co.uk/menus/ > > Blaine > >> Initially, I thought Dirk was referring to the header's top menu, by >> his use of "menu_elements". But now, referring specifically to the >> Config Menu, Blaine yes, I prefer the dropline menu over the old tab >> menu. >> >> Alford, thanks for sharing that insight into CSS, I hadn't thought of >> that for lists. :-) >> >> It is based on this article: >> http://www.htmldog.com/articles/suckerfish/dropdowns/. I know that >> most of this is personal taste though, so YMMV. :-) >> >> Thx! >> >> Eric >> >> Blaine Lang wrote: >>> Dirk Haun wrote: >>> > Apologies - this is not an issue with the config GUI. It's an >>> issue with the stylesheet. >>> >>> When you mentioned the config GUI, I initially thought the issue you >>> were describing was related to the online config manager menu. I've >>> updated the CSS now to retain the menu item order. I floated the UL >>> element right and made the LI items float left. It appears to work >>> now as expected in IE and FF. >>> >>> Blaine >>>> Dirk Haun wrote: >>>> >>>> >>>>> - The entries for the menu_elements are coming out in reverse >>>>> order. For >>>>> example, I have 'plugins' as the last entry in the config, but >>>>> plugins >>>>> are listed first in the site's navigation bar. >>>>> >>>> >>>> >>>> >>>> I was just making a theme where I wanted the menu elements >>>> left-aligned, >>>> so I changed >>>> >>>> .header-navigation-container li{ >>>> float:right; >>>> >>>> to >>>> >>>> .header-navigation-container li{ >>>> float:left; >>>> >>>> and then they're in the correct order. >>>> >>>> Can one of our resident CSS gurus suggest a way to get the menu >>>> elements >>>> right-aligned and in the correct order? >>>> >>>> bye, Dirk >>>> >>>> >>>> >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel >>> >>> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://eight.pairlist.net/mailman/listinfo/geeklog-devel >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From joe at ThrowingDice.com Fri Jan 4 00:41:04 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 04 Jan 2008 00:41:04 -0500 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager In-Reply-To: <2a1a3bb50801032133q53a337ep501e9f8fcfe5aa45@mail.gmail.com> References: <477D9F53.7040903@portalparts.com> <0JU300CMSSS1ZYZ0@mta4.srv.hcvlny.cv.net> <2a1a3bb50801032133q53a337ep501e9f8fcfe5aa45@mail.gmail.com> Message-ID: <0JU300EEDUHEAPX0@mta5.srv.hcvlny.cv.net> At 12:33 AM 1/4/2008, Aaron Blankstein wrote: >I'm not sure the >config class should be written as a singleton. There should be a core >config object and each plugin should create its own. That way when >you go the staticpages admin page, one of the top menu items would >"configure". > > >The situation you describe does not require an object for each >class. The class being a singleton prevents >over querying the database which I think is a beneficial quality. I don't think 1 additional query per plugin is overquerying the database. An object for each plugin would allow plugins with odd data requirements to properly validate their configuration data. That is far more valuable than saving a small number of db queries. >Special handlers would work if the class was a real class and each >plugin could subclass it for maximum effect. > > >PHP4 and PHP5 simultaneous compatibility makes using subclasses >extremely difficult here. At this rate, PHP4 support seems like an unnecessary complication. When will 1.5 be ready for release? Seen on the php.net website: > >PHP 4.4.8 Released > > > >[03-Jan-2008] > >The PHP development team would like to announce the immediate >availability of PHP 4.4.8. It >continues to improve the security and the stability of the 4.4 >branch and all users are strongly encouraged to upgrade to it as >soon as possible. This release wraps up all the outstanding patches >for the PHP 4.4 series, and is therefore the last normal PHP 4.4 >release. If necessary, releases to address security issues could be >made until 2008-08-08. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From devel at portalparts.com Fri Jan 4 00:43:10 2008 From: devel at portalparts.com (Blaine Lang) Date: Fri, 04 Jan 2008 00:43:10 -0500 Subject: [geeklog-devel] lib-layout.php In-Reply-To: <477DC3F1.8090804@ecsnet.com> References: <477DBB94.6000000@portalparts.com> <477DC3F1.8090804@ecsnet.com> Message-ID: <477DC76E.5010608@portalparts.com> Mark, I may not have properly explained what I had in mind but yes, I have spent time with Chameleon and do understand what and how it's working. It's because of that for which I was suggesting the change. I don't think it's a good long term strategy to copy the complete COM_siteHeader and COM_siteFooter functions into the themes. There are already a number of changes in CVS and with each release. Sites have to merge manually the changes into their themes and I suspect most site admin's won't know where to start and will have to wait for the theme owner to release an update. As you noted 99% of the code was copied to functions.php and then for chameleon, you moved sections of code from COM_siteHeader to COM_siteFooter. What I was suggesting is there are sections of related code blocks that can be broken out into smaller functions and then called as needed from either header/footer passing in the target template. This way the core code can be maintain outside the templates but still be modular enough so that theme designers can pick and choose and extend as required. Certainly was not suggesting we remove the over-ride functionality to use theme specific functions. Mark R. Evans wrote: > If you look at what Chameleon does, it actually duplicates 99% of the > code in COM_siteHeader() and COM_siteFooter(). The 1% I left out was > the logic on whether the left / right blocks are built in the header / > footer. We had to add a lot of code to do things the new CSS based > way as well. Chameleon renders the full page in COM_siteFooter() > which is very different from how the stock functions work. > Originally, all I had COM_siteHeader() do was set the global variables > for the parameters passed. It wasn't until I realized that some > plugins don't buffer the COM_siteHeader() call or their output that I > created a new template, htmlheader.thtml and now send the HTML headers > in COM_siteHeader(). The rest of the heavy lifting is all done in > COM_siteFooter(). The #1 goal of this approach is to render the > content first, then the left / right if enabled. Unless I'm missing > something, the only way to do it as Geeklog is currently designed is > to do it in the COM_siteFooter() call, along with a little PHP magic > to force the buffering of plugins / Geeklog's content. > > From the perspective of the Chameleon approach, adding a set of > functions with the template handle as a parameter won't give me the > control I need to accomplish what we're doing. I can certainly see > some value for themes that continue to use the table based structure. > It would add the ability to easily add or modify certain aspects of > the templates. > > Personally, I would just remove COM_siteHeader() / COM_siteFooter() > completely from lib-common.php and put it in the themes > functions.php. Generally the first step in creating a new Geeklog > theme is to copy Professional over and start hacking. I don't see the > functions.php as any different than a specific template file. This > would give each theme full control over the functions without having > any duplicate or unnecessary code sitting around. > > Obviously this would have to be a staged approach. Maybe in v1.5 you > have if (!function_exists('COM_siteHeader')) ... so it is duplicated > in both places (lib-common and function.php), but it gives a safety > net for folks with custom themes to just make the necessary template > changes after upgrading. Then in 1.5.1 or 1.6 or whatever is the next > major release, they come out of lib-common.php completely. > > If they stay in lib-common and are enhanced by new functions in > lib-layout.php, I would ask that the ability to override by the theme > not be removed. > Thanks! > Mark > > Blaine Lang wrote: >> I was looking at how we could make it easier to create theme specific >> siteHeader and siteFooter functions - specifically with Chameleon but >> I've also had to create theme specific functions in the past. It's >> not hard - copy/paste and modify but 90% of the code or more is the >> same as in the lib-common functions and these functions evolve every >> release. Chameleon has moved some of the code from COM_siteHeader >> into COM_siteFooter (theme versions) but still it's mostly >> restructuring of code chunks. >> >> I was thinking that it may be a good idea to create a set of >> functions which take the &$template variable which would be called by >> the header and footer related functions. This way the code to set the >> siteheader menu could be called in the header or footer function, >> same for the code to generate the left or right blocks etc. >> >> Reason to consider this now is for easier ongoing support of custom >> themes. >> >> Is this a new feature or a change (not sure) >> >> Is it worth doing as part of 1.5 - thats the ? >> >> Blaine >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://eight.pairlist.net/mailman/listinfo/geeklog-devel >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From dirk at haun-online.de Fri Jan 4 07:04:24 2008 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 4 Jan 2008 13:04:24 +0100 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager In-Reply-To: <2a1a3bb50801032133q53a337ep501e9f8fcfe5aa45@mail.gmail.com> References: <477D9F53.7040903@portalparts.com> <0JU300CMSSS1ZYZ0@mta4.srv.hcvlny.cv.net> <2a1a3bb50801032133q53a337ep501e9f8fcfe5aa45@mail.gmail.com> Message-ID: <20080104120424.1007214343@smtp.haun-online.de> Aaron Blankstein wrote: >On Jan 3, 2008 11:39 PM, Joe Mucchiello wrote: >>I also notice you have to be in 'root' use the config gui. That makes >> sense for options in the old config.php but by moving the >> configuration to a GUI, it should be more flexible. >> > >I agree. Yep, I think it would make sense to add a 'config' permission for every plugin, e.g. 'staticpages.config'. Root users should have this permission by default while plugin admins (Static Page Admin, etc.) should _not_ have it. Otherwise, a lot of plugin Admins will suddenly be able to change the layout / behaviour of the site after an upgrade. That's probably not something you'd expect. Eventually, we will also have to restrict / allow access to only certain parts of the Core config. But that can wait. bye, Dirk -- http://www.haun-online.de/accu/ From mevans at ecsnet.com Fri Jan 4 10:01:48 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Fri, 4 Jan 2008 09:01:48 -0600 (CST) Subject: [geeklog-devel] lib-layout.php In-Reply-To: <477DC76E.5010608@portalparts.com> References: <477DBB94.6000000@portalparts.com> <477DC3F1.8090804@ecsnet.com> <477DC76E.5010608@portalparts.com> Message-ID: <20080104085447.S60848@kimber.ecsnet.org> Blaine, If there are areas that can be modularized easily, then I'm all for it! > I don't think it's a good long term strategy to copy the complete > COM_siteHeader and COM_siteFooter functions into the themes. There are > already a number of changes in CVS and with each release. Sites have to > merge manually the changes into their themes and I suspect most site > admin's won't know where to start and will have to wait for the theme > owner to release an update. We already have this situation where folks are not upgrading their sites because they are using a different theme or have hacked their theme and don.t want to mess with finding the changes. If someone were to hack the COM_siteHeader/COM_siteFooter calls in their theme directory, I.m assuming (dangerous thing to do) they should have enough knowledge to merge their changes into an updated version. Personally, I believe most site admins will either wait for the theme author to publish an update or for someone else to update the theme like Ironmax has been doing. I believe this is a serious enough issue that it should be addressed sooner rather than later. Scanning the forums, it does seem to be a major reason folks don't upgrade. As usual, I have an opinion on how to address it.. [beating dead horse mode on] The Caching Template Library will take an array of locations in the initial new Template() call. This allows you to create a new theme and only copy over the templates you wish to change to the new theme directory. Making the second array element the professional theme, you now have the ability for users to only copy a handful of templates they wish to modify to their new theme directory. Upgrades will not overwrite their work. It will keep it separated which will facilitate upgrades. A quick review of the release notes to see what template files have changed, cross referenced with the custom theme files, you know quickly what you need to change (if anything). Site admins don.t have to remember what they changed, the changes are sitting in their own directory. This is how I am doing themes in Media Gallery now. I'll never worry about an upgrade overwriting a users template modifications. It also makes theming much easier, if you only want to change the overall album view, simply copy the necessary templates over, change them and you're done. Yes, I know, an admin can simply make an exact copy of Professional to another theme directory and then hack away and basically accomplish the same goal. The big difference here is that only the changed files need to go into the new theme directory. Also, if new template files are added in the next version of Geeklog, no problem, the system will pick them up automatically from the Professional layout. This would accomplish what lib-custom.php has tried to do with the code except for themes. I believe this will facilitate future upgrades significantly. Think big picture, long term stuff here.. [beating dead horse mode off] While we are talking about themes, I would love to see themes 'registered' at some point. Instead of just doing a quick directory search for all directories in layout/, make the site admin actually 'install' the theme into Geeklog. I would also add permissions to the theme record too. This would allow an admin to create a test or development theme that is only available to a certain group. When it is ready to go production, change the perms so everyone can select. With all the security checks and really great permission model that Geeklog has, scanning a directory for the themes just doesn't seem to fit the overall model. Thanks! Mark From joe at ThrowingDice.com Fri Jan 4 10:04:23 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 04 Jan 2008 10:04:23 -0500 Subject: [geeklog-devel] lib-layout.php In-Reply-To: <20080104085447.S60848@kimber.ecsnet.org> References: <477DBB94.6000000@portalparts.com> <477DC3F1.8090804@ecsnet.com> <477DC76E.5010608@portalparts.com> <20080104085447.S60848@kimber.ecsnet.org> Message-ID: <0JU400F60KK8H741@mta5.srv.hcvlny.cv.net> At 10:01 AM 1/4/2008, Mark R. Evans wrote: >While we are talking about themes, I would love to see themes >'registered' at some point. Instead of just doing a quick directory >search for all directories in layout/, make the site admin actually >'install' the theme into Geeklog. I would also add permissions to >the theme record too. This would allow an admin to create a test or >development theme that is only available to a certain group. When >it is ready to go production, change the perms so everyone can >select. With all the security checks and really great permission >model that Geeklog has, scanning a directory for the themes just >doesn't seem to fit the overall model. I've said this forever so I endorse such a project now rather than later. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From geiss at midnightforce.com Fri Jan 4 10:27:14 2008 From: geiss at midnightforce.com (geiss at midnightforce.com) Date: Fri, 04 Jan 2008 08:27:14 -0700 Subject: [geeklog-devel] lib-layout.php Message-ID: <20080104082714.fb8bcc2fecb686751fcd9ef4261c8e30.b27b5a296d.wbe@email.secureserver.net> While I don't pretend to understand all the behind the scenes code stuff, I can report that one of the major reasons why theme creation for GL has languished is because of the sheer amount of files to go through. Even though one would only end up modifying a handful, many users look at the professional directory and say, "Whoa!" and get gun shy. Anything to cut down on the size, or number of files would be fantastic for a theme dev POV. I especially like the idea of pulling the majority of .thtml files from the main theme folder, and then building any modified files in a another directory. All around it seems like a leaner, meaner, more user friendly solution. Then, you could include multiple themes in a release without the size overhead of 90% duplicated files. (since it's been reported that people are complaining about the size of the archive then need to FTP up to their servers.) ...one other thought on this is that it seems like the bulk of the file sizes are coming from all the language files. I would see it as more valuable to the user to have more theme selection out of the box than language selection. My thought is to keep a handful of the dominant language files, and roll the rest into a separate language file download. Registering themes also is valuable in that you could check for a particular version of GL to install against. If a theme is only compatible with v1.5 for instance, when they try to install it on a 1.3.9 site, they would get the appropriate incompatibility message. This could greatly reduce support issues. How many forum posts contain, "...copy over the templates from the professional directory..."! Also, I haven't come across any clear documentation as to what each and every .thtml file corresponds to on a site. Over time, I've become relatively familiar with the .thtml files. Once 1.5 is released, I wouldn't mind creating a document that corresponds .thtml files to the part of the site they control. We'll see as time progresses. ...back to work! :-) Eric > -------- Original Message -------- > Subject: Re: [geeklog-devel] lib-layout.php > From: "Mark R. Evans" > Date: Fri, January 04, 2008 8:01 am > To: Geeklog Development > Blaine, > If there are areas that can be modularized easily, then I'm all for it! > > I don't think it's a good long term strategy to copy the complete > > COM_siteHeader and COM_siteFooter functions into the themes. There are > > already a number of changes in CVS and with each release. Sites have to > > merge manually the changes into their themes and I suspect most site > > admin's won't know where to start and will have to wait for the theme > > owner to release an update. > We already have this situation where folks are not upgrading their sites > because they are using a different theme or have hacked their theme and > don.t want to mess with finding the changes. If someone were to hack the > COM_siteHeader/COM_siteFooter calls in their theme directory, I.m assuming > (dangerous thing to do) they should have enough knowledge to merge their > changes into an updated version. > Personally, I believe most site admins will either wait for the theme > author to publish an update or for someone else to update the theme like > Ironmax has been doing. > I believe this is a serious enough issue that it should be addressed > sooner rather than later. Scanning the forums, it does seem to be a major > reason folks don't upgrade. As usual, I have an opinion on how to address > it.. > [beating dead horse mode on] > The Caching Template Library will take an array of locations in the > initial new Template() call. This allows you to create a new theme and > only copy over the templates you wish to change to the new theme > directory. Making the second array element the professional theme, you > now have the ability for users to only copy a handful of templates they > wish to modify to their new theme directory. Upgrades will not overwrite > their work. It will keep it separated which will facilitate upgrades. A > quick review of the release notes to see what template files have changed, > cross referenced with the custom theme files, you know quickly what you > need to change (if anything). Site admins don.t have to remember what > they changed, the changes are sitting in their own directory. > This is how I am doing themes in Media Gallery now. I'll never worry > about an upgrade overwriting a users template modifications. It also > makes theming much easier, if you only want to change the overall album > view, simply copy the necessary templates over, change them and you're > done. > Yes, I know, an admin can simply make an exact copy of Professional to > another theme directory and then hack away and basically accomplish the > same goal. The big difference here is that only the changed files need to > go into the new theme directory. Also, if new template files are added in > the next version of Geeklog, no problem, the system will pick them up > automatically from the Professional layout. This would accomplish what > lib-custom.php has tried to do with the code except for themes. > I believe this will facilitate future upgrades significantly. Think big > picture, long term stuff here.. > [beating dead horse mode off] > While we are talking about themes, I would love to see themes 'registered' > at some point. Instead of just doing a quick directory search for all > directories in layout/, make the site admin actually 'install' the theme > into Geeklog. I would also add permissions to the theme record too. > This would allow an admin to create a test or development theme that is > only available to a certain group. When it is ready to go production, > change the perms so everyone can select. With all the security checks and > really great permission model that Geeklog has, scanning a directory for > the themes just doesn't seem to fit the overall model. > Thanks! > Mark > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel From mevans at ecsnet.com Fri Jan 4 10:54:08 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Fri, 4 Jan 2008 09:54:08 -0600 (CST) Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477DB1E2.3030904@portalparts.com> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> <477DB1E2.3030904@portalparts.com> Message-ID: <20080104093931.L62491@kimber.ecsnet.org> > I would prefer we not create any more tabs as the core->menu was already > longer then I wanted. We need to ensure the menu does not wrap on > narrower browsers. Using the dropline menu has regained space but if we > do any more significant restructuring it would be something considering. > This option effects more then just the editor so it may be better placed > on the Site Tab - thats easy to do. Trying to ensure the menu doesn't wrap is the wrong area to focus. Don't try and make more space, make the menu wrap gracefully. What looks good with English selected may be much wider when another language is selected. My point is that you'll never win the no-wrap game. Assume it is going to wrap and do it gracefully. The current menu does not wrap well, so that would be an area to focus. Another approach to a two-tiered menu could be to use a select box to choose Core, pluign X, plugin Y, or plugin Z. This removes the need for a two tiered approach. Not sure what it gains you, but it would keep that section of options from possibly wrapping in the future if you had 10 or 15 plugins installed that used the configuration API. > Agree this would be better and will look at extending the UI Javascript > methods to add a select type element for the 'Add Element' feature. This > may have to wait to see if we move the config manager to use AJAX as now > the DHTML has to be more generic. The 'Add Element' is a generic UI JS > function and this would require it be unique to add a select that has a > unique set of options. Easy to do with AJAX but not sure I want to break > the UI code now to add this feature. The current state of the configuration system concerns me a little. I understand the goal of using as generic a set of tools as possible to allow easy extention and use by plugins. But, if this is at the sacrifice of having a configuration system with selectable options, limits and validations, I'm not sure that is the right choice. I realize what is gained by moving to an online configuration system. No more butchering of the config.php file (missed end quotes, semi-colons, etc.) and no more FTPing it up / down to edit. But, as it stands right now, there are a few things that are lost. Specifically all the inline documentation that tells you what each option does and the list of valid values. To me, this is a big piece that must be duplicated in the online version. Since JavaScript is now required to perform configuration, why not continue to exploit that requirement and implement some nice pop-up windows or tooltips for help or at least duplicate what was in the config.php. I strongly believe if an option has a finite set of selections, that set must be presented to the user through the interface. Allowing users to free form the entry will result is just as many support issues as mistyping in the old config.php. While the current online configurator is no worse than hand editing the config.php, I believe it should aim higher than being no worse. Don't get me wrong, I think what has been done so far is an excellent start and is very well done from a technical perspective. I believe it now needs to be addressed from a user perspective which may change or enhance how it currently works. It is a great starting point, but is it ready for prime time? A final comment on the current system... A user support issues I've seen with tabbed menus is when a user makes a change, then clicks on another tab, in this case the change is lost. But, in contrast, the story editor, switching tabs doesn't loose the changes between the screens. We all know it is because in the story editor, JS is being used to hide each of the non-active tabs and you are really dealing with one big page and the online configuration is actually calling a separate page with each tab. My point is that we have an inconsistency in the various areas of Geeklog when it comes to tabbed menus. A possible solution is to detect changes and use JS pop-up to warn that changes have been made, do you want to save before continuing. Thanks! Mark On Thu, 3 Jan 2008, Blaine Lang wrote: > Mark R. Evans wrote: >> THEME -> MENU ELEMENTS >> This should be a drop down of allowed values. If I put 'Home' in there, >> nothing happens, but if I enter 'home', it will place the Home link in the >> menu. Since this is a static list of valid values, make it a drop down. >> This will cut down on support issues. >> >> TOPICS AND DAILY DIGEST -> TOPIC SORT METHOD >> This should also be a drop down selection. There are only 2 valid options >> for this field. Again, makes it more user friendly and will cut down on >> support issues. > Agree this would be better and will look at extending the UI Javascript > methods to add a select type element for the 'Add Element' feature. This may > have to wait to see if we move the config manager to use AJAX as now the > DHTML has to be more generic. The 'Add Element' is a generic UI JS function > and this would require it be unique to add a select that has a unique set of > options. Easy to do with AJAX but not sure I want to break the UI code now to > add this feature. >> >> TOPICS AND DAILY DIGEST -> WHAT'S NEW >> If possible, use something besides seconds for the time entry, use minutes >> or hours and convert on save. Seconds are very confusing, it is difficult >> to know just how long is 172800 seconds. But, something like 48 hours is >> pretty clear. > I think the change would need to be made to the COM_whatsNewBlock as we have > no specialized handlers in the config class. We can certainly make the > setting be hours and change the COM function - Dirk? >> >> >> USERS AND SUBMISSIONS >> I don't think this is the right place to set the advanced editor options. I >> would create a new tab for editor specific items. > I would prefer we not create any more tabs as the core->menu was already > longer then I wanted. We need to ensure the menu does not wrap on narrower > browsers. Using the dropline menu has regained space but if we do any more > significant restructuring it would be something considering. This option > effects more then just the editor so it may be better placed on the Site Tab > - thats easy to do. >> >> Actually, I think the entire organization should probably be revisited and >> mapped a little differently. I understand this was the format of the >> config.php file, but if you are planning on improving the overall >> configuration, a better organization might be worth looking into. > I've looked at the organization a few times while trying to see if I could > eliminate one of the tabbed sections to reduce the size of the Core->submenu > and it may be just that I've been using GL too long and it's the config > optons are too familiar now to me but I am not seeing any clear > restructuring. I think it's actually far easier to find a setting now then it > ever was in the config.php > >> >> CONFIGURATION -> THEMES >> Why not make the Theme field a drop down, there is already a function, >> COM_getThemes() that returns a list of available themes. This would make it >> a bit more user friendly and keep someone from mis-typing a theme name. > Possible but would require extending the class or adding a new config value > type. Worth considering if there are more config settings to use that > feature. > > > Blaine > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From devel at portalparts.com Fri Jan 4 11:20:04 2008 From: devel at portalparts.com (Blaine Lang) Date: Fri, 04 Jan 2008 11:20:04 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080104093931.L62491@kimber.ecsnet.org> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> <477DB1E2.3030904@portalparts.com> <20080104093931.L62491@kimber.ecsnet.org> Message-ID: <477E5CB4.3030101@portalparts.com> Mark R. Evans wrote: > Another approach to a two-tiered menu could be to use a select box to choose Core, pluign X, plugin Y, or plugin Z. This removes the need for a two tiered approach. Not sure what it gains you, but it would keep that section of options from possibly wrapping in the future if you had 10 or 15 plugins installed that used the configuration API. Considered that and felt it did not address the issues I was trying to solve and prefer an interface where the user can easily scan the tabs without having to click and have the screen change. The core site config menu is likely the worst case and if we can make the screens and menu work for that, then most plugins will work. Once we get 10+ plugins that support the online config manager, we will likely need to use a Javascript menu to better handle scrolling/wrapping. > The current state of the configuration system concerns me a little. I understand the goal of using as generic a set of tools as possible to allow easy extention and use by plugins. But, if this is at the sacrifice of having a configuration system with selectable options, limits and validations, I'm not sure that is the right choice. Not much validation if any is done today but that is not an excuse. We will add config validation functions that allow plugins to extend the core config class but we are trying to get this release out. If time permits, we can extend the config class the support this now. > Since JavaScript is now required to perform configuration, why not continue to exploit that requirement and implement some nice pop-up windows or tooltips for help or at least duplicate what was in the config.php. This has been discussed and will be added . > A user support issues I've seen with tabbed menus is when a user makes a change, then clicks on another tab, in this case the change is lost. But, in contrast, the story editor, switching tabs doesn't loose the changes between the screens. I'd like to see us move to using AJAX so that changes can be saved asynchronously and will offer many other UI enhancements. There was a time not so long ago that JS was not allowed in GL code anywhere unless the screen worked as well with JS disabled ;) Blaine From dirk at haun-online.de Fri Jan 4 11:14:10 2008 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 4 Jan 2008 17:14:10 +0100 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080104093931.L62491@kimber.ecsnet.org> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> <477DB1E2.3030904@portalparts.com> <20080104093931.L62491@kimber.ecsnet.org> Message-ID: <20080104161410.1086473110@smtp.haun-online.de> Mark R. Evans wrote: >> We need to ensure the menu does not wrap on narrower browsers. > >Trying to ensure the menu doesn't wrap is the wrong area to focus. Don't >try and make more space, make the menu wrap gracefully. What looks good >with English selected may be much wider when another language is selected. >My point is that you'll never win the no-wrap game. Just FYI, it does already wrap in my browser - and that's in English ... >The current menu does not wrap well, so that would be an area to focus. Yep. Also, I found that with the long list of options you tend to go diagonally (from "Core" to something far out right). And then the dropline tends to close. You have to be careful to go down into the dropline first and then to the right. So I have to say while this initially looked like a good solution, it does display a few usability issues after a while. >> I would prefer we not create any more tabs as the core->menu was already >> longer then I wanted. I think we should focus on logical groups first, then see how many that turn out to be, and only then think about restricting the number of entries. bye, Dirk -- http://www.haun-online.de/accu/ From devel at portalparts.com Fri Jan 4 11:27:40 2008 From: devel at portalparts.com (Blaine Lang) Date: Fri, 04 Jan 2008 11:27:40 -0500 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <20080104161410.1086473110@smtp.haun-online.de> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> <477DB1E2.3030904@portalparts.com> <20080104093931.L62491@kimber.ecsnet.org> <20080104161410.1086473110@smtp.haun-online.de> Message-ID: <477E5E7C.2080708@portalparts.com> Dirk Haun wrote: > I found that with the long list of options you tend to go diagonally (from "Core" to something far out right). And then the dropline tends to close. You have to be careful to go down into the dropline first and then to the right. When you go diagonally, your mouse is passing over another top line menuitem or moving off the Core menu item which collapses the dropline menu. It's just using CSS and activated bu the on-hover link. I could add some JS to introduce a on-hover delay so the dropline menu would stick for a fraction of a sec and give you time to get the mouse down to the dropline should you not move straight down first. Blaine > Mark R. Evans wrote: > > >>> We need to ensure the menu does not wrap on narrower browsers. >>> >> Trying to ensure the menu doesn't wrap is the wrong area to focus. Don't >> try and make more space, make the menu wrap gracefully. What looks good >> with English selected may be much wider when another language is selected. >> My point is that you'll never win the no-wrap game. >> > > Just FYI, it does already wrap in my browser - and that's in English ... > > > >> The current menu does not wrap well, so that would be an area to focus. >> > > Yep. Also, > > So I have to say while this initially looked like a good solution, it > does display a few usability issues after a while. > > > >>> I would prefer we not create any more tabs as the core->menu was already >>> longer then I wanted. >>> > > I think we should focus on logical groups first, then see how many that > turn out to be, and only then think about restricting the number of entries. > > bye, Dirk > > > From dwight at trumbower.com Fri Jan 4 11:49:28 2008 From: dwight at trumbower.com (Dwight Trumbower) Date: Fri, 4 Jan 2008 10:49:28 -0600 Subject: [geeklog-devel] Config GUI issues In-Reply-To: <477E5E7C.2080708@portalparts.com> References: <20080101201540.1705656633@smtp.haun-online.de> <477AA179.8020902@ecsnet.com> <477DB1E2.3030904@portalparts.com> <20080104093931.L62491@kimber.ecsnet.org> <20080104161410.1086473110@smtp.haun-online.de> <477E5E7C.2080708@portalparts.com> Message-ID: <62564dee0801040849p66dfc159o8deb7a3d8d033281@mail.gmail.com> On Jan 4, 2008 10:27 AM, Blaine Lang wrote: > Dirk Haun wrote: > > I found that with the long list of options you tend to go diagonally > (from "Core" to something far out right). And then the dropline tends to > close. You have to be careful to go down into the dropline first and > then to the right. > > When you go diagonally, your mouse is passing over another top line > menuitem or moving off the Core menu item which collapses the dropline > menu. It's just using CSS and activated bu the on-hover link. I could > add some JS to introduce a on-hover delay so the dropline menu would > stick for a fraction of a sec and give you time to get the mouse down to > the dropline should you not move straight down first. > > Blaine > > Not real pretty. (file attached) -- Have a Great Day! Dwight Trumbower -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: geekmenu.jpg Type: image/jpeg Size: 84036 bytes Desc: not available URL: From dirk at haun-online.de Fri Jan 4 13:18:51 2008 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 4 Jan 2008 19:18:51 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/plugins/staticpages/language english.php, 1.21, 1.22 english_utf-8.php, 1.7, 1.8 In-Reply-To: <20080104021531.0E5A710FE16@qs1489.pair.com> References: <20080104021531.0E5A710FE16@qs1489.pair.com> Message-ID: <20080104181852.40982331@smtp.haun-online.de> Blaine Lang wrote: >Log Message: >Upgrades to support ver1.5 installation and upgrade. Removed config.php >so that if upgrading, sites config.php not over-written. Added new file >install_defaults.php for initial installation defaults for the online >config records. Something broke there. I don't have a config menu for static pages any more. I tried both an upgrade and a fresh install. "Core" is there, "Staticpages" isn't. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From devel at portalparts.com Fri Jan 4 13:57:10 2008 From: devel at portalparts.com (Blaine Lang) Date: Fri, 04 Jan 2008 13:57:10 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/plugins/staticpages/language english.php, 1.21, 1.22 english_utf-8.php, 1.7, 1.8 In-Reply-To: <20080104181852.40982331@smtp.haun-online.de> References: <20080104021531.0E5A710FE16@qs1489.pair.com> <20080104181852.40982331@smtp.haun-online.de> Message-ID: <477E8186.8050408@portalparts.com> After your plugin upgrade, is the plugins config.php still there? It needs to be removed or renamed. The upgrade does a rename. The fresh install now does not have a confg.php file. Blaine Dirk Haun wrote: > Blaine Lang wrote: > > >> Log Message: >> Upgrades to support ver1.5 installation and upgrade. Removed config.php >> so that if upgrading, sites config.php not over-written. Added new file >> install_defaults.php for initial installation defaults for the online >> config records. >> > > Something broke there. I don't have a config menu for static pages any > more. I tried both an upgrade and a fresh install. "Core" is there, > "Staticpages" isn't. > > bye, Dirk > > > From dirk at haun-online.de Fri Jan 4 16:00:09 2008 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 4 Jan 2008 22:00:09 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/plugins/staticpages/language english.php, 1.21, 1.22 english_utf-8.php, 1.7, 1.8 In-Reply-To: <477E8186.8050408@portalparts.com> References: <20080104021531.0E5A710FE16@qs1489.pair.com> <20080104181852.40982331@smtp.haun-online.de> <477E8186.8050408@portalparts.com> Message-ID: <20080104210009.1210334819@smtp.haun-online.de> Blaine Lang wrote: >After your plugin upgrade, is the plugins config.php still there? >It needs to be removed or renamed. The upgrade does a rename. The fresh >install now does not have a confg.php file. Actually, I don't see any code for the static page config in a fresh install or database upgrade. The only thing that seems to work for me is (after a fresh install) to uninstall the static pages plugin (from the Admin's Plugin menu) and then reinstall it from there. Then I get a config GUI for it. What am I missing? bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From devel at portalparts.com Fri Jan 4 16:10:20 2008 From: devel at portalparts.com (Blaine Lang) Date: Fri, 04 Jan 2008 16:10:20 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/plugins/staticpages/language english.php, 1.21, 1.22 english_utf-8.php, 1.7, 1.8 In-Reply-To: <20080104210009.1210334819@smtp.haun-online.de> References: <20080104021531.0E5A710FE16@qs1489.pair.com> <20080104181852.40982331@smtp.haun-online.de> <477E8186.8050408@portalparts.com> <20080104210009.1210334819@smtp.haun-online.de> Message-ID: <477EA0BC.1020105@portalparts.com> I don't think your missing anything. I have not updated the GL installation install or upgrade process. I only re-worked the plugin installtion/upgrade. Dirk Haun wrote: > Blaine Lang wrote: > > >> After your plugin upgrade, is the plugins config.php still there? >> It needs to be removed or renamed. The upgrade does a rename. The fresh >> install now does not have a confg.php file. >> > > Actually, I don't see any code for the static page config in a fresh > install or database upgrade. The only thing that seems to work for me is > (after a fresh install) to uninstall the static pages plugin (from the > Admin's Plugin menu) and then reinstall it from there. Then I get a > config GUI for it. > > What am I missing? > > bye, Dirk > > > From info at heatherengineering.com Fri Jan 4 18:07:58 2008 From: info at heatherengineering.com (Euan McKay) Date: Sat, 5 Jan 2008 08:07:58 +0900 Subject: [geeklog-devel] lib-layout.php In-Reply-To: <20080104082714.fb8bcc2fecb686751fcd9ef4261c8e30.b27b5a296d.wbe@email.secureserver.net> References: <20080104082714.fb8bcc2fecb686751fcd9ef4261c8e30.b27b5a296d.wbe@email.secureserver.net> Message-ID: I haven't followed this entire discussion, but this is what I do mostly: 1) I have a theme based off professional incorporating the blueprint css library (http://code.google.com/p/blueprintcss/) so windows layout is not too much hassle. 2) I add a new css file for my new theme and put everything I do in there. 3) I then make any changes to the actual theme files if required. If I then upgrade, I only need to update my base theme, and everything else is roughly the same - less a few patches from (3). I think it makes sense to have a "template" folder, with the basic (x)html files, and then a "theme" folder that holds the unique images and css for each theme. 2 yen. Cheers, Euan. On 1/5/08, geiss at midnightforce.com wrote: > While I don't pretend to understand all the behind the scenes code > stuff, I can report that one of the major reasons why theme creation for > GL has languished is because of the sheer amount of files to go through. > Even though one would only end up modifying a handful, many users look > at the professional directory and say, "Whoa!" and get gun shy. > > Anything to cut down on the size, or number of files would be fantastic > for a theme dev POV. I especially like the idea of pulling the majority > of .thtml files from the main theme folder, and then building any > modified files in a another directory. All around it seems like a > leaner, meaner, more user friendly solution. Then, you could include > multiple themes in a release without the size overhead of 90% duplicated > files. (since it's been reported that people are complaining about the > size of the archive then need to FTP up to their servers.) ...one other > thought on this is that it seems like the bulk of the file sizes are > coming from all the language files. I would see it as more valuable to > the user to have more theme selection out of the box than language > selection. My thought is to keep a handful of the dominant language > files, and roll the rest into a separate language file download. > > Registering themes also is valuable in that you could check for a > particular version of GL to install against. If a theme is only > compatible with v1.5 for instance, when they try to install it on a > 1.3.9 site, they would get the appropriate incompatibility message. This > could greatly reduce support issues. How many forum posts contain, > "...copy over the templates from the professional directory..."! > > Also, I haven't come across any clear documentation as to what each and > every .thtml file corresponds to on a site. Over time, I've become > relatively familiar with the .thtml files. Once 1.5 is released, I > wouldn't mind creating a document that corresponds .thtml files to the > part of the site they control. We'll see as time progresses. > > ...back to work! :-) > > Eric > > > -------- Original Message -------- > > Subject: Re: [geeklog-devel] lib-layout.php > > From: "Mark R. Evans" > > Date: Fri, January 04, 2008 8:01 am > > To: Geeklog Development > > Blaine, > > If there are areas that can be modularized easily, then I'm all for it! > > > I don't think it's a good long term strategy to copy the complete > > > COM_siteHeader and COM_siteFooter functions into the themes. There are > > > already a number of changes in CVS and with each release. Sites have to > > > merge manually the changes into their themes and I suspect most site > > > admin's won't know where to start and will have to wait for the theme > > > owner to release an update. > > We already have this situation where folks are not upgrading their sites > > because they are using a different theme or have hacked their theme and > > don.t want to mess with finding the changes. If someone were to hack the > > COM_siteHeader/COM_siteFooter calls in their theme directory, I.m assuming > > (dangerous thing to do) they should have enough knowledge to merge their > > changes into an updated version. > > Personally, I believe most site admins will either wait for the theme > > author to publish an update or for someone else to update the theme like > > Ironmax has been doing. > > I believe this is a serious enough issue that it should be addressed > > sooner rather than later. Scanning the forums, it does seem to be a major > > reason folks don't upgrade. As usual, I have an opinion on how to address > > it.. > > [beating dead horse mode on] > > The Caching Template Library will take an array of locations in the > > initial new Template() call. This allows you to create a new theme and > > only copy over the templates you wish to change to the new theme > > directory. Making the second array element the professional theme, you > > now have the ability for users to only copy a handful of templates they > > wish to modify to their new theme directory. Upgrades will not overwrite > > their work. It will keep it separated which will facilitate upgrades. A > > quick review of the release notes to see what template files have changed, > > cross referenced with the custom theme files, you know quickly what you > > need to change (if anything). Site admins don.t have to remember what > > they changed, the changes are sitting in their own directory. > > This is how I am doing themes in Media Gallery now. I'll never worry > > about an upgrade overwriting a users template modifications. It also > > makes theming much easier, if you only want to change the overall album > > view, simply copy the necessary templates over, change them and you're > > done. > > Yes, I know, an admin can simply make an exact copy of Professional to > > another theme directory and then hack away and basically accomplish the > > same goal. The big difference here is that only the changed files need to > > go into the new theme directory. Also, if new template files are added in > > the next version of Geeklog, no problem, the system will pick them up > > automatically from the Professional layout. This would accomplish what > > lib-custom.php has tried to do with the code except for themes. > > I believe this will facilitate future upgrades significantly. Think big > > picture, long term stuff here.. > > [beating dead horse mode off] > > While we are talking about themes, I would love to see themes 'registered' > > at some point. Instead of just doing a quick directory search for all > > directories in layout/, make the site admin actually 'install' the theme > > into Geeklog. I would also add permissions to the theme record too. > > This would allow an admin to create a test or development theme that is > > only available to a certain group. When it is ready to go production, > > change the perms so everyone can select. With all the security checks and > > really great permission model that Geeklog has, scanning a directory for > > the themes just doesn't seem to fit the overall model. > > Thanks! > > Mark > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > -- ----------------------------------------------------------------------------- Euan McKay PhD Candidate in International Relations Department of Advanced Social and International Studies Graduate School of Arts and Sciences The University of Tokyo From joe at ThrowingDice.com Fri Jan 4 21:55:05 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Fri, 04 Jan 2008 21:55:05 -0500 Subject: [geeklog-devel] Plugins and GL 1.5 online config manager In-Reply-To: <477D9F53.7040903@portalparts.com> References: <477D9F53.7040903@portalparts.com> Message-ID: <0JU500606HGS1E90@mta2.srv.hcvlny.cv.net> Dirk, With all the work that seems necessary in 1.5, have you considered going back to the 1.4.1_1 line that you have in CVS and releasing it? It's been a year since Geeklog releases. I'm not sure what's in 1.4.1_1 but a small release to take the pressure off 1.5 might be a good idea. Just throwing the idea out there. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From dirk at haun-online.de Sat Jan 5 05:15:49 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 5 Jan 2008 11:15:49 +0100 Subject: [geeklog-devel] Geeklog 1.4.1-1 (was: Plugins and GL 1.5 online config manager) In-Reply-To: <0JU500606HGS1E90@mta2.srv.hcvlny.cv.net> References: <477D9F53.7040903@portalparts.com> <0JU500606HGS1E90@mta2.srv.hcvlny.cv.net> Message-ID: <20080105101549.1951133913@smtp.haun-online.de> Joe Mucchiello wrote: >With all the work that seems necessary in 1.5, have you considered >going back to the 1.4.1_1 line that you have in CVS and releasing it? I was actually thinking about releasing it in parallel with a first 1.5 beta (for no particular reason). >It's been a year since Geeklog releases. I'm not sure what's in >1.4.1_1 but a small release to take the pressure off 1.5 might be a good idea. The changes are documented here: Since it's a pretty conservative list of changes it could be released any day, i.e. with minimal or no testing. Many of these changes are already in use on one site or another. Upgrading from 1.4.1 should also be straightforward, as there are no changes in the database, the themes, or the language files. >to take the pressure off 1.5 Who says I want to take the pressure off 1.5? We need to release this thing sooner rather than later. bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ From dirk at haun-online.de Sat Jan 5 07:45:33 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 5 Jan 2008 13:45:33 +0100 Subject: [geeklog-devel] Static Pages vs. user's theme choice Message-ID: <20080105124533.272873555@smtp.haun-online.de> Okay, I leave this for someone else to figure out (Blaine? Aaron?): Step 1: User switches to another theme in their My Account settings. The site however still loads with the Professional theme. Step 2: Disable Static Pages plugin. Suddently, the correct theme is picked up. I guess initialisation of the config GUI for the plugin somehow resets / reloads the Core config. I have confirmed that the cookie and 'theme' field in gl_users are set correctly. At the end of the piece of code in lib-common.php that handles the theme choice, the correct (user-selected) theme is in all the $_CONF and $_USER vars. But by the time COM_siteHeader is called, everything's back to Professional. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From devel at portalparts.com Sat Jan 5 10:07:38 2008 From: devel at portalparts.com (Blaine Lang) Date: Sat, 05 Jan 2008 10:07:38 -0500 Subject: [geeklog-devel] Static Pages vs. user's theme choice In-Reply-To: <20080105124533.272873555@smtp.haun-online.de> References: <20080105124533.272873555@smtp.haun-online.de> Message-ID: <477F9D3A.7030705@portalparts.com> I will take that issue Dirk .. I see it now as well. Blaine Dirk Haun wrote: > Okay, I leave this for someone else to figure out (Blaine? Aaron?): > > Step 1: User switches to another theme in their My Account settings. The > site however still loads with the Professional theme. > > Step 2: Disable Static Pages plugin. Suddently, the correct theme is > picked up. > > I guess initialisation of the config GUI for the plugin somehow resets / > reloads the Core config. > > I have confirmed that the cookie and 'theme' field in gl_users are set > correctly. At the end of the piece of code in lib-common.php that > handles the theme choice, the correct (user-selected) theme is in all > the $_CONF and $_USER vars. But by the time COM_siteHeader is called, > everything's back to Professional. > > bye, Dirk > > > From dirk at haun-online.de Sat Jan 5 12:36:21 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 5 Jan 2008 18:36:21 +0100 Subject: [geeklog-devel] if IE 7 Message-ID: <20080105173621.687798890@smtp.haun-online.de> Something's not right here (from admin/config/menu_element.thtml):
  • {group_display} The And so we're left with a sole with no matching . Unless this is some elaborate hack to achieve something specific in IE7, I think the entire comment, i.e. everything after the should be removed. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From joe at ThrowingDice.com Sat Jan 5 13:30:15 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Sat, 05 Jan 2008 13:30:15 -0500 Subject: [geeklog-devel] if IE 7 In-Reply-To: <20080105173621.687798890@smtp.haun-online.de> References: <20080105173621.687798890@smtp.haun-online.de> Message-ID: <0JU600MOXORGTF30@mta4.srv.hcvlny.cv.net> At 12:36 PM 1/5/2008, Dirk Haun wrote: >Unless this is some elaborate hack to achieve something specific in IE7, >I think the entire comment, i.e. everything after the should be >removed. Yes, it's an elaborate hack. Don't try to understand it, it made my head hurt when I looked it up. It has to do with making cascading menus and proper placement of anchors for use in a:hover CSS. Makes my head spin. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From dirk at haun-online.de Sat Jan 5 13:46:26 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 5 Jan 2008 19:46:26 +0100 Subject: [geeklog-devel] Dropline menu and the DTD Message-ID: <20080105184626.633540222@smtp.haun-online.de> Here's something to remember for future 1.5 theme authors: If you're going back to a Transitional DTD (now that Professional is "Strict"), you need to use the long form of the DOCTYPE declaration that includes the URL to the DTD: With the short form, the dropline simply didn't show up (at least not in Firefox and Safari). Took me a while to figure that one out ... bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From dirk at haun-online.de Sun Jan 6 03:24:15 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 6 Jan 2008 09:24:15 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080105234552.4E98610FE14@qs1489.pair.com> References: <20080105234552.4E98610FE14@qs1489.pair.com> Message-ID: <20080106082415.606721504@smtp.haun-online.de> Blaine Lang wrote: >Log Message: >Changes to support revised conifg manager menu The problem with this version now is that it doesn't wrap around at all. I'm missing the "Misc" menu (see screenshot) and thought it was a bug. But it's simply because my browser window isn't wide enough - it shows up when I make it wider. bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: nomisc.png Type: image/png Size: 3160 bytes Desc: not available URL: From devel at portalparts.com Sun Jan 6 09:16:12 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 06 Jan 2008 09:16:12 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080106082415.606721504@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.haun-online.de> Message-ID: <4780E2AC.9030602@portalparts.com> Is your browser not even 900px wide? Blaine Dirk Haun wrote: > Blaine Lang wrote: > > >> Log Message: >> Changes to support revised conifg manager menu >> > > The problem with this version now is that it doesn't wrap around at all. > I'm missing the "Misc" menu (see screenshot) and thought it was a bug. > But it's simply because my browser window isn't wide enough - it shows > up when I make it wider. > > bye, Dirk > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > From dirk at haun-online.de Sun Jan 6 09:54:28 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 6 Jan 2008 15:54:28 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <4780E2AC.9030602@portalparts.com> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.haun-online.de> <4780E2AC.9030602@portalparts.com> Message-ID: <20080106145428.594572461@smtp.haun-online.de> Blaine Lang wrote: >Is your browser not even 900px wide? Obviously not :-) I think we just need something that wraps around nicely. Consider someone using it on their iPhone, Eee PC, or some other device with a small screen. We just can't assume a certain window or screen size for something this vital. bye, Dirk -- http://www.haun-online.de/accu/ From dirk at haun-online.de Sun Jan 6 12:47:36 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 6 Jan 2008 18:47:36 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080106145428.594572461@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.haun-online.de> <4780E2AC.9030602@portalparts.com> <20080106145428.594572461@smtp.haun-online.de> Message-ID: <20080106174736.332806063@smtp.haun-online.de> Dirk Haun wrote: >I think we just need something that wraps around nicely. I had a look at the Wordpress "Dashboard", but that doesn't provide any solution that would help us. Effectively, they have a simple two-row menu bar and both rows wrap around on small windows. It works, but if you assume the top row is used for the plugins and you have a lot of them you'll end up with a row that wraps around twice or more. Another idea, but that could be a lot of work: I had a look at the web interface my hosting service provides. When you think domain == plugin, this is something that could work: First you get a list of all plugins. When you select one, you get a bunch of side blocks for the various things you can configure there. Consider what we now have as the contents of a tab, e.g. for the "Stories and Trackback" tab, we have: - Trackback - Pingback - Story Now we put those in a block and when you click on "Trackback", you get only the Trackback settings in the center area. I.e. only one fieldset at a time. And what is now a tab would be a side block. Let me try some ASCII art ... [Stories & TB] +-[Trackback]-------------------------------+ |Trackback | | Trackback? [True] | |Pingback | | Trackback Default [Trackback Enabled] | |Story | | Multiple Trackbacks [Reject] | | Trackback Speed Limit [300] | [Topics & DD ] | Check Trackbacks [Check full URL] | |Topic | +-------------------------------------------+ |Who's Online| |Daily Digest| |What's New | This would have the added bonus of being able to see all the available options (or option groups, really) at once without having to hunt through the menu. And it should be very extensible. But, as I said, it's probably a lot of work ... bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From devel at portalparts.com Sun Jan 6 18:53:19 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 06 Jan 2008 18:53:19 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080106174736.332806063@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.haun-online.de> <4780E2AC.9030602@portalparts.com> <20080106145428.594572461@smtp.haun-online.de> <20080106174736.332806063@smtp.haun-online.de> Message-ID: <478169EF.80805@portalparts.com> Dirk, I think that may be the way to go - use the left block area. As you suggest, we could use a left block to pick the component (core or plugin) and second menu that displays the component. This would eliminate the menu issue completely. The other idea is a leftblock area menu like this one: http://www.cssplay.co.uk/menus/slide_fly.html Which presents the dual menu idea into a single menu. Blaine Dirk Haun wrote: > Dirk Haun wrote: > > >> I think we just need something that wraps around nicely. >> > > I had a look at the Wordpress "Dashboard", but that doesn't provide any > solution that would help us. Effectively, they have a simple two-row > menu bar and both rows wrap around on small windows. It works, but if > you assume the top row is used for the plugins and you have a lot of > them you'll end up with a row that wraps around twice or more. > > > Another idea, but that could be a lot of work: I had a look at the web > interface my hosting service provides. When you think domain == plugin, > this is something that could work: > > First you get a list of all plugins. When you select one, you get a > bunch of side blocks for the various things you can configure there. > > Consider what we now have as the contents of a tab, e.g. for the > "Stories and Trackback" tab, we have: > > - Trackback > - Pingback > - Story > > Now we put those in a block and when you click on "Trackback", you get > only the Trackback settings in the center area. I.e. only one fieldset > at a time. And what is now a tab would be a side block. > > Let me try some ASCII art ... > > [Stories & TB] +-[Trackback]-------------------------------+ > |Trackback | | Trackback? [True] | > |Pingback | | Trackback Default [Trackback Enabled] | > |Story | | Multiple Trackbacks [Reject] | > | Trackback Speed Limit [300] | > [Topics & DD ] | Check Trackbacks [Check full URL] | > |Topic | +-------------------------------------------+ > |Who's Online| > |Daily Digest| > |What's New | > > > This would have the added bonus of being able to see all the available > options (or option groups, really) at once without having to hunt > through the menu. And it should be very extensible. > > But, as I said, it's probably a lot of work ... > > bye, Dirk > > > From dirk at haun-online.de Sun Jan 13 10:56:16 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 13 Jan 2008 16:56:16 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <478169EF.80805@portalparts.com> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.h aun-online.de> <4780E2AC.9030602@portalparts.com> <20080106145428.594572461@sm tp.haun-online.de> <20080106174736.332806063@smtp.haun-online.de> <478169EF.80805@portalparts.com> Message-ID: <20080113155616.568206934@smtp.haun-online.de> Blaine Lang wrote: >I think that may be the way to go - use the left block area. Does our current block code actually let you do that? I.e. hide the current left blocks and, just for the current page, display a completely different selection? I know you can add blocks dynamically. But I have to admit that I don't really understand the block code any more ... bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ From dirk at haun-online.de Sun Jan 13 11:39:38 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 13 Jan 2008 17:39:38 +0100 Subject: [geeklog-devel] State of 1.5 development? Message-ID: <20080113163938.1045287600@smtp.haun-online.de> So, where are we in 1.5 development? The biggest remaining issue appears to be the config GUI (see other posts). I spent some time with the Links plugin and consider that done now. I ran into one or two glitches in the Polls plugin today - have to look into that (shouldn't be too much, hopefully). The Webservices API is finished, too. I've added some end-user documentation to the wiki as well as some implementation details and notes on the compliance to RFC 5023: http://wiki.geeklog.net/wiki/index.php/Using_the_Webservices http://wiki.geeklog.net/wiki/index.php/Webservices_API Misc. items from my list: * MS SQL support. I guess the SQL files are not up to date. Anyone willing to look into it? * FCKeditor. We should plan to include the current version by the time we actually ship 1.5. * Anything else? Some testing is also needed, of course. I'm almost ready to upgrade Damn Spam! to 1.5. The only thing holding me back is the config GUI - mostly because it's a bit awkward to update if you only have access through ftp and phpMyAdmin ... bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From dirk at haun-online.de Sun Jan 13 11:51:15 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 13 Jan 2008 17:51:15 +0100 Subject: [geeklog-devel] Relicensing the feed parser code (was: GPLv3) In-Reply-To: <7b42e7470707071414r5b4a1635if60fbee5b39260b9@mail.gmail.com> References: <20070629195139.1438474201@smtp.haun-online.de> <20070707175233.1923336566@smtp.haun-online.de> <7b42e7470707071121s1cbd5222j6aafec0125e5e87d@mail.gmail.com> <20070707194235.2139146745@smtp.haun-online.de> <7b42e7470707071414r5b4a1635if60fbee5b39260b9@mail.gmail.com> Message-ID: <20080113165115.1748273989@smtp.haun-online.de> Michael Jervis wrote (in a post back in July): >In that case I hearby grant the geeklog project full copyright of the >software and the ability to then license it under any license the >project sees fit to distribute it under. I'd suggest that we re-license Mike's feed parser code under the GPLv2 as of Geeklog 1.5. That would bring us one step closer to having the same license on all of our code. Plus we've already concluded that the only license change that we can realistically make anyway (if we wanted to) would be to GPLv3, so we're not giving any options up there. Any objections? bye, Dirk For reference: Discussion started here (note that it carries over into July) List of the various pieces of Geeklog and their license: Mike's post, as quoted above: -- http://www.geeklog.net/ http://geeklog.info/ From devel at portalparts.com Sun Jan 13 12:57:45 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 13 Jan 2008 12:57:45 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080113155616.568206934@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.h aun-online.de> <4780E2AC.9030602@portalparts.com> <20080106145428.594572461@sm tp.haun-online.de> <20080106174736.332806063@smtp.haun-online.de> <478169EF.80805@portalparts.com> <20080113155616.568206934@smtp.haun-online.de> Message-ID: <478A5119.8070005@portalparts.com> Hi Dirk, Yes, it can in fact do that. I will work on an example of this idea for the config manager today. Blaine Dirk Haun wrote: > Blaine Lang wrote: > > >> I think that may be the way to go - use the left block area. >> > > Does our current block code actually let you do that? I.e. hide the > current left blocks and, just for the current page, display a completely > different selection? > > I know you can add blocks dynamically. But I have to admit that I don't > really understand the block code any more ... > > bye, Dirk > > > From dirk at haun-online.de Sun Jan 13 13:14:16 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 13 Jan 2008 19:14:16 +0100 Subject: [geeklog-devel] Call for ideas and mentors for the SoC 2008 Message-ID: <20080113181416.328443735@smtp.haun-online.de> Should Google decide to run the Summer of Code program again this year, we can probably expect an announcement sometime in February, followed by a short application phase for projects. So assuming we want to take part again this year, it's about time we start collecting ideas. We would also need mentors. I don't know about Tony and Blaine, but I've decided to take only one student this year. Matt and Ramnath were great to work with and mostly found their way through Geeklog's traps and pitfalls without my help, but I always felt guilty for not spending enough time with them. So I think we should try and get some "fresh blood" on board this year. Which includes former students, btw (something that Google encourages). Also, I think we don't need to restrict ourselves to the core Geeklog code - we could easily take a few plugins under the Geeklog umbrella. There already was some interest in an e-commerce plugin last year, but improving existing plugins would also suit the program nicely, I would think. I've cleaned up the Wiki page for your perusal: http://wiki.geeklog.net/wiki/index.php/Google_Summer_of_Code bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From joe at ThrowingDice.com Sun Jan 13 13:41:32 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Sun, 13 Jan 2008 13:41:32 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080113155616.568206934@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <4780E2AC.9030602@portalparts.com> <20080106174736.332806063@smtp.haun-online.de> <478169EF.80805@portalparts.com> <20080113155616.568206934@smtp.haun-online.de> Message-ID: <0JUL00INIIN4W5P0@mta2.srv.hcvlny.cv.net> At 10:56 AM 1/13/2008, Dirk Haun wrote: >Blaine Lang wrote: > > >I think that may be the way to go - use the left block area. > >Does our current block code actually let you do that? I.e. hide the >current left blocks and, just for the current page, display a completely >different selection? If you are going to suppress all the other left blocks, why not just make the page display no blocks and div up the page anyway you want? This way the navigation box is always on the left and not slung along the bottom if that where the admin's "left" blocks are. This way you don't clutter the blocks table and don't have to deal with themes that shuffle stuff around. The config page has a single look and feel. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From mjervis at gmail.com Sun Jan 13 13:58:26 2008 From: mjervis at gmail.com (Michael Jervis) Date: Sun, 13 Jan 2008 18:58:26 +0000 Subject: [geeklog-devel] Relicensing the feed parser code (was: GPLv3) In-Reply-To: <20080113165115.1748273989@smtp.haun-online.de> References: <20070629195139.1438474201@smtp.haun-online.de> <20070707175233.1923336566@smtp.haun-online.de> <7b42e7470707071121s1cbd5222j6aafec0125e5e87d@mail.gmail.com> <20070707194235.2139146745@smtp.haun-online.de> <7b42e7470707071414r5b4a1635if60fbee5b39260b9@mail.gmail.com> <20080113165115.1748273989@smtp.haun-online.de> Message-ID: <7b42e7470801131058idb8d2ddk50cc2f27b86c27a8@mail.gmail.com> > Any objections? No objections, but, just wondering does it help to have the less-restrictive code tightened up at all? From mevans at ecsnet.com Sun Jan 13 17:13:33 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Sun, 13 Jan 2008 16:13:33 -0600 Subject: [geeklog-devel] State of 1.5 development? In-Reply-To: <20080113163938.1045287600@smtp.haun-online.de> References: <20080113163938.1045287600@smtp.haun-online.de> Message-ID: <478A8D0D.6030406@ecsnet.com> Here's what I have on my list that I've posted a couple of times.... UTF-8 SUPPORT There is no method on installation or through configuration to make a site UTF-8. STORY EDITOR Using HTML Editor (not advanced editor), each time I preview I get a lot of whitespace injected at the beginning and at the end of the text. This is caused by the template, it has the following: So the spaces between the beginning textarea are being picked up. You'll only see this if you are using HTML editor (not advanced). Thanks! Mark Dirk Haun wrote: > So, where are we in 1.5 development? > > The biggest remaining issue appears to be the config GUI (see other posts). > > I spent some time with the Links plugin and consider that done now. I > ran into one or two glitches in the Polls plugin today - have to look > into that (shouldn't be too much, hopefully). > > The Webservices API is finished, too. I've added some end-user > documentation to the wiki as well as some implementation details and > notes on the compliance to RFC 5023: > > http://wiki.geeklog.net/wiki/index.php/Using_the_Webservices > http://wiki.geeklog.net/wiki/index.php/Webservices_API > > Misc. items from my list: > > * MS SQL support. I guess the SQL files are not up to date. Anyone > willing to look into it? > > * FCKeditor. We should plan to include the current version by the time > we actually ship 1.5. > > * Anything else? > > Some testing is also needed, of course. I'm almost ready to upgrade Damn > Spam! to 1.5. The only thing holding me back is the config GUI - mostly > because it's a bit awkward to update if you only have access through ftp > and phpMyAdmin ... > > bye, Dirk > > > From mevans at ecsnet.com Sun Jan 13 17:16:22 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Sun, 13 Jan 2008 16:16:22 -0600 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/layout/professional droplinemenu.css, 1.1, 1.2 In-Reply-To: <20080113155616.568206934@smtp.haun-online.de> References: <20080105234552.4E98610FE14@qs1489.pair.com> <20080106082415.606721504@smtp.h aun-online.de> <4780E2AC.9030602@portalparts.com> <20080106145428.594572461@sm tp.haun-online.de> <20080106174736.332806063@smtp.haun-online.de> <478169EF.80805@portalparts.com> <20080113155616.568206934@smtp.haun-online.de> Message-ID: <478A8DB6.5070808@ecsnet.com> Keep in mind there are sites that do not use the left blocks. Will placing the configuration menu there cause a problem? I've even seen custom themes that do not include any of the left block calls in the templates. I believe Joe's recommendation of forgetting about the blocks and using divs in the config templates is the right way to do it. This is what I've done in Media Gallery to ensure that I have the menus I need regardless of how the admin has configured the site. Thanks! Mark Dirk Haun wrote: > Blaine Lang wrote: > > >> I think that may be the way to go - use the left block area. >> > > Does our current block code actually let you do that? I.e. hide the > current left blocks and, just for the current page, display a completely > different selection? > > I know you can add blocks dynamically. But I have to admit that I don't > really understand the block code any more ... > > bye, Dirk > > > From dirk at haun-online.de Sun Jan 13 17:23:29 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 13 Jan 2008 23:23:29 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/admin configuration.php, 1.3, 1.4 In-Reply-To: <20080113214717.23B7E10FE12@qs1489.pair.com> References: <20080113214717.23B7E10FE12@qs1489.pair.com> Message-ID: <20080113222329.375231378@smtp.haun-online.de> Blaine Lang wrote: >Log Message: >Changes to support using a leftblock menu for the configmanager menu. >Note: I will clean this up if this approach is accepted as the final solution. Yes, this looks much better (IMHO, FWIW, anyway) and should "scale" much better than the previous version. bye, Dirk -- http://www.haun-online.de/ http://spam.tinyweb.net/ From info at heatherengineering.com Sun Jan 13 22:02:32 2008 From: info at heatherengineering.com (info at heatherengineering.com) Date: Sun, 13 Jan 2008 22:02:32 -0500 Subject: [geeklog-devel] Tracker plugin (idea) Message-ID: I just remembered this, which I suggested to Tom (webmaster) back in April last year, and thought I'd throw it out there now that you're looking for ideas for SoC - I don't think it is exciting enough for an SoC project, but if someone is looking for a plugin idea, they are welcome to this one as I won't have time to make it: The "Tracker" Plugin. Using JpGraph (http://www.aditus.nu/jpgraph/), it is possible to make pretty pictures (this page used to work back in 2006 showing stats for gl but is not right now for some reason: eg http://www.heatherengineering.com/staticpages/ index.php?page=jpgraph-en). A simple plugin that allows users to create "trackers": basically tables of data that allow them to enter values every now and then, which are then automatically shown as graphs or tables. When a tracker is created, the user chooses how many variables to track, and is queried for them from a dynamically created form each time they choose to update the tracker. Perhaps the user can also choose whether to group trackers into meta-groups, or perhaps a single tracker can contain multiple "items" that are graphed/tracked. So, eg, a user creates a tracker called "weight", and enters their weight in kg every now and then with the date of measurement, which is then automatically graphed. If desired, this could be grouped with another item tracking "number of cookies eaten today" so that the two graphs are shown on the same page, or the two items can be combined into one tracker. The user can have a personal page that shows their trackers as graphs, and clicking on the tracker goes to a page for that tracker that gives the graph and more details if wanted. Users can set trackers to be private or public, and there can be a public page to show trackers, or perhaps users can choose which users' trackers they want to see. Cheers, Euan. From marco at heavenlysanctuary.com Fri Jan 18 17:20:45 2008 From: marco at heavenlysanctuary.com (Marco Belmonte) Date: Fri, 18 Jan 2008 14:20:45 -0800 Subject: [geeklog-devel] Performance In-Reply-To: <20080113222329.375231378@smtp.haun-online.de> References: <20080113214717.23B7E10FE12@qs1489.pair.com> <20080113222329.375231378@smtp.haun-online.de> Message-ID: <004501c85a20$5f54b7a0$1dfe26e0$@com> Hi Devs, I thought some of you may be interested in the following thread that I started over on glLabs concerning some of the issues that I was having with Geeklog performance. Because I'm not a programmer I couldn't do much to tweak the code so I took it upon myself to start doing everything a non-programmer/typical sysadmin could do to help enhance Geeklog performance. The thread outlines in detail our hardware setup consisting of three servers, all of the software involved and the configuration of that software and of course the benchmark results as each new discovery was implemented. The thread is still a work in process and I haven't finished, but it's easily far along enough now that it may be helpful for the developers of GL to use as a way to rule where enhancements to the code may be beneficial as opposed to user configuration problems. As a side note, for those who may not have the time to read through 15 or so pages, I was able to boost Geeklog performance by almost 100% so far. The only software modification that I made with the help of Joe Mucchiello was GL's template system. Joe's caching template mod was responsible for almost 50% of the 100% increase. I really appreciate all the work you developers have done to make GL what it is. I look forward to all of the great stuff you all haven't even thought about yet! :-) Warmly, - Marco Belmonte PS: Uh, maybe I should post the link: http://www.gllabs.org/forum/viewtopic.php?showtopic=7318 From dirk at haun-online.de Sat Jan 19 17:21:26 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 19 Jan 2008 23:21:26 +0100 Subject: [geeklog-devel] Relicensing the feed parser code (was: GPLv3) In-Reply-To: <7b42e7470801131058idb8d2ddk50cc2f27b86c27a8@mail.gmail.com> References: <20070629195139.1438474201@smtp.haun-online.de> <20070707175233.1923336566@smtp.haun-online.de> <7b42e7470707071121s1cbd5222j6aafec0125e5e87d@mail.gmail.com> <20070707194235.2139146745@smtp.haun-online.de> <7b42e7470707071414r5b4a1635if60fbee5b39260b9@mail.gmail.com> <20080113165115.1748273989@smtp.haun-online.de> <7b42e7470801131058idb8d2ddk50cc2f27b86c27a8@mail.gmail.com> Message-ID: <20080119222126.531215923@smtp.haun-online.de> Michael Jervis wrote: >just wondering does it help to have the >less-restrictive code tightened up at all? After thinking some more about this - I guess you're right. There's no immediate need or benefit from a license change. Other than it being nice and orderly and that 1.5 sounded like a good cutoff point. Okay, so we leave things as they are unless we really need it. bye, Dirk -- http://www.haun-online.de/accu/ From dirk at haun-online.de Sat Jan 19 17:17:22 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 19 Jan 2008 23:17:22 +0100 Subject: [geeklog-devel] State of 1.5 development? In-Reply-To: <478A8D0D.6030406@ecsnet.com> References: <20080113163938.1045287600@smtp.haun-online.de> <478A8D0D.6030406@ecsnet.com> Message-ID: <20080119221722.284959759@smtp.haun-online.de> Mark R. Evans wrote: >STORY EDITOR >Using HTML Editor (not advanced editor), each time I preview I get a lot >of whitespace injected at the beginning and at the end of the text. >This is caused by the template, it has the following: > > I don't see that. Not in CVS and not in 1.4.1 either. Must be something on your end ... bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From geiss at midnightforce.com Sat Jan 19 19:01:32 2008 From: geiss at midnightforce.com (=MF=Geiss) Date: Sat, 19 Jan 2008 17:01:32 -0700 Subject: [geeklog-devel] Staticpages plugin - Print icon Message-ID: <47928F5C.4010001@midnightforce.com> Does the Staticpages plugin have a config option to hide the print and edit icons? I know you can manually edit it out in (path_to_geeklog)/plugins/staticpages/templates/centerblock.thtml, but it would be nice if this was part of the online config, just like the current options to hide the hit counter and date. Thx! Eric From mark at the-howards.net Sat Jan 19 19:26:51 2008 From: mark at the-howards.net (Mark Howard) Date: Sat, 19 Jan 2008 19:26:51 -0500 Subject: [geeklog-devel] Staticpages plugin - Print icon In-Reply-To: <47928F5C.4010001@midnightforce.com> References: <47928F5C.4010001@midnightforce.com> Message-ID: <011b01c85afb$27841d80$768c5880$@net> The printer icon behavior for staticpages is currently a global 'story setting': $_CONF['hideprintericon'] .. although I agree that I would like to independently control the visibility of that icon in staticpage rendering, and therefore wish it were a plugin config item. I don't know that hiding the edit link for users that have permissions has any kind of precedent wrt stories, etc., but I suppose it could be useful. (my 2cents) -m -----Original Message----- From: geeklog-devel-bounces at lists.geeklog.net [mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of =MF=Geiss Sent: Saturday, January 19, 2008 7:02 PM To: Geeklog Development Subject: [geeklog-devel] Staticpages plugin - Print icon Does the Staticpages plugin have a config option to hide the print and edit icons? I know you can manually edit it out in (path_to_geeklog)/plugins/staticpages/templates/centerblock.thtml, but it would be nice if this was part of the online config, just like the current options to hide the hit counter and date. Thx! Eric _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://eight.pairlist.net/mailman/listinfo/geeklog-devel From mevans at ecsnet.com Sat Jan 19 22:49:38 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Sat, 19 Jan 2008 21:49:38 -0600 Subject: [geeklog-devel] State of 1.5 development? In-Reply-To: <20080119221722.284959759@smtp.haun-online.de> References: <20080113163938.1045287600@smtp.haun-online.de> <478A8D0D.6030406@ecsnet.com> <20080119221722.284959759@smtp.haun-online.de> Message-ID: <4792C4D2.2030609@ecsnet.com> From the CVS viewer: public_html/layout/professional/admin/story/storyeditor_advanced.thtml
    {lang_introtext}: {lang_bodytext}:
    Notice the The same applies to the story_bodytext too. Thanks! Mark Dirk Haun wrote: > Mark R. Evans wrote: > > >> STORY EDITOR >> Using HTML Editor (not advanced editor), each time I preview I get a lot >> of whitespace injected at the beginning and at the end of the text. >> This is caused by the template, it has the following: >> >> >> > > I don't see that. Not in CVS and not in 1.4.1 either. Must be something > on your end ... > > bye, Dirk > > > From dirk at haun-online.de Sun Jan 20 03:18:53 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 20 Jan 2008 09:18:53 +0100 Subject: [geeklog-devel] State of 1.5 development? In-Reply-To: <4792C4D2.2030609@ecsnet.com> References: <20080113163938.1045287600@smtp.haun-online.de> <478A8D0D.6030406@ecsnet.com> <20080119221722.284959759@smtp.haun-online.de> <4792C4D2.2030609@ecsnet.com> Message-ID: <20080120081853.1758706660@smtp.haun-online.de> Mark R. Evans wrote: > From the CVS viewer: >public_html/layout/professional/admin/story/storyeditor_advanced.thtml Right. But that's for the advanced editor (FCKEditor) and you explictly said you did see it in the normal editor. That's what confused me ... bye, Dirk -- http://www.haun-online.de/accu/ From mevans at ecsnet.com Sun Jan 20 09:29:38 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Sun, 20 Jan 2008 08:29:38 -0600 Subject: [geeklog-devel] State of 1.5 development? In-Reply-To: <20080120081853.1758706660@smtp.haun-online.de> References: <20080113163938.1045287600@smtp.haun-online.de> <478A8D0D.6030406@ecsnet.com> <20080119221722.284959759@smtp.haun-online.de> <4792C4D2.2030609@ecsnet.com> <20080120081853.1758706660@smtp.haun-online.de> Message-ID: <47935AD2.6010901@ecsnet.com> Sorry Dirk, I should have been a bit clearer on the description. Advanced Editor is enabled, but I'm selecting Post Mode: HTML Formatted, so I'm never using the advanced editor. Anyway, it looks like you got it fixed, thanks! Mark Dirk Haun wrote: > Mark R. Evans wrote: > > >> From the CVS viewer: >> public_html/layout/professional/admin/story/storyeditor_advanced.thtml >> > > Right. But that's for the advanced editor (FCKEditor) and you explictly > said you did see it in the normal editor. That's what confused me ... > > bye, Dirk > > > From dirk at haun-online.de Sun Jan 20 16:11:03 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 20 Jan 2008 22:11:03 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <20080120205519.598EE10FE14@qs1489.pair.com> References: <20080120205519.598EE10FE14@qs1489.pair.com> Message-ID: <20080120211103.1230753205@smtp.haun-online.de> Dirk Haun wrote: >Log Message: >Introduced a new config type 'fn:' that calls a specified function to >provide contents of a dropdown at runtime, e.g. for the language and >theme selection Can I have some opinions on this, please? Aaron, Blaine, anyone? In a nutshell, this introduces a new config type 'fn:' which, when written as "fn:something" calls a function configmanager_something, expecting it to return the selection array. In other words, it's a dynamic version of the 'select' type. I've already implemented it for the two obvious candidates: The site's default language and theme. As others have pointed out, we already have functions that provide dropdowns for those, so why not use them in the configuration (well, they both needed small wrapper functions ...). Is the function name okay or should it start with "CONF_" instead? Any room for improvements? bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From dirk at haun-online.de Sun Jan 20 16:54:15 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 20 Jan 2008 22:54:15 +0100 Subject: [geeklog-devel] Plugin version number in configuration Message-ID: <20080120215415.1697026970@smtp.haun-online.de> While we're brainstorming: The first entry on the configuration screen for the static pages plugin currently is - the plugin's version number. Which really doesn't belong there. Sticking it into the code somewhere is awkward, so I was thinking if maybe we need a "hidden" type for config options. Or will this provide the potential for misuse? Maybe we should simply hide options that are named "version"? bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From devel at portalparts.com Sun Jan 20 17:05:58 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 20 Jan 2008 17:05:58 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <20080120211103.1230753205@smtp.haun-online.de> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> Message-ID: <4793C5C6.8030000@portalparts.com> Dirk, I was wondering why we need a new config type and not just check for the existance of a configmanager_fieldname function? I was thinking we need to check for a function to feed the values to a config parm as well as validate upon save. The validate function could do any post processing like convert days to seconds (if a field wanted to present a update frequency in days and field needed to be saved as seconds). configmanager_fieldname_preprocess() and configmanager_fieldname_postprocess() Most likely the preprocess function would only be used for checkboxes, select and radio fields but postprocess may be used or any config parm. Blaine Dirk Haun wrote: > Dirk Haun wrote: > > >> Log Message: >> Introduced a new config type 'fn:' that calls a specified function to >> provide contents of a dropdown at runtime, e.g. for the language and >> theme selection >> > > Can I have some opinions on this, please? Aaron, Blaine, anyone? > > In a nutshell, this introduces a new config type 'fn:' which, when > written as "fn:something" calls a function configmanager_something, > expecting it to return the selection array. In other words, it's a > dynamic version of the 'select' type. > > I've already implemented it for the two obvious candidates: The site's > default language and theme. As others have pointed out, we already have > functions that provide dropdowns for those, so why not use them in the > configuration (well, they both needed small wrapper functions ...). > > Is the function name okay or should it start with "CONF_" instead? Any > room for improvements? > > bye, Dirk > > > From mevans at ecsnet.com Sun Jan 20 18:04:08 2008 From: mevans at ecsnet.com (Mark R. Evans) Date: Sun, 20 Jan 2008 17:04:08 -0600 (CST) Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <4793C5C6.8030000@portalparts.com> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> <4793C5C6.8030000@portalparts.com> Message-ID: <20080120170122.Q10644@kimber.ecsnet.org> I would recommend that if you check for the existence of the function, you use a slightly different naming convention. Instead of configmanager_fieldname, use configmanager_core/pluginnumae_fieldname, this will prevent plugins that might take advantage of this from worrying about duplicate field names. Also, I prefer to see 'geeklog' instead of Core, at least in the text prompts. For the non-technical folks using Geeklog, I think it would make more sense. Thanks! Mark On Sun, 20 Jan 2008, Blaine Lang wrote: > Dirk, > > I was wondering why we need a new config type and not just check for the > existance of a configmanager_fieldname function? > > I was thinking we need to check for a function to feed the values to a config > parm as well as validate upon save. The validate function could do any post > processing like convert days to seconds (if a field wanted to present a > update frequency in days and field needed to be saved as seconds). > > configmanager_fieldname_preprocess() and > configmanager_fieldname_postprocess() > > Most likely the preprocess function would only be used for checkboxes, select > and radio fields but postprocess may be used or any config parm. > > Blaine > > Dirk Haun wrote: >> Dirk Haun wrote: >> >> >>> Log Message: >>> Introduced a new config type 'fn:' that calls a specified function to >>> provide contents of a dropdown at runtime, e.g. for the language and >>> theme selection >>> >> >> Can I have some opinions on this, please? Aaron, Blaine, anyone? >> >> In a nutshell, this introduces a new config type 'fn:' which, when >> written as "fn:something" calls a function configmanager_something, >> expecting it to return the selection array. In other words, it's a >> dynamic version of the 'select' type. >> >> I've already implemented it for the two obvious candidates: The site's >> default language and theme. As others have pointed out, we already have >> functions that provide dropdowns for those, so why not use them in the >> configuration (well, they both needed small wrapper functions ...). >> >> Is the function name okay or should it start with "CONF_" instead? Any >> room for improvements? >> >> bye, Dirk >> >> >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://eight.pairlist.net/mailman/listinfo/geeklog-devel > > From joe at ThrowingDice.com Sun Jan 20 22:00:03 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Sun, 20 Jan 2008 22:00:03 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <4793C5C6.8030000@portalparts.com> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> <4793C5C6.8030000@portalparts.com> Message-ID: <0JUZ00JO74C9Z560@mta2.srv.hcvlny.cv.net> At 05:05 PM 1/20/2008, Blaine Lang wrote: >Dirk, > >I was wondering why we need a new config type and not just check for >the existance of a configmanager_fieldname function? So you could have a series of similar config settings with the same options not clutter the system with a bunch of duplicate functions. For example, if for some reason you needed to store dates in the configuration, there's no reason to have more than one function that displays dates. Of course, one could say having both is most flexible. Have configmanager_type_$type for new classes of data and have configmanager_field_$fieldname for specific fields that need special processing. But my example below assumes there are just "types". >I was thinking we need to check for a function to feed the values to >a config parm as well as validate upon save. The validate function >could do any post processing like convert days to seconds (if a >field wanted to present a update frequency in days and field needed >to be saved as seconds). > >configmanager_fieldname_preprocess() and configmanager_fieldname_postprocess() Why spend time call function_exists more than once? What happens when preprocess and postprocess aren't enough? And they aren't, there should be three state: to_display, to_edit, and to_save. Arguably there could be a 4th state: to_validate called before save but they can be combined. function configmanager_type_$type($config_object, $mode, $param, $extra = null) $config_object is the config object instance. $mode could be 'display', 'edit', 'save'. $param is the database entry for the item. $extra depends on the mode. At the moment only save would use it. Save uses it to hold the $_POST array of the field list received during "edit" mode. That should be infinitely extensible. Return is always an array. A return of false means the function does not process that mode. (Returning an array means the returns can also be extensible.) Return for display mode is HTML text for displaying the current value. Return for edit mode is a map: 'html' => $html_text, 'fields' => array of fields where html_text is $date); case 'edit': return Array( 'fields' => Array($param['name'].'_month', $param['name'].'_day', $param['name'].'_year'), 'html' => " / / " ); case 'save': $month = COM_applyFilter($extra[$param['name'].'_month'], true); $day = COM_applyFilter($extra[$param['name'].'_day'], true); $year = COM_applyFilter($extra[$param['name'].'_year'], true); return Array('value' => mktime(0,0,0,$month, $day, $year)); } return false; } Other potential modes could be stuff like "default_value". For a date field, default might always be "today". >>Is the function name okay or should it start with "CONF_" instead? Any >>room for improvements? I prefer user callback functions to have the long names like plugin_ and phpblock_ whereas API functions should have short names like PLG_, COM_, SEC_ >>bye, Dirk >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://eight.pairlist.net/mailman/listinfo/geeklog-devel ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From devel at portalparts.com Sun Jan 20 22:43:30 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 20 Jan 2008 22:43:30 -0500 Subject: [geeklog-devel] Plugin version number in configuration In-Reply-To: <20080120215415.1697026970@smtp.haun-online.de> References: <20080120215415.1697026970@smtp.haun-online.de> Message-ID: <479414E2.1060903@portalparts.com> I agree and thought I pulled that out last time I was working on the plugin. The install.php for the plugin has it defined because we do not want to have a plugins config.php and there is no need for a config file of a different name with just that one variable. I suggest it be removed as it should not be something the user/admin can change without doing a proper plugin upgrade. Blaine Dirk Haun wrote: > While we're brainstorming: > > The first entry on the configuration screen for the static pages plugin > currently is - the plugin's version number. Which really doesn't belong there. > > Sticking it into the code somewhere is awkward, so I was thinking if > maybe we need a "hidden" type for config options. Or will this provide > the potential for misuse? Maybe we should simply hide options that are > named "version"? > > bye, Dirk > > > From devel at portalparts.com Sun Jan 20 22:53:39 2008 From: devel at portalparts.com (Blaine Lang) Date: Sun, 20 Jan 2008 22:53:39 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <0JUZ00JO74C9Z560@mta2.srv.hcvlny.cv.net> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> <4793C5C6.8030000@portalparts.com> <0JUZ00JO74C9Z560@mta2.srv.hcvlny.cv.net> Message-ID: <47941743.7010904@portalparts.com> Joe Mucchiello wrote: > So you could have a series of similar config settings with the same options not clutter the system with a bunch of duplicate functions. For example, if for some reason you needed to store dates in the configuration, there's no reason to have more than one function that displays dates. Create a function stub for those fields and call a common date format function. I'd rather not have to create a new config option type which appears to be more restrictive. I don't expect most plugin config options will need these extra functions. > Why spend time call function_exists more than once? What time - this is the configmanager code that is called on edit and I don't think a few extra microseconds are going to matter. > What happens when preprocess and postprocess aren't enough? And they aren't, there should be three state: to_display, to_edit, and to_save. Arguably there could be a 4th state: to_validate called before save but they can be combined. There is only an edit mode, so I see no need for a display option and validate would be done in the postprocess function. Blaine From joe at ThrowingDice.com Sun Jan 20 23:20:37 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Sun, 20 Jan 2008 23:20:37 -0500 Subject: [geeklog-devel] Plugin version number in configuration In-Reply-To: <479414E2.1060903@portalparts.com> References: <20080120215415.1697026970@smtp.haun-online.de> <479414E2.1060903@portalparts.com> Message-ID: <0JUZ0024G82DEJ50@mta4.srv.hcvlny.cv.net> At 10:43 PM 1/20/2008, Blaine Lang wrote: >I agree and thought I pulled that out last time I was working on the >plugin. The install.php for the plugin has it defined because we do >not want to have a plugins config.php and there is no need for a >config file of a different name with just that one variable. > >I suggest it be removed as it should not be something the user/admin >can change without doing a proper plugin upgrade. It should be in function.php so the admin/plugin.php screen can access it to see if the code is out of date with the plugin table. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From joe at ThrowingDice.com Sun Jan 20 23:45:53 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Sun, 20 Jan 2008 23:45:53 -0500 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <47941743.7010904@portalparts.com> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> <4793C5C6.8030000@portalparts.com> <0JUZ00JO74C9Z560@mta2.srv.hcvlny.cv.net> <47941743.7010904@portalparts.com> Message-ID: <0JUZ00LW198H9P40@mta5.srv.hcvlny.cv.net> At 10:53 PM 1/20/2008, Blaine Lang wrote: >Joe Mucchiello wrote: > > So you could have a series of similar config settings with the > same options not clutter the system with a bunch of duplicate > functions. For example, if for some reason you needed to store > dates in the configuration, there's no reason to have more than one > function that displays dates. > >Create a function stub for those fields and call a common date >format function. I'd rather not have to create a new config option >type which appears to be more restrictive. I don't expect most >plugin config options will need these extra functions. I don't know how to respond to this. How is what I wrote "more restrictive"? Heck, I suggested having configmanager_type_$type AND configmanager_field_$fieldname. I write APIs for a living. I try to make them as flexible as possible. I'm trying to look ahead of the current issue to find a solution that not only solves the immediate need but will solve problems we don't know we have now. That means having extra stuff that you don't need now. We don't need a display option now. Maybe we will. Most web stuff has three states to_display, to_editor and to_database. Just because the config screen is locked in edit mode now doesn't mean it will always be that way. Using mode as a parameter if over time its meaning changes (will preprocess always be what we are doing?) we can change the mode to move with the new paradigm. If the function contains "preprocess" in it, we have less flexibility. This is just like the templatesetvars issue. It works passably but it could be so much better. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com From ironmax at spacequad.com Mon Jan 21 07:28:29 2008 From: ironmax at spacequad.com (Michael Brusletten) Date: Mon, 21 Jan 2008 07:28:29 -0500 Subject: [geeklog-devel] Bad Behavior and spammers References: Message-ID: <002401c85c29$26b59cb0$fe00a8c0@ns2.spacequad.com> To all site owners running Bad Behavior, I know this is not really the place to post this, but I wanted to get the message out as fast as I could to everyone that has been hit by Casino, Ringtones, and Credit Card spam. We need everyone that was hit by this spammer to contact us as soon as possible. We are in contact with the authorities that are investigating this matter. And they are asking us to find as many sites as possible that have been affected to contact us so that we can relay that information to them. Please drop me an email to admin at spacequad.com to be counted and we will also send you a transcript of the conversations. Thank you for your time in this matter. Michael Brusletten admin at spacequad.com Spacequad Anti-Spam Services Thunder Bay, Ontario ---------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirk at haun-online.de Mon Jan 21 14:04:26 2008 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 21 Jan 2008 20:04:26 +0100 Subject: [geeklog-devel] Bad Behavior and spammers In-Reply-To: <002401c85c29$26b59cb0$fe00a8c0@ns2.spacequad.com> References: <002401c85c29$26b59cb0$fe00a8c0@ns2.spacequad.com> Message-ID: <20080121190426.1334471202@smtp.haun-online.de> Michael Brusletten wrote: >I know this is not really the place to post this Yep. How about using the geeklog-spam list? Btw, where's the connection between Bad Behavior and Casino spam? bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From dirk at haun-online.de Mon Jan 21 14:24:15 2008 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 21 Jan 2008 20:24:15 +0100 Subject: [geeklog-devel] Plugin version number in configuration In-Reply-To: <0JUZ0024G82DEJ50@mta4.srv.hcvlny.cv.net> References: <20080120215415.1697026970@smtp.haun-online.de> <479414E2.1060903@portalparts.com> <0JUZ0024G82DEJ50@mta4.srv.hcvlny.cv.net> Message-ID: <20080121192415.385864479@smtp.haun-online.de> Joe Mucchiello wrote: >It should be in function.php so the admin/plugin.php screen can >access it to see if the code is out of date with the plugin table. Yeah, I completely forgot that it's needed there. No need to have it in the database at all (the current version is already in the gl_plugins table). functions.inc sounds like the best possible place. bye, Dirk -- http://www.haun-online.de/accu/ From dirk at haun-online.de Mon Jan 21 14:29:50 2008 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 21 Jan 2008 20:29:50 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/system/classes config.class.php, 1.16, 1.17 In-Reply-To: <20080120170122.Q10644@kimber.ecsnet.org> References: <20080120205519.598EE10FE14@qs1489.pair.com> <20080120211103.1230753205@smtp.haun-online.de> <4793C5C6.8030000@portalparts.com> <20080120170122.Q10644@kimber.ecsnet.org> Message-ID: <20080121192950.723130548@smtp.haun-online.de> Mark R. Evans wrote: >Also, I prefer to see 'geeklog' instead of Core, at least in the text >prompts. For the non-technical folks using Geeklog, I think it would make >more sense. Agreed. I'm also not too happy with "Staticpages" - it's the Static Pages plugin, it should be two words. In other words, there should be a language file entry that maps the internal name ('Core', 'staticpages') to a more userfriendly name for display. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From dirk at haun-online.de Sat Jan 26 13:41:15 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 26 Jan 2008 19:41:15 +0100 Subject: [geeklog-devel] [geeklog-cvs] Geeklog-1.x/public_html/admin/plugins/spamx install.php, 1.20, 1.21 In-Reply-To: <20080126183133.32DF610FE12@qs1489.pair.com> References: <20080126183133.32DF610FE12@qs1489.pair.com> Message-ID: <20080126184115.364293635@smtp.haun-online.de> Dirk Haun wrote: >+ /** >+ * Add plugin configuration >+ * >+ */ >+ function plugin_config() Yeah, I know - having the plugin config stuff in 4(!) different places is ... less than ideal. bye, Dirk -- http://www.haun-online.de/accu/ From dirk at haun-online.de Sat Jan 26 13:47:22 2008 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 26 Jan 2008 19:47:22 +0100 Subject: [geeklog-devel] Should we ship the Project Honey Pot module? Message-ID: <20080126184722.734972020@smtp.haun-online.de> While working on the config GUI for the Spam-X plugin, I began to wonder if we should really include the Project Honey Pot module in a standard Geeklog install. I mean, how many of our users are really going to set up a honeypot - which is a requirement to use this module? If we're not shipping it, then I can save myself the trouble of adding the config stuff for it. We could have an accompanying Admin module for the setup and provide it as a separate download on geeklog.net. It should even work with 1.4.1. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From joe at ThrowingDice.com Mon Jan 28 16:06:07 2008 From: joe at ThrowingDice.com (Joe Mucchiello) Date: Mon, 28 Jan 2008 16:06:07 -0500 Subject: [geeklog-devel] Config class Message-ID: <0JVD0019XHA6XFL0@mta2.srv.hcvlny.cv.net> Is there a reason the config class does not also deal with user configurations? Was it just out of scope for the GSOC? Seems to me most user config stuff is stuff that overrides a plugin's $_PLG_CONF array. Basically if I want to have configuable option in my plugin, the admin gets a builtin place to go set them. But if I want settings for the users I have to roll my own. Here's my thoughts on how it could be done without too much hassle. And it would eliminate lots of little tables in the database. Modify the conf_values table, add a by_user boolean. If true, the field can be set individually by user. Create a conf_user_values table: uid, group, name, value Add a global array to the class containing all the group/name pairs that can be set individually (saves a SELECT in several routines) Modify the add() function to include the "by_user" boolean. Modify the initconfig() function to read values out of the conf_user_values table after reading the main table. And to setup the new global array Modify the set() function with a new parameter "$target". It defaults to system where it modifies the system value of the parameter. The other value is 'user' where, after making sure the parameter can be set individually, it set the user table's value. Modify restore_param and unset_param similarly to set() although unset_param($target = 'user') is a delete. The del() function just needs to hit both tables. The ui function would need flags for whether they show the system values or the user values. There also might need to be flags for just showing one group of config options. Well, that's a lot of bullet points but none of them are very complex. ---- Joe Mucchiello Throwing Dice Games http://www.throwingdice.com