phpslash-devel — For developers of phpslash to communicate.

Re: [Phpslash-devel] Using addClassRequirement in PSL 0.7

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

On Mon, Feb 10, 2003 at 08:44:22PM +0000, Peter Cruickshank wrote:

<snip>
> 
> (Have you noticed that $_PSL does in fact end up as a session variable, via $auth->db->psl)?
>

I think this is corrected in RC2.  RC1 was screwed up this way.
 
config.php should be >= 1.30

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpslash/phpslash-ft/public_html/config-dist.php3.diff?r1=1.29&r2=1.30

auth4 has some code to do the "persistent_slots" with php4 sessions.

> >The phplib session class using PHP4 sessions currently doesn't
> >support calling a init script once per session (which is where the
> >registration of nonessential classes would go).  And with phplib PHP3 
> >sessions, registering such a large multidimensional variable actually 
> >slowed down subsequent page calls.  So movement in the sessionizing-$_PSL 
> >direction stalled.  I think eventually we'll find the right way to get an 
> >init script working.
>

If the auto_init was working correctly for phplib I think we would 
release it.  I'm going to try to get the template path patch applied 
too.


Joe
 
> OK
> 
> Peter
> 
> 
> -----------------------------
> Peter Cruickshank
> Tel: +44 7092 086 881
> email: pe...@kr...
> 
> 

Re: [Phpslash-devel] suggestions

[Peter C. <li...@kr...>]

At 09:32 10/02/03 -0600, Joe Stewart wrote:
<snip>

> - I think caching should be *off* on the initial install. It's confusing getting old error messages when you've fixed the problem - especially for users not familiar with phpslash. And it's a rare installation that goes right first time.

>I'd really like to make jpcache refuse to cache when there is an error.

That would be ideal.

>Turning the cache off may be OK.  It may need to be added to some "tuning" 
>docs.

A good second-best until the ideal can be realised, I think.

>> - Related thought: the config.ini.php file should include jpcache settings, at least to
>>         - flag whether to require "/path/to/jpcache.php";  (and what path to use)
>>         - turn jpcache off and on (ie value for $JPCACHE_ON)
>>         - the other $JPCACHE settings might also be useful (eg $JPCACHE_TIME)
>>    that way, users have one less reason to need to touch config.php
>> 
>
>Yeah, we were getting it installed and working.  config should be done in 
>config.ini.

OK. 

>> - Unrelated thought for Joe. I think you should put something in the config.php on how to use default_block_options - it's a cool feature. In fact, it might be worth putting in the 'column' feature, since that would deal with a FAQ on how to create blocks too.
>> 
>
>good point.  Since the column option is pretty much required it would be a 
>good example.  Possibly width too?

Yup (though its not needed for all skins), and possibly box_type (and perms?)

>Should column have a default value?

Yes - I've used 'right' in my setups

>The problem with it is the way the ini parsing brings the variable in.  I 
>think we can put this in though.
>
>[default_block_option]
>
>column = ""
>width = ""
>
>Or just put it in config.php?

eg with values:

[default_block_option]
column = right
width = 160
box_type = 

I think it would be good to do this - not sure if that can be fitted into the xxxxx.yyyy format though. The config.php approach would also work until the best approach for the ini has been found.


>As Matthew has suggested, the variable names need to be revisited. (After 
>0.7 is final).
>
>Like:
>
>block_option.count
>block_option.default
>block_option.udf
>
>author_option.count
>author_option.default

Not sure I'm getting what this is about, but don't worry :-) it'll sink in when I have to use it.

>The one place in particular that I think will help is with the skin, 
>language and template variables.  We can clean this up since the use of the 
>slashTemplate class centralized much of this.
>
>skin.default
>skin.current
>skin.choice
>
>lang.default
>lang.current
>lang.choice

- which brings us to another topic for another time: multi-lingual sites....

<snip>

Anyway, thanks for the responses. I'm moving Back-End to use 0.7 - I'll keep you posted with any other issues I find.

Cheers

Peter

Re: [Phpslash-devel] RC2 testing: manage block types/more Win98 woes

[Peter C. <li...@kr...>]

At 12:41 10/02/03 -0600, Joe Stewart wrote:
>On Mon, Feb 10, 2003 at 06:25:13PM +0000, Peter Cruickshank wrote:
>> More stuff:
>> 
>> The 'Manage block types' option at the foot of the blockAdmin screen needs altered to allow for the fact that Block_render_***.class has to be manually registered with the resource engine by editing config.php. I cant think of a neat way round it, short of storing block classnames in the database/cache, or dropping it altogether + replacing with a HOWTO doc.
>>
>
>Already addressed in cvs:
>
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpslash/phpslash-ft/class/Block.class.diff?r1=1.24&r2=1.25

OK.

> Another Win98Special
>> The new slashSess gives problems with session save path (giving error "Failed to write session data (files)."*) - solved by swapping in the old slashSess from PSL 0.6.5 (so it's not down to php.ini settings). But then of course, the class lists arent loaded using the old slashSess, so I cant do anything... google brought up loads of unresolved problems with this, so I've switched to developing in Unix.
>> 
>
>So the php install doesn't have write access to a default session save 
>path?

<snip>

Fair points all... I'll have a look sometime to see what fixes it.

>> But it would be interesting to know if there are any other Windows users out there to find if this is a real problem, or specific to my config.
>> 
>> 
>
>tobozo has been running winders too.

... so it's only a problem with my setup, not an issue. Cool.

Peter

Re: [Phpslash-devel] Using addClassRequirement in PSL 0.7

[Peter C. <pe...@kr...>]

Hi Matt

At 13:28 10/02/03 -0500, you wrote:
>Hi Peter,
>
>Right now, there's no difference.  
>
>The addClassRequirements build up a large hash from which pslNew() can 
>determine exactly what files need to be included to instantiate any class.  
>Since this data isn't going to change often, it's worth sessionizing.

<snip>

>Right now, though, there's no sessionizing of $_PSL so it's not a big
>deal.  

Thanks for that - it's what I suspected. I'll see how I can fit the Back-End stuff into the long-term plan though.

(Have you noticed that $_PSL does in fact end up as a session variable, via $auth->db->psl)?

>The phplib session class using PHP4 sessions currently doesn't
>support calling a init script once per session (which is where the
>registration of nonessential classes would go).  And with phplib PHP3 
>sessions, registering such a large multidimensional variable actually 
>slowed down subsequent page calls.  So movement in the sessionizing-$_PSL 
>direction stalled.  I think eventually we'll find the right way to get an 
>init script working.

OK

Peter


-----------------------------
Peter Cruickshank
Tel: +44 7092 086 881
email: pe...@kr...

Re: [Phpslash-devel] RC2 testing: manage block types/more Win98 woes

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

On Mon, Feb 10, 2003 at 06:25:13PM +0000, Peter Cruickshank wrote:
> More stuff:
> 
> The 'Manage block types' option at the foot of the blockAdmin screen needs altered to allow for the fact that Block_render_***.class has to be manually registered with the resource engine by editing config.php. I cant think of a neat way round it, short of storing block classnames in the database/cache, or dropping it altogether + replacing with a HOWTO doc.
>

Already addressed in cvs:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpslash/phpslash-ft/class/Block.class.diff?r1=1.24&r2=1.25

 
> Another Win98Special
> The new slashSess gives problems with session save path (giving error "Failed to write session data (files)."*) - solved by swapping in the old slashSess from PSL 0.6.5 (so it's not down to php.ini settings). But then of course, the class lists arent loaded using the old slashSess, so I cant do anything... google brought up loads of unresolved problems with this, so I've switched to developing in Unix.
> 

So the php install doesn't have write access to a default session save 
path?

1) set it where it can save it.

or

2) Change config.php to call session.inc, auth.inc, page.inc instead.  
They are just commented out.  This would revert to previous sessions.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpslash/phpslash-ft/public_html/config-dist.php3.diff?r1=1.30&r2=1.26

or

3) Change config.php and session.inc to use session4_custom.inc so phplib 
can store php4 sessions in the db.

> But it would be interesting to know if there are any other Windows users out there to find if this is a real problem, or specific to my config.
> 
> 

tobozo has been running winders too.

> P
> 
> 

[Phpslash-devel] RC2 testing: manage block types/more Win98 woes

[Peter C. <li...@kr...>]

More stuff:

The 'Manage block types' option at the foot of the blockAdmin screen needs altered to allow for the fact that Block_render_***.class has to be manually registered with the resource engine by editing config.php. I cant think of a neat way round it, short of storing block classnames in the database/cache, or dropping it altogether + replacing with a HOWTO doc.

Another Win98Special
The new slashSess gives problems with session save path (giving error "Failed to write session data (files)."*) - solved by swapping in the old slashSess from PSL 0.6.5 (so it's not down to php.ini settings). But then of course, the class lists arent loaded using the old slashSess, so I cant do anything... google brought up loads of unresolved problems with this, so I've switched to developing in Unix.

But it would be interesting to know if there are any other Windows users out there to find if this is a real problem, or specific to my config.


P

[Phpslash-devel] Using addClassRequirement in PSL 0.7

[Peter C. <li...@kr...>]

Hi

Can someone explain what the difference is between using addClassRequirements before or after the page_open call in config.ini.

I'm trying to work out where to declare the back-end classes - before the page_open seems to work, but I dont know what the implications are.

Thanks

Peter


-----------------------------
Peter Cruickshank
Tel: +44 7092 086 881
email: pe...@kr...

Re: [Phpslash-devel] suggestions

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

On Sat, Feb 08, 2003 at 12:09:27PM +0000, Peter Cruickshank wrote:

<snip>
> 
>  From my experiences, there's a couple of things that might be worth picking up on:
> 
> - maybe put a note in the config.ini.php reminding people that the phplib path requires a trailing slash (unlike all the other paths)
>

true.
 
> - I think caching should be *off* on the initial install. It's confusing getting old error messages when you've fixed the problem - especially for users not familiar with phpslash. And it's a rare installation that goes right first time.
> 

I'd really like to make jpcache refuse to cache when there is an error.

Turning the cache off may be OK.  It may need to be added to some "tuning" 
docs.

> - Related thought: the config.ini.php file should include jpcache settings, at least to
>         - flag whether to require "/path/to/jpcache.php";  (and what path to use)
>         - turn jpcache off and on (ie value for $JPCACHE_ON)
>         - the other $JPCACHE settings might also be useful (eg $JPCACHE_TIME)
>    that way, users have one less reason to need to touch config.php
> 

Yeah, we were getting it installed and working.  config should be done in 
config.ini.

> - Unrelated thought for Joe. I think you should put something in the config.php on how to use default_block_options - it's a cool feature. In fact, it might be worth putting in the 'column' feature, since that would deal with a FAQ on how to create blocks too.
> 

good point.  Since the column option is pretty much required it would be a 
good example.  Possibly width too?

Should column have a default value?

The problem with it is the way the ini parsing brings the variable in.  I 
think we can put this in though.

[default_block_option]

column = ""
width = ""

Or just put it in config.php?

As Matthew has suggested, the variable names need to be revisited. (After 
0.7 is final).

Like:

block_option.count
block_option.default
block_option.udf

author_option.count
author_option.default

The one place in particular that I think will help is with the skin, 
language and template variables.  We can clean this up since the use of the 
slashTemplate class centralized much of this.

skin.default
skin.current
skin.choice

lang.default
lang.current
lang.choice

etc.

> I've now committed the slashTemplate fix that started this all off.
>

Thanks Peter and Matthew for your help,

Joe
 
> Cheers
> 
> Peter
> 

Re: [Phpslash-devel] RC2 and Windows + jpcache question

[Peter C. <li...@kr...>]

At 12:43 07/02/03 -0500, Matthew Leingang wrote:

>On Thu, 6 Feb 2003, Peter Cruickshank wrote:
><snip>
>> I've not committed the change - although it works on the RC2 snapshot,
>> the phpslash-ft CVS version is crashing Apache on Win98SE during the
>> loadLibrary('phplib'); in config.php3. It would be good to check
>> whether Windows servers (NT/2k/xp) have the same problem...
>> 
>> I'm not familiar enough with how lib.resources.php works to be able to
>> pin down the error, so I thought it best to leave well alone.
>
>OK, I think I fixed it.  

<snip>


I hadnt spotted that phplib was missing....

>;;;
>;; PHPLIB configuration
>;;
>;; directory where PHPLIB classes and functions can be found 
>phplibdir = "/home/leingang/src/phpslash-0.7alpha/class/phplib/php/"
>;;(etc.)
>
>The crashing was due to the fact that pslError caused an infinite loop if 
>called before templates got registered.  I fixed that by giving getError a 
>fallback if templates aren't avaiable.
>
>Please check and see if this works for you, too.

Now works on Windows 98. Thanks for sorting it!

 From my experiences, there's a couple of things that might be worth picking up on:

- maybe put a note in the config.ini.php reminding people that the phplib path requires a trailing slash (unlike all the other paths)

- I think caching should be *off* on the initial install. It's confusing getting old error messages when you've fixed the problem - especially for users not familiar with phpslash. And it's a rare installation that goes right first time.

- Related thought: the config.ini.php file should include jpcache settings, at least to
        - flag whether to require "/path/to/jpcache.php";  (and what path to use)
        - turn jpcache off and on (ie value for $JPCACHE_ON)
        - the other $JPCACHE settings might also be useful (eg $JPCACHE_TIME)
   that way, users have one less reason to need to touch config.php

- Unrelated thought for Joe. I think you should put something in the config.php on how to use default_block_options - it's a cool feature. In fact, it might be worth putting in the 'column' feature, since that would deal with a FAQ on how to create blocks too.

I've now committed the slashTemplate fix that started this all off.

Cheers

Peter

Re: [Phpslash-devel] RC2 and Windows + jpcache question

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

On Thu, 6 Feb 2003, Peter Cruickshank wrote:
<snip>
> I've not committed the change - although it works on the RC2 snapshot,
> the phpslash-ft CVS version is crashing Apache on Win98SE during the
> loadLibrary('phplib'); in config.php3. It would be good to check
> whether Windows servers (NT/2k/xp) have the same problem...
> 
> I'm not familiar enough with how lib.resources.php works to be able to
> pin down the error, so I thought it best to leave well alone.

OK, I think I fixed it.  

The first thing is to make sure you have a phpslash-compatible phplib.  In 
config.ini.php, the 'phplibdir' directive is normally commented out.  Then 
config.php sets $_PSL['phplibdir'] to $_PSL['classdir'] . '/phplib', which 
is normally fine since phplib is included in releases.  But not in the cvs 
version.  So...what I did was set that 'phplibdir' directive in 
config.ini.php to a previous psl-distributed phplib version:

;;;
;; PHPLIB configuration
;;
;; directory where PHPLIB classes and functions can be found 
phplibdir = "/home/leingang/src/phpslash-0.7alpha/class/phplib/php/"
;;(etc.)

The crashing was due to the fact that pslError caused an infinite loop if 
called before templates got registered.  I fixed that by giving getError a 
fallback if templates aren't avaiable.

Please check and see if this works for you, too.

--Matt



-- 
----------------------------------------------------------------
Matthew Leingang                http://www.math.rutgers.edu/
Rutgers University              lei...@ma...
Department of Mathematics       "This signature needs no quote."

Re: [Phpslash-devel] RC2 and Windows + jpcache question

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

On Fri, 7 Feb 2003, Joe Stewart wrote:

> On Thu, Feb 06, 2003 at 05:58:27PM +0000, Peter Cruickshank wrote:
> > Joe
> > 
> > At 15:25 04/02/03 -0600, Joe Stewart wrote:
> > >On Tue, Feb 04, 2003 at 09:13:54PM +0000, Peter Cruickshank wrote:
<snip>
> > I've not committed the change - although it works on the RC2
> snapshot, the phpslash-ft CVS version is crashing Apache on Win98SE 
during the loadLibrary('phplib'); in config.php3. It would be good to
check whether Windows servers (NT/2k/xp) have the same problem...

> > > I'm not familiar enough with how lib.resources.php works to be
> able to pin down the error, so I thought it best to leave well alone.

> I think this is because the phplib library is not included in the 
> phpslash-ft cvs.  I've been adding it in during the release.  Copying the 
> phplib directory tree to class/phplib should fix it.

I have the same apache-crashes-on-cvs problem and am getting to the bottom 
of it.  Yes, phpslash looks for phplib in the wrong place because phplib 
isn't included in CVS.  lib.resources.php determines whether strings are 
filenames based on whether they name actual files, so if the files don't 
exist, all hell breaks loose.  :-(

Another problem is that the resources functions call pslError, which 
requires a template.  If the template doesn't load, the resources 
functions call pslError, which requires a template.  If the template 
doesn't load, the resources functions call pslError, which requires a 
template... think this might be the cause of the crash?  Perhaps pslError 
needs to be changed so that it can always succeed -- i.e., if 
slashTemplate isn't available, call user_error or just print out the 
message.

Stay tuned...

--Matt

-- 
----------------------------------------------------------------
Matthew Leingang                http://www.math.rutgers.edu/
Rutgers University              lei...@ma...
Department of Mathematics       "This signature needs no quote."

Re: [Phpslash-devel] RC2 and Windows + jpcache question

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

On Thu, Feb 06, 2003 at 05:58:27PM +0000, Peter Cruickshank wrote:
> Joe
> 
> At 15:25 04/02/03 -0600, Joe Stewart wrote:
> >On Tue, Feb 04, 2003 at 09:13:54PM +0000, Peter Cruickshank wrote:
> >
> ><snip>
> >> 
> >> Can you remind me how to update the CHANGES doc?
> >>
> >
> >Just edit it in your local copy and commit with your changed file(s).
> 
> I've not committed the change - although it works on the RC2 snapshot, the phpslash-ft CVS version is crashing Apache on Win98SE during the loadLibrary('phplib'); in config.php3. It would be good to check whether Windows servers (NT/2k/xp) have the same problem...
> 
> I'm not familiar enough with how lib.resources.php works to be able to pin down the error, so I thought it best to leave well alone.
> 
> Sorry.
>

I think this is because the phplib library is not included in the 
phpslash-ft cvs.  I've been adding it in during the release.  Copying the 
phplib directory tree to class/phplib should fix it.
 
Sorry

Joe

Re: [Phpslash-devel] CSS Standards Compliance in basic skins

[Peter C. <li...@kr...>]

Hi 
At 17:00 06/02/03 -0500, you wrote:
>Hi all,
>
>I'm trying to develop a new skin off of the basic set.  Thanks to Joe for 
>making this easy!
<snip>

>Is there a reason (like, older browsers don't like it) not to go to
>compliant CSS?  There shouldn't be too much to change (I'll volunteer if
>nobody else wants to do it), and it'd be The Right Thing To Do.

Your email has kicked me into action.

FWIW, I've never heard anything about even NN4 not liking classes instead of ids....

I've posted a couple of skins I've playing around with to the Patches area - they use ids to divide the page into zones and then classes for everything else. Combining ids and classes is great because it means that blocks can look different depending where they are on the page, without defining new templates.

You can see the skins in action at www.cruickshank.biz and www.cruickshank.biz/sl/ - there's still a couple of layout problems to sort out (eg the topic graphic element in Mozilla) and they're only designed to be readable by NN4, not pretty-looking - though I've moved the worst NN-breaking stuff into a separate stylesheet brought in by an @import.

Feel free to use or modify.

Cheers

Peter


-----------------------------
Peter Cruickshank
Tel: +44 7092 086 881
email: pe...@kr...

Re: [Phpslash-devel] RC2 and Windows + jpcache question (PS)

[Peter C. <li...@kr...>]

Some possibly useful info:

The last log message is:
[06-Feb-2003 17:41:55] PHP Warning:  Failed opening 'urn:class:c:/phpdev/www/phpslash-ft/class/phplib/phpdb_mysql.inc' for inclusion (include_path='.;C:/phpdev/php/includes;C:/phpdev/php/class') in c:\phpdev\www\phpslash-ft\class\lib.resources.php on line 336

I wonder if some code is getting confused by the colon in the windows filepath?

P

Re: [Phpslash-devel] RC2 and Windows + jpcache question

[Peter C. <li...@kr...>]

Joe

At 15:25 04/02/03 -0600, Joe Stewart wrote:
>On Tue, Feb 04, 2003 at 09:13:54PM +0000, Peter Cruickshank wrote:
>
><snip>
>> 
>> Can you remind me how to update the CHANGES doc?
>>
>
>Just edit it in your local copy and commit with your changed file(s).

I've not committed the change - although it works on the RC2 snapshot, the phpslash-ft CVS version is crashing Apache on Win98SE during the loadLibrary('phplib'); in config.php3. It would be good to check whether Windows servers (NT/2k/xp) have the same problem...

I'm not familiar enough with how lib.resources.php works to be able to pin down the error, so I thought it best to leave well alone.

Sorry.



><snip>
>> 
>> Tried that, then slashAuthCR complained on login....
>> 
>
>Oops.  I did that.  It *did* work.  I call the jpcache garbage collection 
>routine when the session is authenticated successfully.
>
>There are other places that this is done too. (function_exists 
>check maybe?)

Knowing about the $JPCACHE_ON flag is probably enough. I only want to be able to disable caching while developing the site.

Peter

[Phpslash-devel] CSS Standards Compliance in basic skins

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

Hi all,

I'm trying to develop a new skin off of the basic set.  Thanks to Joe for 
making this easy!

I noticed that there are a lot of templates like this one:

<!-- START fancybox.tpl:  {TITLE} -->
<div id="fancyBox">
  <div id="fancyBoxHeader">
      {LINK_OPEN}{TITLE}{LINK_CLOSE}
  </div>
  <!-- START fancyBox template content -->
  {CONTENTS}
  <!-- END fancyBox template content -->
</div> <!-- id="fancyBox" -->
<!-- END fancybox.tpl -->

I ran a phpslash page through a CSS validator and it complains about the 
<div id=...> lines.  "id" is only supposed to be used for unique elements, 
and usually fancybox gets repeated.  It should instead be <div class=...>.  
Then in the style sheet, "#fancyBox" should be changed to ".fancyBox."

Is there a reason (like, older browsers don't like it) not to go to
compliant CSS?  There shouldn't be too much to change (I'll volunteer if
nobody else wants to do it), and it'd be The Right Thing To Do.

--Matt

-- 
----------------------------------------------------------------
Matthew Leingang                http://www.math.rutgers.edu/
Rutgers University              lei...@ma...
Department of Mathematics       "This signature needs no quote."

Re: [Phpslash-devel] RC2 and Windows + jpcache question

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

On Tue, Feb 04, 2003 at 09:13:54PM +0000, Peter Cruickshank wrote:

<snip>
> 
> Can you remind me how to update the CHANGES doc?
>

Just edit it in your local copy and commit with your changed file(s).
 

<snip>
> 
> Tried that, then slashAuthCR complained on login....
> 

Oops.  I did that.  It *did* work.  I call the jpcache garbage collection 
routine when the session is authenticated successfully.

There are other places that this is done too. (function_exists 
check maybe?)

Joe

> 
> Peter
> 

Re: [Phpslash-devel] RC2 and Windows + jpcache question

[Peter C. <li...@kr...>]

At 14:41 04/02/03 -0600, you wrote:
>On Tue, Feb 04, 2003 at 04:46:10PM +0000, Peter Cruickshank wrote:
>> ...anyway, as part of improvements to functionality, slashTemplate's been created and uses absolute paths. Now, a recent change that seems to have happened with php (by 4.2.3 anyway) is that you now need to specify a drive letter in filepaths, so basedir has to be set as 'C:/path/to/phpslash'.
>
>I haven't used php on win lately, is this related to safe_mode settings?

Dont think so. Might be trying to prevent exploits to do with drive switching which I guess could allow you to define your own phplib etc.

>> template::filename() checks for absolute paths by looking for an initial '/' & so decides that a path starting with 'C:' is relative and sticks a './' in front of the filename, causing a missing template error. I fixed it by adding this to slashTemplate.class:
>> // As per template.inc, with added test for windows absolute path
>>    function filename($filename) {
>>     if ($this->debug & 4) {
>>       echo "<p><b>filename:</b> filename = $filename</p>\n";
>>     }
>>     if (substr($filename, 0, 1) != "/" && substr($filename, 1, 1) != ":") { // Test for Windows absolute path - could use preg_match(/[A-Z]:/i,...) test?
>>       $filename = $this->root."/".$filename;
>>     }
>> 
>>     if (!file_exists($filename)) {
>>       $this->halt("filename: file $filename does not exist.");
>>     }
>>     return $filename;
>>   }
>> 
>> This isn't a bug in psl, more a feature in template.inc, but I guess it's worth knowing about. 
>>
>
>gotcha, thanks.  You wanna go ahead and commit this to slashTemplate and 
>override the template.inc filename function?

Will do.

Can you remind me how to update the CHANGES doc?

>Then submit a patch to phplib?

OK.

Do you know much about Macs? - it's occurred to me that an absolute path in a Mac might start with a ':' ... might as well take that into account too.


>> 
>> My question: how do you disable jpcache short of commenting everything out or forcing a (false)? Particularly the but that starts "// begin built-in jpcache".
>> 
>
>Set line the JPCACHE_ON variable to zero:
>
>        262 $JPCACHE_ON  =   1;   // Turn caching on/off
>
>To individually disable for one page use the cachetimeout variable:
>
>        // don't cache this page
>        $cachetimeout=-1;

Thanks - it's mostly for development/debugging work.

>If you don't want the code included at all I gues you have to force a 
>false condition.

Tried that, then slashAuthCR complained on login....


Peter

Re: [Phpslash-devel] RC2 and Windows + jpcache question

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

On Tue, Feb 04, 2003 at 04:46:10PM +0000, Peter Cruickshank wrote:
> Hi
> 
> A point and a question:
> 
> OK I know I'm in a minority here, but I develop on a windows box before uploading to a unix ISP...
> 
> ...anyway, as part of improvements to functionality, slashTemplate's been created and uses absolute paths. Now, a recent change that seems to have happened with php (by 4.2.3 anyway) is that you now need to specify a drive letter in filepaths, so basedir has to be set as 'C:/path/to/phpslash'.

I haven't used php on win lately, is this related to safe_mode settings?

> 
> template::filename() checks for absolute paths by looking for an initial '/' & so decides that a path starting with 'C:' is relative and sticks a './' in front of the filename, causing a missing template error. I fixed it by adding this to slashTemplate.class:
> // As per template.inc, with added test for windows absolute path
>    function filename($filename) {
>     if ($this->debug & 4) {
>       echo "<p><b>filename:</b> filename = $filename</p>\n";
>     }
>     if (substr($filename, 0, 1) != "/" && substr($filename, 1, 1) != ":") { // Test for Windows absolute path - could use preg_match(/[A-Z]:/i,...) test?
>       $filename = $this->root."/".$filename;
>     }
> 
>     if (!file_exists($filename)) {
>       $this->halt("filename: file $filename does not exist.");
>     }
>     return $filename;
>   }
> 
> This isn't a bug in psl, more a feature in template.inc, but I guess it's worth knowing about. 
>

gotcha, thanks.  You wanna go ahead and commit this to slashTemplate and 
override the template.inc filename function?

Then submit a patch to phplib?
 
> 
> My question: how do you disable jpcache short of commenting everything out or forcing a (false)? Particularly the but that starts "// begin built-in jpcache".
> 

Set line the JPCACHE_ON variable to zero:

	262 $JPCACHE_ON  =   1;   // Turn caching on/off

To individually disable for one page use the cachetimeout variable:

	// don't cache this page
	$cachetimeout=-1;

If you don't want the code included at all I gues you have to force a 
false condition.

Joe

> Thanks
> 
> 
> Peter
> 
> 

[Phpslash-devel] RC2 and Windows + jpcache question

[Peter C. <li...@kr...>]

Hi

A point and a question:

OK I know I'm in a minority here, but I develop on a windows box before uploading to a unix ISP...

...anyway, as part of improvements to functionality, slashTemplate's been created and uses absolute paths. Now, a recent change that seems to have happened with php (by 4.2.3 anyway) is that you now need to specify a drive letter in filepaths, so basedir has to be set as 'C:/path/to/phpslash'.

template::filename() checks for absolute paths by looking for an initial '/' & so decides that a path starting with 'C:' is relative and sticks a './' in front of the filename, causing a missing template error. I fixed it by adding this to slashTemplate.class:
// As per template.inc, with added test for windows absolute path
   function filename($filename) {
    if ($this->debug & 4) {
      echo "<p><b>filename:</b> filename = $filename</p>\n";
    }
    if (substr($filename, 0, 1) != "/" && substr($filename, 1, 1) != ":") { // Test for Windows absolute path - could use preg_match(/[A-Z]:/i,...) test?
      $filename = $this->root."/".$filename;
    }

    if (!file_exists($filename)) {
      $this->halt("filename: file $filename does not exist.");
    }
    return $filename;
  }

This isn't a bug in psl, more a feature in template.inc, but I guess it's worth knowing about. 


My question: how do you disable jpcache short of commenting everything out or forcing a (false)? Particularly the but that starts "// begin built-in jpcache".

Thanks


Peter

[Phpslash-devel] LDAP authorization with phpSlash and Back-End

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

Hello,

Peter Starowicz has been working with OpenConcept.ca on developing LDAP
authorization for Back-End (and also phpSlash).

We've put the relevant files in the Back-End0.5.x module of the Back-End
CVS:
	http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/back-end

class/LDAP.class has been added and class/slashAuthCR.class &
public_html/config.php have been slightly changed (but the changes are
big and bold, so they'll be easy to see).

Back-End is presently based on phpSlash 0.6.5.  We are considering a
move to M7, but will need to put out a release of our current
development and start another development iteration before we can
proceed with that.

Comments & feedback would be appreciated.

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca

[Phpslash-devel] LDAP

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

Hello Austin,

On Tue, 2003-01-14 at 15:19, 
> From: Austin Theen <au...@pe...>
> My .02c would suggest that it might be cool. but setting up ldap for a
> cms system seems like overkill. if it's already in place, then maybe it
> makes sense. 

That's the case here..  I don't think we would have suggested it
otherwise.  They wanted to give organization wide access to the cms and
allow a single username/password for this.  However, once it is
implemented there's a lot more that you can do with this
system/organization wide level of authorization.

> I'm having a hard time just setting up an ldap based addressbook for my
> office. let alone trying to integrate with multiple systems like
> evolution, projekt, phpgroupware and others. 

Yes..  But hopefully there will be more tools in the future that will
make this type of integration easier.  

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca

Re: [Phpslash-devel] pconnect & M7

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

Hi Joe,

On Tue, 2003-01-14 at 12:59, Joe Stewart wrote:
> On Tue, Jan 14, 2003 at 12:31:41PM -0500, Mike Gifford wrote:
> > Just got a mysql error here:
> > 	http://www.phpslash.org/article.php3?story_id=73
> > with too many open connections (sorry for not copying the error when it
> > was there)..
> Probably just the sf.net db server is overloaded.  pconnect looks to be 
> off on that install.

That's quite likely..  Who knows how many projects they have on a given
server..

> > Went to check to see if this could be an issue with pconnect and it does
> > seem to be that with the last tarball I downloaded that mysql_pconnect
> > is still used here:
> > class/phplib/php/db_mysql.inc
> There is a configuration variable in the db class to allow its use:
> var $PConnect      = 0;     ## Set to 1 to use persistent database 
> connections
> see:  http://www.sanisoft.com/phplib/manual/DB_SqlAddedInfo.php

Thanks for clarifying this.
 
<snip>

> > btw, looks like we've got some ldap code which will enable phpSlash to
> > authorize against OpenLDAP.  If you're interested in testing this, let
> > me know.
> coolness.
> Post some patches :)

Will do..  Hopefully later on today.

Mike
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca

[Phpslash-devel] ldap <-> phpslash interface]

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

Hello Jeremy,

Joe just brought this to my attention (I'm using the digest mode so I
just got it through him).

Just this week we've got an LDAP authorization module which can be
plugged into phpSlash.  

A LDAP.class and some changes to the config.ini.php & slashAuthCR.class

They were set up for Back-End, which is presently  based on 0.6.5, so
there may need to be some modifications done for phpSlash.

We could use some help testing this (especially on phpSlash M7).  I can
send the files to the list (though that would make for a messy
digest)..  Guess I should just sumbit it as a patch on SF when I get the
files.

Mike

btw.  Just wanted to encourage phpSlash to get sf.net to change the file
extensions on the cvs files from .php3 -> .php so that it will be easier
to relate between the CVS version and the tarball.  Back-End did this
with not loss of data as far as revision histories.

> From: Jeremy Field <je...@fl...>
> To: php...@li...
> Subject: [Phpslash-devel] ldap <-> phpslash interface
> Date: 14 Jan 2003 19:19:19 +1100
> 
> Hi,
> 
> Is anyone working on this? Or should I set to it?
> 
> Cheers,
> Jeremy
-- 
Mike Gifford <mi...@op...>
OpenConcept Consulting http://www.openconcept.ca

Re: [Phpslash-devel] pconnect & M7

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

On Tue, Jan 14, 2003 at 12:31:41PM -0500, Mike Gifford wrote:
> Hello Folks,
> 
> Just got a mysql error here:
> 	http://www.phpslash.org/article.php3?story_id=73
> 
> with too many open connections (sorry for not copying the error when it
> was there)..
> 

Probably just the sf.net db server is overloaded.  pconnect looks to be 
off on that install.

> Went to check to see if this could be an issue with pconnect and it does
> seem to be that with the last tarball I downloaded that mysql_pconnect
> is still used here:
> 
> class/phplib/php/db_mysql.inc
>

There is a configuration variable in the db class to allow its use:

var $PConnect      = 0;     ## Set to 1 to use persistent database 
connections


see:  http://www.sanisoft.com/phplib/manual/DB_SqlAddedInfo.php
 
> I'd suggest that the default be mysql_connect as unless you know what
> you are doing and set up PHP/MYSQL correctly, pconnect is going to give
> you more grief..
> 

agreed.

> Mike
> 
> btw, looks like we've got some ldap code which will enable phpSlash to
> authorize against OpenLDAP.  If you're interested in testing this, let
> me know.

coolness.

Post some patches :)

Joe

> -- 
> Mike Gifford <mi...@op...>
> OpenConcept Consulting http://www.openconcept.ca
> 
>