phpslash-devel Mailing List for phpSlash (Page 13)
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel — For developers of phpslash to communicate.
This list is closed, nobody may subscribe to it.
| 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
|
|
From: nathan r. h. <na...@ds...> - 2003-05-11 20:38:36
|
On Sun, 11 May 2003, Luis M wrote:
> >Can you please give a very specific example what exactly you did to
> >discover this (including html/exttrans/plain settings, phpversion,
> >phpslash version, os version, browser, and a step-by-step regression)
> >Does this happen every time? If so I'd like to fix this and get it out
> >pronto.
>
> I believe this is the same for all versions of phpslash since 0.62 up to
> 0.72rc1:
>
> 1. Go to the Admin section
> 2. Hit "new" to add a new story
> 3. Try to add a story that contains Perl code with hashes defined like:
> $myhas{td} . etc...
>
I have tried this with the current CVS (and current php-lib-stable cvs)
using both the nobody user / submission page and as a root user using the
story admin page and cannot replicate this behavior using extrans, html
or plaintext formats using Safari-b2.
Please, what versions of phpslash, phplib and php are you running? Does
the above exmaple work exactly as you describe under your environment?
Can you take a screengrab of whhat you enter into the page and what the
preview looks like? Can you send me the extact text that caused this?
> The {td} part of the hashes will mess up the article badly when previewing.
> In fact, the whole page gets mumble with all kinds of crazy things. What I
> do to fix that is adding spaces between the curly-braces.
>
Clearly that should not happen.
> I don't think this affects the server directly, nor have I try to inject any
> type of code to the database. In other words, I'm assuming this cannot be
> done and have not tried. In any case, only the users with Admin rights can
> add news to the site. So, nothing to worry (right?).
>
If this is a real bug, it may also affect the submission.php page...
> However, I believe that the stories (the text coming from the database to be
> displayed as stories) should not be parse as if it was a template or as if
> dynamic PHP code was coming from the database... That could create problems.
> (It creates problems for people who have sites publishing code, as I do :-)
The input stuff should clean() the text before it even gets to the
database. the {} construct is also the same for phplib tempalte
plcasehoder, AFIK, things that look like {foo} get removed during parsing
by the template system and should be additionally fixed by the submission
and story classes. Joe probably knows how this works off the top of his
head..
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Luis M <le...@ho...> - 2003-05-11 19:23:46
|
Hi,
>
>On Sat, 10 May 2003, Luis M wrote:
>
> >
> > ummm it seems that posting code to an article causes phpslash to parse
>the
> > code. This makes yet another suggestion for the future release:
> >
> > #. Do not parse code coming from articles.
> >
> > Things like having $php variables, or {VAR} containers for templates...
>They
> > should all be escaped if the text comes from an article. That could
> > potentially eliminate all types of cross-site scripting and sql-code
> > injection that <i>might</i> be lurking in the phpslash code...
> >
>
>Can you please give a very specific example what exactly you did to
>discover this (including html/exttrans/plain settings, phpversion,
>phpslash version, os version, browser, and a step-by-step regression)
>Does this happen every time? If so I'd like to fix this and get it out
>pronto.
I believe this is the same for all versions of phpslash since 0.62 up to
0.72rc1:
1. Go to the Admin section
2. Hit "new" to add a new story
3. Try to add a story that contains Perl code with hashes defined like:
$myhas{td} . etc...
The {td} part of the hashes will mess up the article badly when previewing.
In fact, the whole page gets mumble with all kinds of crazy things. What I
do to fix that is adding spaces between the curly-braces.
I don't think this affects the server directly, nor have I try to inject any
type of code to the database. In other words, I'm assuming this cannot be
done and have not tried. In any case, only the users with Admin rights can
add news to the site. So, nothing to worry (right?).
However, I believe that the stories (the text coming from the database to be
displayed as stories) should not be parse as if it was a template or as if
dynamic PHP code was coming from the database... That could create problems.
(It creates problems for people who have sites publishing code, as I do :-)
)
----)(-----
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
|
|
From: nathan r. h. <na...@ds...> - 2003-05-11 17:54:48
|
On Sun, 11 May 2003, Joe Stewart wrote: > > There are a few things I've been doing outside the Makefile temporarily. > > I think this is all: > > run extch.sh > copy config-dist.php to config.php > rename db_xfer.php3.disabled to db_xfer.php.disabled > copy phplib into class directory > make dist > Makes sense > I haven't scripted this because when I tried to keep a snapshot with the > extchg.sh step, I couldn't keep a local repository w/php3 and a release w/php. > Well, there's no reason we can't change the Makefile's dist target to do all of that and make a snap taget that doesn't extch, right? -n -- ------ nathan hruby na...@ds... ------ |
|
From: Joe S. <joe...@us...> - 2003-05-11 16:59:49
|
On Sun, May 11, 2003 at 12:02:47PM -0500, Joe Stewart wrote: > On Sun, May 11, 2003 at 07:49:18AM -0700, nathan r. hruby wrote: > > Ok, > > > > This seems like a stupid really stupid question, but I haven't played with > > what's in CVS for a long time. Is it just me, or is there not a copy of > > phplib in the -ft CVS module? How have we been adding a pre-configured > > phplib into the release tarballs? > > > There are a few things I've been doing outside the Makefile temporarily. I think this is all: run extch.sh copy config-dist.php to config.php rename db_xfer.php3.disabled to db_xfer.php.disabled copy phplib into class directory make dist I haven't scripted this because when I tried to keep a snapshot with the extchg.sh step, I couldn't keep a local repository w/php3 and a release w/php. Joe |
|
From: Joe S. <joe...@us...> - 2003-05-11 16:51:42
|
On Sun, May 11, 2003 at 07:49:18AM -0700, nathan r. hruby wrote: > Ok, > > This seems like a stupid really stupid question, but I haven't played with > what's in CVS for a long time. Is it just me, or is there not a copy of > phplib in the -ft CVS module? How have we been adding a pre-configured > phplib into the release tarballs? > I've been adding it right before "make dist". If you want to add it in, I don't have a problem. I've been running the extchg.sh script to change the file extensions and it would apply to all of phplib too. I think the 0.7.2RC1 reflects the current -ft cvs. Anything found to hold up 0.7.2? The -dev cvs should get a flurry of activity this next week. I've been working with it some and would like to get others testing too. Just need to prepare a db export. Joe > -n > > -- > ------ > nathan hruby > na...@ds... > ------ > > |
|
From: nathan r. h. <na...@ds...> - 2003-05-11 15:34:47
|
Ok, This seems like a stupid really stupid question, but I haven't played with what's in CVS for a long time. Is it just me, or is there not a copy of phplib in the -ft CVS module? How have we been adding a pre-configured phplib into the release tarballs? -n -- ------ nathan hruby na...@ds... ------ |
|
From: nathan r. h. <na...@ds...> - 2003-05-11 13:27:56
|
Hi,
On Sat, 10 May 2003, Luis M wrote:
>
> ummm it seems that posting code to an article causes phpslash to parse the
> code. This makes yet another suggestion for the future release:
>
> #. Do not parse code coming from articles.
>
> Things like having $php variables, or {VAR} containers for templates... They
> should all be escaped if the text comes from an article. That could
> potentially eliminate all types of cross-site scripting and sql-code
> injection that <i>might</i> be lurking in the phpslash code...
>
Can you please give a very specific example what exactly you did to
discover this (including html/exttrans/plain settings, phpversion,
phpslash version, os version, browser, and a step-by-step regression)
Does this happen every time? If so I'd like to fix this and get it out
pronto.
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Luis M <le...@ho...> - 2003-05-10 23:32:13
|
ummm it seems that posting code to an article causes phpslash to parse the
code. This makes yet another suggestion for the future release:
#. Do not parse code coming from articles.
Things like having $php variables, or {VAR} containers for templates... They
should all be escaped if the text comes from an article. That could
potentially eliminate all types of cross-site scripting and sql-code
injection that <i>might</i> be lurking in the phpslash code...
At least people should have the option to turn code parsing off, in case
somebody actually wants to allow this for his/her site.
Suggestions?
P.S. For the meantime I'll try to escape as much as I can by hand (as I
usually do).
----)(-----
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
|
|
From: Luis M <le...@ho...> - 2003-05-10 03:13:46
|
<snip> > >I *think* this is the short answer - > >The views - index, article, search, admin story list, etc show your >local time. > >The story admin form shows the server time. ( Matt, if this is >true, can we modify it to be the user's time too? It's kind of >confusing this way). > Now, this is really confusing... Why not just use the server time for everything? If only there was a way to calculate the users' time (without using client-side scripting) and use the users' timezone as a reference to calculate the date/time that the articles display... That way all servers will just be setup to UTC and if a user, say from NYC, connects to the site, the time for all news would show UTC -05:00 time "on the fly"... but, that could messup all the caching and who knows what else... just day dreaming... Unless of course, we can pick and choose what we want to cache and what part of the index.php we want to be dynamic. . . 0.8??? >Matt, can you explain better? Or did I recently introduce a new >bug? > > > 2. When updating articles, the icons should not be renormalized. > > > >Never for updates or only if the date/time changed? > >Should be able to move the renorm up to where it only applied to new >articles pretty easily. yes, renorm should only apply to new articles. no need to shuffle the icons if a story gets updated. It's awkward and the icons show in the main page as if there was a story related to that in the first page. awkward. > > > 3. When posting an article to multiple topics, instead of saying "this > > article was also posted in 'section'"it should display a list of icons >for > > the other sections to which the story is posted. > > > >Should be fairly straight forward. We already get the image info >from the db, but discard all but the first one. Have to correct >some array funkiness I think though. > Nice! The first page displayes one image (the main topic image) and then if the user clicks on "More" sees all other topic images for which this story have been posted. ----)(----- 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 Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Joe S. <joe...@us...> - 2003-05-09 18:26:22
|
On Thu, May 08, 2003 at 10:30:06PM -0400, Luis M wrote: > <snip> > >3. When posting an article to multiple topics, instead of saying "this > >article was also posted in 'section'"it should display a list of icons for > >the other sections to which the story is posted. > > > > I forgot to mention that the icons should not be displayed on the main page > (index.php), but on the actual article when a user clicks on "more". Similar > to what Slash does nowadays... > This could be a skin feature, using the same type changes to storyIndex discussed before. If everybody hasn't noticed, 0.7.2RC1 was released. 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 > |
|
From: Joe S. <joe...@us...> - 2003-05-09 18:24:24
|
On Thu, May 08, 2003 at 08:52:48PM -0400, Luis M wrote: > > 1. The Admin page for adding new "stories" should use the date from the > server to set the "default" date at which an article should show in the main > page. After that, then the index.php page should use the server's date to > decided when it's time to show the articles. For some reason, having a > webserver with UTC time and posting news from a different timezone, > "screwed" the news for the first page so that the articles would not show. I > guess part of how the new timezone code works? In other words, if the > server's time is UTC and the config.ini.php is set to use a given timezone, > the articles on the main page will show only when that timezone's time > arrives.... confusing to explain, I hope somebody gets my point. By the way, > my timezone engine is set to "true" and everything else is left untouched as > suggested by the config.ini.php comments. > I *think* this is the short answer - The views - index, article, search, admin story list, etc show your local time. The story admin form shows the server time. ( Matt, if this is true, can we modify it to be the user's time too? It's kind of confusing this way). Matt, can you explain better? Or did I recently introduce a new bug? > 2. When updating articles, the icons should not be renormalized. > Never for updates or only if the date/time changed? Should be able to move the renorm up to where it only applied to new articles pretty easily. > 3. When posting an article to multiple topics, instead of saying "this > article was also posted in 'section'"it should display a list of icons for > the other sections to which the story is posted. > Should be fairly straight forward. We already get the image info from the db, but discard all but the first one. Have to correct some array funkiness I think though. > That's good enough for now. Any comments? > > > ----)(----- > 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 > |
|
From: Luis M <le...@ho...> - 2003-05-09 02:30:12
|
<snip> >3. When posting an article to multiple topics, instead of saying "this >article was also posted in 'section'"it should display a list of icons for >the other sections to which the story is posted. > I forgot to mention that the icons should not be displayed on the main page (index.php), but on the actual article when a user clicks on "more". Similar to what Slash does nowadays... ----)(----- 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 Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Luis M <le...@ho...> - 2003-05-09 00:52:55
|
1. The Admin page for adding new "stories" should use the date from the server to set the "default" date at which an article should show in the main page. After that, then the index.php page should use the server's date to decided when it's time to show the articles. For some reason, having a webserver with UTC time and posting news from a different timezone, "screwed" the news for the first page so that the articles would not show. I guess part of how the new timezone code works? In other words, if the server's time is UTC and the config.ini.php is set to use a given timezone, the articles on the main page will show only when that timezone's time arrives.... confusing to explain, I hope somebody gets my point. By the way, my timezone engine is set to "true" and everything else is left untouched as suggested by the config.ini.php comments. 2. When updating articles, the icons should not be renormalized. 3. When posting an article to multiple topics, instead of saying "this article was also posted in 'section'"it should display a list of icons for the other sections to which the story is posted. That's good enough for now. Any comments? ----)(----- 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 Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Luis M <le...@ho...> - 2003-05-08 02:52:00
|
>On Fri, May 02, 2003 at 07:55:42PM -0400, Luis M wrote:
> > >How about this?
> > >
> > >$extra_ary = '';
> > >// Are there extra tags/variables to pass to slashHead.tpl?
> > >if(is_array($_PSL['extra_ary'])) {
> > > $extra_ary = $_PSL['extra_ary'];
> > >}
> > >
> > >$header = getHeader($pagetitle,$_PSL['metatags'], $extra_ary);
> > >
> > >Then it could be defined in config.ini, config.php, or in the
> > >script. But couldn't come from the url.
> > >
> > That sounds perfect. But how would the "extra_ary" be defined in the
>.ini ?
> > This way:
> >
> > extra_ary = KEY=>'value', KEY2=>'value2', ..., KEYn=>'valuen'
> >
> > ?? just curious...
>
>Sorry, forgot about this.
>
>This would create the array -
>
>at the END of the ini file:
>
>[extra_ary]
>key1 = value1
>key2 = value2
>key3 = value3
>
>However, I'm not sure why you wouldn't just put the values in the
>template file.
>
>Joe
Well, the .ini can give sort of a "default" value for certain user-defined
variables for the templates (sort of "place holders") and then the user
might develop her/his own modules/scripts/functions to generate data for
those place holders during the page "execution" (when people visit the
site). Sort of what I'm doing to get banners for the accplusli.com site.
$ary['IMAGES']=random_image("banners.txt");
slashHead($foo,$bar,$ary);
...
etc...
----)(-----
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 Search, le moteur de recherche qui pense comme vous !
http://search.msn.fr/worldwide.asp
|
|
From: Joe S. <joe...@us...> - 2003-05-07 14:40:49
|
On Fri, May 02, 2003 at 01:27:14AM -0400, Luis M wrote: > --- CC'ing -devel ---- > > >Hello, > > > >Do you have the mailinglist working for your site now with the > >changes we made? > > > >If so, can you apply the appropriate changes to the -ft cvs? > > > >I'd like to get a RC release going soon. > > Yes. The mailing list has been working for some time in my "production" site > with no hiccups. I'll be doing the diff'ing and applying changes to -ft very > soon. I see the Mailinglist.class is synced. The cronmail script looks up to date. Correct? The -dev cronmail needs the error reporting line fixed. Anything else for a 0.7.2 test release? Otherwise I'll package it up today. Joe |
|
From: Joe S. <joe...@us...> - 2003-05-07 14:38:00
|
On Fri, May 02, 2003 at 07:55:42PM -0400, Luis M wrote:
> >How about this?
> >
> >$extra_ary = '';
> >// Are there extra tags/variables to pass to slashHead.tpl?
> >if(is_array($_PSL['extra_ary'])) {
> > $extra_ary = $_PSL['extra_ary'];
> >}
> >
> >$header = getHeader($pagetitle,$_PSL['metatags'], $extra_ary);
> >
> >Then it could be defined in config.ini, config.php, or in the
> >script. But couldn't come from the url.
> >
> That sounds perfect. But how would the "extra_ary" be defined in the .ini ?
> This way:
>
> extra_ary = KEY=>'value', KEY2=>'value2', ..., KEYn=>'valuen'
>
> ?? just curious...
Sorry, forgot about this.
This would create the array -
at the END of the ini file:
[extra_ary]
key1 = value1
key2 = value2
key3 = value3
However, I'm not sure why you wouldn't just put the values in the
template file.
Joe
|
|
From: Luis M <le...@ho...> - 2003-05-02 23:55:48
|
<snip>
> > For some reason, after upgrading one of my production sites to 0.7.1 I
>lost
> > this functionality. I'm not sure if it has to do with phplib or that's
>the
> > way things were in previous versions of phpslash and we somehow changed
>this
> > for the 0.7.1 release... What I mean is that STORY_ID was declared
>somewhere
> > and as te templates for slashhead() were parse, somehow that container
>was
> > still active when getTitleBar() got called... In short, having this
>variable
> > available for titles don't hurt. We would love to let people click on
>MORE
> > or the TITLE of the story to go to the whole article ... it's just
>natural.
> >
>
>Not sure how you handled this before. What I've done is replace the
>{TITLEBAR} with {TITLE} like:
>
><a href="{ROOTDIR}/article.php3?story_id={STORY_ID}">{TITLE}</a>
>
>This is in story.tpl or storyIndex.tpl.
>
>I usually also pretty much replace the {THESTORY} tag in
>storyIndex.tpl with most of the stuff in story.tpl. I believe a few
>of the skins in the -skins cvs do this. In this way, the index page
>can look different than just the first part of the article page.
>Just because the original slashdot page does this doesn't mean your
>layout needs to.
That's exactly what I needed to know. Thx. Before I just had the
titlebar.tpl setup in the same bgcolor that the story.tpl had, and then made
the title a link to the story... exactly what you said here. Thx again for
the input!
>
> > 2. there should be a way to declare arrays/containers/hashes directly
>from
> > the config.ini.php file (or somewhere else) so that the user can just do
> > things in that file (or maybe thru the "admin" links right into the
> > database) and don't need to modify the slashhead() calls to get
>variables
> > declared at the slashhead(). For instance, prior to 0.7.1, I had to do
> > things like:
> >
> > $banner=random_image("file.txt");
> > slashHead(...,...,"",$banner);
> >
> > This means that I had to modify the functions.inc and e/a slashHead()
>call
> > for e/a script/page I wanted to show a random banner chosen from a
>file...
> > painfull to maintain and upgrade!
> >
> > Thanks goodness that you changed slashHead() to get an $extra_ary hash
>for
> > which keys will be taken as containers for the templates, now I can just
>do:
> >
> > $banner["RANDOM_IMAGE"]=random_image("file.txt");
> > slashHead(...,...,$banner);
> >
> > And things work as expected. You are a genius :-D This functionality
>should
> > be added to the manual for other webmasters out there who use phpslash
>for
> > their customers ;-) People love to have banners and other "commercials"
>in
> > their sites.
> >
>
>gotcha. The guts are there, but each page has to be modified to
>call the header correctly.
>
>I had been thinking that this would be spread out for different ad
>"zones".
>
>How about this?
>
>$extra_ary = '';
>// Are there extra tags/variables to pass to slashHead.tpl?
>if(is_array($_PSL['extra_ary'])) {
> $extra_ary = $_PSL['extra_ary'];
>}
>
>$header = getHeader($pagetitle,$_PSL['metatags'], $extra_ary);
>
>Then it could be defined in config.ini, config.php, or in the
>script. But couldn't come from the url.
>
That sounds perfect. But how would the "extra_ary" be defined in the .ini ?
This way:
extra_ary = KEY=>'value', KEY2=>'value2', ..., KEYn=>'valuen'
?? just curious...
>
> > 3. We should stress the poll (system: classes, functions, pages, admin
> > pages) to make sure that we took care of all "known" bugs. I'll be doing
> > this ASAP and I'll let you know if I find something that needs to be
> > changed.
> >
>
>I don't think there is anything here to hold us up, but we'll see.
Me either. But just to be sure...
----)(-----
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 Search, le moteur de recherche qui pense comme vous !
http://search.msn.fr/worldwide.asp
|
|
From: Joe S. <joe...@us...> - 2003-05-02 15:10:45
|
On Fri, May 02, 2003 at 01:27:14AM -0400, Luis M wrote:
> --- CC'ing -devel ----
>
> >Hello,
> >
> >Do you have the mailinglist working for your site now with the
> >changes we made?
> >
> >If so, can you apply the appropriate changes to the -ft cvs?
> >
> >I'd like to get a RC release going soon.
>
> Yes. The mailing list has been working for some time in my "production" site
> with no hiccups. I'll be doing the diff'ing and applying changes to -ft very
> soon.
>
> There are couple of things we need to keep in mind for 0.7.2 before
> considering RC's:
>
> 1. getTitleBar doesn't have a STORY_ID variable (container). Before I had
> titles that when you click on then get you to the story ( a la "MORE" link).
> For some reason, after upgrading one of my production sites to 0.7.1 I lost
> this functionality. I'm not sure if it has to do with phplib or that's the
> way things were in previous versions of phpslash and we somehow changed this
> for the 0.7.1 release... What I mean is that STORY_ID was declared somewhere
> and as te templates for slashhead() were parse, somehow that container was
> still active when getTitleBar() got called... In short, having this variable
> available for titles don't hurt. We would love to let people click on MORE
> or the TITLE of the story to go to the whole article ... it's just natural.
>
Not sure how you handled this before. What I've done is replace the
{TITLEBAR} with {TITLE} like:
<a href="{ROOTDIR}/article.php3?story_id={STORY_ID}">{TITLE}</a>
This is in story.tpl or storyIndex.tpl.
I usually also pretty much replace the {THESTORY} tag in
storyIndex.tpl with most of the stuff in story.tpl. I believe a few
of the skins in the -skins cvs do this. In this way, the index page
can look different than just the first part of the article page.
Just because the original slashdot page does this doesn't mean your
layout needs to.
> 2. there should be a way to declare arrays/containers/hashes directly from
> the config.ini.php file (or somewhere else) so that the user can just do
> things in that file (or maybe thru the "admin" links right into the
> database) and don't need to modify the slashhead() calls to get variables
> declared at the slashhead(). For instance, prior to 0.7.1, I had to do
> things like:
>
> $banner=random_image("file.txt");
> slashHead(...,...,"",$banner);
>
> This means that I had to modify the functions.inc and e/a slashHead() call
> for e/a script/page I wanted to show a random banner chosen from a file...
> painfull to maintain and upgrade!
>
> Thanks goodness that you changed slashHead() to get an $extra_ary hash for
> which keys will be taken as containers for the templates, now I can just do:
>
> $banner["RANDOM_IMAGE"]=random_image("file.txt");
> slashHead(...,...,$banner);
>
> And things work as expected. You are a genius :-D This functionality should
> be added to the manual for other webmasters out there who use phpslash for
> their customers ;-) People love to have banners and other "commercials" in
> their sites.
>
gotcha. The guts are there, but each page has to be modified to
call the header correctly.
I had been thinking that this would be spread out for different ad
"zones".
How about this?
$extra_ary = '';
// Are there extra tags/variables to pass to slashHead.tpl?
if(is_array($_PSL['extra_ary'])) {
$extra_ary = $_PSL['extra_ary'];
}
$header = getHeader($pagetitle,$_PSL['metatags'], $extra_ary);
Then it could be defined in config.ini, config.php, or in the
script. But couldn't come from the url.
> 3. We should stress the poll (system: classes, functions, pages, admin
> pages) to make sure that we took care of all "known" bugs. I'll be doing
> this ASAP and I'll let you know if I find something that needs to be
> changed.
>
I don't think there is anything here to hold us up, but we'll see.
Joe
> I think that's it for now. If I remember other things I'll let you know as I
> find them.
>
> ----)(-----
> 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
>
|
|
From: Luis M <le...@ho...> - 2003-05-02 05:27:20
|
--- CC'ing -devel ----
>Hello,
>
>Do you have the mailinglist working for your site now with the
>changes we made?
>
>If so, can you apply the appropriate changes to the -ft cvs?
>
>I'd like to get a RC release going soon.
Yes. The mailing list has been working for some time in my "production" site
with no hiccups. I'll be doing the diff'ing and applying changes to -ft very
soon.
There are couple of things we need to keep in mind for 0.7.2 before
considering RC's:
1. getTitleBar doesn't have a STORY_ID variable (container). Before I had
titles that when you click on then get you to the story ( a la "MORE" link).
For some reason, after upgrading one of my production sites to 0.7.1 I lost
this functionality. I'm not sure if it has to do with phplib or that's the
way things were in previous versions of phpslash and we somehow changed this
for the 0.7.1 release... What I mean is that STORY_ID was declared somewhere
and as te templates for slashhead() were parse, somehow that container was
still active when getTitleBar() got called... In short, having this variable
available for titles don't hurt. We would love to let people click on MORE
or the TITLE of the story to go to the whole article ... it's just natural.
2. there should be a way to declare arrays/containers/hashes directly from
the config.ini.php file (or somewhere else) so that the user can just do
things in that file (or maybe thru the "admin" links right into the
database) and don't need to modify the slashhead() calls to get variables
declared at the slashhead(). For instance, prior to 0.7.1, I had to do
things like:
$banner=random_image("file.txt");
slashHead(...,...,"",$banner);
This means that I had to modify the functions.inc and e/a slashHead() call
for e/a script/page I wanted to show a random banner chosen from a file...
painfull to maintain and upgrade!
Thanks goodness that you changed slashHead() to get an $extra_ary hash for
which keys will be taken as containers for the templates, now I can just do:
$banner["RANDOM_IMAGE"]=random_image("file.txt");
slashHead(...,...,$banner);
And things work as expected. You are a genius :-D This functionality should
be added to the manual for other webmasters out there who use phpslash for
their customers ;-) People love to have banners and other "commercials" in
their sites.
3. We should stress the poll (system: classes, functions, pages, admin
pages) to make sure that we took care of all "known" bugs. I'll be doing
this ASAP and I'll let you know if I find something that needs to be
changed.
I think that's it for now. If I remember other things I'll let you know as I
find them.
----)(-----
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 Search, le moteur de recherche qui pense comme vous !
http://search.msn.fr/worldwide.asp
|
|
From: Joe S. <joe...@us...> - 2003-04-30 15:44:30
|
On Wed, Apr 23, 2003 at 11:22:15AM -0500, Joe Stewart wrote: > > With the -dev modules, you really don't need all the different > scripts. GET variables can trigger the module and page to use. > A variation is to use the existing phpSlash structure and assign sections for the modules. Otherwise the modules always have the same blocks as the home page. A side note - We've been able to apply arguments to getStories like max and section. What would be the best way to pass these arguments as block options? > For instance they could be called something like: > > index.php?module=Story&page=admin > > How far should this go? All the way to only index.php? and > backend.php? > > The entire admin/ directory can go. > > I'd like to eventually replace the about page with either a block or > story. It's pretty bad now that it can't be modified through the admin > interface. > What else cannot be done through the web interface that maybe should be? Assigning pages to navbar items comes to mind for me. With module sections, there is a lot of flexibility in the page that is presented. - a different header for some sections. ( header block) - different arguments to the modules for some sections. (module block) - multiple module blocks per page. These are probably the major things I've had to do in the scripts. - different skins for different sections (page block) - You can do other weird things like make an entire section a static page using blocks. (page column) Joe |
|
From: nathan r. h. <na...@ds...> - 2003-04-29 20:22:56
|
On Tue, 29 Apr 2003, Matthew Leingang wrote:
> Hey,
>
> Still thinking about this...
>
Good!
> nathan r. hruby wrote:
> > if it's an object that's needed, much of this framework lays already in
> > phplib session object, which we can expand from, if an object is *truly*
> > desired. Again, I htink that having this in the globall scope would
> > probably be easier and faster in the long run.
>
> I don't think URLs should stay in the templates because then changing
> GET variable names means having to change the templates and that seems
> like a breach of the design/logic barrier.
We left 'em there to make it easier for people who don;t want to chnage
code to futz with stuff. I've also found it hand to not have to deal with
the URL or any of the presets in code. This may just be me, and I might
be willing to give up that ease for the benifit of having path-ified URL's
and the ability to move away from & as an argument seperator.
> I still think a class is the
> best way to allow different implementations of the URL, or just to have
> all in one place the functions which put it together.
>
I disagree. If the functionality is simple and/or needed by *everything*
it belongs in a global function. In this instance both of those
requirments are fulfilled. There's no need to spend time creation an
destroyiog ab object 50 times a page load just to process some variables.
> Perhaps global wrapper functions could be used for the most common url
> creation methods for coding ease.
>
> > // Set the inital URL we want
> > $url = '/foo.php';
> >
> > // thake this and bring back an array of everything we need to develop a
> > // URI for what we want to ppoint at
> > $url = urlAddQuery($url, array('foo' => 'bar', 'session' => $sessid));
> >
> > // it should look somehting like this.
> > print_r($url);
> > // Array(
> > // [method] => $_PSL['protocol']
> > // [base] => $_PSL['rooturl']
> > // [file] => /foo.php
> > // [args] => Array(
> > // [foo] => bar
> > // [session] => fjiweqcn ujnjrinu290vncu034vn u390vntu13
> > // )
> > //)
> >
> > // take that array and push it though a function to turn it into a URI
> > $tpl->add_var('URL', urlFinish($url));
>
> But if you want to add other GET variables conditionally, you'll have to
> manipulate $url['args']. What about removing a GET variable? Even
> uglier. It just naturally looks like members and methods to me.
>
Well, my my world urlAddQuery() pops things onto the end of the array, so
you can call it multiple times, conditionally or no :) And you can very
easily make a urlRemoveQuery('varname') that removes the the array entry
for the named index.
Members and methods and variables and functions are the same thing, one's
in it's own namespace, the other isn't, but that namespace has a cost. I
also think that a whole class and object dedicated to a fairly trivial
task is just over-engineering without any inherit benifit.
> > Easier to grok, less creation/teardown costs, etc.. (I've been working on
> > another project that's wacked out but all procudural using jsut
> > include_once() to seperate code. It's a mess to navigate and use, but
> > it's freakin' *fast* so my new thing is to look for places where we can
> > reduce/reuse existing structures or at least avoid introduccing new stuff.
> > :)
>
> Is the procedural model definitely faster than OO? We already use lots
> of classes. If we're reorganizing the whole project architecture then I
> think introducing new stuff is not a bad idea after all.
>
Yes, the procedural method is a bit faster, this probably will not be the
case after php5. I'm not suggesting a re-org of the entire codebase,
though there are a few places where I'd like to reduce and optimize things
for better performance and easier grokability. My pet peeve is The fact
that $_PSL is in every class, including db so print_r()'ing a object is
worthless - I'm tempted to write a quick sed script to change every
$this->psl into $GLOBALS['_PSL'] jsut to get rid of them.
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Matthew L. <lei...@ma...> - 2003-04-29 19:33:01
|
Hey,
Still thinking about this...
nathan r. hruby wrote:
>>I don't understand why this needs to be an object. It'll get used
>>everywhere, it's probably best in functions.inc and let the individual
>>classes manage the storage of the variables.
>>
>
>
> To expand..
>
> if it's an object that's needed, much of this framework lays already in
> phplib session object, which we can expand from, if an object is *truly*
> desired. Again, I htink that having this in the globall scope would
> probably be easier and faster in the long run.
I don't think URLs should stay in the templates because then changing
GET variable names means having to change the templates and that seems
like a breach of the design/logic barrier. I still think a class is the
best way to allow different implementations of the URL, or just to have
all in one place the functions which put it together.
Perhaps global wrapper functions could be used for the most common url
creation methods for coding ease.
> // Set the inital URL we want
> $url = '/foo.php';
>
> // thake this and bring back an array of everything we need to develop a
> // URI for what we want to ppoint at
> $url = urlAddQuery($url, array('foo' => 'bar', 'session' => $sessid));
>
> // it should look somehting like this.
> print_r($url);
> // Array(
> // [method] => $_PSL['protocol']
> // [base] => $_PSL['rooturl']
> // [file] => /foo.php
> // [args] => Array(
> // [foo] => bar
> // [session] => fjiweqcn ujnjrinu290vncu034vn u390vntu13
> // )
> //)
>
> // take that array and push it though a function to turn it into a URI
> $tpl->add_var('URL', urlFinish($url));
But if you want to add other GET variables conditionally, you'll have to
manipulate $url['args']. What about removing a GET variable? Even
uglier. It just naturally looks like members and methods to me.
> Easier to grok, less creation/teardown costs, etc.. (I've been working on
> another project that's wacked out but all procudural using jsut
> include_once() to seperate code. It's a mess to navigate and use, but
> it's freakin' *fast* so my new thing is to look for places where we can
> reduce/reuse existing structures or at least avoid introduccing new stuff.
> :)
Is the procedural model definitely faster than OO? We already use lots
of classes. If we're reorganizing the whole project architecture then I
think introducing new stuff is not a bad idea after all.
--Matt
--
----------------------------------------------------------------
Matthew Leingang http://www.math.rutgers.edu/~leingang
Rutgers University lei...@ma...
Department of Mathematics "This signature needs no quote."
|
|
From: nathan r. h. <na...@ds...> - 2003-04-28 17:07:54
|
On Mon, 28 Apr 2003, nathan r. hruby wrote:
[snip]
> >
> > I've been thinking about something for a long time, and this looks like
> > a good time to bring it up. What about getting all URLs out of the
> > templates and objectifying them? A url object would be able to parse
> > $QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
> > toString method which output would go into the templates.
> >
> > $url = new PslUrl();
> > $url->setPath("/index.php");
> > $url->setVar("foo","bar");
> > $url->toString() // returns index.php?foo=bar,
> >
[snip]
>
> I don't understand why this needs to be an object. It'll get used
> everywhere, it's probably best in functions.inc and let the individual
> classes manage the storage of the variables.
>
To expand..
if it's an object that's needed, much of this framework lays already in
phplib session object, which we can expand from, if an object is *truly*
desired. Again, I htink that having this in the globall scope would
probably be easier and faster in the long run.
// Set the inital URL we want
$url = '/foo.php';
// thake this and bring back an array of everything we need to develop a
// URI for what we want to ppoint at
$url = urlAddQuery($url, array('foo' => 'bar', 'session' => $sessid));
// it should look somehting like this.
print_r($url);
// Array(
// [method] => $_PSL['protocol']
// [base] => $_PSL['rooturl']
// [file] => /foo.php
// [args] => Array(
// [foo] => bar
// [session] => fjiweqcn ujnjrinu290vncu034vn u390vntu13
// )
//)
// take that array and push it though a function to turn it into a URI
$tpl->add_var('URL', urlFinish($url));
Easier to grok, less creation/teardown costs, etc.. (I've been working on
another project that's wacked out but all procudural using jsut
include_once() to seperate code. It's a mess to navigate and use, but
it's freakin' *fast* so my new thing is to look for places where we can
reduce/reuse existing structures or at least avoid introduccing new stuff.
:)
I belive that at one point we had talked about moving all URL generation
into $sess->url calls but felt that was a large undertaking for not a lot
of benifit. This may be something we want to re-evaluate now that there
are motiviations other than session propigation for rewriting url's in a
predefined manner.
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: nathan r. h. <na...@ds...> - 2003-04-28 16:23:22
|
On Mon, 28 Apr 2003, Matthew Leingang wrote:
> Joe Stewart wrote:
> >
> >
> > In the past I have done this with mod_rewrite rules for the section
> > index pages, article pages and search results.
>
> I thought we were staying away from URL fanciness because
> (theoretically) not all PSL users have access to http.conf or .htaccess
> files. Maybe that's an imagined memory.
>
I think that Jow was jsut saying that's how he's handled this in the past.
yes, you are correct in thinking this only works when you have confi file
access.
> > Most of the changes could be made in the templates. How true that
> > is now days, I don't know.
>
> I've been thinking about something for a long time, and this looks like
> a good time to bring it up. What about getting all URLs out of the
> templates and objectifying them? A url object would be able to parse
> $QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
> toString method which output would go into the templates.
>
> $url = new PslUrl();
> $url->setPath("/index.php");
> $url->setVar("foo","bar");
> $url->toString() // returns index.php?foo=bar,
>
> but if we use a different URL scheme, $url->toString() would return
> index.php/foo/bar or /foo=bar or whatever. Any URL object should be
> able to understand and encode its own get variables.
>
> Then we can provide a choice of URL encoding schemes: the basic one with
> ? and & and = which needs no .htaccess, or something fancier which does.
> A call AddClassReplacement makes the choice
>
> If you're going "all the way up to index.php", then the url object does
> all the deciding of what page is actually being requested.
>
I don't understand why this needs to be an object. It'll get used
everywhere, it's probably best in functions.inc and let the individual
classes manage the storage of the variables.
> --Matt
> (invigorated from PHPCon East)
>
Rat bastid. I want a PHPCon South (or alternativly, I'd be nice to move
back to NYC :)
-n
--
------
nathan hruby
na...@ds...
------
|
|
From: Matthew L. <lei...@ma...> - 2003-04-28 15:46:18
|
Joe Stewart wrote:
> On Fri, Apr 25, 2003 at 05:31:26PM -0700, Aric Caley wrote:
>
>>Just wanted to chime in that I think this is A Good Idea.
>>
>>Take it all the way to index.php.
>>
>>I'd also like to see it work without the ? and &. For example:
>>
>>index.php/story/admin
>>index.php/backend/rss
>>
>>The first part ('story') could be always interpreted as the module name, the
>>second part the page. After that can be interpreted any way the module
>>chooses.
>>
>
>
> In the past I have done this with mod_rewrite rules for the section
> index pages, article pages and search results.
I thought we were staying away from URL fanciness because
(theoretically) not all PSL users have access to http.conf or .htaccess
files. Maybe that's an imagined memory.
> Most of the changes could be made in the templates. How true that
> is now days, I don't know.
I've been thinking about something for a long time, and this looks like
a good time to bring it up. What about getting all URLs out of the
templates and objectifying them? A url object would be able to parse
$QUERY_STRING and/or $PATH_INFO and decode it. It would also have a
toString method which output would go into the templates.
$url = new PslUrl();
$url->setPath("/index.php");
$url->setVar("foo","bar");
$url->toString() // returns index.php?foo=bar,
but if we use a different URL scheme, $url->toString() would return
index.php/foo/bar or /foo=bar or whatever. Any URL object should be
able to understand and encode its own get variables.
Then we can provide a choice of URL encoding schemes: the basic one with
? and & and = which needs no .htaccess, or something fancier which does.
A call AddClassReplacement makes the choice
If you're going "all the way up to index.php", then the url object does
all the deciding of what page is actually being requested.
--Matt
(invigorated from PHPCon East)
--
----------------------------------------------------------------
Matthew Leingang http://www.math.rutgers.edu/~leingang
Rutgers University lei...@ma...
Department of Mathematics "This signature needs no quote."
|
2 messages has been excluded from this view by a project administrator.
