phpslash-devel Mailing List for phpSlash (Page 16)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

How about if I setup this code in the "phpslash" cvs tree to get us 
started?  It's pretty well borked at the moment anyway.

Joe

Note:  Moved to the -devel list

On Sun, Mar 09, 2003 at 05:13:48PM -0800, nathan r. hruby wrote:
> On Sun, 9 Mar 2003, Gary de Montigny wrote:
> 
> > [error] PHP Notice:  Undefined index:  NID in
> > /var/www/class/lib.resources.php on line 163
> > [error] PHP Notice:  Undefined index:  isReplacedBy in
> > /var/www/class/lib.resources.php on line 462
> > [error] PHP Notice:  Undefined index:  NID in
> > /var/www/class/lib.resources.php on line 163
> > [error] PHP Notice:  Undefined index:  TZ in /var/www/htdocs/config.php
> > on line 645
> > [error] PHP Notice:  Undefined index:  TZ in
> > /var/www/class/functions.inc on line 1324
> > [error] PHP Notice:  Undefined index:  isReplacedBy in
> > /var/www/class/lib.resources.php on line 462
> > [error] PHP Notice:  Undefined index:  NID in
> > /var/www/class/lib.resources.php on line 163
> > [error] PHP Notice:  Undefined property:  zone_file in
> > /var/www/class/tz.class on line 67
> > [error] PHP Notice:  Undefined property:  country_file in
> > /var/www/class/tz.class on line 70
> >
> 
> None of these errors are critical, they are php issuing warnings about
> improper use of array indices or object properties.  They will fill up
> your error_log awful quick though (last months set of error logs for my
> phpslash site was about 4GB using 0.65 :)
> 
> > Any idea how to correct the above errors?  Thanks.
> >
> 
> Instant Gratification: edit your php.ini file and set error_reporting to
> E_ALL & ~E_NOTICE.  this will make the notices stopp happening, they'll
> still occur, but you won't get any verbosity about it.  If you don;t have
> access to php.ini on your machine (eg: you;re on a hosted box) you can
> open up $INSTALL/public_html/config.php and look for some lines like
> this, making them refect the values listed below:
> 
> /**** START DEBUGGING - Comment or delete this for production! ****/
> //ini_set('display_errors', 1);
> //ini_set('display_startup_errors', 1);
> //ini_set('error_reporting', E_ALL);
> ini_set('error_reporting', E_ALL & ~E_NOTICE);
> /**** END DEBUGGING ****/
> 
> 
> Fix the problem:  Go to the lines indocated in the error log and see what
> the code is doing, and then change it to have the same effect but use a
> fucntion that doesn't raise a notice.  After that, submit a patch to the
> SF patch manager so we can merge your fixes into the next release.
> 

While I was dedicating effort to eliminating these warnings, I noticed 
measurable degradation in performance.  Some of these places did show 
areas that needed improvement for sure.  PHP has some goofiness in dealing 
with using values of arrays that was frustrating too.  I've forgotten now, 
but maybe I can dig up an example.

So I stopped trying.

Joe

> Tell someone else about it:  File a bug in the SF bug tracker about
> this and someone will get around to fixing it for 0.71 (aka: m7-pl1?)
> 
> HTH,
> 
> -n
> -- 
> ------
> nathan hruby
> na...@ds...
> ------
> 

Hey,

does this qualify as a FAQ yet? :-)  Is there an appropriate place in the 
dox to mention it?

Is there a cleaner way around it?  loadClass could check to make sure the 
class doesn't already exist, but that might make other errors harder to 
catch (like, you create a new class that never gets loaded b/c of name 
confusion).

--Matt

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

---------- Forwarded message ----------
Date: Sat, 8 Mar 2003 18:21:48 -0800
From: Andrew Johnson <an...@ma...>
To: php...@li...
Subject: [phpslash-users] Re: almost installed

Thanks...   commented out the auto_prepend_file in my php.ini and works 
great.

-andrew

>
>> I get to the second to last step of the installation and get a error 
>> in
>> my browser:
>>
>> Fatal error: Cannot redeclare class db_sql in
>> /Library/WebServer/phpslash-0.7/class/phplib/php/db_mysql.inc on line 
>> 12
>
> Check to make sure that you are NOT automatically including a phplib
> prepend.php file, like in an .htaccess file.  PHPslash loads phplib
> classes on its own now.
>
> --Matt

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
phpslash-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/phpslash-users

<snip>

>Another small issue - the poll list cache is not deleted when a new poll
>is added. If someone would tell me a quick regex for "string contains poll
>and not question_id" this would be fixed too.

something like (in the same line "poll" exists, but not "question_id"):

"/.*\bpoll\b.*[^question_id]/" <--- PCRE

at least question_id is not matched... so it depends on what you are trying 
to do... search and replace?

s/.*\bpoll\b.*\[^question_id\]//gc <--- delete all lines where string "poll" 
but not the sequence "question_id" exists.... this is Vim's version...

you might want to try that a couple of times somewhere else before :-) my 
perl script find_replace.pl should do this nicely like:

find_replace.pl ".*\bpoll\b.*[^question_id]" "" ".class" <--- in all .class 
files look for string in first argument and replace with second argument...

to try it, without changing anything, use find_inline.pl first:
find_infile.pl ".*\bpoll\b.*[^question_id]" ".class"

<snip>

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

>On Thu, Mar 06, 2003 at 11:11:29PM -0500, Luis M wrote:
> >
> > >
> > >Can we get rid of the config.php file from the CVS?  That way there
> > >won't be any conflicts with cvs checkouts?
> > >
> > >Just a suggestion....
> > >
> > >later,
> > >ajay
> > >
> >
> > don't despair. the file will go away for 0.7.1 coming very soon.
> >
>
>Now for you guys input on this:
>
>1.  delete config.php from cvs entirely
>
yes, be-gone!

>2.  move config-dist.php to config.php

yes, after deleting the current one. no one need to modify this file ever, 
except for maybe adding where the .ini.php is... also, "error_reporting" 
should be set to "0" for realeases.

>3.  change config.php to only contain text that phpslsash is not
>configured and to read the install documentation.

yes, in config-dist.php after moving to config.php, include a comment that 
config.ini.php doesn't exist...

summary:

mv config-dist.php to config.php and add comment when config.ini.php is not 
set or cannot be read/found.

<snip>

>Ajay - Luis found a problem with the poll total votes if you manually put
>values into the form.  Maybe you could give him a hint.  I remember the
>old days with the bad counts and you fighting with this.
>

http://www.latinomixed.com/phpslash/poll.php3 <-- this is straight from CVS 
but abused...

this is the abused poll results:
http://www.latinomixed.com/phpslash/poll.php3?submit=viewresults&question_id=20

default password/user is set, so you can become god and break the phpslash 
installation there... I will reinstall as soon as Joe tells me 0.7.1 is 
ready...

<snip>

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

On Fri, Mar 07, 2003 at 02:08:35PM -0600, Joe Stewart wrote:

<snip>
>  
> > > Ajay - Luis found a problem with the poll total votes if you manually
> > > put values into the form.  Maybe you could give him a hint.  I
> > > remember the old days with the bad counts and you fighting with this.
> > 
> > I'll have to dig into the code since I've been pretty much AWOL for the 
> > last year.  :)  I do have a working 7.0 installation at home so I'll try 
> > to recreate this bug.
> > 
> 
> He kind of abused it by putting a very large number in one of the Votes 
> fields ( all 9's).
> 

This seems to be confined to using mozilla cvs snapshot.  While other browsers 
also accepts an extra digit in the form field, this version of mozilla also 
submits it.  Creating a screwed up database entry.

Joe

On Fri, 7 Mar 2003, Joe Stewart wrote:

> On Fri, Mar 07, 2003 at 12:14:08PM -0800, Ajay Sharma wrote:
> > > Now for you guys input on this:
> > > 
> > > 1.  delete config.php from cvs entirely
> > > 
> > > 2.  move config-dist.php to config.php
> > > 
> > > 3.  change config.php to only contain text that phpslsash is not 
> > > configured and to read the install documentation.
> > > 
> > > All three seem to have pros and cons to me.
> > 
> > just for consistancy reasons, I would choose number 1 because we don't 
> > distribute a config.ini.php file, so right now there are three config 
> > files:
> >
> 
> I lean to this one because the config files don't get written over 
> accidently :)

Me too on #1.  

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

On Fri, Mar 07, 2003 at 12:14:08PM -0800, Ajay Sharma wrote:
> > Now for you guys input on this:
> > 
> > 1.  delete config.php from cvs entirely
> > 
> > 2.  move config-dist.php to config.php
> > 
> > 3.  change config.php to only contain text that phpslsash is not 
> > configured and to read the install documentation.
> > 
> > All three seem to have pros and cons to me.
> 
> just for consistancy reasons, I would choose number 1 because we don't 
> distribute a config.ini.php file, so right now there are three config 
> files:
>

I lean to this one because the config files don't get written over 
accidently :)

> config.php
> config-dist.php
> config-dist.ini.php
> 
> config.php is just out of place and should be removed.  Then in the 
> install docs, we should specify that the first thing you should do when 
> installing phpslash is:
> 
> mv config-dist.php config.php
> mv config-dist.ini.php config.ini.php
> 

The regular install already says to copy these:

http://www.phpslash.org/article.php3?story_id=32&topic_id=39&section_id=8#ss2.5

However, for the release I did the copy to reduce questions. Probably 
not a good idea though.  So the quick install didn't mention copying 
config-dist.php tp config.php.

> >  Another small issue - the poll list cache is not deleted when a new
> > poll is added. If someone would tell me a quick regex for "string
> > contains poll and not question_id" this would be fixed too.
> 
> does it have to be a regex:
> 
> if (strstr('poll',$string) and !strstr('question_id',$string)) {
>

When a poll is added, the poll.php can still be pulled from a cache 
unless we do some garbage collection.

// expire cache for this question_id
jpcache_gc('string', "-question_id-" . $HTTP_POST_VARS['question_id'], "100");

This line deletes the cache for a particular poll when updating it.  It 
does a string match of "question_id-nn" on the cache name and deletes it 
if found.

The list of polls is just poll.php without any arguments.  So that's why I 
wanted the above regex.  The jpcache_gc can now search for string, regex 
or timeout.

> > Ajay - Luis found a problem with the poll total votes if you manually
> > put values into the form.  Maybe you could give him a hint.  I
> > remember the old days with the bad counts and you fighting with this.
> 
> I'll have to dig into the code since I've been pretty much AWOL for the 
> last year.  :)  I do have a working 7.0 installation at home so I'll try 
> to recreate this bug.
> 

He kind of abused it by putting a very large number in one of the Votes 
fields ( all 9's).

I'm committing a fix for the default poll strangely adding an entry when 
saving.

Joe

> later,
> ajay
> 
> --------------------------------------------------------------------
> Satyajot (Ajay) Sharma 
> ss...@od...
> --------------------------------------------------------------------
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Phpslash-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-devel
> 

At 09:16 07/03/03 -0600, Joe Stewart wrote:
>Now for you guys input on this:
>
>1.  delete config.php from cvs entirely

>>> my preference. Nothing to confuse merging apps/CVS.

Peter

> Now for you guys input on this:
> 
> 1.  delete config.php from cvs entirely
> 
> 2.  move config-dist.php to config.php
> 
> 3.  change config.php to only contain text that phpslsash is not 
> configured and to read the install documentation.
> 
> All three seem to have pros and cons to me.

just for consistancy reasons, I would choose number 1 because we don't 
distribute a config.ini.php file, so right now there are three config 
files:

config.php
config-dist.php
config-dist.ini.php

config.php is just out of place and should be removed.  Then in the 
install docs, we should specify that the first thing you should do when 
installing phpslash is:

mv config-dist.php config.php
mv config-dist.ini.php config.ini.php

>  Another small issue - the poll list cache is not deleted when a new
> poll is added. If someone would tell me a quick regex for "string
> contains poll and not question_id" this would be fixed too.

does it have to be a regex:

if (strstr('poll',$string) and !strstr('question_id',$string)) {

> Ajay - Luis found a problem with the poll total votes if you manually
> put values into the form.  Maybe you could give him a hint.  I
> remember the old days with the bad counts and you fighting with this.

I'll have to dig into the code since I've been pretty much AWOL for the 
last year.  :)  I do have a working 7.0 installation at home so I'll try 
to recreate this bug.

later,
ajay

--------------------------------------------------------------------
Satyajot (Ajay) Sharma 
ss...@od...
--------------------------------------------------------------------

On Fri, 7 Mar 2003, Peter Cruickshank wrote:

<snip>
> No more sleep for a while then, Matt :-)  Congratulations anyway.

<plug style="shameless" href="http://www.leingang.net/baby"/>

> Here are my thoughts...
> 
> What I like about phpSlash, and what makes it stand out from the
> crowd, is that it is flexible and easy for a developer to extend or
> customise. I think it would be a shame to try to idiot-proof the code
> at the expense of performance or flexibility (might as well use a
> *Nuke then with its huge range of modules).

Hear that.  I've downloaded and played a little with *Nuke and it also 
seems that its autoloading is at the expense of performance.  

> So I dont think there's much need for any auto-install code or other
> hand-holding (not that it's been discussed here).
> 
> Having said that, it is good to be rethinking things - the code's
> grown up a lot since 0.6.2.
> 
> It would also be good to have criteria for acceptance of new modules.
> Just have to make sure the existing code is up to scratch!

Good point, although nobody's beating down the door with patches. :-)

> Some other random thoughts:
> 
> Config/installation issues I can think of (no answers though, sorry):
> - adding menu items
> - adding classRequirements
> - module customisation (passwords etc)
> - database changes (new tables, updating permissions and groups etc)

Sounds like the module developer should provide:
- a patch to config.ini
- content script, admin script
- an SQL script incrmental from last major release? 

> Currently, it's a case of editing config.ini and manually running SQL. Possibly painful, but runs efficiently once done.
Did somebody say README?

> I dont think it would be good if we end up with a chain of config
> files having to be read and processed every time a page is loaded.
Good point.  Would you feel differently if each module had a config file 
that was loaded once per session?

> The database has got to the stage though that modules might need an
> install.php script to create the apprpriate tables, work out record
> ids and update db_sequences where new block-types or permissions are
> added.

Wherever possible, I think this should be done with class methods.  If 
you want to add a permission, there should be a slashPerm::addPerm() 
method (or something).  

> Would save a fair bit of unnecessary array processing for sure.
> 
> I think en_US is overkill at least at the moment (see below)

<snip>
> >> Silly question:  Why do we have language divisions in the template
> >> directory?  Isn't all i18n destined for the locale directory?
> 
> I think it's good that language-specific stuff (for static info) can
> be dealt with within .tpl files if wanted. Some stuff it just too
> complicated/big to include in $pslstrings. See my thoughts on
> structuring skins below...

OK, I understand this now.  Joe pointed out that you might have banner
images with text in different languages, so that's one reason to localize 
skins.

> >> Another idea, which I think PHPGW uses, is that within each module 
> >> directory you have template and l10n subdirectories.  

I wanted to double check their directory structure, but it seems they shot 
themselves in the foot.  All of their site's content got deleted!  By 
downloading a release, I confirmed:  
phpgroupware/MODULE/templates/SKIN/*.tpl is how they do it.  

Something that's bothering me:  It seems that programmers should develop 
new modules, but graphic designers should develop new skins.  I suspect
that most of us do both, but is there a way to keep them totally separate?  
Maybe that's not such a big deal.  The skin designer could add templates 
to any module.  

> >I've given this a little more thought.  I think templates will have to 
> >reside with the module by default.  But support being moved to skins and 
> >language directories.
> 
> Templates dont have to be with the module code once installed. Modules could come packages as a zipped up tree. There's the risk of overwriting existing stuff, but that can be got round by naming convenions (eg all must start with module name).
> 
> As far as skins are concerned, I think that stylesheets and images should be closer to the tpl files. I also think that skins should consist of base sets (in en_US I guess!), with language-specific variations. So for skin sssss:
>         /public_html/skins/ssss/*.tpl
>         /public_html/skins/ssss/de/*.tpl (i think the number of language-specific templates will be relatively small)
>         /public_html/skins/ssss/images
>         /public_html/skins/ssss/images/de/ (allow for different title and button graphics, for instance)
>         /public_html/skins/ssss/scripts
>         /public_html/skins/ssss/styles/ssss.css (to allow for locale-specific stylesheets, if ever needed)
> 

> - it'll make maintenance/extension of skins easier by having all the
> skin stuff under one tree

And the contributor of a new module has to traipse into the skin dir...

> - it leaves the .tpl files exposed within the URL, no serious risk though.

No risk, but unappealing to me

> - adding module names into the directory structure could make things
> very convoluted, I see Joe's point about it being good to include
> skins within modules - but we'd have to deal with image or script
> files (must be within the URL) and *.class files (should be away from
> URL root). I think a naming convention would be enough to prevent
> confusion.

Aye, there's the rub.  If we want module contributions to be in a single
part of the psl tree, then we have to put stuff that should be
world-visible (images, admin scripts), and stuff that shouldn't (include
scripts, and to a lesser extent, templates) into the same level of the
tree.  Maybe that's the reason for the admin.php?module=foo style...

> A separate internationalisation point is that much of the code assumes that the 'submit' button has english values (eg save, update). We really should be able to deal with the german, french, norwegian words... maybe it's just a case of changing
>         switch ($submit) {
>         case 'save':
>                 :
>         }
> to 
>         switch ($submit) {
>         case pslGetText('save'):
>                 :
>         }
> And also change the buttons to be
>         <input type="submit" name="submit" value="{LANG_SAVE}">
> throughout? (saves having extra variations on the templates).

Very good point.  Could be done right away.

> 
> - is it worth trying to deal with variations within a language for
> spelling/timeformats (en_UK, en_CA, en_AU, de_DE, de_CH)? - I can't
> see that it would be an issue in practise. 'english', 'deutsch' etc
> would be whatever the language of the main users. Though I am
> impressed when I see an international site produce UK english, I can
> still make sense of the word 'internationalize' even if it is spelt
> wrong, and dates even if the month is in the wrong place. Possibly a
> controversial thought though.

I think we should, because we can.  And I don't think its that hard if we
write a good pslGetText and psl_getLocalInfo.  I agree it would be
bothersome to provide separate language files for every single locale, so
why not do it like we're doing the skins?  You can have a full language
file en_US/foo.php; then en_UK/foo.php could indicate that whatever
strings weren't localized (um, localised) there should be taken from the
language default.

That's all for now.

Later,
Matt

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

On Fri, Mar 07, 2003 at 03:15:49PM +0000, Peter Cruickshank wrote:

<snip>
> 
> What I like about phpSlash, and what makes it stand out from the crowd, is that it is flexible and easy for a developer to extend or customise. I think it would be a shame to try to idiot-proof the code at the expense of performance or flexibility (might as well use a *Nuke then with its huge range of modules).
> 
> So I dont think there's much need for any auto-install code or other hand-holding (not that it's been discussed here).
> 

There may be room for some command-line installation scripts without 
sacrificing the configuration flexibility.  Last summer I had a commitment from the debian maintainer of postnuke to help 
with a debian package:

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=81947

> Having said that, it is good to be rethinking things - the code's grown up a lot since 0.6.2. 
> 
> It would also be good to have criteria for acceptance of new modules. Just have to make sure the existing code is up to scratch!
> 

I think an published API would help in this regard too.

> Some other random thoughts:
> 
> Config/installation issues I can think of (no answers though, sorry):
> - adding menu items

Maybe a web based menu admin.

> - adding classRequirements

In my proposal the classRequirements would move to the module's scripts.  
JIT class registration.

> - module customisation (passwords etc)
> - database changes (new tables, updating permissions and groups etc)
> 
> Currently, it's a case of editing config.ini and manually running SQL. Possibly painful, but runs efficiently once done.
> 
> I dont think it would be good if we end up with a chain of config files having to be read and processed every time a page is loaded.
>

Good question about module configuration needs.

> The database has got to the stage though that modules might need an install.php script to create the apprpriate tables, work out record ids and update db_sequences where new block-types or permissions are added.
> 
> 
<snip>

> >
> >I've given this a little more thought.  I think templates will have to 
> >reside with the module by default.  But support being moved to skins and 
> >language directories.
> 
> Templates dont have to be with the module code once installed. Modules could come packages as a zipped up tree. There's the risk of overwriting existing stuff, but that can be got round by naming convenions (eg all must start with module name).
> 

no, but where to put them?  Just choose the "basic" skin?

If they stayed with the module by default, a site designer could setup 
skin specific ones under the skin's directory optionally.

> As far as skins are concerned, I think that stylesheets and images should be closer to the tpl files. I also think that skins should consist of base sets (in en_US I guess!), with language-specific variations. So for skin sssss:
>         /public_html/skins/ssss/*.tpl
>         /public_html/skins/ssss/de/*.tpl (i think the number of language-specific templates will be relatively small)
>         /public_html/skins/ssss/images
>         /public_html/skins/ssss/images/de/ (allow for different title and button graphics, for instance)
>         /public_html/skins/ssss/scripts
>         /public_html/skins/ssss/styles/ssss.css (to allow for locale-specific stylesheets, if ever needed)
>

The kicker to this is the templates themselves actually have nothing to do 
with the public_html stuff and are more similar to the other included 
files.  They don't need to be in web-root at all.

> - it'll make maintenance/extension of skins easier by having all the skin stuff under one tree
> 

agreed.  This was bantered some as to how to setup the styles.  Lars Hueur 
suggested the styles directory with skin-name.css.  This allows for actual 
stylesheet files to be cached by the browser.

thanks for your input,

Joe

> - it leaves the .tpl files exposed within the URL, no serious risk though.
> 
> - adding module names into the directory structure could make things very convoluted, I see Joe's point about it being good to include skins within modules - but we'd have to deal with image or script files (must be within the URL) and *.class files (should be away from URL root). I think a naming convention would be enough to prevent confusion.
> 
> 
> A separate internationalisation point is that much of the code assumes that the 'submit' button has english values (eg save, update). We really should be able to deal with the german, french, norwegian words... maybe it's just a case of changing
>         switch ($submit) {
>         case 'save':
>                 :
>         }
> to 
>         switch ($submit) {
>         case pslGetText('save'):
>                 :
>         }
> And also change the buttons to be
>         <input type="submit" name="submit" value="{LANG_SAVE}">
> throughout? (saves having extra variations on the templates).
> 
> 
> - is it worth trying to deal with variations within a language for spelling/timeformats (en_UK, en_CA, en_AU, de_DE, de_CH)? - I can't see that it would be an issue in practise. 'english', 'deutsch' etc would be whatever the language of the main users. Though I am impressed when I see an international site produce UK english, I can still make sense of the word 'internationalize' even if it is spelt wrong, and dates even if the month is in the wrong place. Possibly a controversial thought though.
> 
> >> I think it's important to remember the goal:  A phpslash contributor 
> >> should be able to add functionality without changing files.  So either you 
> >> add a new directory with standard subdirectory/filename structure or each 
> >> new module can add files in certain directories, or a mix of the two.  
> 
> Has to be a mix IMO cos of the need to keep *.class files away from the URL
> 
> >> 
> >> [snip]
> >> 
> >> > I probably won't get too much more time to look at this till Monday.
> >> 
> >> I'm out for a few days as well.
> 
> No wonder!
> 
> Anyway, I hope my thoughts were useful, even if they ended up being more about skins...
> 
> Peter 
> 

Note:  starting this discussion again on the -devel list.

No holding still I guess.

I've been think about fleshing out a spec for phpSlash modules, including moving 
around the directory structure some.

I'm sure you won't be too surprised that all the compartmenting of code, 
ensuring return of output to variable instead of "echo", and the 
AddClassRequirements/pslNew stuff is paying off here.

I wanted to get your opinions before beginning a RFC document and spec.

1.  Change directory structure (hopefully formatting is clear enough):

phpslash-ft-
           - contrib  
           - include -
                     - class
                     - locale
                     - modules -
                               - story
                               - block -
                                       - blocktypes
                               - glossary
                               - submission
                               - mailinglist
                               - etc.
                     - templates -
                                 - en -
                                      - basic
                                      - basiccurves
                                      - default
           - scripts
           - doc      
           - public_html -
                         - admin
                         - images
                         - styles
           - tables

By moving to an include directory this further simplifies configuration and 
makes moving the templates and admin scripts out of the web root easier.

3. The module's directoy would contain the class files as well as the public 
script and admin script as applicable.

4. The configuration changes may include:

        dir.include variable
        module.current variable
	changing the modules array to point to the module to use ( instead of 
"true").	

thanks,

Joe

On Thu, Mar 06, 2003 at 11:11:29PM -0500, Luis M wrote:
> 
> >
> >Can we get rid of the config.php file from the CVS?  That way there
> >won't be any conflicts with cvs checkouts?
> >
> >Just a suggestion....
> >
> >later,
> >ajay
> >
> 
> don't despair. the file will go away for 0.7.1 coming very soon.
> 

Now for you guys input on this:

1.  delete config.php from cvs entirely

2.  move config-dist.php to config.php

3.  change config.php to only contain text that phpslsash is not 
configured and to read the install documentation.

All three seem to have pros and cons to me.

> for live talk about phpslash people should hang out on
> 
> irc.freenode.com #phpslash
> 
> mostly during daytime (EST?||PST?)...
> 
> we found lots of bugs lurking and got squashed in CVS -- some of them in the 
> poll class by the way. tomorrow you will see those commits (or so Joe said). 
> config.php still works, but has to go away (missing some locale-related 
> stuff). config-dist.php is the way to go.
>

We've definitely found some bugs.  I think the "remember me" functionality 
should work correctly now.  Mike Gifford had reported this previously but 
I hadn't been able to reproduce.  The cookie path was being set to the 
rooturl.  For good reason some browsers would not read these cookies with 
and url as a path.

Another small issue - the poll list cache is not deleted when a new poll 
is added. If someone would tell me a quick regex for "string contains poll 
and not question_id" this would be fixed too.

Ajay - Luis found a problem with the poll total votes if you manually put 
values into the form.  Maybe you could give him a hint.  I remember the 
old days with the bad counts and you fighting with this.

So, yes, I think a point release should be coming pretty quickly.  The one 
thing I'd personally like to see in the next release is Peter's templates 
as the default set.

Joe

> my $0.02
> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
> 

>
>Can we get rid of the config.php file from the CVS?  That way there
>won't be any conflicts with cvs checkouts?
>
>Just a suggestion....
>
>later,
>ajay
>

don't despair. the file will go away for 0.7.1 coming very soon.

for live talk about phpslash people should hang out on

irc.freenode.com #phpslash

mostly during daytime (EST?||PST?)...

we found lots of bugs lurking and got squashed in CVS -- some of them in the 
poll class by the way. tomorrow you will see those commits (or so Joe said). 
config.php still works, but has to go away (missing some locale-related 
stuff). config-dist.php is the way to go.

my $0.02

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous ! 
http://search.msn.fr/worldwide.asp

Can we get rid of the config.php file from the CVS?  That way there 
won't be any conflicts with cvs checkouts?  

Just a suggestion....   

later,
ajay

--------------------------------------------------------------------
Satyajot (Ajay) Sharma 
ss...@od...
--------------------------------------------------------------------

> > Joe, I forgot what was the IRC that you guys use. I have like 4 instant
> > messenger names but... IRC is better :-) no need for registration...
> >
>
>It was irc.dal.net #phpslash.  But lately they've been pretty well shut
>down by a extended DOS attack.
>
>I've been trying to hang out at irc.freenode.net #phpslash.  But I'm open
>to suggestions?  Trollboy?  babbos?

what about irc.openprojects.net ?
that would be perfect wouldn't it?

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

On Tue, Mar 04, 2003 at 07:46:32PM -0500, Luis M wrote:
> <snip>
> >On Mon, Mar 03, 2003 at 10:09:01AM -0500, Luis M wrote:
> > >
> > > I found this to be a little annoyance which might or might not be a bug. 
> >The
> > > templates under $PATH/templates/en/ are only offer under the "skin" 
> >block to
> > > the browsers who have English languages (en). Thus if you, say, have a
> > > $PATH/fr/skin1 directory for the french language (and the same for other
> > > languages) only that skin is offer to french browsers.
> >
> >Yes, I think I follow this now.  This is one reason you don't want to
> >cache the skin block.  Another is you get links to articles, etc.
> >
> >This is the designed behavior.
> >
> 
> good to know. I noticed the same kind of behaviour for the "Votes" block. If 
> a user in a different language goes to the site, and happens to go after the 
> cache for this block has time out, then the next time I go with a different 
> language I see the block in whatever the last language it was cache. To 
> avoid this, I set the cache to 0 -- I remember that setting a block's cache 
> to 0 used to cause problems in earlier versions of phpSlash. In any case, 
> setting this to zero helps, but doesn't solve the problem ... more on this 
> later on...
>

The previous problems turned out to be almost entirely caused by a memory 
allocation bug in php4.06.  Reducing the number of blocks updating at one 
time reduced the chance of hitting the bug.

> > > Since the text for the whole site gets translated regardless of the skin
> > > being used, I think it would make more sense to offer all templates from 
> >a
> > > given directory (or have a folder which is the default language for all
> > > other -- I think this is what "en" is).
> >
> >Uh, some templates contain text that is not translated - the submission
> >form, login form, poll results, etc.
> 
> True. But, eventually they will be able to translate from the "gettext"-like 
> functions phpSlash uses, right? In any case, only a few strings are left 
> out.
> 

I don't know about this.  The templates are pretty free-form for you to 
modify.  Seems to me it would be better to translate the text in its 
proper context.

> >
> > > Either that or users will have to
> > > create a directory in e/a directory for the language they want to 
> >support
> > > and put a "skin.ini" file whose skin.parent is the default language for 
> >the
> > > given site.
> >
> >Yes.  Except you can't refer back to the default language's skin
> >(yet, maybe?) in the skin.ini.
> >
> 
> yes you can :-) it's tricky thought. You have to use 
> "skin.parent=../../en/basic"; but it works. I'm doing this now. I hope that 
> it's not possible to pass something like this in the actual URL. If not 
> users will be doing things like "skin=../../../../../../../../etc/passwd" 
> and who knows what can happen. I have not tried to break the installation by 
> doing all illegal things I can think of, but I will very soon. I will report 
> whatever I find.
> 

This will probably not work in the future and instead more directives will 
be added to the skin.ini file such as parentlanguage.

Try to break stuff as suggested.  It should be protected.

> > > I know that modifying the algorithm for the "skin" blocktype could 
> >easily
> > > yield to recurring thru a list of duplicated directories, so a solution
> > > should involved default-ing to just one directory and not to all other
> > > languages to look for template directories that are not present in the
> > > current language... (confusing uh, just read this paragraph again...).
> > >
> > > I hope that this makes sense to you guys out there (Joe?).
> > >
> >
> >I think I understood after reading it a few times :)
> >
> >Setting the skin using the user accounts and preferences hopefully will
> >be the preferred method to choose skins.  However, I have done no testing
> >on what skins are available after a language change.
> >I think this might be broken.
> >
> 
> I knew it was confusing to write it, so it had to be worse to understand it.
> I have not tried to register a "normal" user account and changing the users' 
> preferences. Will users be able to see all skins regardless of language 
> settings and the directories used to placed the skins?
> i.e. skins in $templates/en $templates/fr $templates/lang will all show as 
> options to the users?

The language choices shown are for all text translations available.

The skin choices shown should be for the current language displayed ( if 
available).  It does not do this currently.  It still displays the default 
language's skin.  This is broken.  The skins block seems to do the same 
thing for me.  I think we can get this fixed back to showing only those 
skins available to the chosen language if any are available - otherwise 
we display the default language's skins.

Because we don't use javascript forms, the choices can get out of sync.

> Let me play with the site a bit so that I can get a better sense of these 
> things. So far, I think that the best solution is to just put an empty 
> directory in all the language directories with a skin.ini file pointing 
> couple of directories backward to whatever the "basic" directory is for a 
> given site.
> 

Might end up being the best way to provide the full translations and make 
all skins available.

Joe

> peace out!
> 
> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
> 

On Wed, Mar 05, 2003 at 10:45:06AM -0500, Luis M wrote:

<snip>
> 
> Joe, I forgot what was the IRC that you guys use. I have like 4 instant 
> messenger names but... IRC is better :-) no need for registration...
>

It was irc.dal.net #phpslash.  But lately they've been pretty well shut 
down by a extended DOS attack.

I've been trying to hang out at irc.freenode.net #phpslash.  But I'm open 
to suggestions?  Trollboy?  babbos?

> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
> 

>nathan and luis,
>
>Can you guys coordinate on the Mailinglist stuff?  You both had expressed
>interest in working on it.
>

I have lots of time today. I called out sick! (i'm truely getting sick).

In any case, Nathan if you can, then we can work on this today. I already 
got it working yesterday and it worked beautifully.
It's not as sophisticated as the previous version, in other words, it 
doesn't send emails every 15 min to a bunch of users... so there is room for 
improvement there.

<snip>

Joe, I forgot what was the IRC that you guys use. I have like 4 instant 
messenger names but... IRC is better :-) no need for registration...

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous ! 
http://search.msn.fr/worldwide.asp

nathan and luis,

Can you guys coordinate on the Mailinglist stuff?  You both had expressed 
interest in working on it.

thanks

On Wed, Mar 05, 2003 at 02:03:10AM -0500, Luis M wrote:
> 
> here is my first patch to the stable .7 phpslash. it's the latest 
> incarnation of cronmail.php cron script. it's not as sophisticated as the 
> past ones, but this one works better. it uses the mailinglist class and it's 
> a lot less confusing, thus cleaner.
> 
> please let me know if you have problems with it.
> 
> p.s. it still need some cleaning when outputing the report on what was done. 
> i.e. there is no need to use HTML tags. however, after the first run most 
> users might just redirect this to /dev/null anyway.
> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
> 
> 
> 

here is my first patch to the stable .7 phpslash. it's the latest 
incarnation of cronmail.php cron script. it's not as sophisticated as the 
past ones, but this one works better. it uses the mailinglist class and it's 
a lot less confusing, thus cleaner.

please let me know if you have problems with it.

p.s. it still need some cleaning when outputing the report on what was done. 
i.e. there is no need to use HTML tags. however, after the first run most 
users might just redirect this to /dev/null anyway.

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous ! 
http://search.msn.fr/worldwide.asp

<snip>
>On Mon, Mar 03, 2003 at 10:09:01AM -0500, Luis M wrote:
> >
> > I found this to be a little annoyance which might or might not be a bug. 
>The
> > templates under $PATH/templates/en/ are only offer under the "skin" 
>block to
> > the browsers who have English languages (en). Thus if you, say, have a
> > $PATH/fr/skin1 directory for the french language (and the same for other
> > languages) only that skin is offer to french browsers.
>
>Yes, I think I follow this now.  This is one reason you don't want to
>cache the skin block.  Another is you get links to articles, etc.
>
>This is the designed behavior.
>

good to know. I noticed the same kind of behaviour for the "Votes" block. If 
a user in a different language goes to the site, and happens to go after the 
cache for this block has time out, then the next time I go with a different 
language I see the block in whatever the last language it was cache. To 
avoid this, I set the cache to 0 -- I remember that setting a block's cache 
to 0 used to cause problems in earlier versions of phpSlash. In any case, 
setting this to zero helps, but doesn't solve the problem ... more on this 
later on...

> > Since the text for the whole site gets translated regardless of the skin
> > being used, I think it would make more sense to offer all templates from 
>a
> > given directory (or have a folder which is the default language for all
> > other -- I think this is what "en" is).
>
>Uh, some templates contain text that is not translated - the submission
>form, login form, poll results, etc.

True. But, eventually they will be able to translate from the "gettext"-like 
functions phpSlash uses, right? In any case, only a few strings are left 
out.

>
> > Either that or users will have to
> > create a directory in e/a directory for the language they want to 
>support
> > and put a "skin.ini" file whose skin.parent is the default language for 
>the
> > given site.
>
>Yes.  Except you can't refer back to the default language's skin
>(yet, maybe?) in the skin.ini.
>

yes you can :-) it's tricky thought. You have to use 
"skin.parent=../../en/basic"; but it works. I'm doing this now. I hope that 
it's not possible to pass something like this in the actual URL. If not 
users will be doing things like "skin=../../../../../../../../etc/passwd" 
and who knows what can happen. I have not tried to break the installation by 
doing all illegal things I can think of, but I will very soon. I will report 
whatever I find.

> > I know that modifying the algorithm for the "skin" blocktype could 
>easily
> > yield to recurring thru a list of duplicated directories, so a solution
> > should involved default-ing to just one directory and not to all other
> > languages to look for template directories that are not present in the
> > current language... (confusing uh, just read this paragraph again...).
> >
> > I hope that this makes sense to you guys out there (Joe?).
> >
>
>I think I understood after reading it a few times :)
>
>Setting the skin using the user accounts and preferences hopefully will
>be the preferred method to choose skins.  However, I have done no testing
>on what skins are available after a language change.
>I think this might be broken.
>

I knew it was confusing to write it, so it had to be worse to understand it.
I have not tried to register a "normal" user account and changing the users' 
preferences. Will users be able to see all skins regardless of language 
settings and the directories used to placed the skins?
i.e. skins in $templates/en $templates/fr $templates/lang will all show as 
options to the users?
Let me play with the site a bit so that I can get a better sense of these 
things. So far, I think that the best solution is to just put an empty 
directory in all the language directories with a skin.ini file pointing 
couple of directories backward to whatever the "basic" directory is for a 
given site.

peace out!

----)(-----
Luis Mondesi
System Administrator/Web developer
LatinoMixed.com

le...@ho...

"Black holes are where God divided by zero" - Steven Wright

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

note:  Moved to -devel list.

On Mon, Mar 03, 2003 at 10:09:01AM -0500, Luis M wrote:
> 
> I found this to be a little annoyance which might or might not be a bug. The 
> templates under $PATH/templates/en/ are only offer under the "skin" block to 
> the browsers who have English languages (en). Thus if you, say, have a 
> $PATH/fr/skin1 directory for the french language (and the same for other 
> languages) only that skin is offer to french browsers.

Yes, I think I follow this now.  This is one reason you don't want to 
cache the skin block.  Another is you get links to articles, etc.

This is the designed behavior.

> Since the text for the whole site gets translated regardless of the skin 
> being used, I think it would make more sense to offer all templates from a 
> given directory (or have a folder which is the default language for all 
> other -- I think this is what "en" is). 

Uh, some templates contain text that is not translated - the submission 
form, login form, poll results, etc.

> Either that or users will have to 
> create a directory in e/a directory for the language they want to support 
> and put a "skin.ini" file whose skin.parent is the default language for the 
> given site.

Yes.  Except you can't refer back to the default language's skin 
(yet, maybe?) in the skin.ini. 

> I know that modifying the algorithm for the "skin" blocktype could easily 
> yield to recurring thru a list of duplicated directories, so a solution 
> should involved default-ing to just one directory and not to all other 
> languages to look for template directories that are not present in the 
> current language... (confusing uh, just read this paragraph again...).
> 
> I hope that this makes sense to you guys out there (Joe?).
> 

I think I understood after reading it a few times :)

Setting the skin using the user accounts and preferences hopefully will 
be the preferred method to choose skins.  However, I have done no testing 
on what skins are available after a language change.  
I think this might be broken.

later,

Joe

> 
> 
> ----)(-----
> Luis Mondesi
> System Administrator/Web developer
> LatinoMixed.com
> 
> le...@ho...
> 
> "Black holes are where God divided by zero" - Steven Wright
> 
> Public signature: http://www.latinomixed.com/lems1/public-a.asc
> 
> 
> 
> 
> _________________________________________________________________
> MSN Search, le moteur de recherche qui pense comme vous ! 
> http://search.msn.fr/worldwide.asp
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> phpslash-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpslash-users
> 

Hopefully this RC4 release can get some quick testing and be released as 
FINAL.

If anything is out of whack, speak up.

thanks,

Joe

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (45)	Dec (50)
2002	Jan (29)	Feb (49)	Mar (38)	Apr (22)	May (39)	Jun (21)	Jul (6)	Aug (9)	Sep (6)	Oct (26)	Nov (42)	Dec (19)
2003	Jan (15)	Feb (71)	Mar (40)	Apr (41)	May (28)	Jun (5)	Jul (25)	Aug	Sep (2)	Oct (50)	Nov (89)	Dec (19)
2004	Jan (21)	Feb (9)	Mar (5)	Apr (6)	May (7)	Jun	Jul (4)	Aug	Sep (14)	Oct (24)	Nov (3)	Dec
2005	Jan (2)	Feb	Mar	Apr	May	Jun (3)	Jul (2)	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

phpslash-devel Mailing List for phpSlash (Page 16)

phpslash-devel — For developers of phpslash to communicate.