simplog-devel — Mailing list for Simplog developers

Re: [Simplog-devel] Introductions and a quick question

[Jim Hu <ji...@ta...>]

I'm not sure about this either -  $blogEntry->entryId should give=20
access to the entry ID.  I use the --postid-- in something I wrote to=20
feed blog information to other websites, but it's not clear that I need=20=

to do it that way.

Jim Hu

On Mar 21, 2005, at 9:52 AM, Mike Creuzer wrote:

> Hello everyone.
> I just picked up simplog last week to jumpstart making a very simple=20=

> blog. I don't need (can't have) all these "extra features".
> =A0
> Simplog seemed to be a good starting point -- easy to hack and slash=20=

> into the minimalist display that I need. It is nice to see a piece of=20=

> software that is just the "kitchen sink" in these days of bloated=20
> "everything but the kitchen sink" behemoths.
> =A0
> I have posted a couple of bug fixes (including the correct code) to=20
> the bug list.
> =A0
> Now, to my question.
> =A0
> What is the following function for in lib.php? It isn't documented. It=20=

> APPEARS to be to track a post? Why does it need to be templated in=20
> using --postid-- in the marker_sub() function?
> =A0
> =A0=A0=A0 function get_postid() {
> =A0=A0=A0=A0=A0=A0=A0 global $pid;
> =A0=A0=A0=A0=A0=A0=A0 return 'pid' . $pid;
> =A0=A0=A0 }
>
> =A0
> What I was looking for was a way to access the 'blog_entry_id' from=20
> the database so I have a unique identifier so I can name anchors=20
> properly.
>  =A0
> I don't see this implemented anywhere.
> =A0
> Who could I send changes too to get them added quickly? I could be=20
> added as a devel if needed and judged "worthy".
> I see that there is minimal error checking in the code...
> =A0
> Regards,
> =A0
> Mike Creuzer

[Simplog-devel] Introductions and a quick question

[Mike C. <mcr...@r-...>]

Hello everyone.
I just picked up simplog last week to jumpstart making a very simple
blog. I don't need (can't have) all these "extra features".
=20
Simplog seemed to be a good starting point -- easy to hack and slash
into the minimalist display that I need. It is nice to see a piece of
software that is just the "kitchen sink" in these days of bloated
"everything but the kitchen sink" behemoths.
=20
I have posted a couple of bug fixes (including the correct code) to the
bug list.
=20
Now, to my question.
=20
What is the following function for in lib.php? It isn't documented. It
APPEARS to be to track a post? Why does it need to be templated in using
--postid-- in the marker_sub() function?
=20
    function get_postid() {
        global $pid;
        return 'pid' . $pid;
    } <mailto:sim...@li...>=20
=20
What I was looking for was a way to access the 'blog_entry_id' from the
database so I have a unique identifier so I can name anchors properly.=20
=20
I don't see this implemented anywhere.
=20
Who could I send changes too to get them added quickly? I could be added
as a devel if needed and judged "worthy".
I see that there is minimal error checking in the code...
=20
Regards,
=20
Mike Creuzer

[Simplog-devel] Bug in user.php

[Kade C. <si...@gm...>]

Wanted to drop a line to the developers that I think I found a bug in
the user.php page. Around line 51 the user.php currently reads:
		$enc = md5($_REQUEST['$pass1']);
I believe this should read:
		$enc = md5($_REQUEST['pass1']);

I stumbled across this when my users were having issues
updating/changing passwords.

Thanks,

Kade P. Cole

PS. I am willing to volunteer some time to help with coding.

Re: [Simplog-devel] Question about the install scripts

[Jason L. B. <ja...@bu...>]

I do not believe the DB is created for you. You create that (using the
tools provided by mysql or postgres), then simplog will install it's
tables into that DB.

-jason
-- 
Jason L. Buberel - ja...@bu... - http://www.buberel.org
JabberID:ja...@im... - m:+16504831989

On Tue, February 15, 2005 3:06 pm, Jim Hu said:
> I'm trying to understand the install scripts.  It's been so long since
> I did my install that I don't remember what happened then, but I have a
> vague memory that I had to tweak mySQL.
>
>    I can't figure out where the db is created...and on my test system
> I'm getting a fatal error because it isn't happening.
>
> Jim
>
>
>
> -------------------------------------------------------
> 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
>

[Simplog-devel] Question about the install scripts

[Jim Hu <ji...@ta...>]

I'm trying to understand the install scripts.  It's been so long since 
I did my install that I don't remember what happened then, but I have a 
vague memory that I had to tweak mySQL.

   I can't figure out where the db is created...and on my test system 
I'm getting a fatal error because it isn't happening.

Jim

[Simplog-devel] Found where to disable trackback insertion

[Jim Hu <ji...@ta...>]

I commented out the insert statement in tb.php...now I just have to 
figure out what to do next.

Jim

[Simplog-devel] Trackback spam - Help!!

[Jim Hu <ji...@ta...>]

I just posted this to the BBS:
============================

I just got through deleting about a thousand trackbacks from porn 
sites...and I seem to be under a spider attack sending more as I write 
this.

  :(

Anyone else having this problem?  Solutions?
============================
I didn't see these right away, as many are tracking back to older 
entries.  I was playing with the trackback functions to see how they 
work, and looked in the mySQL database... and whoa!

I'm now looking for how to temporarily disable trackbacks while I think 
about this.  If you know how, please email me!

Jim

[Simplog-devel] my status...again

[Jeremy A. <ash...@13...>]

since i got no reaction the first time i sent this out, I'll send it 
again and copy the general list as well......

 after looking back at the past year, I find that I have grossly 
 neglected this project.  Its not that I didn"t want to do more, but my 
 personal life has not allowed me to.  I keep meaning to make more time 
 to put into the project, but having a new son and my increasing 
 responsibilities at my job aren't allowing me to.  I don't forsee my 
 schedule opening up anytime in the near future either, so I'd like to 
 hand over control of this project to someone else.  I'd rather see this 
 project move on under someone else than stagnate under my control. 
 
 This started out in 2000 as an attempt to scratch an itch out of 
 frustration with Blogger, and its been great to see it evolve over the 
 years.  My only regret is that I haven't had as much time to put into it 
 as I would have like to.
 
 If you're interested in taking over, let me know.....
 
 f-bomb
 Jeremy Ashcraft

[Simplog-devel] my status

[Jeremy A. <ash...@13...>]

after looking back at the past year, I find that I have grossly 
neglected this project.  Its not that I didn't want to do more, but my 
personal life has not allowed me to.  I keep meaning to make more time 
to put into the project, but having a new son and my increasing 
responsibilities at my new job aren't allowing me to.  I don't forsee my 
schedule opening up anytime in the near future either, so I'd like to 
hand over control of this project to someone else.  I'd rather see this 
project move on under someone else than stagnate under my control. 

This started out in 2000 as an attempt to scratch an itch out of 
frustration with Blogger, and its been great to see it evolve over the 
years.  My only regret is that I haven't had as much time to put into it 
as I would have like to.

If you're interested in taking over, let me know.....

f-bomb
Jeremy Ashcraft

[Simplog-devel] Security and isUserAuthorized

[Jim Hu <ji...@ta...>]

Jason and Jeremy,

It just occurred to me that the way isUserAuthorized and is set up now, 
there is a potential security hole for protected blogs in a multiuser 
environment.  For protected blogs, we only check using:

      	elseif ( $this->blogType == 'protected ' ) {
             	if ( isset ($_SESSION['login']) ) {
            	     return true;
             	}
	}

First, this will give access to a blog user on blogid=1 to a protected 
blogid=2, even if the user isn't on the blog_acl.  More seriously, if a 
user (or hacker) has access to anything else on the same server, she 
can write a web application that creates a session with the session 
variable named "login", and this statement will evaluate to true.  I 
haven't actually tried this to break into a protected blog (because I'm 
still have isUserAuthorized inactivated on my server for other reasons 
related to our need to standardize what we all mean by protected and 
private, as discussed before), but I use something like this for 
administration controlled by Simplog - I have scripts in my websites 
that ask whether a user is currently logged into Simplog.  If this hole 
really exists, then it may also be possible to break into private blogs 
too, as long as the attacker knows/guesses the login of the 
administrator.

I think that this is a general security issue with $_SESSION, and from 
a quick Google, it looks like it has been discussed before.  I haven't 
digested the discussion thoroughly, but it seems like a stronger 
session-based security system would have to cache a session_id when it 
is created by Simplog and recheck it each time it's invoked in order to 
assure that the session isn't a fake.  I don't have a problem with 
other applications knowing that I'm logged into Simplog (in fact I use 
that property), but we don't want spoofing to be this easy.

Note that as far as I can tell, this is not a problem that goes between 
hosts or even virtual hosts.  However, in the kind of academic 
environment I work in, hacking attacks are frequent - I've had two 
linux servers crash due to attacks in the past two years - so I tend to 
be paranoid.

Jim

p.s.  I vacillated about sending this out to the general list, as it 
basically tells how to break in.  However, in the end, I decided that a 
hacker who wanted to do this would already be able to figure it out by 
just looking at the code, and that doing so would be easier than 
looking through the archives of the developer listserv.  Seems like it 
would be better to draw on the experience and ideas of the others on 
the list.

[Simplog-devel] Some tweaks

[Jim Hu <ji...@ta...>]

I decided that it's a bit of a pain to have to scroll through a list to 
find a specific post in order to edit it, so I set up my blogs so that 
when you view just that specific post, an Edit link replaces the 
permalink link...after all, clicking the permalink would just send you 
to the same view.

Here's what I did:

In archive.php:

	foreach ($blogEntries as $blogEntry) {
		$line = 
marker_sub(stripslashes($blogInfo->getBlogTemplate()),$blogEntry, 
$blogInfo);
		if ($_REQUEST['pid']){
			$line = str_replace("archive.php?","edit.php?act=edit&",$line);
			$line = str_replace(">permalink<",">Edit<",$line);
		}	
		echo $line;

replaces the original foreach loop.

That's all it takes.

Jim

Re: [Simplog-devel] adodb

[Jim Hu <ji...@ta...>]

Jason,

I think it's logical for you to build on the security stuff that you 
have started on.

For the attributes, I'm not sure if you are still thinking in terms of 
the schema diagram you sent the other day.  It's taken me a few days to 
find the time to look at it.  As I understand it, the benefit of this 
is that modifications can be built into 1.0 without having to change 
the underlying schema.  Although it seems contrary in some ways to my 
really primitive understanding of database normalization (i.e. that it 
would make sense to have additional columns), it seems to me that your 
idea is basically a good one in terms of upgrade paths and 
standardization.  If I'm following your thinking, the set of attribute 
tables is basically a catch-all for extra fields that people could add 
on top of 1.0.  It would allow something similar to a plug-in model for 
customization where an added php module could use attributes in these 
tables and not touch the underlying schema.  If that's the idea, I like 
it!... especially since I've already gotten out of sync with everyone 
else by splitting my date fields in blog_entries into both created and 
modified.

However, the schema you sent seems more complicated than necessary to 
my naive eye.  What is the problem with handling the attributes with 
just one additional table instead of four?

CREATE  TABLE `attribute`  (
`attribute_id` INT UNSIGNED NOT  NULL  AUTO_INCREMENT ,
`table_name` INT UNSIGNED NOT  NULL ,
`foreign_key` INT UNSIGNED NOT  NULL ,
`attribute_key` VARCHAR( 10  )  NOT  NULL ,
`attribute_val` VARCHAR( 10  )  NOT  NULL ,
PRIMARY  KEY ( `attribute_id`   )
);

To use your example, to set blog number 4 to allow rss, a row would be 
created with values ('','blog_list','4','allow_rss','true')
and retrieve the info with something like:

SELECT attribute_key, attribute_val FROM attribute, blog_list WHERE 
table_name = ' blog_list'
	AND blog_id = foreign_key AND blog_id = 4 AND 
attribute_key='allow_rss';

To get the list of blogs with rss feeds, you'd change to something like:

SELECT blog_id FROM attribute, blog_list WHERE table_name = ' blog_list'
	AND blog_id = foreign_key AND attribute_key='allow_rss' AND 
attribute_val='true';

and so on. From what I understand, this simpler schema would lose the 
ability to specify which attributes are allowed, and which key=>value 
pairs are allowed...but what is the cost of that?  I'm thinking that 
this could just as easily be controlled from the php interface 
side...but I'm sure I'm missing something, as your schema looks more 
like what I remember from my one intermittently audited db class.

Whichever way attributes are handled, it also seems to me that in 
integer releases those modules that are most useful should be rolled 
into new columns or tables in the core schema. Between integer 
releases, new functionalities would use the attributes table, and 
ideally the overall software scheme could be modified to make things 
modular so that just like the core schema, the core php files don't 
have to change for new features, just for bug fixes.  I'm not 
completely sure how I would do this, but I'm thinking of something like 
this:

class.BlogInfo would add methods to handle attributes.
lib.php would include a line include("plugins.php").  plugins.php would 
be a list of include statements for plugin modules, which would live in 
a plugins folder.

In addition to the rss example, it seems to me that attributes could 
control many of the features that have been discussed/requested, 
including applying different css files and layouts to different blogs, 
closing comments on specific blog_entries, and so on.

Just my $0.02.

Jim

On Sep 21, 2004, at 11:37 PM, Jason L. Buberel wrote:

> I'd like to make one (hopefully the last for a while) infrastructure 
> investment in the database schema - to allow us to flexibly add 
> attributes to various tables in the DB without having to add new 
> columns to existing tables all of the time.
>
>  design email with diagrams to follow shortly.
>
>  i'd like to take a pass at the security overhaul, fwiw.
>
>  -jason
> <snip>

Re: [Simplog-devel] adodb

[Jeremy A. <ash...@13...>]

Jim Hu wrote:

>
>
> I don't think that works - I don't think pass the $_GET vars via 
> include unless it's via a url - the regular filesystem doesn't parse 
> them.  Of course, you could just have include blocksleft.php and 
> include blocksright.php.
>
true, but you can also define $_REQUEST['show'] = right before including 
the blocks file

<?php

$_REQUEST['show'] = 'right';
include("blocks.php");

?>

>
> I could deal with the Mozilla browsers.  When I use Firefox 0.8 to go to:
>
> http://www.interactivetools.com/products/htmlarea/index.html#demo
>
> I just see a textbox with html in it, which is the same as what I see 
> with Safari.  Am I missing something obvious?  Should I be trying a 
> different URL for a demo?  Should I just download it and try it?
>
htmlArea v2 only works in IE

htmlArea v3 works in all the above browsers

http://www.dynarch.com/htmlarea/

>
> Another thing - I'd like to grant administrator privileges to more 
> than one person, but not on all blogs.  Is the admin field in blog_acl 
> doing anything?  Was that the function?  Also, there's the question of 
> who can add users.  This may be something I've messed up in my 
> customizations, but in my setup the blog adminstrator can move 
> existing users around, but does not get the user administration 
> available to the main administrator.  I'm not sure whether or not 
> that's a good thing!  I think what I'd like is for a blog admin to be 
> able to add users to that specific blog, but not be able to delete or 
> edit their global priveleges/info.
>
not currently, that was its original function, but we never implemented 
it that way

> It is probably the xmlrpc problem, but when I tried to install on my 
> laptop, I got a blank screen after the step where you choose upgrade 
> vs install.  I think others have had that problem.  Editing the file 
> made it usable, but a new user will get stuck.
>
is this a Windows based install?  I've never tested or even tried to 
install it on windows, nor do I ever care to. :)  If you can track it 
down, let me know....

Re: [Simplog-devel] blocks.php

[Jim Hu <ji...@ta...>]

Playing with this some more, I realized that I needed a few more tweaks:
I changed $_GET['blogid'] to $_REQUEST['blogid'] to handle posts that  
invoke the page.

More importantly, I realized that calendar blocks were not behaving  
correctly, so I split the mk_drawCalendar function into two functions.
In blocks.php I changed
	mk_drawCalendar($m,$y,0);
to
	$string .= mk_Calendar($m,$y,0);

Splitting into the two functions makes any other calls to  
mk_drawCalendar work the same as before.
Sorry to send off the other version prematurely...hope this works  
better.

Jim

--------------------revised functions for lib.php------------------
#
# mk_drawCalendar - builds calander for archive script
#
function mk_drawCalendar($m,$y,$search=1)
{
	echo mk_Calendar($m,$y,$search=1);
}

function mk_Calendar($m,$y,$search=1)
{
     global $blogid, $db;
	
     if ((!$m) || (!$y))
     {
          $m = date("n",mktime());
          $y = date("Y",mktime());
     }
								
    /*== get what weekday the first is on ==*/
    $tmpd = getdate(mktime(0,0,0,$m,1,$y));
    $month = $tmpd["month"];
    $firstwday= $tmpd["wday"];
    $today = date("Ymd",mktime());
								
    $lastday = mk_getLastDayofMonth($m,$y);


$string = '
<table><tr>
<td  
style="padding-left:12px;padding-right:12px;padding-top:4px;padding- 
bottom:4px;border:1px solid #999999;background-color:#eeeeee;">
		<table cellspacing="0" cellpadding="2" border="0">
					<tr>
						<td colspan="7" align="center"><b>'."$month $y".'</b>
						</td>
					</tr>
					<tr>

						<td width="19" align="center" class="calday">Sun</td>
						<td width="19" align="center" class="calday">Mon</td>
						<td width="19" align="center" class="calday">Tue</td>
						<td width="19" align="center" class="calday">Wed</td>
						<td width="19" align="center" class="calday">Thu</td>
						<td width="19" align="center" class="calday">Fri</td>
						<td width="19" align="center" class="calday">Sat</td>
					</tr>';
	$d = 1;
     $wday = $firstwday;
     $firstweek = true;

	 /*== loop through all the days of the month ==*/
	 while ( $d <= $lastday)
	 {
				
	    /*== set up blank days for first week ==*/
	    if ($firstweek) {
	    	$string .= "<tr>";
	    	for ($i=1; $i<=$firstwday; $i++)
	    	{ $string .= "<td>&nbsp;</td>"; }
	    	$firstweek = false;
	    }
																						
        /*== Sunday start week with <tr> ==*/
        if ($wday==0) { $string .= "<tr>"; }
															
															
        $mo = $m;
        if($mo <10) {
            if(!preg_match("/0\d/",$mo)) {
                 $mo = "0".$mo;
            }
        }
																																								
        $da = $d;
        if($da <10) {
             if(!preg_match("/0\d/",$da)) {
                  $da = "0".$da;
             }
        }
																																																						
  		/*== Look for blog entries for this day ==*/
	   $sql = "select count(*) as count from blog_entries where blog_id =  
$blogid AND date like '$y-$mo-$da%'";
	   $res = $db->Execute($sql);

	  /*== check for event ==*/
       $showdate = $y.$mo.$da;

	  $string .= "<td align=center class=calday";
       if($showdate == $today) {
	       $string .= " bgcolor=gainsboro";
	  }
	  $string .= ">";

	  /*== if entries are found, output link to that days entries ==*/
	  if($res->fields['count'] > 0) {
	       $string .= "<a  
href=\"archive.php?m=$mo&d=$da&y=$y&blogid=$blogid\">$d</a>";
	  } else {
	       $string .= $d;
	  }
	  $string .= "</td>\n";

	  /*== Saturday end week with </tr> ==*/
       if ($wday==6) { $string .= "</tr>\n"; }
	
       $wday++;
       $wday = $wday % 7;
       $d++;
	}

	if($wday != 0) {
		for($i=$wday; $i <7; $i++) {
			$string .= "<td></td>\n";
		}
		$string .= "</tr>\n";
	}

	#determine next and previous month
	if(($m-1)<1) { $pm = 12; } else { $pm = $m-1; }
	if(($m+1)>12) { $nm = 1; } else { $nm = $m+1; }

	if(strlen($pm) == 1) { $pm = "0".$pm; };
	if(strlen($nm) == 1) { $nm = "0".$nm; };

$string .= '<tr><td colspan=3 align=right>';
$string .= "<b><a href=\"archive.php?m=$pm&y=(($m-1)<1) ? $y-1 :  
$y&blogid=$blogid\">".getPrevMo($mo)."</a></b>
</td><td><br></td>";
$string .= "<td colspan=3 align=left><b><a  
href=\"archive.php?m=$nm&y=(($m+1)>12) ? $y+1 :  
$y&blogid=$blogid?>\">".getNextMo($mo)."</b></a></td></tr>
</table>";
if($search){
$string .= "<div align=center>
<hr>
<form action=\"archive.php\" method=POST>
<input type=hidden name=blogid value=\"$blogid\">
<input type=hidden name=act value=\"search\">
<input type=text class=search2 name=keyw><br><input class=search  
type=submit value=\"Search\">
</form>
</div>";
}
$string .="</td></tr></table><br>";

return $string;
/*== end drawCalendar function ==*/
}


On Sep 23, 2004, at 1:00 AM, Jim Hu wrote:

> Here's my revised version of blocks.php to put the blocks in an array.  
>  To display them,
>
> 		include "blocks.php";		
> 		foreach ($blockarray as $key=>$block){
> 			echo $block;
> 		}
>
> To display just the first 3 (for example)
> 		include "blocks.php";		
> 		foreach ($blockarray as $key=>$block){
> 			if ($key<3) echo $block;
> 		}
> This is much better than what I posted before - as with the problem  
> with isUserAuthorized, using file("blocks.php?blogid=3") doesn't pass  
> the $_SESSION vars, so the login block doesn't act like you're ever  
> logged in.  With this approach it works as expected.
>
> Jim
>
> <blocks.php>

[Simplog-devel] blocks.php

[Jim Hu <ji...@ta...>]

Here's my revised version of blocks.php to put the blocks in an array.  
To display them,

		include "blocks.php";		
		foreach ($blockarray as $key=>$block){
			echo $block;
		}

To display just the first 3 (for example)
		include "blocks.php";		
		foreach ($blockarray as $key=>$block){
			if ($key<3) echo $block;
		}
This is much better than what I posted before - as with the problem 
with isUserAuthorized, using file("blocks.php?blogid=3") doesn't pass 
the $_SESSION vars, so the login block doesn't act like you're ever 
logged in.  With this approach it works as expected.

Jim

Re: [Simplog-devel] adodb

[Jim Hu <ji...@ta...>]

On Sep 22, 2004, at 7:21 PM, Jeremy Ashcraft wrote:

> Jim Hu wrote:
>
>>
>> I had been wondering, since the adobdb files in 0.91 are an older 
>> version than in 0.90!
>>
> whoops......looks like an old ADOdb version that was languishing in 
> CVS slipped past me.  I usually expoprt the source from CVS, then add 
> in the latest adodb build when packaging a release.  I'll update it 
> tonight, fix the small bug you spotted and post an 0.9.2  release on 
> the site.
>
>>>
>>> Here's a quick list of  some preliminary ideas for 1.0:
>>> - be able to enable/disable commenting for individual posts
>>> - new permissions system
>>> - sitewide templates/make it easier for users to customize look and 
>>> feel
>>
>>
>> As I recall a bunch of users asked for the option for a 3-column 
>> layout.
>> I guess a question is how much you want to do stuff for the user, vs. 
>> how much to just have tips on setting things up.  The basic blogs are 
>> very functional, and learning how to customize beyond the standard 
>> install is part of the fun!
>>
> I might just allow the user to flag if a block is supposed to be right 
> or left and pass a flag to the blocks.php to display R or L blocks 
> only, so you' include blocks.php?show=left in one column and 
> blocks.php?show=right on the other.  I was thinking of adding a style 
> manager for the blog admins rather than try to implement a full blown 
> site templating system.    Since the whole idea behind simplog was to 
> include PHP inline, the user can layout the page however they want in 
> the index.php file.....

I don't think that works - I don't think pass the $_GET vars via 
include unless it's via a url - the regular filesystem doesn't parse 
them.  Of course, you could just have include blocksleft.php and 
include blocksright.php.


>
>>> - extended text for posts
>>> - post via email
>>> - integrate htmlArea editor into app
>>
>> Regarding editing:
>> - As I've said before, I hope this won't be a required editor, since 
>> as far as I can tell it doesn't work on Macs.  Does it work with 
>> other browsers on Windows?
>
> It works in IE5.5+, Netscape 7.1+, Mozilla 1.3+, Firebird/fox 0.7+, 
> Camino 0.8+ on any platform that supports those browsers.  Moz, 
> Firefox, and Camino are all available on the Mac.  I was thinking of 
> making it a preference to the user to enable/disable it.  I don't know 
> of any for Safari, as its based on KHTML(idiot apple!), which doesn't 
> current have the technology to edit markup inline in the browser....
>
> We can also make available other inline editors, like FCK(which their 
> demo doesn't work on FF1.0PR..grrr) or others
>
> We use it in an app at work and all our Mac users get pissed when I 
> tell them to download Firefox. :)

I could deal with the Mozilla browsers.  When I use Firefox 0.8 to go 
to:

http://www.interactivetools.com/products/htmlarea/index.html#demo

I just see a textbox with html in it, which is the same as what I see 
with Safari.  Am I missing something obvious?  Should I be trying a 
different URL for a demo?  Should I just download it and try it?

>
>>> - user auto registration with/without admin approval
>>> - a couple other things I can't remember right now.....
>>
>>
>> There was a feature request from someone for a way to manage image 
>> uploads and links.
>>
> i remember now....
>
>>>
>>> anything else you guys would like to see?
>>
>>
>> Have both creation vs. last updated as fields...(I've done this in 
>> mine...it's trivial, but I haven't figured out where to change the 
>> install scripts to be compatible)
>
> no problem....there will be a 09to10.php script to add all DB changes 
> for upgrades, and another script where the tables are created, but its 
> name is escaping me right now....
>
>> I'd like a way to email everyone on the acl for a specific blog.
>
> sure

Another thing - I'd like to grant administrator privileges to more than 
one person, but not on all blogs.  Is the admin field in blog_acl doing 
anything?  Was that the function?  Also, there's the question of who 
can add users.  This may be something I've messed up in my 
customizations, but in my setup the blog adminstrator can move existing 
users around, but does not get the user administration available to the 
main administrator.  I'm not sure whether or not that's a good thing!  
I think what I'd like is for a blog admin to be able to add users to 
that specific blog, but not be able to delete or edit their global 
priveleges/info.

>
>> I think the installer scripts need some work.
>
> me too....what did you have in mind?

It is probably the xmlrpc problem, but when I tried to install on my 
laptop, I got a blank screen after the step where you choose upgrade vs 
install.  I think others have had that problem.  Editing the file made 
it usable, but a new user will get stuck.

>
>> Is there a way to have two versions of xmlrpc.inc (with and without 
>> xmlrpc_decode and xmlrpc_encode) and have the installer detect based 
>> on error trapping which one to install?
>>
> I think we should just rename the functions.....:)
>
>

I was actually wondering if we could do that!

Re: [Simplog-devel] adodb

[Jeremy A. <ash...@13...>]

Jim Hu wrote:

>
> I had been wondering, since the adobdb files in 0.91 are an older 
> version than in 0.90!
>
whoops......looks like an old ADOdb version that was languishing in CVS 
slipped past me.  I usually expoprt the source from CVS, then add in the 
latest adodb build when packaging a release.  I'll update it tonight, 
fix the small bug you spotted and post an 0.9.2  release on the site.

>>
>> Here's a quick list of  some preliminary ideas for 1.0:
>> - be able to enable/disable commenting for individual posts
>> - new permissions system
>> - sitewide templates/make it easier for users to customize look and feel
>
>
> As I recall a bunch of users asked for the option for a 3-column layout.
> I guess a question is how much you want to do stuff for the user, vs. 
> how much to just have tips on setting things up.  The basic blogs are 
> very functional, and learning how to customize beyond the standard 
> install is part of the fun!
>
I might just allow the user to flag if a block is supposed to be right 
or left and pass a flag to the blocks.php to display R or L blocks only, 
so you' include blocks.php?show=left in one column and 
blocks.php?show=right on the other.  I was thinking of adding a style 
manager for the blog admins rather than try to implement a full blown 
site templating system.    Since the whole idea behind simplog was to 
include PHP inline, the user can layout the page however they want in 
the index.php file.....

>> - extended text for posts
>> - post via email
>> - integrate htmlArea editor into app
>
> Regarding editing:
> - As I've said before, I hope this won't be a required editor, since 
> as far as I can tell it doesn't work on Macs.  Does it work with other 
> browsers on Windows? 

It works in IE5.5+, Netscape 7.1+, Mozilla 1.3+, Firebird/fox 0.7+, 
Camino 0.8+ on any platform that supports those browsers.  Moz, Firefox, 
and Camino are all available on the Mac.  I was thinking of making it a 
preference to the user to enable/disable it.  I don't know of any for 
Safari, as its based on KHTML(idiot apple!), which doesn't current have 
the technology to edit markup inline in the browser....

We can also make available other inline editors, like FCK(which their 
demo doesn't work on FF1.0PR..grrr) or others

We use it in an app at work and all our Mac users get pissed when I tell 
them to download Firefox. :)

>> - user auto registration with/without admin approval
>> - a couple other things I can't remember right now.....
>
>
> There was a feature request from someone for a way to manage image 
> uploads and links.
>
i remember now....

>>
>> anything else you guys would like to see?
>
>
> Have both creation vs. last updated as fields...(I've done this in 
> mine...it's trivial, but I haven't figured out where to change the 
> install scripts to be compatible)

no problem....there will be a 09to10.php script to add all DB changes 
for upgrades, and another script where the tables are created, but its 
name is escaping me right now....

> I'd like a way to email everyone on the acl for a specific blog.

sure

> I think the installer scripts need some work.

me too....what did you have in mind?

> Is there a way to have two versions of xmlrpc.inc (with and without 
> xmlrpc_decode and xmlrpc_encode) and have the installer detect based 
> on error trapping which one to install?
>
I think we should just rename the functions.....:)

Re: [Simplog-devel] adodb

[Jim Hu <ji...@ta...>]

On Sep 21, 2004, at 11:26 AM, Jeremy Ashcraft wrote:

> I was just too lazy to go out to the adodb site and grab the latest 
> version when I built the current release. :)
> I think the permissions system needs an overhaul, so your ideas are 
> good.  Plus simplog is wide open for comment spam right now, so 
> locking down comments is a good idea.

I had been wondering, since the adobdb files in 0.91 are an older 
version than in 0.90!

>
> Here's a quick list of  some preliminary ideas for 1.0:
> - be able to enable/disable commenting for individual posts
> - new permissions system
> - sitewide templates/make it easier for users to customize look and 
> feel

As I recall a bunch of users asked for the option for a 3-column 
layout.  I think this could be done by duplicating the blocks stuff to 
be leftblocks and rightblocks and then setting up blocksadmin to 
display two copies of what it has now...perhaps the display could 
depend on whether the blog is specified as 2-column or 3-column.  
Alternatively, one could just use the current setup and make it so that 
blocks 1-n up go on the left, while n+1 to end go on the right.  Just 
to try this, I changed my blocks.php to add:

include_once("lib.php");
include_once ("class.BlogInfo.php");
include_once ("class.BlogEntry.php");

I also altered it so that each block starts with a comment 
"<!--block-->"
This allows me to treat blocks.php as a feed generator.  In my site, I 
inserted the following code in the part that encodes left side:

		$blocks=implode("",file("$baseurl/blocks.php?blogid=3"));
		
		$blockarray=explode("<!--block-->",$blocks);
		foreach ($blockarray as $key=>$block){
			if ($key<3) echo $block;
		}

and on the right column cell I put in:
	foreach ($blockarray as $key=>$block){
			if ($key>=3) echo $block;
		}

The result can be seen at: 
http://dimer.tamu.edu/simplog/index.php?blogid=3.  Actually, this can 
be done more cleanly by changing blocks.php to load up the array 
directly.  I may play with that idea tonight.

I guess a question is how much you want to do stuff for the user, vs. 
how much to just have tips on setting things up.  The basic blogs are 
very functional, and learning how to customize beyond the standard 
install is part of the fun!

> - extended text for posts
> - post via email
> - integrate htmlArea editor into app
Regarding editing:
- As I've said before, I hope this won't be a required editor, since as 
far as I can tell it doesn't work on Macs.  Does it work with other 
browsers on Windows?  In looking into this, it seems like there are 
other javascript based rtf/html editors out there.  FCKeditor seems to 
have a lot of hits on sourceforge, and there may be others.  
FCKEditor's demo almost works on Mozilla Firefox on my Mac, but not in 
Safari.

If this is done, I'd like to see some way where a user can configure 
what editor to use, or for Simplog to detect the browser and load one 
that works - or the basic textarea one.

- At a much simpler level, I'm thinking that it might be nice to have 
the editing boxes come up in a new window instead of next to the list 
of posts.  That way, when you click update, you'd close the editing 
window but go straight back to the list of posts - which would be right 
where you left it, instead of defaulting to the most recent.  It would 
also allow you to work in a larger window for the actual editing.

- In my copy, I did some tweaking to get rid of <br /> tags that get 
inserted by marker_sub inside tables.  I'm not happy with my 
implementation, and I'd like to work with the rest of you guys to make 
it better.  If there really is a good wysiwyg html/javascript editor 
out there this would be moot, of course.  In the meantime, what makes 
my current solution clunky is I'm having marker_sub look specifically 
for the tags I want to exempt from added breaks.  I could make things a 
lot simpler if I just make a rule that any line that ends in ">" 
followed by whitespace is not a real line break.  Users could put in 
two line breaks to get the <br /> tag back, or hard-code the <br />.  
Can anyone think of a reason why this would be bad?

> - user auto registration with/without admin approval
> - a couple other things I can't remember right now.....

There was a feature request from someone for a way to manage image 
uploads and links.

>
> anything else you guys would like to see?

Have both creation vs. last updated as fields...(I've done this in 
mine...it's trivial, but I haven't figured out where to change the 
install scripts to be compatible)
I'd like a way to email everyone on the acl for a specific blog.
I think the installer scripts need some work.  Is there a way to have 
two versions of xmlrpc.inc (with and without xmlrpc_decode and 
xmlrpc_encode) and have the installer detect based on error trapping 
which one to install?

...and...I'd like a script that automatically cooks all those recipes 
that jason posts on his blog!

Jim
<snip>

Re: [Simplog-devel] rss

[Jason L. B. <ja...@bu...>]

there is no DB field in which to track this sort of attribute on a 
per-blog basis. however, I can certainly see a present and future need 
for tracking this kind of data. this is really begging for the classical 
attribute-link database solution, which will prevent us from having to 
add database columns for each new attribute (like 'supportsRssFeed') 
that we think each blog might need.

the classical solution to this is:



*attribute_master* holds the list of attributes that can be defined 
(such as 'supportsRssFeed' or 'supportsAtomFeed').

*attribute_value* holds the actual value of each instance of each 
attribute (such as 'blog_id 4 has attribute supportsRssFeed with value 
true').

*attribute_link *is a join table (contianing only primary keys or 
foriegn keys) that tells you which attribute_values are associated with 
each blog or other entity in the system.

*attribute_master_value* joins attribute_master with attribute_values to 
tell you what possible values each attribute_master definition can have. 
Useful for building pull down menus and options lists.

So to determine if a particular blog supports an RSS2.0 feed, you might 
do the following query:

select
    av.attribute_value, b.blog_id
from
    blog b, attribute_value av, attribute_link al, attribute_master am
where
    b.attribute_link_id = al.attribute_link_id and
    al.attribute_link_id = av.attribute_value_id and
    al.attribute_master_id = am.attribute_master_id and
    am.attribute_master_name = 'supportsRss2.0Feed' and
    b.blog_id = 4;

You would then check the value of 'av.attribute_value' to determine if 
the blog with blog_id =4 supports RSS2.0 feeds.

We can use this sub-schema to associate arbitrary numbers of attributes 
(essentially name = value pairs) in a controlled manner with any of the 
primary entities in the database (blogs, blog_entries, comments, etc.). 
And we can add new attributes with each release by simply inserting new 
rows into attribute_master, attribute_master_value and attribute_value 
as needed. We would no longer need to create new tables or add columns 
to existing tables in most cases.

If properly indexed, the performance is reasonable.

What do you think? We could use Jim's request of per-blog RSS-feed 
support as the first test case of this.

-jason


Jim Hu wrote:

> No! What I meant is: what if I don't want a specific blog to generate 
> an rss feed at all...one of my simplog-controlled blogs, that is.  I 
> know that I could hard-code it into rss.php, but I was wondering if 
> there was a field in the database that controlled whether or not 
> rss.php will return data - it didn't look like it from the code.
>
> Hope that makes more sense.
>
> JH
>
> On Sep 21, 2004, at 8:07 PM, ja...@bu... wrote:
>
>> What exactly do you mean by that first question?
>> If you use the Blocks Admin section for your blog, and you include 
>> the RSS/Atom block, then your blog will show the icons/links to the 
>> appropriate feeds.
>> If you mean "Is there some internet standard mechanism by which a web 
>> site or web page can declare, through the use of XHTML meta data, 
>> that it contains an RSS-compliant feed", then the answer is Yes. Use 
>> a 1.0PR release of Firefox to browse Slashdot.org, and look at the 
>> lower right corner of the browser window: it shows an RSS icon.
>> It accomplishes this using the following in the < head > section of 
>> the page:
>> <LINK REL="alternate" TITLE="Slashdot RSS" 
>> HREF="//slashdot.org/index.rss" TYPE="application/rss+xml">
>> -jason
>> Jim Hu writes:
>>
>>> Is there currently a way to specify whether or not a site gives an 
>>> rss feed?
>>> I also noticed that two of my 13 blogs give XML parsing errors Jim 
>>> Hu  -------------------------------------------------------
>>> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>> Project Admins to receive an Apple iPod Mini FREE for your judgement on
>>> who ports your project to Linux PPC the best. Sponsored by IBM.
>>> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>> _______________________________________________
>>> Simplog-devel mailing list
>>> Sim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/simplog-devel 
>>> !DSPAM:4150af04292852839519405!
>>
>>
>

-- 
Jason L. Buberel - ja...@bu... - http://www.buberel.org
JabberID:ja...@im... - m:+16504831989

Re: [Simplog-devel] adodb

[Jason L. B. <ja...@bu...>]

I'd like to make one (hopefully the last for a while) infrastructure 
investment in the database schema - to allow us to flexibly add 
attributes to various tables in the DB without having to add new columns 
to existing tables all of the time.

design email with diagrams to follow shortly.

i'd like to take a pass at the security overhaul, fwiw.

-jason

Jeremy Ashcraft wrote:

> I was just too lazy to go out to the adodb site and grab the latest 
> version when I built the current release. :)
> I think the permissions system needs an overhaul, so your ideas are 
> good.  Plus simplog is wide open for comment spam right now, so 
> locking down comments is a good idea.
>
> Here's a quick list of  some preliminary ideas for 1.0:
> - be able to enable/disable commenting for individual posts
> - new permissions system
> - sitewide templates/make it easier for users to customize look and feel
> - extended text for posts
> - post via email
> - integrate htmlArea editor into app
> - user auto registration with/without admin approval
> - a couple other things I can't remember right now.....
>
> anything else you guys would like to see?
>
> Jim Hu wrote:
>
>> Jason,
>>
>> Can't say about 4.2, but I also put it on my server, which is still 
>> running 4.3. Seems to work with Simplog. The Sourceforge page says it 
>> requires php 4.0.5 or later.
>>
>> OK, I figured out the problem. The index file I had modified uses:
>>
>> <?php @include("$baseurl/blog.php?blogid=$blogid"); ?>
>>
>> which I think was based on an older version of index.php. Yours uses
>>
>> <?php include("blog.php"); ?>
>>
>> I believe what is happening is that when the include statement looks 
>> for http://hostname/simplog/blog.php?blodid=X, the session info is 
>> not being transferred via the http request...in other words, the 
>> content is being called by user Apache, not the user logged in. Since 
>> Apache is not on the blog_acl, and is not logged in, isUserAuthorized 
>> returns false and no content comes back.
>>
>> So, the good news is that I can fix this to work now with 
>> isUserAuthorized on all of my blogs. However, there is a design issue 
>> regarding the meaning of public, protected, and private that should 
>> be resolved before going further - I think that your function changes 
>> the meanings...it does so in a way that I sort of agree with, but 
>> here's the problem:
>>
>> In the help files, Jeremy defines the three kinds of blogs as follows:
>>
>>     A new blog can be Public, Protected or Private, and this provides
>>     a method of pre-defining which users can contribute new comments
>>     without explicitly defining each. In a public blog, any user with
>>     a logon can add entries. In a protected blog, any one of a specfic
>>     set of users can add entries, and others are stopped. In a private
>>     blog, only one person can add entries. Regardless of whether the
>>     blog is public, protected or private, everyone can read the blog.
>>
>>
>> With isUserAuthorized, this has changed so that only authorized users 
>> can _read_ protected and private blogs. I think that having blogs 
>> that are not accessible to the public is useful, and I took a 
>> different approach to get this functionality by adding auth() to the 
>> index files for each blog. However, this is trivially defeated by 
>> bypassing the index file via http://host/simplog/blog.php?blogid=X, 
>> so your solution should be better. The problem is - I think your 
>> solution breaks something we've been telling users about how to 
>> customize their pages - by using blog.php to pass formatted content 
>> to the target website. This means that upgrading to 0.91 may break 
>> some existing sites.
>>
>> It seems to me that it would be better to define the kinds of blogs 
>> differently than either of the above, based on four kinds of access 
>> permissions: view, comment, post, and administer. I'm not sure that 
>> the current distinction between protected and private is useful, as 
>> one could in principle make protected blogs with only one user. I'd 
>> suggest that all kinds of blogs should only allow posts by acl users, 
>> and all kinds of blogs should allow administration within a blog by 
>> anyone set as an administrator in the blog_acl table (not clear to me 
>> that the admin column in blog_acl does anything in current versions). 
>> The site administrator would still have global admin privileges. In 
>> addition, the three kinds would mean:
>>
>> public = anyone can view or comment
>> protected = anyone can view, only acl users can comment
>> private = only acl users can view or comment.
>>
>> What do people think? I'm wondering if I'm missing some history or 
>> standards within the blogging software world.
>>
>> Jim
>>
>> On Sep 21, 2004, at 12:24 AM, Jason L. Buberel wrote:
>>
>>     is the new adodb backwards compatible with php 4.3 and 4.2? if so,
>>     I would vote we upgrade simplog to use the new version.
>>
>>     -jason
>>
>>     PS Told you so :)
>>
>>     Jim Hu wrote:
>>     While playing with installing simplog on another computer (my
>>     laptop) to see if the distribution version of Simplog works
>>     without my modifications, I discovered that the version of adodb
>>     in the distribution is not compatible with php5.  There is one
>>     available at:
>>
>>
>>     http://adodb.sourceforge.net/
>>
>>     which seems to work fine.  Jason's security system seems to work
>>     on my laptop too, so I'll have to hunt down what I did differently
>>     in the other installation...looks like one of my changes is
>>     incompatible with his. :^(
>>
>>     Jim Hu
>>
>>
>>
>>     -------------------------------------------------------
>>     This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>>     Project Admins to receive an Apple iPod Mini FREE for your
>>     judgement on
>>     who ports your project to Linux PPC the best. Sponsored by IBM.
>>     Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>>     _______________________________________________
>>     Simplog-devel mailing list
>>
>>     Sim...@li...
>>     https://lists.sourceforge.net/lists/listinfo/simplog-devel
>>
>>    
>>
>>
>>
>>     --     Jason L. Buberel - ja...@bu... - http://www.buberel.org
>>     JabberID:ja...@im... - m:+16504831989
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Simplog-devel mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simplog-devel
>
> !DSPAM:415100b8273071624118016!
>

-- 
Jason L. Buberel - ja...@bu... - http://www.buberel.org
JabberID:ja...@im... - m:+16504831989

Re: [Simplog-devel] adodb

[Jeremy A. <ash...@13...>]

I was just too lazy to go out to the adodb site and grab the latest 
version when I built the current release. :) 

I think the permissions system needs an overhaul, so your ideas are 
good.  Plus simplog is wide open for comment spam right now, so locking 
down comments is a good idea.

Here's a quick list of  some preliminary ideas for 1.0:
- be able to enable/disable commenting for individual posts
- new permissions system
- sitewide templates/make it easier for users to customize look and feel
- extended text for posts
- post via email
- integrate htmlArea editor into app
- user auto registration with/without admin approval
- a couple other things I can't remember right now.....

anything else you guys would like to see?

Jim Hu wrote:

> Jason,
>
> Can't say about 4.2, but I also put it on my server, which is still 
> running 4.3. Seems to work with Simplog. The Sourceforge page says it 
> requires php 4.0.5 or later.
>
> OK, I figured out the problem. The index file I had modified uses:
>
> <?php @include("$baseurl/blog.php?blogid=$blogid"); ?>
>
> which I think was based on an older version of index.php. Yours uses
>
> <?php include("blog.php"); ?>
>
> I believe what is happening is that when the include statement looks 
> for http://hostname/simplog/blog.php?blodid=X, the session info is not 
> being transferred via the http request...in other words, the content 
> is being called by user Apache, not the user logged in. Since Apache 
> is not on the blog_acl, and is not logged in, isUserAuthorized returns 
> false and no content comes back.
>
> So, the good news is that I can fix this to work now with 
> isUserAuthorized on all of my blogs. However, there is a design issue 
> regarding the meaning of public, protected, and private that should be 
> resolved before going further - I think that your function changes the 
> meanings...it does so in a way that I sort of agree with, but here's 
> the problem:
>
> In the help files, Jeremy defines the three kinds of blogs as follows:
>
>     A new blog can be Public, Protected or Private, and this provides
>     a method of pre-defining which users can contribute new comments
>     without explicitly defining each. In a public blog, any user with
>     a logon can add entries. In a protected blog, any one of a specfic
>     set of users can add entries, and others are stopped. In a private
>     blog, only one person can add entries. Regardless of whether the
>     blog is public, protected or private, everyone can read the blog.
>
>
> With isUserAuthorized, this has changed so that only authorized users 
> can _read_ protected and private blogs. I think that having blogs that 
> are not accessible to the public is useful, and I took a different 
> approach to get this functionality by adding auth() to the index files 
> for each blog. However, this is trivially defeated by bypassing the 
> index file via http://host/simplog/blog.php?blogid=X, so your solution 
> should be better. The problem is - I think your solution breaks 
> something we've been telling users about how to customize their pages 
> - by using blog.php to pass formatted content to the target website. 
> This means that upgrading to 0.91 may break some existing sites.
>
> It seems to me that it would be better to define the kinds of blogs 
> differently than either of the above, based on four kinds of access 
> permissions: view, comment, post, and administer. I'm not sure that 
> the current distinction between protected and private is useful, as 
> one could in principle make protected blogs with only one user. I'd 
> suggest that all kinds of blogs should only allow posts by acl users, 
> and all kinds of blogs should allow administration within a blog by 
> anyone set as an administrator in the blog_acl table (not clear to me 
> that the admin column in blog_acl does anything in current versions). 
> The site administrator would still have global admin privileges. In 
> addition, the three kinds would mean:
>
> public = anyone can view or comment
> protected = anyone can view, only acl users can comment
> private = only acl users can view or comment.
>
> What do people think? I'm wondering if I'm missing some history or 
> standards within the blogging software world.
>
> Jim
>
> On Sep 21, 2004, at 12:24 AM, Jason L. Buberel wrote:
>
>     is the new adodb backwards compatible with php 4.3 and 4.2? if so,
>     I would vote we upgrade simplog to use the new version.
>
>     -jason
>
>     PS Told you so :)
>
>     Jim Hu wrote:
>     While playing with installing simplog on another computer (my
>     laptop) to see if the distribution version of Simplog works
>     without my modifications, I discovered that the version of adodb
>     in the distribution is not compatible with php5.  There is one
>     available at:
>
>
>     http://adodb.sourceforge.net/
>
>     which seems to work fine.  Jason's security system seems to work
>     on my laptop too, so I'll have to hunt down what I did differently
>     in the other installation...looks like one of my changes is
>     incompatible with his. :^(
>
>     Jim Hu
>
>
>
>     -------------------------------------------------------
>     This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>     Project Admins to receive an Apple iPod Mini FREE for your
>     judgement on
>     who ports your project to Linux PPC the best. Sponsored by IBM.
>     Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>     _______________________________________________
>     Simplog-devel mailing list
>
>     Sim...@li...
>     https://lists.sourceforge.net/lists/listinfo/simplog-devel
>
>     !DSPAM:414fba2e123313405524358!
>
>
>
>
>     -- 
>     Jason L. Buberel - ja...@bu... - http://www.buberel.org
>     JabberID:ja...@im... - m:+16504831989
>
>

Re: [Simplog-devel] rss

[Jim Hu <ji...@ta...>]

No! What I meant is: what if I don't want a specific blog to generate 
an rss feed at all...one of my simplog-controlled blogs, that is.  I 
know that I could hard-code it into rss.php, but I was wondering if 
there was a field in the database that controlled whether or not 
rss.php will return data - it didn't look like it from the code.

Hope that makes more sense.

JH

On Sep 21, 2004, at 8:07 PM, ja...@bu... wrote:

> What exactly do you mean by that first question?
> If you use the Blocks Admin section for your blog, and you include the 
> RSS/Atom block, then your blog will show the icons/links to the 
> appropriate feeds.
> If you mean "Is there some internet standard mechanism by which a web 
> site or web page can declare, through the use of XHTML meta data, that 
> it contains an RSS-compliant feed", then the answer is Yes. Use a 
> 1.0PR release of Firefox to browse Slashdot.org, and look at the lower 
> right corner of the browser window: it shows an RSS icon.
> It accomplishes this using the following in the < head > section of 
> the page:
> <LINK REL="alternate" TITLE="Slashdot RSS" 
> HREF="//slashdot.org/index.rss" TYPE="application/rss+xml">
> -jason
> Jim Hu writes:
>> Is there currently a way to specify whether or not a site gives an 
>> rss feed?
>> I also noticed that two of my 13 blogs give XML parsing errors Jim Hu 
>>  -------------------------------------------------------
>> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>> Project Admins to receive an Apple iPod Mini FREE for your judgement 
>> on
>> who ports your project to Linux PPC the best. Sponsored by IBM.
>> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>> _______________________________________________
>> Simplog-devel mailing list
>> Sim...@li...
>> https://lists.sourceforge.net/lists/listinfo/simplog-devel 
>> !DSPAM:4150af04292852839519405!
>

Re: [Simplog-devel] rss

[<ja...@bu...>]

What exactly do you mean by that first question? 

If you use the Blocks Admin section for your blog, and you include the 
RSS/Atom block, then your blog will show the icons/links to the appropriate 
feeds. 

If you mean "Is there some internet standard mechanism by which a web site 
or web page can declare, through the use of XHTML meta data, that it 
contains an RSS-compliant feed", then the answer is Yes. Use a 1.0PR release 
of Firefox to browse Slashdot.org, and look at the lower right corner of the 
browser window: it shows an RSS icon. 

It accomplishes this using the following in the < head > section of the 
page: 

<LINK REL="alternate" TITLE="Slashdot RSS" HREF="//slashdot.org/index.rss" 
TYPE="application/rss+xml"> 

 -jason 

Jim Hu writes: 

> Is there currently a way to specify whether or not a site gives an rss 
> feed?
> I also noticed that two of my 13 blogs give XML parsing errors 
> 
> Jim Hu 
> 
>  
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Simplog-devel mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simplog-devel 
> 
> !DSPAM:4150af04292852839519405! 
> 
 

[Simplog-devel] rss

[Jim Hu <ji...@ta...>]

Is there currently a way to specify whether or not a site gives an rss 
feed?
I also noticed that two of my 13 blogs give XML parsing errors

Jim Hu

[Simplog-devel] Blog types

[Jim Hu <ji...@ta...>]

I changed the subject line to be more relevant.

On Sep 21, 2004, at 12:04 PM, ja...@bu... wrote:
<snip>
> I actually looked for an official definition of what those three 
> things meant, but didn't find anything, so I just made up what I 
> thought was appropriate (public = anyone, protected = any 
> authenticated, private = user on the acl).
> Keep in mind that I haven't implemented any of the protection stuff on 
> the insert/update operations in class.BlogInfo or class.BlogEntry yet.
>> With isUserAuthorized, this has changed so that only authorized users 
>> can _read_ protected and private blogs.  I think that having blogs 
>> that are not accessible to the public is useful, and I took a 
>> different approach to get this functionality by adding auth() to the 
>> index files for each blog.  However, this is trivially defeated by 
>> bypassing the index file via http://host/simplog/blog.php?blogid=X, 
>> so your solution should be better.
>
> Well, it's not 'trivially defeated' - because the protection is 
> enforced near the data - in class.BlogInfo. That is why the calls to 
> isUserAuthorized() were placed there. Which is where the data security 
> should be enforced.
>> The problem is - I think your solution breaks something we've been 
>> telling users about how to customize their pages - by using blog.php 
>> to pass formatted content to the target website.  This means that 
>> upgrading to 0.91 may break some existing sites.

I meant trivially defeated in my install, where isUserAuthorized is 
still turned off by changing the final return to true.

>
> Well, it's a bit too late, seeing as 0.9.1 has been released. I 
> haven't seen any traffic on the user list to indicate that this has 
> caused problems.
>> It seems to me that it would be better to define the kinds of blogs 
>> differently than either of the above, based on four kinds of access 
>> permissions: view, comment, post, and administer.  I'm not sure that 
>> the current distinction between protected and private is useful, as 
>> one could in principle make protected blogs with only one user.  I'd 
>> suggest that all kinds of blogs should only allow posts by acl users, 
>> and all kinds of blogs should allow administration within a blog by 
>> anyone set as an administrator in the blog_acl table (not clear to me 
>> that the admin column in blog_acl does anything in current versions). 
>>  The site administrator would still have global admin privileges.  In 
>> addition, the three kinds would mean:
>
> The only thing missing from the above suggestion is 'simplicity'. Of 
> course we could come up with a much richer, more sophisticated ACL 
> implementation.
> The question is: Do users need it? Do administrators want it? Would it 
> justify the increase in complexity of the UI?
> If we are to continue to think of simplog as a 'personal blog 
> publishing tool', I would think could adopt:
> 1. Public - anyone can read, only ACL-users can insert/update/delete.
> 2. Protected - only ACL-users can read/insert/update/delete
> 3. Private - ACL-users can read, only owner can insert/update/delete
> -jason
>

This sounds reasonable to me, with the only other thing I'd 
add/emphasize is that the blog-specific ACL apply to all three kinds.  
I don't see a reason to have the ACL membership controlled by the blog 
type at all.
I'm assuming that comments will be set so that if you can read a post 
and comments are enabled, you can comment on it.  This would take care 
of protected and private blogs.  From your earlier response, spambots 
haven't been a problem for simplog comments, so this is probably fine - 
and if someone wants to limit who can comment, that could be an add-on 
customization.

Jeremy, what do you think?

Jim