simplog-devel Mailing List for Simplog (Page 2)
Brought to you by:
f-bomb
Menu
▾
▴
simplog-devel — Mailing list for Simplog developers
You can subscribe to this list here.
| 2004 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(26) |
Sep
(29) |
Oct
|
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(3) |
May
(4) |
Jun
(12) |
Jul
(15) |
Aug
|
Sep
(4) |
Oct
(4) |
Nov
|
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Jim Hu <ji...@ta...> - 2005-07-11 19:14:07
|
I'll send notes and bugs as they come up. Install new worked smoothly on MacOSX 10.3 server running php5 Upgrade from 0.9 had a problem, but this may because my test database is already partially modified. Anyway, I get this error: [Mon Jul 11 13:51:52 2005] [error] PHP Notice: Undefined offset: 0 in /Volumes/dimer_web/WebServer/Documents/simplog_0.92/install/ 09to092.php on line 72 [Mon Jul 11 13:51:52 2005] [error] PHP Fatal error: mysql error: [1065: Query was empty] in ADODB_Error_Handler(, )\n in /Volumes/ dimer_web/WebServer/Documents/simplog_0.92/adodb/adodb- errorhandler.inc.php on line 77 It looks like the problem is after line 72 based on the notice. I also know that it successfully installed the new tables before it crashed. I wonder if this is because MySQL objected when the script tried to create a field that already exists. I don't understand why that would give "Query was empty", but perhaps that's a misleading diagnostic. This makes me wonder if we should check for the existence of a table or field before trying to add it. This would come up if someone crashes partway through an upgrade and then has to try again...when I rerun the script on the partially upgraded database, the script fails at the first sql statement. Going back to the working install, there's a bug that is also in the earlier release. When you have a calendar block and click on the month navigation, something gets messed up. I've been meaning to diagnose this but I haven't had a chance yet. That's it so far. Jim On Jul 10, 2005, at 8:00 PM, Jeremy Ashcraft wrote: > got another test release for you guys. hopefully this will be the > last > > http://www.simplog.org/simplog-0.9.2test2.tar.gz > > What's new: > > updated xmlrpc libs to fix security hole > fixed the no entry/preview bug > fixed a bug in posting from the aggregator > fixed the bugs jim pointed out to me > > I know i didn't want to add anything new, but Jim had brought up > something about using Flickr to enable adding images into posts, so > in messing around with it, i came up with a workable drop in for > this release. right now, it lets you enter in info for a flickr > account and an API key, then you can select from a list of > thumbnails in your flickr acct to add a thumbnail into a post. > play with it and let me know.... > > what's left: > TEST, TEST, TEST! > update the documentation (any takers? I hate doing documentation) > > I want to get this out the door so we can start on 1.0! > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel > |
|
From: Jeremy A. <ash...@13...> - 2005-07-11 01:00:12
|
got another test release for you guys. hopefully this will be the last http://www.simplog.org/simplog-0.9.2test2.tar.gz What's new: updated xmlrpc libs to fix security hole fixed the no entry/preview bug fixed a bug in posting from the aggregator fixed the bugs jim pointed out to me I know i didn't want to add anything new, but Jim had brought up something about using Flickr to enable adding images into posts, so in messing around with it, i came up with a workable drop in for this release. right now, it lets you enter in info for a flickr account and an API key, then you can select from a list of thumbnails in your flickr acct to add a thumbnail into a post. play with it and let me know.... what's left: TEST, TEST, TEST! update the documentation (any takers? I hate doing documentation) I want to get this out the door so we can start on 1.0! |
|
From: Jeremy A. <ash...@13...> - 2005-07-07 18:20:31
|
they've added ina check to disable their functions if the xmlrpc=20 extension is installed Jim Hu wrote: > I'm a bit confused about whether this affects the installations that =20 > comment out functions in the xmlrpc.inc libraries and use the ones =20 > that come installed in php. On a completely different subject, I'm =20 > starting another software project and am planning on using the =20 > modularity ideas from Tom and Jeremy for it. > > Jim > > On Jul 7, 2005, at 12:33 PM, Jeremy Ashcraft wrote: > >> I'l add it in tonight. I was on vacation last week, but have a lot =20 >> of free time this week, so i'll get 0.9.2 out the door and started=20 >> on 1.0. >> >> Thomas Cort wrote: >> >>> As reported on slashdot there is a new xmlrpc exploit. >>> http://it.slashdot.org/it/05/07/04/2153224.shtml?=20 >>> tid=3D95&tid=3D172&tid=3D169 >>> >>> I believe that simplog uses phpxmlrpc (xmlrpc.inc & xmlrpcs.inc). Wil= l >>> replacing those two files close the hole? >>> >>> The new version which fixes the code injection vulnerability can be >>> downloaded here: >>> http://prdownloads.sourceforge.net/phpxmlrpc/xmlrpc-1.1.1.tgz?downloa= d >>> >>> Security Advisories >>> http://secunia.com/advisories/15852/ >>> http://news.postnuke.com/Article2699.html >>> >>> -Tom >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategie= s >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk >>> _______________________________________________ >>> Simplog-devel mailing list >>> Sim...@li... >>> https://lists.sourceforge.net/lists/listinfo/simplog-devel >>> >>> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick >> _______________________________________________ >> Simplog-devel mailing list >> Sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simplog-devel > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel > |
|
From: Jim Hu <ji...@ta...> - 2005-07-07 18:04:53
|
I'm a bit confused about whether this affects the installations that =20 comment out functions in the xmlrpc.inc libraries and use the ones =20 that come installed in php. On a completely different subject, I'm =20 starting another software project and am planning on using the =20 modularity ideas from Tom and Jeremy for it. Jim On Jul 7, 2005, at 12:33 PM, Jeremy Ashcraft wrote: > I'l add it in tonight. I was on vacation last week, but have a lot =20= > of free time this week, so i'll get 0.9.2 out the door and started on =20= > 1.0. > > Thomas Cort wrote: > >> As reported on slashdot there is a new xmlrpc exploit. >> http://it.slashdot.org/it/05/07/04/2153224.shtml?=20 >> tid=3D95&tid=3D172&tid=3D169 >> >> I believe that simplog uses phpxmlrpc (xmlrpc.inc & xmlrpcs.inc). = Will >> replacing those two files close the hole? >> >> The new version which fixes the code injection vulnerability can be >> downloaded here: >> = http://prdownloads.sourceforge.net/phpxmlrpc/xmlrpc-1.1.1.tgz?download >> >> Security Advisories >> http://secunia.com/advisories/15852/ >> http://news.postnuke.com/Article2699.html >> >> -Tom >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration = Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk >> _______________________________________________ >> Simplog-devel mailing list >> Sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simplog-devel >> >> > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel |
|
From: Jeremy A. <ash...@13...> - 2005-07-07 17:33:44
|
I'l add it in tonight. I was on vacation last week, but have a lot of=20 free time this week, so i'll get 0.9.2 out the door and started on 1.0. Thomas Cort wrote: >As reported on slashdot there is a new xmlrpc exploit. >http://it.slashdot.org/it/05/07/04/2153224.shtml?tid=3D95&tid=3D172&tid=3D= 169 > >I believe that simplog uses phpxmlrpc (xmlrpc.inc & xmlrpcs.inc). Will >replacing those two files close the hole? > >The new version which fixes the code injection vulnerability can be >downloaded here: >http://prdownloads.sourceforge.net/phpxmlrpc/xmlrpc-1.1.1.tgz?download > >Security Advisories >http://secunia.com/advisories/15852/ >http://news.postnuke.com/Article2699.html > >-Tom > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk >_______________________________________________ >Simplog-devel mailing list >Sim...@li... >https://lists.sourceforge.net/lists/listinfo/simplog-devel > > =20 > |
|
From: Thomas C. <lin...@gm...> - 2005-07-04 23:34:20
|
As reported on slashdot there is a new xmlrpc exploit. http://it.slashdot.org/it/05/07/04/2153224.shtml?tid=3D95&tid=3D172&tid=3D1= 69 I believe that simplog uses phpxmlrpc (xmlrpc.inc & xmlrpcs.inc). Will replacing those two files close the hole? The new version which fixes the code injection vulnerability can be downloaded here: http://prdownloads.sourceforge.net/phpxmlrpc/xmlrpc-1.1.1.tgz?download Security Advisories http://secunia.com/advisories/15852/ http://news.postnuke.com/Article2699.html -Tom |
|
From: Jeremy A. <ash...@13...> - 2005-06-26 16:59:05
|
I've got a test release of 0.9.2 ready for you guys to bang around. finally. http://www.simplog.org/simplog-0.9.2test1.tar.gz What's inside: New Comment and Trackback spam filters. Sitewide IP banning numerous bug fixes updated ADOdb libraies updated RSS/Atom parsing libraries What still needs to be done fix the "no entry/preview" bug maybe add one of the timezone patches that have been submitted My test environment is currently PHP 4.3.11, Apache 1.3.31, mysql 4.0.25 on Linux. I haven't tested against postgres yet, but i will at some point. Anyone who can try this against other DBs and other platforms would be a great help. As always, please report any bugs you find to the Bug Tracker http://www.simplog.org/bugs/ thanks f-bomb |
|
From: Jeremy A. <ash...@13...> - 2005-06-18 00:35:51
|
I've got some development done for 0.9.2 and need to add in the upgrade scripts for the DB changes. I'll put out a test release pretty soon. Here's what's new/changed and what's left: Fixed a few bugs. Added jimhu's trackback filter (jim: i put the filter terms in a table rather than reading in arrays) Added ability to ban IPs Created new comment filtering Added admin section for IP/Spam control ToDo: ability to delete trackbacks be able to run filters against existing trackbacks/comments to catch previously missed spam add in timezone patch from tcort(or somebody) jim: I took out some of the customizations you had checked into CVS and the HTML and special character charts. I didn't want to add anything into this release unless it was really needed, like the spam filters. We can add those features into the 1.0 release. thanks to all you submitted bugs, added patches, etc.... f-bomb |
|
From: Mike C. <mcr...@r-...> - 2005-06-15 18:13:00
|
=20 Regards, =20 Mike Creuzer =20 Webmaster REALTOR(r) Association of Greater Fort Lauderdale, Inc.=20 1765 NE 26 Street, Fort Lauderdale, Florida 33305-1438 954-563-7261 ext. 5022 954-568-9695 fax Email: mcr...@r-... Visit our website www.R-World.com=20 Your opinion matters. Click here to take our member relations online satisfaction survey. =20 . . . your full service Realtor Association Resource =20 The mission of the REALTOR(r) Association of Greater Fort Lauderdale is to secure the interests of its members and their ability to conduct a thriving business, to promote the highest standards of professional practice in the real estate community, and to support members in maximizing their individual potential for success. -----Original Message----- From: Mike Creuzer=20 Sent: Wednesday, June 15, 2005 2:07 PM To: 'Jeremy Ashcraft' Subject: RE: [Simplog-devel] a little help...... I am listening. I just haven't had a chance to download the code and look through it yet... Without looking at the code, I have a few comments. I tend to not like globals, they can mask variable/code interactions. I have seen where a global gets changed by a "module" and a 2nd "module" depends on that old value in other pieces of software.=20 I like to either pass everything around, or wrap it up in a class and pass an object around. I am too lazy to debug collateral damage. I like the module idea, where different blogs can have different modules. I have a question, does anybody else have the situation where they have several dissimilar locations on a single website where simplog is deployed? At the moment if I where to add a 2nd blog, I either need to do some mod_rewrite magic, some serious symlinking or have a 2nd install of simplog. Is it/will it possible to set simplog up in such a way that there is a central code library and somehow have multiple deploy points? Basically, embed simplog a simplog blog into an assortment of existing webpages on a site?=20 Right now, on a blog page, I am including simplog like the following... <body> <!-- a bunch of HTML for my site template, header, navigation, etc --> <?php include("simplog/index.php"); ?> <!-- a bunch of HTML for my site footer and other post-blog static content --> </body> </html> But if I deploy a second blog, this wouldn't work anymore. Would it be possible to do something like: <?php include("simplog/index.php"); $blog =3D new simplog('blog_name'); echo $blog->startblog();=09 ?> Like most programmers, I am lazy, and only want a single code source. In short, I would like to embed a blog into various pages of my existing site, sometimes intermixed with existing content. I wouldn't mind having a central admin area, I just want to be able to embed blogs or mini-blogs all over the place on my site. Ya know what I mean? Well, enough of my rambling without looking at your new source... Regards, =20 Mike Creuzer =20 Webmaster REALTOR(r) Association of Greater Fort Lauderdale, Inc.=20 -----Original Message----- From: sim...@li... [mailto:sim...@li...] On Behalf Of Jeremy Ashcraft Sent: Wednesday, June 15, 2005 12:45 PM To: sim...@li... Subject: [Simplog-devel] a little help...... Seems that Jim and I are the only ones involved in this discussion. I know that there are 13 of us subscribed to this list, yet only 2 of us are doing any of the talking...... If you're interested in the development of this application, then get involved, even if its only talking about things. jeremy ashcraft ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Simplog-devel mailing list Sim...@li... https://lists.sourceforge.net/lists/listinfo/simplog-devel |
|
From: Jim Hu <ji...@ta...> - 2005-06-15 17:10:57
|
Hmm...I think we're agreeing but not expressing the ideas in the same way. Probably because I'm a newbie in thinking in terms of events and triggers. But I'm jazzed about learning this. If WP is getting code bloat, we certainly don't want to follow their lead...and this means that I don't have to spend time deciphering their code! I had suggested it based on their claims for flexibility and modularity. It would be interesting to hear from your friends re: what mistakes made by WP we should learn from. Jim |
|
From: Jeremy A. <ash...@13...> - 2005-06-15 16:45:13
|
Seems that Jim and I are the only ones involved in this discussion. I know that there are 13 of us subscribed to this list, yet only 2 of us are doing any of the talking...... If you're interested in the development of this application, then get involved, even if its only talking about things. jeremy ashcraft |
|
From: Jeremy A. <ash...@13...> - 2005-06-15 16:40:57
|
Jim Hu wrote: > Deleted material where we agree completely or no comment is needed. I > think I'm viewing this differently because I'm now up to 27 blogs > running from my installation, each with different customization. > that's why I want to build this to be as flexible and scalable as possible, to accomodate people with one blog or 27. :) > > It's very minor, and perhaps inappropriate since it's a "powerful..yet > simple" package, but I like to do whatever I can to avoid variable > namespace conflicts from being able to happen. Based on the sloppy > coding I do, I expect users to experiment with the code to add > functionalities that we don't include. This is generally a good > thing, but we want to make it harder for them to name some new random > variable $event_table and redefine what it means, breaking the module > system. This is more likely to happen if a variable is named in an > included file that looks like a bunch of functions. Perhaps this was > just how you set it up for the prototype...the alternative is to put > the setup for all the reserved variables, including $modlist and > $event_table in the init.config.php file. > yeah, they'll eventually go into an init or bootstrap file..... > > OK. So header and footer were just example tests and would ultimately > not be handled by triggers? they will be, but we just need to build the core > I agree that modules in general should be administered by the > superuser. But my recollection is that waaay back when I first joined > the dev list, there was some discussion of using modules to provide > users with different versions of the guts of edit.php, based on things > like whether or not they would want to use a WYSIWG javascript editor > that is only compatible with some platforms/browsers. So I had > pictured it as: > > Installations will differ in modules used based on choices made by the > superuser correct, the super user will control which modules are installed, active, and available for everyone to use > Blogs will differ based on choices made by the blogadmin, constrained > by choices made by superuser correct. My idea is that the blog admin can select which modules are used within a blog and set any blog level configuration for the modules > User experience will differ based on choices made by the user, > constrained by choices made by blogadmin and superuser > correct, users should be able to set preferences as to certain user level functionality provided by the modules > > See above. I'm especially thinking about form editors, but it applies > to other aspects. Examples: > 1) On a particular install, a superuser might want to offer blogadmins > different comment subsystems - perhaps blog 1 would want to use > Haloscan, blog 2 might want to use our normal system, and so on. So > different modules for comments would have to be on the install, but > each blog would only want one handler to respond to the event. > Perhaps even though I can't imagine why, someone would want both to > respond. I'd like to see this settable by the users (in the broad > sense) with who have privileges at the appropriate level. > see above > 2) Customizing which modules are used at the blog level could be a way > of handling the differences between the various flavors of public, > protected, and private we discussed last year. Some of my blogs are > viewable by the public, while others require a login page even though > they have multiple posters. This seems like a perfect place for > blog-level modularity. Although I suppose it could be handled by > options within the templating system, it makes more sense to me to > have a collection of security modules that are turned on or off for > each blog. > I think there will be a core set of security features (permissions, etc...) and then have modules be able to extend the core security features. I see 3 levels of preferences being set: system, blog, user. Each module could offer settings that are controlled at each level. > 3) Those of us on the dev list will probably want to check out any > modules that are submitted. I'd like to keep them all in the modules > directory and turn them on and off from a module manager (which itself > should be alternative modules) rather than moving things in and out of > the modules directory while testing for conflicts. I think it would > be a bad idea to have the module managers use the filesystem to move > files and directories for security reasons. > agreed. There will be a module management interface and module should be activated/deactivated from there. A module can sit on the filesystem, but if its not active, it shouldn't do anything..... > > I'll take a look over there. I've also looked briefly at how > WordPress (http://wordpress.org/) does their stuff. It might be worth > thinking about how they handle multiple developers. > I've heard that the WP codebase is getting bloated and is not easy to work with. I've not looked at it myself, but i know a couple guys who use it and say the code is terrible.... *shrug* |
|
From: Jim Hu <ji...@ta...> - 2005-06-15 15:10:17
|
Deleted material where we agree completely or no comment is needed. I
think I'm viewing this differently because I'm now up to 27 blogs
running from my installation, each with different customization.
On Jun 15, 2005, at 3:52 AM, Jeremy Ashcraft wrote:
> Jim Hu wrote:
>> 1) I'm wondering if there might be a way to eliminate the global
>> variables $event_table and $modlist (should it be $mod_list?) by
>> either including them in class Collection, or by making class
>> ModuleCollection extends Collection, so that a new ModuleCollection
>> object loads the modules and registers their actions.
>
> We'd still have to have global object to accessm so I don't see
> anything wrong with them.
It's very minor, and perhaps inappropriate since it's a "powerful..yet
simple" package, but I like to do whatever I can to avoid variable
namespace conflicts from being able to happen. Based on the sloppy
coding I do, I expect users to experiment with the code to add
functionalities that we don't include. This is generally a good thing,
but we want to make it harder for them to name some new random variable
$event_table and redefine what it means, breaking the module system.
This is more likely to happen if a variable is named in an included
file that looks like a bunch of functions. Perhaps this was just how
you set it up for the prototype...the alternative is to put the setup
for all the reserved variables, including $modlist and $event_table in
the init.config.php file.
>
>> The constructor for ModuleCollection could include a path so that a
>> subset of the modules in the modules directory could be loaded if
>> specified, or the default would be everything or nothing. I'd like
>> to see this set up so that we could do something like this:
>>
>> $myModules = new ModuleCollection()
>> $myModules-> loadmodules(path1);
>> $myModules-> loadmodules(path2);
>>
>> etc. so that different subsets could be loaded, appending to the list
>> of event handlers. This will come in handy when we want to pull
>> which module packages to load for individual users, or different
>> blogs - which I'm thinking will ultimately be stored somewhere in the
>> database. I'm imagining that a module manager something like the
>> current blocksadmin would let users move modules up and down their
>> individualized priority lists.
>>
> I think that modules should be administered by the superuser and
> available across all blogs and available to all users. Mmodules are a
> system level feature, not a blog level piece. Individual blog
> customization shouldl come from more detailed blog level configuration
> and a good templating system.
OK. So header and footer were just example tests and would ultimately
not be handled by triggers? I agree that modules in general should be
administered by the superuser. But my recollection is that waaay back
when I first joined the dev list, there was some discussion of using
modules to provide users with different versions of the guts of
edit.php, based on things like whether or not they would want to use a
WYSIWG javascript editor that is only compatible with some
platforms/browsers. So I had pictured it as:
Installations will differ in modules used based on choices made by the
superuser
Blogs will differ based on choices made by the blogadmin, constrained
by choices made by superuser
User experience will differ based on choices made by the user,
constrained by choices made by blogadmin and superuser
>
>> We need to control how many handlers are allowed to respond to an
>> event. For example, different blogs running from a single install
>> will have different headers, and trigger("header") should only do one
>> per blog...but we want to allow different kinds of header modules to
>> coexist in a single installation. This could be done by passing an
>> integer to trigger that determines how many to run. Or perhaps this
>> should be controlled by an associative array of event types:
>> $do_trigger['header'] = 1; $do_trigger['blocks'] = 0; # 0 means do
>> all available.
>>
> triggering an event should call all module methods that have
> registered for that event. That's the whole point of having the
> callback system. We shouldn;t limit the number of methods that
> respond to that event. The module system is for easily adding
> functionality to blogging engine as a whole, not for blog level
> tweaking and customizing.
See above. I'm especially thinking about form editors, but it applies
to other aspects. Examples:
1) On a particular install, a superuser might want to offer blogadmins
different comment subsystems - perhaps blog 1 would want to use
Haloscan, blog 2 might want to use our normal system, and so on. So
different modules for comments would have to be on the install, but
each blog would only want one handler to respond to the event. Perhaps
even though I can't imagine why, someone would want both to respond.
I'd like to see this settable by the users (in the broad sense) with
who have privileges at the appropriate level.
2) Customizing which modules are used at the blog level could be a way
of handling the differences between the various flavors of public,
protected, and private we discussed last year. Some of my blogs are
viewable by the public, while others require a login page even though
they have multiple posters. This seems like a perfect place for
blog-level modularity. Although I suppose it could be handled by
options within the templating system, it makes more sense to me to have
a collection of security modules that are turned on or off for each
blog.
3) Those of us on the dev list will probably want to check out any
modules that are submitted. I'd like to keep them all in the modules
directory and turn them on and off from a module manager (which itself
should be alternative modules) rather than moving things in and out of
the modules directory while testing for conflicts. I think it would be
a bad idea to have the module managers use the filesystem to move files
and directories for security reasons.
>
> I really like some of the stuff drupal is doing with their
> architechture. it'd be worth looking at what their doing to steal
> some ideas....
> http://www.drupal.org and http://www.drupaldocs.org
I'll take a look over there. I've also looked briefly at how WordPress
(http://wordpress.org/) does their stuff. It might be worth thinking
about how they handle multiple developers.
|
|
From: Jeremy A. <ash...@13...> - 2005-06-15 08:52:31
|
Jim Hu wrote:
> I've looked at it, and the modifications you made make sense to me.
> I'm assuming that for now we are not requiring php5.
nope...just remember this code was just a way to prove that my framework
idea actually worked, not to be the base to start development
from......nothing is set in stone.....
> Here are some half-baked thoughts:
>
> 1) I'm wondering if there might be a way to eliminate the global
> variables $event_table and $modlist (should it be $mod_list?) by
> either including them in class Collection, or by making class
> ModuleCollection extends Collection, so that a new ModuleCollection
> object loads the modules and registers their actions.
We'd still have to have global object to accessm so I don't see anything
wrong with them.
> The constructor for ModuleCollection could include a path so that a
> subset of the modules in the modules directory could be loaded if
> specified, or the default would be everything or nothing. I'd like to
> see this set up so that we could do something like this:
>
> $myModules = new ModuleCollection()
> $myModules-> loadmodules(path1);
> $myModules-> loadmodules(path2);
>
> etc. so that different subsets could be loaded, appending to the list
> of event handlers. This will come in handy when we want to pull which
> module packages to load for individual users, or different blogs -
> which I'm thinking will ultimately be stored somewhere in the
> database. I'm imagining that a module manager something like the
> current blocksadmin would let users move modules up and down their
> individualized priority lists.
>
I think that modules should be administered by the superuser and
available across all blogs and available to all users. Mmodules are a
system level feature, not a blog level piece. Individual blog
customization shouldl come from more detailed blog level configuration
and a good templating system.
> We need to control how many handlers are allowed to respond to an
> event. For example, different blogs running from a single install
> will have different headers, and trigger("header") should only do one
> per blog...but we want to allow different kinds of header modules to
> coexist in a single installation. This could be done by passing an
> integer to trigger that determines how many to run. Or perhaps this
> should be controlled by an associative array of event types:
> $do_trigger['header'] = 1; $do_trigger['blocks'] = 0; # 0 means do all
> available.
>
triggering an event should call all module methods that have registered
for that event. That's the whole point of having the callback system.
We shouldn;t limit the number of methods that respond to that event.
The module system is for easily adding functionality to blogging engine
as a whole, not for blog level tweaking and customizing.
> 2) I think that the do module code in index.php should be rolled into
> a common function.
>
me too, i was just being lazy :)
> 3) For purposes of inter-module communication, I think that modules
> should never print or echo directly - they have methods that a) print
> and b) return string variables or false for another module to use as
> input.
>
agreed, again, me being lazy
> 4) I'd make common.php a modules.php file within a subdirectory called
> common, or functions, or something like that. I'm assuming that
> despite the OO redesign, some common use functions will still be in
> the equivalent of the current lib.php. I think lib.php is a bit
> awkward as it's set up now, and dividing it into different functional
> groups in different files might make life easier.
>
yep, i think there will end up being a common or includes dir with all
the shared function libs in it
> 5) Unrelated to the OO design, but I'm wondering if we can change the
> way permalink and archive URL paths are set up so that it's easier for
> technorati to index our blogs. Well, actually this may be related to
> OO, since I'm not sure this would be the same on Apache vs. other
> servers, so perhaps different modules would be used depending on the
> server software.
>
the entry URLs will change, and i'm thinking on making them more search
engine friendly, it'll break the old URLs and GUIDs in the syndication
feeds, but oh well.....I've been thinking of doing some URL rewriting
with mod_rewite (sorry non-apache folks) to have nice readable urls like
http://www.simplog.org/1/blog/add or http://www.simplog.org/1/view/32,
or something like that
I really like some of the stuff drupal is doing with their
architechture. it'd be worth looking at what their doing to steal some
ideas....
http://www.drupal.org and http://www.drupaldocs.org
|
|
From: Jim Hu <ji...@ta...> - 2005-06-15 07:17:05
|
I've looked at it, and the modifications you made make sense to me.
I'm assuming that for now we are not requiring php5. Here are some
half-baked thoughts:
1) I'm wondering if there might be a way to eliminate the global
variables $event_table and $modlist (should it be $mod_list?) by either
including them in class Collection, or by making class ModuleCollection
extends Collection, so that a new ModuleCollection object loads the
modules and registers their actions. The constructor for
ModuleCollection could include a path so that a subset of the modules
in the modules directory could be loaded if specified, or the default
would be everything or nothing. I'd like to see this set up so that we
could do something like this:
$myModules = new ModuleCollection()
$myModules-> loadmodules(path1);
$myModules-> loadmodules(path2);
etc. so that different subsets could be loaded, appending to the list
of event handlers. This will come in handy when we want to pull which
module packages to load for individual users, or different blogs -
which I'm thinking will ultimately be stored somewhere in the database.
I'm imagining that a module manager something like the current
blocksadmin would let users move modules up and down their
individualized priority lists.
We need to control how many handlers are allowed to respond to an
event. For example, different blogs running from a single install will
have different headers, and trigger("header") should only do one per
blog...but we want to allow different kinds of header modules to
coexist in a single installation. This could be done by passing an
integer to trigger that determines how many to run. Or perhaps this
should be controlled by an associative array of event types:
$do_trigger['header'] = 1; $do_trigger['blocks'] = 0; # 0 means do all
available.
2) I think that the do module code in index.php should be rolled into a
common function.
3) For purposes of inter-module communication, I think that modules
should never print or echo directly - they have methods that a) print
and b) return string variables or false for another module to use as
input.
4) I'd make common.php a modules.php file within a subdirectory called
common, or functions, or something like that. I'm assuming that
despite the OO redesign, some common use functions will still be in the
equivalent of the current lib.php. I think lib.php is a bit awkward as
it's set up now, and dividing it into different functional groups in
different files might make life easier.
5) Unrelated to the OO design, but I'm wondering if we can change the
way permalink and archive URL paths are set up so that it's easier for
technorati to index our blogs. Well, actually this may be related to
OO, since I'm not sure this would be the same on Apache vs. other
servers, so perhaps different modules would be used depending on the
server software.
Jim Hu
On Jun 14, 2005, at 12:45 PM, Jeremy Ashcraft wrote:
> had any time to look at the proof of concept i posted?
>
> <snip>
|
|
From: Jeremy A. <ash...@13...> - 2005-06-14 08:33:39
|
got my proof of concept code ready for inspection. http://www.simplog.org/v1.tgz An explaination is in the README file all this does is test the framework, nothing more, nothing less. |
|
From: Jeremy A. <ash...@13...> - 2005-06-13 22:56:46
|
quick note to everyone. I've temporarily disabled CVS access for everyone to freeze the code while i put together a final 0.9.x release to fix some of the current issues and keep folks happy until we can get a 1.0 release out the door. I've gotten a good start on the framework I mentioned in my last email and will post my proof of concept code shortly for questions/comments. f-bomb |
|
From: Jeremy A. <ash...@13...> - 2005-06-07 18:59:38
|
just letting everyone know i had a bit of time over the weekend and put some thought to the 1.0 release. I'm basing my design partly on tcort's module design and partly on the module architecture that drupal uses. My wife is (probably) going on a trip in a week or so, so i'll have more time to wrap up a final 0.9.x release and get an initial design doc for 1.0 started. What i'm basically shooting for is to have a fully modular architecture. A set of "core" modules will make up the underlying "blog engine". These core modules will have a "Core API" that we can build other interfaces on top of (Default Web Interface, Email Gateway INterface, SOAP Interface, Metaweblog and Blogger API interface, etc.....). I still don't have many details worked out in my head yet, but i'm hoping to organize those soon. savvy? later, f-bomb |
|
From: Jim Hu <ji...@ta...> - 2005-05-12 22:04:07
|
Tom, I'm wondering about whether this should be by blog or by user. Jim On May 12, 2005, at 1:34 PM, Thomas A. Cort wrote: > I just finished a timezone patch which will allow the owner of a blog > to set the timezone for his or her blog. It inroduces a new database > column to the table blog_list. The column is called tz_offset and > holds an integer. The column is not null and defaults to '0'. The > integer represents the number of hours to add or subtract from the > server's time to get the local time. The blogging software now uses > the local time (server time + offset) when storing comments or > entries. To change the offset simply go to Blog Administration and > change it. > > This code patches the May 12th cvs version of simplog. I have no idea > if it will work with version 0.9.1 (the lastest stable release). If > you have an exisiting blog and it does apply cleanly you'll have to > alter the blog_list table to have a non-null integer column called > tz_offset with a default value of 0. > > The code is available here: http://mediumbagel.org/code/timezone.patch > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel |
|
From: Thomas A. C. <tc...@od...> - 2005-05-12 18:34:33
|
I just finished a timezone patch which will allow the owner of a blog to set the timezone for his or her blog. It inroduces a new database column to the table blog_list. The column is called tz_offset and holds an integer. The column is not null and defaults to '0'. The integer represents the number of hours to add or subtract from the server's time to get the local time. The blogging software now uses the local time (server time + offset) when storing comments or entries. To change the offset simply go to Blog Administration and change it. This code patches the May 12th cvs version of simplog. I have no idea if it will work with version 0.9.1 (the lastest stable release). If you have an exisiting blog and it does apply cleanly you'll have to alter the blog_list table to have a non-null integer column called tz_offset with a default value of 0. The code is available here: http://mediumbagel.org/code/timezone.patch |
|
From: Jeremy A. <ash...@13...> - 2005-05-09 18:09:57
|
there is a private development forum on the BBS that I've set up. If there is anyone on here who wants to start using it, go setup an account in the support forums, let me know what it is, and I'll give you access. We also have an IRC channel that I've had one person visit at irc.simplog.org channel #simplog I'm in there part of the day during the weekdays. As far as development communication, I like to be notified of new posts in some manner, because I'm really bad at checking sites on a regular basis due to my busy schedule outside of the project. I get instant notifcation via my email client using the listserv and can respond almost immediately. That's my only real holdup to using Simplog, as it currently doesn't do notifications. I'm open to almost anything you guys want to use as long as I can be notified via email or something...... Jim Hu wrote: > I can understand why certain development issues shouldn't be on the > bbs - especially discussion of unclosed security holes - and it seems > like the bbs is used mostly to do user support. But it seems to me > that there's a basic problem with the listserv model for developer > discussions: when someone new joins, the collective memory is in the > listserv archive which is not that well organized. > > By contrast, if we had a blog for the discussion, we could use > categories, links, comments, and trackbacks to organize the discussion > so that a new developer could have a better sense of what has or has > not already been hashed out, what problems were found etc. It's not > like the listserv archives are secured anyway. Posting and commenting > could be limited to people on the dev list, using stuff we already > have working in Simplog (I have a login-only version of comment.php in > the CVS, and it would be easy to modify to have different levels of > restriction on different blogs). > > From my own experience, it sure would have been nice to be able to > have a place to go to learn about how certain things work. I've > modified the trackback handling, but it took a while to figure out > what the existing code does. Similarly, it took me a while to > understand the installer. These weren't hard, but it would have been > easier if I could just read someone else's posts about who had figured > it out before me, or who had explained it in more detail than you'd > want to put in the code comments. I think that explaining the weird > way I've handled custom layouts in what's in the CVS might be > useful...and could stimulate discussion of what should be done > differently in version 2. > > I was thinking about this because I've been using Simplog this way for > discussion of other group projects...and it dawned on me that one of > the places I'm not using it is in the discussion of Simplog itself! > Also, I'm thinking that new user Tom Cort might be a good addition, > and we can help him and others get up to speed faster if we have > better archives. > > Jim Hu > > p.s. I'm not sure if this general idea would be better using Simplog > or phpBB. But I think either is better than the listserv...or they > can be complementary. I like using Simplog partly because it's more > under our direct control, and partly because it's a nice advert for > the program. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. > Get your fingers limbered up and give it your best shot. 4 great > events, 4 > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to > win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel > |
|
From: Jim Hu <ji...@ta...> - 2005-05-09 17:35:04
|
I can understand why certain development issues shouldn't be on the bbs - especially discussion of unclosed security holes - and it seems like the bbs is used mostly to do user support. But it seems to me that there's a basic problem with the listserv model for developer discussions: when someone new joins, the collective memory is in the listserv archive which is not that well organized. By contrast, if we had a blog for the discussion, we could use categories, links, comments, and trackbacks to organize the discussion so that a new developer could have a better sense of what has or has not already been hashed out, what problems were found etc. It's not like the listserv archives are secured anyway. Posting and commenting could be limited to people on the dev list, using stuff we already have working in Simplog (I have a login-only version of comment.php in the CVS, and it would be easy to modify to have different levels of restriction on different blogs). From my own experience, it sure would have been nice to be able to have a place to go to learn about how certain things work. I've modified the trackback handling, but it took a while to figure out what the existing code does. Similarly, it took me a while to understand the installer. These weren't hard, but it would have been easier if I could just read someone else's posts about who had figured it out before me, or who had explained it in more detail than you'd want to put in the code comments. I think that explaining the weird way I've handled custom layouts in what's in the CVS might be useful...and could stimulate discussion of what should be done differently in version 2. I was thinking about this because I've been using Simplog this way for discussion of other group projects...and it dawned on me that one of the places I'm not using it is in the discussion of Simplog itself! Also, I'm thinking that new user Tom Cort might be a good addition, and we can help him and others get up to speed faster if we have better archives. Jim Hu p.s. I'm not sure if this general idea would be better using Simplog or phpBB. But I think either is better than the listserv...or they can be complementary. I like using Simplog partly because it's more under our direct control, and partly because it's a nice advert for the program. |
|
From: Jason L. B. <ja...@bu...> - 2005-04-11 21:21:52
|
Jim, I would agree with both of your suggested changes. Go ahead and commit them to CVS. -jason -- Jason L. Buberel - ja...@bu... - http://www.buberel.org JabberID:ja...@im... - m:+16504831989 On Mon, April 11, 2005 10:49 am, Jim Hu said: > I noticed long ago that there is a field in blog_acl called admin. I > don't think it does anything in the current release, but I am guessing > that it is there to allow more than one administrator for a blog. This > can be implemented by changing function isBlogAdmin($blogid) to: > > function isBlogAdmin($blogid) { > > global $uid, $db; > > $sql = "SELECT admin from blog_list where blog_id=$blogid"; > $res = $db->Execute($sql); > > $sql = "SELECT admin from blog_acl where blog_id=$blogid AND > user_id=$uid"; > $res2 = $db->Execute($sql); > > // Return true if the user is an admin for this blog > // or is the superadmin > if($res->fields['admin'] == $uid || $res2->fields['admin'] == 'Y' || > isAdmin()) { > return 1; > } else { > return 0; > } > > } > > Also, in function getBlogEntriesByRange($limit, $start, $byUser = 0) > in class.BlogInfo.php, the statment that tests for privileges should > have && instead of or > > > if($byUser) { > if(!isAdmin() && !(isBlogAdmin($this->blogId) == 1)) { > $sql .= " and userid=$uid"; > } > } > $sql .=" order by blog_entry_id desc"; > > Using or, the whole statement evaluates FALSE if the user isn't the > overall admin. > > Jim Hu > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Simplog-devel mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplog-devel > |
|
From: Jim Hu <ji...@ta...> - 2005-04-11 17:50:21
|
I noticed long ago that there is a field in blog_acl called admin. I
don't think it does anything in the current release, but I am guessing
that it is there to allow more than one administrator for a blog. This
can be implemented by changing function isBlogAdmin($blogid) to:
function isBlogAdmin($blogid) {
global $uid, $db;
$sql = "SELECT admin from blog_list where blog_id=$blogid";
$res = $db->Execute($sql);
$sql = "SELECT admin from blog_acl where blog_id=$blogid AND
user_id=$uid";
$res2 = $db->Execute($sql);
// Return true if the user is an admin for this blog
// or is the superadmin
if($res->fields['admin'] == $uid || $res2->fields['admin'] == 'Y' ||
isAdmin()) {
return 1;
} else {
return 0;
}
}
Also, in function getBlogEntriesByRange($limit, $start, $byUser = 0)
in class.BlogInfo.php, the statment that tests for privileges should
have && instead of or
if($byUser) {
if(!isAdmin() && !(isBlogAdmin($this->blogId) == 1)) {
$sql .= " and userid=$uid";
}
}
$sql .=" order by blog_entry_id desc";
Using or, the whole statement evaluates FALSE if the user isn't the
overall admin.
Jim Hu
|
|
From: Jeremy A. <ash...@13...> - 2005-04-08 18:33:40
|
Just wanted to make a quick announcement that now in addition to the support forums, we have a new support IRC channel. For our current IRC users, the channel is located at server: irc.simplog.org channel: #simplog there is also a web-based interface to the channel on the site http://www.simplog.org/irc/ I'll be in there most days from 9am - 2pm PST and itermittently the rest of the day and on weekends. Anyone else who can hang out in there is more than welcome. see you in the ether.... f-bomb |
