phpslash-devel — For developers of phpslash to communicate.

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Mike G. <mi...@op...>]

Hi Matthew,

On Fri, 2003-10-03 at 12:48, Matthew Leingang wrote:
> On Fri, 2003-10-03 at 10:18, Mike Gifford wrote:
> [snip]
> > I'm often concerned about system resources & load times..  That first
> > page needs to pop up as quickly as it can..  Would be faster if it
> > loaded from the file system I think..  But I do like the flexibility of
> > having this data just stored in the database too.. 
> So how do you do both?  I was thinking you could use the DB to write an
> INI file, and update when you change the DB.  That brings up other
> issues, of course, like the fact that the INI file must be overwriteable
> by the web user.

I guess it depends on what stuff you are writing to a cached "INI" and
where it is..  We've developed a javascript addon to domMenu which
allows us to have dynamic javascript menus..  It's a fun little addon we
needed to cache..  I suppose some could hack in & write over it, but it
would only affect the navigation for a short period of time as it is
written over daily (all user controllable)..  There isn't any reason why
it couldn't be cached below the root level as well so that an external
source wouldn't be able to overwrite it.

> > > > Also, I've been toying with the idea of how to best develop a download
> > > > module (or do I mean file publication module?).  I've got something at
> > > > my latest PSL install (sorry for the less-than-creative skin)
> > > > http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18 
> > We've developed some upload tool for Back-End.  It shouldn't be too hard
> > to integrate them back into PSL..  Would be nice to see some of the
> > modules we've been developing migrate back into PSL since they are
> > developed on a very similar code base.
> Cool.  I'll take a look at your code.  Do you have a CVSweb interface or
> do I have to download and "more" it?

The latest tarball is here:
	http://back-end.org/snapshots/	

It's all in a sf.net cvs which should be browsable, but I've found it
less useful these days (though right now it seems fairly up-to-date):
http://cvs.sourceforge.net/viewcvs.py/back-end/back-end0.5.x/class/
BE_Upload.class
BE_XUpload.class
BE_XUploadDB.class
BE_XUploadForm.class
	 
Btw, this code was largely hacked together by me, but it's open to
enhancements..  so if you've got ideas, feel free to send me the code..

> > > > The block of downloads is generated automatically by scouring a given
> > > > directory.  Dates and document names are generated automatically (either
> > > > by prettying the filename or parsing LaTeX files), and different formats
> > > > of the same document are recognized.  There's a config file to override
> > > > defaults.  To add an item, I install the files and edit the config file
> > > > if need be.
> > > Looks nice.
> > We haven't integrated the multi format tool like you did..  That's a
> > neat feature.  it also isn't something that we really set up as a
> > download tool.  Would be very useful to be able to assign a section to a
> > particular uploaded file so that the files could be grouped together and
> > each download logged.  
> The multi format stuff may not be necessary.  I've never tracked but I'm
> sure 90% of my downloads are the PDFs.  But think about gzipped and
> bzipped tarballs; much metadata about one is the same for the other. 
> RDF + Dublin Core has the vocabulary to say all this.

Cool..  

> > We set it up so that all files in the updir sub-directory can be deleted
> > through the admin interface.  They can also be uploaded either through
> > scp or through our upload interface.  It's nice to have that
> > flexibility.
> If I upload something with scp I have to make it world-writeable so that
> I can delete it from the web, right?  How does that work?
> [snip]

I do think that is correct..  Would be more secure to move it below the
root directory for sure.

> > > One other thought I've had lately,  what kind of interest is there in the
> > > option to generate a static site?  Write html files to the drive to be
> > > published however.
> > I'd think that it could be quite useful to be able to export it all as
> > an html file.  Certainly for archiving purposes it is useful.  wget is
> > great and all, but would be nice to be able to produce a static version.
> Is there a wget one-liner that slurps a PHPSlash site to static html?  I
> tried it once but got lost.

I think these work:
  wget --convert-links --mirror http://www.slashdot.org
  wget -r -k -R .pdf -Dslashdot.org http://www.slashdot.org
  wget -r -l5 -k -Dslashdot.org http://www.slashdot.org

> I have archiving needs where the "interactivity" of my course web sites
> dies after the semester.  So I'd rather just save it all to HTML and I
> don't have to worry about supporting the database anymore.  So metoo on
> this feature.

Yup..  

> > Could also help to set the home page or even certain articles to be
> > static if they get slashdotted.  jpcache helps a lot with this, but it
> > still causes a lot more load than a good old html file.
> Jpcache can cache to html files, right?  Does that make it better or
> still not as good as you want?

It's good for making a snapshot of the html which is generated by your
dynamic site.  But it grabs all of the dynamic elements just as they
were if the site were actually dynamic..  Not sure there are many
applications where you would want to isolate the static files you want
saved as a .html file and the html you want just cached so that it loads
faster...

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master's tools will never dismantle the master's house - A Lorde

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Matthew L. <lei...@ma...>]

On Fri, 2003-10-03 at 10:18, Mike Gifford wrote:

[snip]
> I'm often concerned about system resources & load times..  That first
> page needs to pop up as quickly as it can..  Would be faster if it
> loaded from the file system I think..  But I do like the flexibility of
> having this data just stored in the database too.. 

So how do you do both?  I was thinking you could use the DB to write an
INI file, and update when you change the DB.  That brings up other
issues, of course, like the fact that the INI file must be overwriteable
by the web user.

> > > Also, I've been toying with the idea of how to best develop a download
> > > module (or do I mean file publication module?).  I've got something at
> > > my latest PSL install (sorry for the less-than-creative skin)
> > > http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18
> 
> We've developed some upload tool for Back-End.  It shouldn't be too hard
> to integrate them back into PSL..  Would be nice to see some of the
> modules we've been developing migrate back into PSL since they are
> developed on a very similar code base.

Cool.  I'll take a look at your code.  Do you have a CVSweb interface or
do I have to download and "more" it?

> > > The block of downloads is generated automatically by scouring a given
> > > directory.  Dates and document names are generated automatically (either
> > > by prettying the filename or parsing LaTeX files), and different formats
> > > of the same document are recognized.  There's a config file to override
> > > defaults.  To add an item, I install the files and edit the config file
> > > if need be.
> > Looks nice.
> 
> We haven't integrated the multi format tool like you did..  That's a
> neat feature.  it also isn't something that we really set up as a
> download tool.  Would be very useful to be able to assign a section to a
> particular uploaded file so that the files could be grouped together and
> each download logged.  

The multi format stuff may not be necessary.  I've never tracked but I'm
sure 90% of my downloads are the PDFs.  But think about gzipped and
bzipped tarballs; much metadata about one is the same for the other. 
RDF + Dublin Core has the vocabulary to say all this.

> We set it up so that all files in the updir sub-directory can be deleted
> through the admin interface.  They can also be uploaded either through
> scp or through our upload interface.  It's nice to have that
> flexibility.

If I upload something with scp I have to make it world-writeable so that
I can delete it from the web, right?  How does that work?

[snip]

> > One other thought I've had lately,  what kind of interest is there in the
> > option to generate a static site?  Write html files to the drive to be
> > published however.
> 
> I'd think that it could be quite useful to be able to export it all as
> an html file.  Certainly for archiving purposes it is useful.  wget is
> great and all, but would be nice to be able to produce a static version.

Is there a wget one-liner that slurps a PHPSlash site to static html?  I
tried it once but got lost.

I have archiving needs where the "interactivity" of my course web sites
dies after the semester.  So I'd rather just save it all to HTML and I
don't have to worry about supporting the database anymore.  So metoo on
this feature.

> Could also help to set the home page or even certain articles to be
> static if they get slashdotted.  jpcache helps a lot with this, but it
> still causes a lot more load than a good old html file.

Jpcache can cache to html files, right?  Does that make it better or
still not as good as you want?

--Matt
-- 
Matthew Leingang
Harvard University Department of Mathematics
lei...@ma...

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Joe S. <joe...@us...>]

On Fri, Oct 03, 2003 at 10:18:13AM -0400, Mike Gifford wrote:
> Howdy Joe & Matthew,
> 
<snip>

> > > Finally, I'm wondering about ways to expand permissions.  I guess I've
> > > been reading too much about Zope, but it seems like there ought be a way
> > > to assign permissions to everything, and permissions not set can be
> > > acquired.  Like a story can have read permissions set to a certain
> > > group, or if it belongs to a section with read permissions set, the
> > > story's permission would default to the section's permission.  
> > Let's expand on this sometime.  The permissions now can do the second
> > story example for sure, and I think the first one too ( maybe with a
> > little coaxing.)
> 
> The permissions in which version? -dev or 0.7.2?
> 

Either ( I think).

> > > That's what I'm thinking about.  What do you all think?
> > good stuff.
> 
> ditto..  
> 
> > One other thought I've had lately,  what kind of interest is there in the
> > option to generate a static site?  Write html files to the drive to be
> > published however.
> 
> I'd think that it could be quite useful to be able to export it all as
> an html file.  Certainly for archiving purposes it is useful.  wget is
> great and all, but would be nice to be able to produce a static version.
> 
> Could also help to set the home page or even certain articles to be
> static if they get slashdotted.  jpcache helps a lot with this, but it
> still causes a lot more load than a good old html file.
> 
> Btw, what's up with:
> 	http://www.phpslash.org
> 
> I can't see it at all..
>

Yeah, the dns seems to have dropped the domain.  I've emailed Jason and
nate w/no answer yet.  I've offered to host the dns for phpslash.org as
well.

Joe


> Mike
> -- 
> Mike Gifford, OpenConcept Consulting
> Free Software for Social Change -> http://www.openconcept.ca
> Fair Vote Petition - http://www.fairvotecanada.org/petition.php
> The master's tools will never dismantle the master's house - A Lorde
> 

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Mike G. <mi...@op...>]

Howdy Joe & Matthew,

On Thu, 2003-10-02 at 07:44, Joe Stewart wrote:
> > > Glad to see Back-End development proceeding.  I've been busy moving our
> > > office.  So hopefully will get cranked back up soon.
> > Giving up your view of the parthenon? :-)
> Yeah, we've got a view of the projects now - but Yazoo Brewing is right down the
> hall. :)   http://www.yazoobrew.com

Well, it may not do much for productivity, but moral will be high!  :)

I thought for a sec that it might have something to do with software
development.  Glad to see that it's a microbrewery..  

[snip]

> > > > I also wanted to know if there was any attempt to extend the ability to
> > > > turn on/off navbar links from the config.ini.php file.  I do think it
> > > > would be useful to allow the more detailed control over what appears in
> > > > the navbar than by simply turning on/off a module.  Certainly for things
> > > > like the links. 
> > > I'd like to see some patches for this, or a web management interface.
> > > I stalled on it with what seemed to be a limitation of the "ini" array
> > > stuff being limited to one level rather than having nested arrays.
> > I once thought that using dotted keywords in the ini file would work
> > almost as well as a nested array.  I still think it does from the
> > installer's standpoint.   You could just put something like
> > navbar.items.login.title = "Login"
> > navbar.items.login.link = "login.php"
> > navbar.items.login.perms = "nobody"

The user setting it up wouldn't much care or be at all concerned that
there were dots in this variable/array.

> That has worked well for some of the stuff in the -dev code.

Neat..  

> > >From a programmer's standpoint, I guess it's worse because you have to
> > do strange searches on the keys of $_PSL, but maybe that could be done
> > once and $_PSL sessionized, as we've been threatening.  
> > OTOH, a web interface is more like what the rest of psl is about. 
> > Probably a lot of the topic bar code could be reused.  The one drawback
> > is that generating the navbar that way would add a database call.  But
> > perhaps it can be sessionized or cached.
> Right.  That's why I kept it in the config file.

I'm often concerned about system resources & load times..  That first
page needs to pop up as quickly as it can..  Would be faster if it
loaded from the file system I think..  But I do like the flexibility of
having this data just stored in the database too.. 

> > Also, I've been toying with the idea of how to best develop a download
> > module (or do I mean file publication module?).  I've got something at
> > my latest PSL install (sorry for the less-than-creative skin)
> > http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18

We've developed some upload tool for Back-End.  It shouldn't be too hard
to integrate them back into PSL..  Would be nice to see some of the
modules we've been developing migrate back into PSL since they are
developed on a very similar code base.

> > The block of downloads is generated automatically by scouring a given
> > directory.  Dates and document names are generated automatically (either
> > by prettying the filename or parsing LaTeX files), and different formats
> > of the same document are recognized.  There's a config file to override
> > defaults.  To add an item, I install the files and edit the config file
> > if need be.
> Looks nice.

We haven't integrated the multi format tool like you did..  That's a
neat feature.  it also isn't something that we really set up as a
download tool.  Would be very useful to be able to assign a section to a
particular uploaded file so that the files could be grouped together and
each download logged.  

We set it up so that all files in the updir sub-directory can be deleted
through the admin interface.  They can also be uploaded either through
scp or through our upload interface.  It's nice to have that
flexibility.

> > I want to add the ability to upload stuff and make it available for
> > download through a web interface, but I don't want to lose the plain-old
> > scp uploading that I do now.  It seems like it would be good to accept
> > RDF metadata, too, rather than my naive config-file which looks like
> > LDIF. The module should also generate whatever metadata it can on its
> > own, but where does this all get stored?  That, and I would like to
> > assign read/overwrite privileges to certain groups...you can see why all
> > I've been doing is thinking about this.

Having metadata and would be useful..  Even a formal abstract to allow
folks to review a document before they bother to download it.

> > Finally, I'm wondering about ways to expand permissions.  I guess I've
> > been reading too much about Zope, but it seems like there ought be a way
> > to assign permissions to everything, and permissions not set can be
> > acquired.  Like a story can have read permissions set to a certain
> > group, or if it belongs to a section with read permissions set, the
> > story's permission would default to the section's permission.  
> Let's expand on this sometime.  The permissions now can do the second
> story example for sure, and I think the first one too ( maybe with a
> little coaxing.)

The permissions in which version? -dev or 0.7.2?

> > That's what I'm thinking about.  What do you all think?
> good stuff.

ditto..  

> One other thought I've had lately,  what kind of interest is there in the
> option to generate a static site?  Write html files to the drive to be
> published however.

I'd think that it could be quite useful to be able to export it all as
an html file.  Certainly for archiving purposes it is useful.  wget is
great and all, but would be nice to be able to produce a static version.

Could also help to set the home page or even certain articles to be
static if they get slashdotted.  jpcache helps a lot with this, but it
still causes a lot more load than a good old html file.

Btw, what's up with:
	http://www.phpslash.org

I can't see it at all..

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master's tools will never dismantle the master's house - A Lorde

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Joe S. <joe...@us...>]

On Thu, Oct 02, 2003 at 01:31:51PM -0400, Matthew Leingang wrote:
> On Thu, 2003-10-02 at 04:24, Joe Stewart wrote:
> > On Thu, Oct 02, 2003 at 11:17:04AM -0400, Mike Gifford wrote:
> > > Hello psl folks,
> > > 
> > > I'm writing mostly to find out when the new block feature that you've
> > > been working on is likely to get released.  I'm not sure when the next
> > > release is planned, but am planning to put out a new release of Back-End
> > > CMS very soon.
> > > 
> > 
> > Glad to see Back-End development proceeding.  I've been busy moving our
> > office.  So hopefully will get cranked back up soon.
> 
> Giving up your view of the parthenon? :-)
> 

Yeah, we've got a view of the projects now - but Yazoo Brewing is right down the
hall. :)   http://www.yazoobrew.com

> I need to get playing with the development code because I have ideas and
> I might as well put them in the new stuff.
> 
> [snip]
> 
> > > I also wanted to know if there was any attempt to extend the ability to
> > > turn on/off navbar links from the config.ini.php file.  I do think it
> > > would be useful to allow the more detailed control over what appears in
> > > the navbar than by simply turning on/off a module.  Certainly for things
> > > like the links. 
> > > 
> > 
> > I'd like to see some patches for this, or a web management interface.
> > 
> > I stalled on it with what seemed to be a limitation of the "ini" array
> > stuff being limited to one level rather than having nested arrays.
> 
> I once thought that using dotted keywords in the ini file would work
> almost as well as a nested array.  I still think it does from the
> installer's standpoint.   You could just put something like
> 
> navbar.items.login.title = "Login"
> navbar.items.login.link = "login.php"
> navbar.items.login.perms = "nobody"
> 
> navbar.items.glossary.title = "Glossary"
> navbar.items.glossary.link = "glossary.php"
> navbar.items.glossary.perms = "nobody"
> 
> navbar.items.admin.title = "Administration"
> navbar.items.admin.link = "login.php"
> navbar.items.admin.perms = "user"
> 
> and then even stuff like
> 
> navbar.perms.write = "someNewPermissionName"
> 
> (more on that idea later)
> 

That has worked well for some of the stuff in the -dev code.

> >From a programmer's standpoint, I guess it's worse because you have to
> do strange searches on the keys of $_PSL, but maybe that could be done
> once and $_PSL sessionized, as we've been threatening. 
> 
> OTOH, a web interface is more like what the rest of psl is about. 
> Probably a lot of the topic bar code could be reused.  The one drawback
> is that generating the navbar that way would add a database call.  But
> perhaps it can be sessionized or cached.
> 

Right.  That's why I kept it in the config file.

> Also, I've been toying with the idea of how to best develop a download
> module (or do I mean file publication module?).  I've got something at
> my latest PSL install (sorry for the less-than-creative skin)
> 
> http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18
> 
> The block of downloads is generated automatically by scouring a given
> directory.  Dates and document names are generated automatically (either
> by prettying the filename or parsing LaTeX files), and different formats
> of the same document are recognized.  There's a config file to override
> defaults.  To add an item, I install the files and edit the config file
> if need be.
> 

Looks nice.

> I want to add the ability to upload stuff and make it available for
> download through a web interface, but I don't want to lose the plain-old
> scp uploading that I do now.  It seems like it would be good to accept
> RDF metadata, too, rather than my naive config-file which looks like
> LDIF. The module should also generate whatever metadata it can on its
> own, but where does this all get stored?  That, and I would like to
> assign read/overwrite privileges to certain groups...you can see why all
> I've been doing is thinking about this.
> 

Thanks.  Some web hosts still probably don't have uploads enabled. 

> Finally, I'm wondering about ways to expand permissions.  I guess I've
> been reading too much about Zope, but it seems like there ought be a way
> to assign permissions to everything, and permissions not set can be
> acquired.  Like a story can have read permissions set to a certain
> group, or if it belongs to a section with read permissions set, the
> story's permission would default to the section's permission.  
>

Let's expand on this sometime.  The permissions now can do the second
story example for sure, and I think the first one too ( maybe with a
little coaxing.)

> That's what I'm thinking about.  What do you all think?
> 

good stuff.

One other thought I've had lately,  what kind of interest is there in the
option to generate a static site?  Write html files to the drive to be
published however.

Joe

> Later,
> Matt
> 
> 
> --
> 
> Matthew Leingang
> Harvard University Department of Mathematics
> lei...@ma...

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Matthew L. <lei...@ma...>]

On Thu, 2003-10-02 at 04:24, Joe Stewart wrote:
> On Thu, Oct 02, 2003 at 11:17:04AM -0400, Mike Gifford wrote:
> > Hello psl folks,
> > 
> > I'm writing mostly to find out when the new block feature that you've
> > been working on is likely to get released.  I'm not sure when the next
> > release is planned, but am planning to put out a new release of Back-End
> > CMS very soon.
> > 
> 
> Glad to see Back-End development proceeding.  I've been busy moving our
> office.  So hopefully will get cranked back up soon.

Giving up your view of the parthenon? :-)

I need to get playing with the development code because I have ideas and
I might as well put them in the new stuff.

[snip]

> > I also wanted to know if there was any attempt to extend the ability to
> > turn on/off navbar links from the config.ini.php file.  I do think it
> > would be useful to allow the more detailed control over what appears in
> > the navbar than by simply turning on/off a module.  Certainly for things
> > like the links. 
> > 
> 
> I'd like to see some patches for this, or a web management interface.
> 
> I stalled on it with what seemed to be a limitation of the "ini" array
> stuff being limited to one level rather than having nested arrays.

I once thought that using dotted keywords in the ini file would work
almost as well as a nested array.  I still think it does from the
installer's standpoint.   You could just put something like

navbar.items.login.title = "Login"
navbar.items.login.link = "login.php"
navbar.items.login.perms = "nobody"

navbar.items.glossary.title = "Glossary"
navbar.items.glossary.link = "glossary.php"
navbar.items.glossary.perms = "nobody"

navbar.items.admin.title = "Administration"
navbar.items.admin.link = "login.php"
navbar.items.admin.perms = "user"

and then even stuff like

navbar.perms.write = "someNewPermissionName"

(more on that idea later)

>From a programmer's standpoint, I guess it's worse because you have to
do strange searches on the keys of $_PSL, but maybe that could be done
once and $_PSL sessionized, as we've been threatening. 

OTOH, a web interface is more like what the rest of psl is about. 
Probably a lot of the topic bar code could be reused.  The one drawback
is that generating the navbar that way would add a database call.  But
perhaps it can be sessionized or cached.

Also, I've been toying with the idea of how to best develop a download
module (or do I mean file publication module?).  I've got something at
my latest PSL install (sorry for the less-than-creative skin)

http://www.math.harvard.edu/~leingang/math1b/index.php?section_id=18

The block of downloads is generated automatically by scouring a given
directory.  Dates and document names are generated automatically (either
by prettying the filename or parsing LaTeX files), and different formats
of the same document are recognized.  There's a config file to override
defaults.  To add an item, I install the files and edit the config file
if need be.

I want to add the ability to upload stuff and make it available for
download through a web interface, but I don't want to lose the plain-old
scp uploading that I do now.  It seems like it would be good to accept
RDF metadata, too, rather than my naive config-file which looks like
LDIF. The module should also generate whatever metadata it can on its
own, but where does this all get stored?  That, and I would like to
assign read/overwrite privileges to certain groups...you can see why all
I've been doing is thinking about this.

Finally, I'm wondering about ways to expand permissions.  I guess I've
been reading too much about Zope, but it seems like there ought be a way
to assign permissions to everything, and permissions not set can be
acquired.  Like a story can have read permissions set to a certain
group, or if it belongs to a section with read permissions set, the
story's permission would default to the section's permission.  

That's what I'm thinking about.  What do you all think?

Later,
Matt


--

Matthew Leingang
Harvard University Department of Mathematics
lei...@ma...

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Mike G. <mi...@op...>]

Howdy Joe,

On Thu, 2003-10-02 at 04:24, Joe Stewart wrote:
> On Thu, Oct 02, 2003 at 11:17:04AM -0400, Mike Gifford wrote:
> > I'm writing mostly to find out when the new block feature that you've
> > been working on is likely to get released.  I'm not sure when the next
> > release is planned, but am planning to put out a new release of Back-End
> > CMS very soon.
> Glad to see Back-End development proceeding.  I've been busy moving our
> office.  So hopefully will get cranked back up soon.

Moving takes a heck of a lot of work.

I'm looking forward to the new release of BE..  Quite like our new
installer script..  Not sure if psl decided to adopt the one which was
being circulated a while back.

> So no release from me planned yet.

We've made a lot of improvements over 0.5.4 so wanted to put out a
release to move us closer to the psl numbering..  So the jump for the
next release will be from .5 to .7

> > One of the contributors to Back-End has created some code for bottom
> > blocks to allow for some navigational elements to be dropped in directly
> > here.  This sounded to me like a lot like the flexibility that the PSL
> > team is working for.
> phpSlash supports this with just changing a couple of things now.  The
> -dev branch does already support top and bottom blocks.

How stable is the development branch and is this top/bottom block
function going to carry on to future releases?  I'd assume so, but just
wanted to find out if there was any concern about this.

> > I also wanted to know if there was any attempt to extend the ability to
> > turn on/off navbar links from the config.ini.php file.  I do think it
> > would be useful to allow the more detailed control over what appears in
> > the navbar than by simply turning on/off a module.  Certainly for things
> > like the links. 
> I'd like to see some patches for this, or a web management interface.

We'll certainly keep you up-to-date if we incorporate a change like
this..  Would really want to get your buy-in before implementing it.. 
Not that it would have to be implemented right away, but that it would
be something which would be in future releases.

> I stalled on it with what seemed to be a limitation of the "ini" array
> stuff being limited to one level rather than having nested arrays.

I haven't investigated this, but can understand how that would be a
pain..  It might make sense build rather a web interface so it could be
turned off there as opposed to the ini.

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master's tools will never dismantle the master's house - A Lorde

Re: [Phpslash-devel] Blocks Everywere, Navbar control

[Joe S. <joe...@us...>]

On Thu, Oct 02, 2003 at 11:17:04AM -0400, Mike Gifford wrote:
> Hello psl folks,
> 
> I'm writing mostly to find out when the new block feature that you've
> been working on is likely to get released.  I'm not sure when the next
> release is planned, but am planning to put out a new release of Back-End
> CMS very soon.
> 

Glad to see Back-End development proceeding.  I've been busy moving our
office.  So hopefully will get cranked back up soon.

So no release from me planned yet.

> One of the contributors to Back-End has created some code for bottom
> blocks to allow for some navigational elements to be dropped in directly
> here.  This sounded to me like a lot like the flexibility that the PSL
> team is working for.
> 

phpSlash supports this with just changing a couple of things now.  The
-dev branch does already support top and bottom blocks.

> I also wanted to know if there was any attempt to extend the ability to
> turn on/off navbar links from the config.ini.php file.  I do think it
> would be useful to allow the more detailed control over what appears in
> the navbar than by simply turning on/off a module.  Certainly for things
> like the links. 
> 

I'd like to see some patches for this, or a web management interface.

I stalled on it with what seemed to be a limitation of the "ini" array
stuff being limited to one level rather than having nested arrays.

later,

Joe

> Mike
> -- 
> Mike Gifford, OpenConcept Consulting
> Free Software for Social Change -> http://www.openconcept.ca
> Fair Vote Petition - http://www.fairvotecanada.org/petition.php
> The master's tools will never dismantle the master's house - A Lorde
> 
> 

[Phpslash-devel] Blocks Everywere, Navbar control

[Mike G. <mi...@op...>]

Hello psl folks,

I'm writing mostly to find out when the new block feature that you've
been working on is likely to get released.  I'm not sure when the next
release is planned, but am planning to put out a new release of Back-End
CMS very soon.

One of the contributors to Back-End has created some code for bottom
blocks to allow for some navigational elements to be dropped in directly
here.  This sounded to me like a lot like the flexibility that the PSL
team is working for.

I also wanted to know if there was any attempt to extend the ability to
turn on/off navbar links from the config.ini.php file.  I do think it
would be useful to allow the more detailed control over what appears in
the navbar than by simply turning on/off a module.  Certainly for things
like the links. 

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master's tools will never dismantle the master's house - A Lorde

Re: [Phpslash-devel] new jpcache code

[Mike G. <mi...@op...>]

On Mon, 2003-09-08 at 05:48, Joe Stewart wrote:
> On Sat, Sep 06, 2003 at 03:40:22PM -0400, Mike Gifford wrote:
> > Howdy folks,
> > 
> > I noticed a little while ago that jpcache had released it's final
> > version of jpcache v2 (they did this in July [26-07-03]) 
> > 	http://jpcache.com/
> > 
> > So what I'm wondering is if phpSlash has updated the jpcache code which
> > you are using?  I know Joe made a number of changes to add a phplib
> > component.
> I haven't synced with the release.  I thought the code was up to date with
> the last code changes he made though.

I'm fine with that Joe.  I just saw that there was a new release and
wasn't sure if the BE code was up to snuff or not.

I'm planning to put out a new release of Back-End.org and just want to
see that things are as up-to-date as possible.

I noticed that phplib put out a release since the last time I checked
too, but expect that you're more than ontop of that.

Thanks.

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master’s tools will never dismantle the master’s house - A Lorde

[Phpslash-devel] new jpcache code

[Mike G. <mi...@op...>]

Howdy folks,

I noticed a little while ago that jpcache had released it's final
version of jpcache v2 (they did this in July [26-07-03]) 
	http://jpcache.com/

So what I'm wondering is if phpSlash has updated the jpcache code which
you are using?  I know Joe made a number of changes to add a phplib
component.

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Fair Vote Petition - http://www.fairvotecanada.org/petition.php
The master’s tools will never dismantle the master’s house - A Lorde

Re: [Phpslash-devel] new Blocks

[Joe S. <joe...@us...>]

On Thu, Jul 31, 2003 at 01:41:50PM -0400, Matthew Leingang wrote:
> Hi again,
> 
> I've got the phpslash-dev version up and running, and it looks pretty 
> cool.  If it's as flexible as it's trying to be, adding new 
> functionality will be easy to do.
> 
> There's something that's bothering me, though...how are the stories 
> associated to the main page?  The way I trace it is that
> public_html/index.php calls include/modules/block/index.php, which finds 
> the page block and calls parse on that.  But I keep thinking there 
> should be a "story" block that is in the center column.  I don't see any 
> such thing, yet the "Congratulations!" story appears right where it 
> should.  
> 
> Tell me how! :-)
> 

A "module" block is assigned to the center column of the home section.  In
the absence of a block_option or GET variable called "module", a default
module is chosen.  "Story" is specified as the default module in
config.ini. 

later,

Joe

> --Matt
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel

[Phpslash-devel] new Blocks

[Matthew L. <lei...@ma...>]

Hi again,

I've got the phpslash-dev version up and running, and it looks pretty 
cool.  If it's as flexible as it's trying to be, adding new 
functionality will be easy to do.

There's something that's bothering me, though...how are the stories 
associated to the main page?  The way I trace it is that
public_html/index.php calls include/modules/block/index.php, which finds 
the page block and calls parse on that.  But I keep thinking there 
should be a "story" block that is in the center column.  I don't see any 
such thing, yet the "Congratulations!" story appears right where it 
should.  

Tell me how! :-)

--Matt

[Phpslash-devel] Re: [Back-end-development] Hello!

[Joe S. <joe...@us...>]

Moved this thread to the phpslash-dev list.

Thanks to Dave for the constructive suggestions.

On Wed, Jul 30, 2003 at 11:02:10PM -0600, Dave Reid wrote:
> On July 30, 2003 06:45 am, Mike Gifford wrote:
> > This is phpSlash code, so I asked them about it:
> > http://sourceforge.net/mailarchive/forum.php?thread_id=2854114&forum_id=153
> >
> > Also asked them about your interest in passing along template variables.
> >
> > Apparently they've stopped using this class in an effort to cut down on
> > the number of db hits.  Might re-introduce it and pass the variables
> > along through the session.
> 
> That's an enlightening thread. The slashTemplate ctor set_var is a step in the 
> right direction, though still hardcoded. A compromise would be for the 
> slashTemplate ctor to do a set_var using some array that is set up in 
> config.ini.php, to allow customization without changing slashTemplate itself. 

This is a natural and useful extension.  And pretty much exactly what you
can already do with the header templates.  You can define an extra_ary and
either supply it directly to getHeader or _PSL and the getHeader function
will apply the array index as a template variable with the array value
substituted.

This could be added to apply generally to all template objects and would
be very welcome.  I'm afraid I won't be able to get to it right away, but
if I find some time will get it committed to the phpslash cvs.  

> In the long term it makes sense to me to go back to using DB variables, and 
> cache them in the session.
> 
> Passing extra block options to the template is a nice idea. I assume the 
> "story options" Joe refers to are specific to phpSlash, with no BE 
> equivalent?
> 
> >
> > > > > Actually what I'd really like would be to have that, and to have one
> > > > > round of template substitution performed on section and maybe article
> > > > > content - I have had to hardcode references to the image dir in a few
> > > > > of these.>
> > > >
> > > > Not sure what you mean here..  You can already specify article/section
> > > > templates..
> > >
> > > Two examples:
> > > 1. I have sections that contain images from {IMAGEDIR} in their content.
> > > I could give each of those their own template and put the image and
> > > surrounding formatting in there instead, but then I have another template
> > > to edit if I rearrange the site, and content admins (who will NOT have
> > > template admin privileges) cannot change the images.
> > > 2. Content admins will upload images using the upload module, then create
> > > articles that refer to those images. I don't want to hardcode the path to
> > > the upload dir in those articles (that's brittle). It would be nice to be
> > > able to define variable UPLOADDIR = '/x/y/z/updir' and ref that in the
> > > articles.
> >
> > How would this be used in the site?  Guess to just brand each section a
> > bit more strongly.
> 
> For example 1, yes. To elaborate, I will have sections that have one or two
> separate parts of the page, with graphic headers. I want to use a common
> template and define those graphics in the page content.
> 
> For example 2, the most common use is photos and PDF files that are 
> associated with stories.
> 
> It's not a big deal - I will just have to do a DB update if I ever move 
> /images or /updir. it only occurred to me because {IMAGEDIR} is so
> handy in templates.
> 

This is one of my uses for the story_options - to add extra story info (
associated image name in particular) without adding any database structure
changes.

Speaking of how phpSlash works, in most places, the {SKIN} variable can be
appended to the {IMAGEDIR} and then you can have separate graphic dir for
each skin.  It sounds like you could use a different skin for certain
sections.  This is not an ability in the current release, but is in the
-dev tree.


may have more - but gotta go now.

thanks,

Joe

[Phpslash-devel] Download objects

[Matthew L. <lei...@ma...>]

Hi guys,

I'm finally unpacked and getting set up in my new job.  I'm planning to 
use a psl-powered site for Calc II this fall, for which I'm the course 
head.  I'll have six or seven sections taught by TAs.

I need a way for course assistants to post solutions to the site.  That 
would be easy if they were in HTML format.  But HTML is still not a 
useful format for math.  So what will have to be posted are PDFs.  Since 
sections are going to probably move at a different pace, I'll need to 
associate permissions as well.

There's no way to do this in the current PSL framework, is there?  It 
seems like a download class is necessary, and I'm willing to work on it. 
 But first I have to familiarize myself with the phpslash-dev code.  I 
just wanted to announce that I'm thinking about it in case others have 
and came to certain conclusions.

--Matt

Re: [Phpslash-devel] Variables.class

[Mike G. <mi...@op...>]

Howdy Joe,

On Wed, 2003-07-30 at 04:40, Joe Stewart wrote:
> On Tue, Jul 29, 2003 at 03:46:28PM -0400, Mike Gifford wrote:
> > On Tue, 2003-07-29 at 07:14, Joe Stewart wrote:
> > > > Speaking of modules, how is the phpSlash modules code going?  
> > > Mostly stable.  There is so much flexibility that you can really screw
> > > things up.  Not sure how I like this part. 
> > That's the trouble when you give folks enough rope to hang themselves
> > on.  :)
> > > Sometimes the bugs have been pretty harsh and unforgiving.
> > How bad?  Just nasty errors or no errors or worse lost data?
> apache hanging was the worst.  Otherwise, blank pages.

That's not all that bad..  As long as it's not on a production server.

> > > Sections can have different headers and skins.  
> > How did you set up the header customization?  I'm not even sure where to
> > start digging..  Is this just built into the standard classes now?  
> > > If you don't use the TopicBar, you simply don't have that block.  No worry
> > > about including the class, etc.
> > There was some talk a while back about making everything a block..  Just
> > depends on how you want to stack them..
> Pretty much everything is a block.

Can't get much more flexible than that.

> The header is just a block assigned to the section.  Use a different
> header template for different sections.  

Can you also specify other body & footer templates?

> So, those that wanted a more monolithic index page ( header and footer included) so that html editors view the entire page can do that too.

That's a nice feature..  Folks liked the old single template/section
from the old back-end.. 

> > > You can have different footers for the two or three column page.  This is
> > > important for all CSS pages ( no tables).
> > Hm..  We haven't incorporated that piece yet..  But can't that all be
> > done in the index1col -> index3cols templates?
> If you look at the index1,2&3 there is no reference to a footer, it was
> added by the index page.  Tableless design using CSS only seems to have
> footer problems when the length of the side columns sometimes might be longer than the center column.  This was noted by the Wired.com folks in their move too.

Ok..  This is all definitely new since the last time I've looked (from
the index.php)

// add page output to be displayed
$output .= $template->parse('OUT','index');

// add header if not parsed above in index page template
if( !$template->is_available('index','HEADER')) {
   $output = $header . $output;
}

// add footer if not parsed above in index page template
if( !$template->is_available('index','FOOTER')) {
   $output .= $footer;
}

So if you want to just use the single template you'd just comment out
these lines:

// get page header and footer
$header = getHeader($pagetitle,$_PSL['metatags']);
$footer = getFooter();

> Now there is a {TOP} and {BOTTOM}, so a footer can be in the CENTER or BOTTOM.

Ok..  

> > This hasn't been released yet..  Just in the standard CVS module at the
> > moment, right?
> phpslash-dev cvs module

I was using 
	phpslash-ft

I'll just go and grab the development version..  Just having trouble
grabbing things from the CVS at the moment.. Might be just something odd
with the SF CVS server..

cvs -d:pserver:ano...@cv...:/cvsroot/phpslash login
cvs [login aborted]: end of file from server (consult above messages if
any)

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/phpslash co
phpslash-dev
cvs [checkout aborted]: end of file from server (consult above messages
if any)

> > So what needs to be done to allow template variables to be accessible in
> > any template?
> To add certain variables to any template add something like this to the
> slashTemplate constructor:
>       $this->set_var(array(
>           'QUERYSTRING'       => $_SERVER['QUERY_STRING'],
>           'SITE_NAME'         => $this->psl['site_name'],
>           'SITE_OWNER'        => $this->psl['site_owner'],
>           'SITE_SLOGAN'       => $this->psl['site_slogan'],
>           'SITE_TITLE'        => $this->psl['site_title'],
>           'ROOTDIR'           => $this->psl['rooturl'],
>           'IMAGEDIR'          => $this->psl['imageurl'],
>           'SKIN'              => $this->psl['skin']
>        ));

Great!  That makes sense.

> Then we could get rid of setting the IMAGEDIR and ROOTDIR all over the
> place.  There is some cleanup needed like ROOTURL/ROOTDIR, IMAGEURL/IMAGEDIR.

So this should actually improve the performance to add it here..

> I've experimented with only using one template instance.  However, it was
> not faster in my limited tests.  We use some common template variable
> names in multiple templates.  This is used for repeating template blocks (
> not phpSlash blocks ). i.e. BEGIN row, END row, etc.  On one hand this is
> good because it simplifies use.  However, you have problems doing this if you have only one template instance.

Right..

> Story and block options accept custom template variables also.  If you add
> a block or story option that is not recognized, it is passed to the
> template as a variable.  If there is one always needed, add it as a
> default option. 

Yes..  That's a nice feature..

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] Variables.class

[Joe S. <joe...@us...>]

On Tue, Jul 29, 2003 at 03:46:28PM -0400, Mike Gifford wrote:
> Hi Joe,
> 
> On Tue, 2003-07-29 at 07:14, Joe Stewart wrote:
> > > Speaking of modules, how is the phpSlash modules code going?  
> > Mostly stable.  There is so much flexibility that you can really screw
> > things up.  Not sure how I like this part. 
> 
> That's the trouble when you give folks enough rope to hang themselves
> on.  :)
> 
> > Sometimes the bugs have been pretty harsh and unforgiving.
> 
> How bad?  Just nasty errors or no errors or worse lost data?
>

No lost data.

apache hanging was the worst.  Otherwise, blank pages.

> > Sections can have different headers and skins.  
> 
> How did you set up the header customization?  I'm not even sure where to
> start digging..  Is this just built into the standard classes now?  
> 
> > If you don't use the TopicBar, you simply don't have that block.  No worry
> > about including the class, etc.
> 
> There was some talk a while back about making everything a block..  Just
> depends on how you want to stack them..
> 

Pretty much everything is a block.

The header is just a block assigned to the section.  Use a different
header template for different sections.  

So, those that wanted a more monolithic index page ( header and footer included) so that html editors view the entire page can do that too.

> > You can have different footers for the two or three column page.  This is
> > important for all CSS pages ( no tables).
> 
> Hm..  We haven't incorporated that piece yet..  But can't that all be
> done in the index1col -> index3cols templates?
> 

If you look at the index1,2&3 there is no reference to a footer, it was
added by the index page.  Tableless design using CSS only seems to have
footer problems when the length of the side columns sometimes might be longer than the center column.  This was noted by the Wired.com folks in their move too.

Now there is a {TOP} and {BOTTOM}, so a footer can be in the CENTER or BOTTOM.

> This hasn't been released yet..  Just in the standard CVS module at the
> moment, right?
> 

phpslash-dev cvs module

<snip>
> 
> So what needs to be done to allow template variables to be accessible in
> any template?
> 

To add certain variables to any template add something like this to the
slashTemplate constructor:

      $this->set_var(array(
          'QUERYSTRING'       => $_SERVER['QUERY_STRING'],
          'SITE_NAME'         => $this->psl['site_name'],
          'SITE_OWNER'        => $this->psl['site_owner'],
          'SITE_SLOGAN'       => $this->psl['site_slogan'],
          'SITE_TITLE'        => $this->psl['site_title'],
          'ROOTDIR'           => $this->psl['rooturl'],
          'IMAGEDIR'          => $this->psl['imageurl'],
          'SKIN'              => $this->psl['skin']
       ));

Then we could get rid of setting the IMAGEDIR and ROOTDIR all over the
place.  There is some cleanup needed like ROOTURL/ROOTDIR, IMAGEURL/IMAGEDIR.

I've experimented with only using one template instance.  However, it was
not faster in my limited tests.  We use some common template variable
names in multiple templates.  This is used for repeating template blocks (
not phpSlash blocks ). i.e. BEGIN row, END row, etc.  On one hand this is
good because it simplifies use.  However, you have problems doing this if you have only one template instance.

Story and block options accept custom template variables also.  If you add
a block or story option that is not recognized, it is passed to the
template as a variable.  If there is one always needed, add it as a
default option. 

Joe

> Mike
> -- 
> Mike Gifford, OpenConcept Consulting
> Free Software for Social Change -> http://www.openconcept.ca
> Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
> The cruelest lies are often told in silence. -- Robert L Stevenson
> 
> 

[Phpslash-devel] Multi-lingual/Multi-skin Blocks

[Mike G. <mi...@op...>]

Hello Again,

Stumbled across another issue I thought I'd bring up with the psl
development team.  Last time I talked to you folks about this the
decision was that multilingual functionality just isn't there for the
blocks..  I was looking at this for Back-End and wondered about this
chunk of code from within the storeParsed data function of the
Block.class file:

         $block_options = $this->block_info["block_options"];
         $lang = $this->psl['lang'];
         $skin = $this->psl['skin'];
         $block_options['cache_data'][$lang][$skin]['cache_data'] =
$this->block_info["cache_data"];
         $block_options['cache_data'][$lang][$skin]['last_update'] =
time();
         $serial_options = addslashes(serialize($block_options));
         /* Store in db */
         $query = "UPDATE psl_block
                      SET block_options = '$serial_options'
                    WHERE id = '$id'";

1st question is is this working anywhere?  Are different skins &
languages being effectively cached within the block options?

Wouldn't it just make more sense to move this into a psl_blockCache or
psl_blockText table?

Since most of the mysql is in Block.class it isn't that hard to make the
change..  

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] Variables.class

[Mike G. <mi...@op...>]

Hi Joe,

On Tue, 2003-07-29 at 07:14, Joe Stewart wrote:
> > Speaking of modules, how is the phpSlash modules code going?  
> Mostly stable.  There is so much flexibility that you can really screw
> things up.  Not sure how I like this part. 

That's the trouble when you give folks enough rope to hang themselves
on.  :)

> Sometimes the bugs have been pretty harsh and unforgiving.

How bad?  Just nasty errors or no errors or worse lost data?

> A few nice things:  
> Easily make a poll, etc on the front page instead of a list of stories.

Ok..  

> The about page can be a story or a block and not necessarily tied to text
> inside a template.

That's good..

> Sections can have different headers and skins.  

How did you set up the header customization?  I'm not even sure where to
start digging..  Is this just built into the standard classes now?  

> If you don't use the TopicBar, you simply don't have that block.  No worry
> about including the class, etc.

There was some talk a while back about making everything a block..  Just
depends on how you want to stack them..

> You can have different footers for the two or three column page.  This is
> important for all CSS pages ( no tables).

Hm..  We haven't incorporated that piece yet..  But can't that all be
done in the index1col -> index3cols templates?

This hasn't been released yet..  Just in the standard CVS module at the
moment, right?

Just trying to figure out where your going so that we can support it
with where we're going with BE at the moment.

> > > I think providing some of the basic common placeholder values to the
> > > template object when initiating it is a natural next step.  We couldn't do
> > > this till we had a slashTemplate class.  Now, we should be able to set
> > > things like rooturl, imageurl, etc. to be provided to all templates.
> > Is someone working on a slashTemplate class?  
> 0.7 includes the slashTemplate class that extends the phplib template
> class.  This allows us to override the set_file method to use absolute
> paths, parent skins, template directories in the module's own directory,
> and as suggested, some initial values for commonly used template
> variables.

Right..  Thought it looked familiar..  just too many files to keep track
of..  

> Previously, we were just using the phplib template class.  So we had keep
> up with the template directory and all variables everywhere.

So what needs to be done to allow template variables to be accessible in
any template?

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] Variables.class

[Joe S. <joe...@us...>]

On Tue, Jul 29, 2003 at 12:13:27PM -0400, Mike Gifford wrote:
> Howdy Joe,
> 
> On Tue, 2003-07-29 at 04:57, Joe Stewart wrote:
> > > How much is this class being used?  Just got a question about trying to
> > > extend this class to allow folks to add global template variables. 
> > > That's beyond what this class does now from what I understand, but it's
> > > an interesting concept.
> > The Variable class is not used at all currently.  0.5.3 had many variables
> > in the db and had many queries to get them each page view.  We worked hard
> > to move to html templates and defining what's needed in the config text
> > file.
> 
> Right...
> 
> > We discussed possibly using it again by loading variables from the db into
> > the session to reduce repeated access issues.  
> 
> This makes sense..  Would be nice to be able to turn modules on/off via
> the web interface and customize other variables through the interface.. 
> But wow..  Has it been 0.5.3 since it was used that way?  That was a
> heck of a long time ago..
> 
> Speaking of modules, how is the phpSlash modules code going?  
> 

Mostly stable.  There is so much flexibility that you can really screw
things up.  Not sure how I like this part.  Sometimes the bugs have been
pretty harsh and unforgiving.

A few nice things:  

Easily make a poll, etc on the front page instead of a list of stories.

The about page can be a story or a block and not necessarily tied to text
inside a template.

Sections can have different headers and skins.  

If you don't use the TopicBar, you simply don't have that block.  No worry
about including the class, etc.

You can have different footers for the two or three column page.  This is
important for all CSS pages ( no tables).

> > I think providing some of the basic common placeholder values to the
> > template object when initiating it is a natural next step.  We couldn't do
> > this till we had a slashTemplate class.  Now, we should be able to set
> > things like rooturl, imageurl, etc. to be provided to all templates.
> 
> Is someone working on a slashTemplate class?  
> 

0.7 includes the slashTemplate class that extends the phplib template
class.  This allows us to override the set_file method to use absolute
paths, parent skins, template directories in the module's own directory,
and as suggested, some initial values for commonly used template
variables.

Previously, we were just using the phplib template class.  So we had keep
up with the template directory and all variables everywhere.

Joe

> Mike
> -- 
> Mike Gifford, OpenConcept Consulting
> Free Software for Social Change -> http://www.openconcept.ca
> Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
> The cruelest lies are often told in silence. -- Robert L Stevenson
> 

Re: [Phpslash-devel] Variables.class

[Mike G. <mi...@op...>]

Howdy Joe,

On Tue, 2003-07-29 at 04:57, Joe Stewart wrote:
> > How much is this class being used?  Just got a question about trying to
> > extend this class to allow folks to add global template variables. 
> > That's beyond what this class does now from what I understand, but it's
> > an interesting concept.
> The Variable class is not used at all currently.  0.5.3 had many variables
> in the db and had many queries to get them each page view.  We worked hard
> to move to html templates and defining what's needed in the config text
> file.

Right...

> We discussed possibly using it again by loading variables from the db into
> the session to reduce repeated access issues.  

This makes sense..  Would be nice to be able to turn modules on/off via
the web interface and customize other variables through the interface.. 
But wow..  Has it been 0.5.3 since it was used that way?  That was a
heck of a long time ago..

Speaking of modules, how is the phpSlash modules code going?  

> I think providing some of the basic common placeholder values to the
> template object when initiating it is a natural next step.  We couldn't do
> this till we had a slashTemplate class.  Now, we should be able to set
> things like rooturl, imageurl, etc. to be provided to all templates.

Is someone working on a slashTemplate class?  

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] Variables.class

[Joe S. <joe...@us...>]

On Tue, Jul 29, 2003 at 10:19:24AM -0400, Mike Gifford wrote:
> In config.php in the CVS I think that you should be linking to
> Variable.class & not variable.class
> 
> AddClassRequirement("variable",$_PSL['classdir'] . "/Variable.class");
>

thanks, will correct.

> How much is this class being used?  Just got a question about trying to
> extend this class to allow folks to add global template variables. 
> That's beyond what this class does now from what I understand, but it's
> an interesting concept.
> 

The Variable class is not used at all currently.  0.5.3 had many variables
in the db and had many queries to get them each page view.  We worked hard
to move to html templates and defining what's needed in the config text
file.

We discussed possibly using it again by loading variables from the db into
the session to reduce repeated access issues.  

I think providing some of the basic common placeholder values to the
template object when initiating it is a natural next step.  We couldn't do
this till we had a slashTemplate class.  Now, we should be able to set
things like rooturl, imageurl, etc. to be provided to all templates.

thanks,

Joe

> Mike
> -- 
> Mike Gifford, OpenConcept Consulting
> Free Software for Social Change -> http://www.openconcept.ca
> Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
> The cruelest lies are often told in silence. -- Robert L Stevenson
> 
> 

[Phpslash-devel] Variables.class

[Mike G. <mi...@op...>]

In config.php in the CVS I think that you should be linking to
Variable.class & not variable.class

AddClassRequirement("variable",$_PSL['classdir'] . "/Variable.class");

How much is this class being used?  Just got a question about trying to
extend this class to allow folks to add global template variables. 
That's beyond what this class does now from what I understand, but it's
an interesting concept.

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] stripBadHTML bug - well kinda

[Mike G. <mi...@op...>]

Hello Luis,

On Mon, 2003-07-21 at 11:49, Luis M wrote:
> >    $str = eregi_replace("<a([^>]*)href=\"?([^\"]*)[\"|>]?([^>]*)>",
> >                          "<a href=\\2>", $str);
> >But I haven't gotten it to work just right...
> maybe:
> $str = eregi_replace("<a([^>]*)href=\"?([^\"]*)\"*([^>]*)>",
>                            "<a href=\\2>", $str);

Your solution worked just fine!  Thanks...

> To match 0 or more times the double quote. Note that this regex would fail 
> misserably if people use single quotes also:
> < a href = ' this is valid html ' >
> < a href = ' this is not valid >

Hmm..  That's annoying (to quote my 2 year old).

> In fact, the regex is not even checking for it...

It's only used in the comment section of phpSlash, so its less likey to
be hit on..  

> >I know this isn't something that many folks are likely to do, but for
> >this type of interface it's good to correct simple typos if you can..
> Better yet is to move away from this system and do a simplify interface for 
> composing messages/stories, etc... I heard a lot of noise about this some 
> time ago here in the -devel list. I hope somebody is working on it.

If you want a wiki interface or WYSIWYG interface..  We've incorporated
those both in Back-end..  They are both available for grabbing,
improving, modifying, etc.. 

> In fact, since phpslash project is GPL'ed and other GPL'ed projects already 
> have this functionality, maybe we should just copy and paste this code from 
> them. phpBB is the best I have seen so far. Allowing users to do simle 
> things as:

There must be a class to do phpBB type formatting out there..  

> [link=this is a URL] text to be linked[/link]
> or just [link=http:server] which also becomes a link showing the URL as the 
> text to be clicked.
> And a lot of nice mnemonics like "[b]" for "bold", "[i]" for "italics" and 
> so on, which may or may not match their HTML counter parts < B > and < I > 
> respectively. It's very awkward for people relatively new to the web and 
> HTML to know how to use HTML tags properly.

Yup..  Both for adding the main content to the site as well as the
comments..

> In addition, while we are at it, I know php coders don't like to use 
> client-side scripting languages, but, as an alternative, a 
> javascript/orwhateverotherstandardscript, template could be provided to 
> replace the standard non-javascript ones found in the "basic" and "default" 
> directories. Something that gives users a way of clicking on a button that 
> adds the tags mentioned about for them: B I Link and others.

I was looking around for some dropdown code for a client and was shocked
at how foreign the idea of gpl is in the javascript world..  Found one
good one:
	http://freshmeat.net/projects/dommenu/	

but unless you're going to write the javascript code from scratch, it
becomes trickier to distribute it under the GPL.

> We should learn from phpBB and similar projects about the ease of use they 
> provide to new users and the simplicity for instalation (phpBB installs with 
> one click after knowing the username, password and database to use). Just 
> ideas for the next realeas ;-) Joe?

We've got a basic config script we've set up for BE..  It works, but
need to do more to test it.  It's in the Back-End CVS

config_setup.ini.php & config_setup.php

It uses the existing mysql tables (so as long as there's a slash_all.sql
file that works, it should be able to upload it).  It also writes to the
config.ini.php, but you have to make sure that the permissions are set
properly there so that apache has write permissions..

I don't think this is a security problem if there is a warning that pops
up when folks log in to let them know that the config.ini.php still has
write permission & that these files still exist and need to be deleted:
	config_setup.ini.php & config_setup.php	

Mike
-- 
Mike Gifford, OpenConcept Consulting
Free Software for Social Change -> http://www.openconcept.ca
Site Launch - Make Every Vote Count - http://www.fairvotecanada.org
The cruelest lies are often told in silence. -- Robert L Stevenson

Re: [Phpslash-devel] stripBadHTML bug - well kinda

[Luis M <le...@ho...>]

[snip]

>    $str = eregi_replace("<a([^>]*)href=\"?([^\"]*)\"?([^>]*)>",
>                          "<a href=\\2>", $str);
>

[snip]

>    $str = eregi_replace("<a([^>]*)href=\"?([^\"]*)[\"|>]?([^>]*)>",
>                          "<a href=\\2>", $str);
>
>But I haven't gotten it to work just right...

maybe:
$str = eregi_replace("<a([^>]*)href=\"?([^\"]*)\"*([^>]*)>",
                           "<a href=\\2>", $str);
To match 0 or more times the double quote. Note that this regex would fail 
misserably if people use single quotes also:
< a href = ' this is valid html ' >
< a href = ' this is not valid >

In fact, the regex is not even checking for it...

>
>I know this isn't something that many folks are likely to do, but for
>this type of interface it's good to correct simple typos if you can..
>

Better yet is to move away from this system and do a simplify interface for 
composing messages/stories, etc... I heard a lot of noise about this some 
time ago here in the -devel list. I hope somebody is working on it.
In fact, since phpslash project is GPL'ed and other GPL'ed projects already 
have this functionality, maybe we should just copy and paste this code from 
them. phpBB is the best I have seen so far. Allowing users to do simle 
things as:
[link=this is a URL] text to be linked[/link]
or just [link=http:server] which also becomes a link showing the URL as the 
text to be clicked.
And a lot of nice mnemonics like "[b]" for "bold", "[i]" for "italics" and 
so on, which may or may not match their HTML counter parts < B > and < I > 
respectively. It's very awkward for people relatively new to the web and 
HTML to know how to use HTML tags properly.

In addition, while we are at it, I know php coders don't like to use 
client-side scripting languages, but, as an alternative, a 
javascript/orwhateverotherstandardscript, template could be provided to 
replace the standard non-javascript ones found in the "basic" and "default" 
directories. Something that gives users a way of clicking on a button that 
adds the tags mentioned about for them: B I Link and others.
We should learn from phpBB and similar projects about the ease of use they 
provide to new users and the simplicity for instalation (phpBB installs with 
one click after knowing the username, password and database to use). Just 
ideas for the next realeas ;-) Joe?


----)(-----
Luis Mondesi
System Administrator
LatinoMixed.com

le...@ho...

"...The Mac does this so smoothly, it feels like an extension of your mind." 
- Paula Speer, MacWorld Magazine 2003-04

Public signature: http://www.latinomixed.com/lems1/public-a.asc

_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis ! 
http://www.msn.fr/msger/default.asp