Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Gregory M. <gre...@gm...> - 2005-11-02 14:20:59
|
A few quick thoughts: I thought "Fallout" was our code name for phpWebSite code still in development and that it was not specific to the 1.x code. For example, phpWebSite 2.0 would be called Fallout when it is in development. (when can we expect this Matt? ;-) If that's true, should the wiki page really be called: http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3DFallout Also, before we start putting links to the wiki in 1.x code, should we decide if we were sticking with Mediawiki or if we were finally going to change to the wiki module for phpwebsite? The more places we put links to the wiki now, the more we will have to change if we ever convert the wiki in the future. Other than that, I like the idea of using the wiki as the documentation. Much easier to keep up-to-date. Regards, Greg On 11/2/05, Matthew McNaney <ma...@tu...> wrote: > Ok Greg. I have had a night's sleep and have had coffee. > > My mind is clear and I understand. > > This is what I propose: > > A core class for help > > The config file for help contains the main wiki address > > The help class will create either a link to the wiki or push the user > there automatically. > > The help class will add the localization prefix to the file name. > > We will go with en_filename (fr_filename, de_filename, etc.) > > This work for everyone? > > Thanks Greg, > Matt > > > On Wed, 2005-11-02 at 01:13 -0700, Greg Morgan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Matt, > > > > Background: > > As you asked I have posted a message here to continue the discussion > > that we had today on IRC > > http://www.phpwebsitemanual.com/index.php?module=3Dpagemaster&PAGE_user= _op=3Dview_page&PAGE_id=3D103&date=3D20051101 > > . As you point out " drkludge, that would be cool. however, there isn't > > a wiki for 1.x yet :)" However, the idea will give you the 1.x pages t= o > > link to. > > > > Fallout Seems Close: > > I figured out that 1.x was really close when I created the fallout doc > > page http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3DFall= out > > . So I sense the need to switch over to work on 1.x release. I > > submitted an RFE for the secure_phpws.sh script here > > https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1345623&g= roup_id=3D15539&atid=3D315539 > > . It still needs work but gets the job done for starters. The run > > option may be flaky just 'cause I don't think I know all the files to > > secure yet. Matt will be happy to receive additional patches to the sc= ript. > > > > The live linking to wiki page idea verses .txt files: > > So how 'bout doc? Well I was thinking I want to leave the 0.10.x wiki > > documentation alone. What I have been doing is creating content and > > then point FAQ questions from the forums to the doc. You can see the > > samples here > > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3DUser_FAQ = . > > I see that Matt has localization in the setup help files. This gave me > > and idea for how 1.x and 0.10.x can co-exist. In the setup directory > > are help files > > pwd > > /var/www/fallout2/setup/help > > [root@bagheera help]# ls > > database.en.txt permissions.en.txt sessions.en.txt > > I have taken a bunch of these .txt files to seed the current wiki pages= . > > The problem with this is that the users only read the .txt and run int= o > > the same problem over and over again in the forums. The .txt presume > > that they have some prior knowledge that many do not have. So for this > > release I'd rather have the .txt files put in the wiki and accessible t= o > > the community to edit. The proposal then provides a mechanism to do > > this and it will make the existing doc co-exist with the fallout doc. > > > > So for example there is a database page in the wiki that is 0.10.x > > oriented. With a little work it can be 1.x oriented. If Matt where to > > create a constant to the wiki URL of > > "http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3D" then > > we're part way there. So now if I copy the > > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3Ddatabase > > page to > > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3Den_databa= se > > then the fallout adjustments can be made. The existing database page > > will work for the current 0.10.x users. The new en_database page would > > be localized. Other languages would use the same page name but use > > fr_database as their page name. In the 1.x documentation, I would use > > the [[en_database | database]] convention each time I wanted to wiki > > link to the page. I use this technique now when I want to refer to > > [[web hosting company]] as a plural i.e. [[web hosting company | web > > hosting companies]]. > > > > The wiki allows forum posts to be massaged together into something > > meaningful. The phpwebsite community can help create the documentation > > so that the core developer's don't have to do it all. All we need is > > for the code to point to the wiki pages verses text files. I recommend > > the en_ prefix because then each localization will be grouped together > > on the all pages page > > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=3DSpecial:A= llpages > > I think the that this will help the users find the documentation. What > > they do now is install via text file; fail; forum post; then if I answe= r > > the post, I point 'em to the wiki page. Some samples > > https://sourceforge.net/forum/message.php?msg_id=3D3400102 and > > https://sourceforge.net/forum/message.php?msg_id=3D3398961 . See with = the > > new 1.x links they can point the the wiki page right away and start > > looking for the answer. Moreover, as I said in the Attribution on the > > FAQ page "Dr kludge would also like to thank firefox. It was through th= e > > Mozzilazine Knowledge Base (http://kb.mozillazine.org/Main_Page) that > > he was inspired to write FAQ questions that point back to specific > > areas of the wiki documentation. This technique saves having multiple > > places and sources of the same information and battle tests the > > documentation. The FAQ questions point to weaknesses in the main wiki > > documentation that need to be enhanced for there to be an effective > > answer to the question." > > > > Regards, > > Greg > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.1 (GNU/Linux) > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > > > iD8DBQFDaHUXxyxe5L6mr7IRAnA9AKCmbxc76eexlAJwBU0hCF5o3k7x6QCfXj3E > > KshzwLgBXkjG3pOpteE0aAw=3D > > =3DNoiz > > -----END PGP SIGNATURE----- > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. Dow= nload > > it for free - -and be entered to win a 42" plasma tv or your very own > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > Phpwebsite-developers mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- > Matthew McNaney > Electronic Student Services > Appalachian State University > http://phpwebsite.appstate.edu > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Downl= oad > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Matthew M. <ma...@tu...> - 2005-11-02 13:28:31
|
Ok Greg. I have had a night's sleep and have had coffee. My mind is clear and I understand. This is what I propose: A core class for help The config file for help contains the main wiki address The help class will create either a link to the wiki or push the user there automatically. The help class will add the localization prefix to the file name. We will go with en_filename (fr_filename, de_filename, etc.) This work for everyone? Thanks Greg, Matt On Wed, 2005-11-02 at 01:13 -0700, Greg Morgan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matt, > > Background: > As you asked I have posted a message here to continue the discussion > that we had today on IRC > http://www.phpwebsitemanual.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=103&date=20051101 > . As you point out " drkludge, that would be cool. however, there isn't > a wiki for 1.x yet :)" However, the idea will give you the 1.x pages to > link to. > > Fallout Seems Close: > I figured out that 1.x was really close when I created the fallout doc > page http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout > . So I sense the need to switch over to work on 1.x release. I > submitted an RFE for the secure_phpws.sh script here > https://sourceforge.net/tracker/index.php?func=detail&aid=1345623&group_id=15539&atid=315539 > . It still needs work but gets the job done for starters. The run > option may be flaky just 'cause I don't think I know all the files to > secure yet. Matt will be happy to receive additional patches to the script. > > The live linking to wiki page idea verses .txt files: > So how 'bout doc? Well I was thinking I want to leave the 0.10.x wiki > documentation alone. What I have been doing is creating content and > then point FAQ questions from the forums to the doc. You can see the > samples here > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User_FAQ . > I see that Matt has localization in the setup help files. This gave me > and idea for how 1.x and 0.10.x can co-exist. In the setup directory > are help files > pwd > /var/www/fallout2/setup/help > [root@bagheera help]# ls > database.en.txt permissions.en.txt sessions.en.txt > I have taken a bunch of these .txt files to seed the current wiki pages. > The problem with this is that the users only read the .txt and run into > the same problem over and over again in the forums. The .txt presume > that they have some prior knowledge that many do not have. So for this > release I'd rather have the .txt files put in the wiki and accessible to > the community to edit. The proposal then provides a mechanism to do > this and it will make the existing doc co-exist with the fallout doc. > > So for example there is a database page in the wiki that is 0.10.x > oriented. With a little work it can be 1.x oriented. If Matt where to > create a constant to the wiki URL of > "http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=" then > we're part way there. So now if I copy the > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=database > page to > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=en_database > then the fallout adjustments can be made. The existing database page > will work for the current 0.10.x users. The new en_database page would > be localized. Other languages would use the same page name but use > fr_database as their page name. In the 1.x documentation, I would use > the [[en_database | database]] convention each time I wanted to wiki > link to the page. I use this technique now when I want to refer to > [[web hosting company]] as a plural i.e. [[web hosting company | web > hosting companies]]. > > The wiki allows forum posts to be massaged together into something > meaningful. The phpwebsite community can help create the documentation > so that the core developer's don't have to do it all. All we need is > for the code to point to the wiki pages verses text files. I recommend > the en_ prefix because then each localization will be grouped together > on the all pages page > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Special:Allpages > I think the that this will help the users find the documentation. What > they do now is install via text file; fail; forum post; then if I answer > the post, I point 'em to the wiki page. Some samples > https://sourceforge.net/forum/message.php?msg_id=3400102 and > https://sourceforge.net/forum/message.php?msg_id=3398961 . See with the > new 1.x links they can point the the wiki page right away and start > looking for the answer. Moreover, as I said in the Attribution on the > FAQ page "Dr kludge would also like to thank firefox. It was through the > Mozzilazine Knowledge Base (http://kb.mozillazine.org/Main_Page) that > he was inspired to write FAQ questions that point back to specific > areas of the wiki documentation. This technique saves having multiple > places and sources of the same information and battle tests the > documentation. The FAQ questions point to weaknesses in the main wiki > documentation that need to be enhanced for there to be an effective > answer to the question." > > Regards, > Greg > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDaHUXxyxe5L6mr7IRAnA9AKCmbxc76eexlAJwBU0hCF5o3k7x6QCfXj3E > KshzwLgBXkjG3pOpteE0aAw= > =Noiz > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Greg M. <drk...@co...> - 2005-11-02 08:13:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt, Background: As you asked I have posted a message here to continue the discussion that we had today on IRC http://www.phpwebsitemanual.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=103&date=20051101 . As you point out " drkludge, that would be cool. however, there isn't a wiki for 1.x yet :)" However, the idea will give you the 1.x pages to link to. Fallout Seems Close: I figured out that 1.x was really close when I created the fallout doc page http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout . So I sense the need to switch over to work on 1.x release. I submitted an RFE for the secure_phpws.sh script here https://sourceforge.net/tracker/index.php?func=detail&aid=1345623&group_id=15539&atid=315539 . It still needs work but gets the job done for starters. The run option may be flaky just 'cause I don't think I know all the files to secure yet. Matt will be happy to receive additional patches to the script. The live linking to wiki page idea verses .txt files: So how 'bout doc? Well I was thinking I want to leave the 0.10.x wiki documentation alone. What I have been doing is creating content and then point FAQ questions from the forums to the doc. You can see the samples here http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=User_FAQ . I see that Matt has localization in the setup help files. This gave me and idea for how 1.x and 0.10.x can co-exist. In the setup directory are help files pwd /var/www/fallout2/setup/help [root@bagheera help]# ls database.en.txt permissions.en.txt sessions.en.txt I have taken a bunch of these .txt files to seed the current wiki pages. The problem with this is that the users only read the .txt and run into the same problem over and over again in the forums. The .txt presume that they have some prior knowledge that many do not have. So for this release I'd rather have the .txt files put in the wiki and accessible to the community to edit. The proposal then provides a mechanism to do this and it will make the existing doc co-exist with the fallout doc. So for example there is a database page in the wiki that is 0.10.x oriented. With a little work it can be 1.x oriented. If Matt where to create a constant to the wiki URL of "http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=" then we're part way there. So now if I copy the http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=database page to http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=en_database then the fallout adjustments can be made. The existing database page will work for the current 0.10.x users. The new en_database page would be localized. Other languages would use the same page name but use fr_database as their page name. In the 1.x documentation, I would use the [[en_database | database]] convention each time I wanted to wiki link to the page. I use this technique now when I want to refer to [[web hosting company]] as a plural i.e. [[web hosting company | web hosting companies]]. The wiki allows forum posts to be massaged together into something meaningful. The phpwebsite community can help create the documentation so that the core developer's don't have to do it all. All we need is for the code to point to the wiki pages verses text files. I recommend the en_ prefix because then each localization will be grouped together on the all pages page http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Special:Allpages I think the that this will help the users find the documentation. What they do now is install via text file; fail; forum post; then if I answer the post, I point 'em to the wiki page. Some samples https://sourceforge.net/forum/message.php?msg_id=3400102 and https://sourceforge.net/forum/message.php?msg_id=3398961 . See with the new 1.x links they can point the the wiki page right away and start looking for the answer. Moreover, as I said in the Attribution on the FAQ page "Dr kludge would also like to thank firefox. It was through the Mozzilazine Knowledge Base (http://kb.mozillazine.org/Main_Page) that he was inspired to write FAQ questions that point back to specific areas of the wiki documentation. This technique saves having multiple places and sources of the same information and battle tests the documentation. The FAQ questions point to weaknesses in the main wiki documentation that need to be enhanced for there to be an effective answer to the question." Regards, Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDaHUXxyxe5L6mr7IRAnA9AKCmbxc76eexlAJwBU0hCF5o3k7x6QCfXj3E KshzwLgBXkjG3pOpteE0aAw= =Noiz -----END PGP SIGNATURE----- |
|
From: Matthew M. <ma...@tu...> - 2005-10-31 12:50:27
|
You are awesome. :) Thank you very much. I hope to get a demo or beta release out this week but I have said that so many times it has lost all meaning :D Matt On Sun, 2005-10-30 at 23:45 -0700, Greg Morgan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matthew McNaney wrote: > > Greetings, > > > > We are easing into the use of 1.x (aka Fallout) here at the university. > > > > As the software becomes more robust, I am curious to how you guys and > > gals would like to see the software released. Here is how I see it: > > > > <snip> > > Matt, > > I tried the fallout installation. I left a trail of bread crumbs here > to encourage others to try out the 1.0.0 release. > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout > > Thanks. I can see you made lots of improvements to keep people from > installing too much at once. It's also nice that you have the log files > and multiple screens for errors to be tagged too. Perhaps the logs will > be more meaningful than having a screen name or number showing up too. > > Greg > > http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDZb1vxyxe5L6mr7IRAttHAJ9xlUj2Tt6dP4sKomEipB44tjwj+ACgjWxI > cctBEbgNbHGx9zgWwJd4jVI= > =VwxT > -----END PGP SIGNATURE----- > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Greg M. <drk...@co...> - 2005-10-31 06:45:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew McNaney wrote: > Greetings, > > We are easing into the use of 1.x (aka Fallout) here at the university. > > As the software becomes more robust, I am curious to how you guys and > gals would like to see the software released. Here is how I see it: > <snip> Matt, I tried the fallout installation. I left a trail of bread crumbs here to encourage others to try out the 1.0.0 release. http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout Thanks. I can see you made lots of improvements to keep people from installing too much at once. It's also nice that you have the log files and multiple screens for errors to be tagged too. Perhaps the logs will be more meaningful than having a screen name or number showing up too. Greg http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Fallout -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDZb1vxyxe5L6mr7IRAttHAJ9xlUj2Tt6dP4sKomEipB44tjwj+ACgjWxI cctBEbgNbHGx9zgWwJd4jVI= =VwxT -----END PGP SIGNATURE----- |
|
From: <re...@ki...> - 2005-10-17 21:06:12
|
This is a (text-only) retry. The version on the list got pretty messed =
up.
Sorry for that!
________________________________
Von: Ren=E9 C. Kiesler [mailto:re...@ki...]=20
Gesendet: Freitag, 14. Oktober 2005 23:27
An: 'php...@li...'
Betreff: mostly fixed the code-tag... (long)
Vertraulichkeit: Pers=F6nlich
...but at what price? I'm not sure and like to call for a discussion =
about
it.
=20
feed for example the following as a message-body to phpwsbb:
=20
[code] function parseInput($text, $allowedTags=3DNULL){
$text =3D PHPWS_Text::stripSlashQuotes($text);
=20
=20
if(preg_match("/src=3D([\"']{0,1}).*(?<=3D[=3D\"']\?|index.php|module=3D)=
.*([\"']{0,
1})/Ui", $text) ||
preg_match("/onload=3D/i", $text))
$text =3D preg_replace("/<img.+>/Uei", "", $text);
=20
if ($allowedTags =3D=3D "none")
$allowedTagString =3D NULL;
elseif (is_array($allowedTags))
$allowedTagString =3D implode("", $allowedTags);
elseif (is_string($allowedTags))
$allowedTagString =3D $allowedTags;
else {
$allowedTagString =3D $GLOBALS["core"]->text->allowed_tags;
/* If the user is allowed to use an extended set of tags, add them =
in
*/
if ($_SESSION['OBJ_user']->allow_access('users', 'extendedTags')) =
{
$allowedTagString .=3D =
$GLOBALS['core']->text->allowed_extra_tags;
/* Process all javascripted code to ensure comparison syntax
doesn't get stripped */
$text =3D preg_replace("/(<script.*>)(.*)(<\/script>)/iseU", =
"'\\1' .
str_replace('\n', '', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);
}
}
=20
$text =3D preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'\\1' .
str_replace('\n', '', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);
$text =3D str_replace("'", "'", $text);
=20
/* Deities don't get any tags stripped from their text */
if ($_SESSION['OBJ_user']->isDeity())
return $text;
=20
return strip_tags($text, $allowedTagString);
}
[/code]
=20
this should be pretty much the parseInput function after applying the =
super
hack.
=20
Note, that the code-tag should preserve everything literally. All the =
code,
all the line feeds, all the tags. Everything.
=20
I've created a test-thread with about the same content at
http://www.kiesler.at/phpwsbb~PHPWSBB_MAN_OP~view~PHPWS_MAN_ITEMS~508~pag=
e~l
ast.html
=20
I've enabled anonymous posts, feel free to play around with it.
=20
=20
=20
Here's the result:
=20
function parseInput($text, $allowedTags=3DNULL){ $text =3D
PHPWS_Text::stripSlashQuotes($text);
if(preg_match("/src=3D([\"']{0,1}).*(?<=3D[=3D\"']\?|index.php|module=3D)=
.*([\"']{0,
1})/Ui", $text) || preg_match("/onload=3D/i", $text)) $text =
=3D
preg_replace("//Uei", "", $text); if ($allowedTags =3D=3D "none")
$allowedTagString =3D NULL; elseif (is_array($allowedTags))
$allowedTagString =3D implode("", $allowedTags); elseif
(is_string($allowedTags)) $allowedTagString =3D $allowedTags; =
else {
$allowedTagString =3D $GLOBALS["core"]->text->allowed_tags; /* If =
the
user is allowed to use an extended set of tags, add them in */ if
($_SESSION['OBJ_user']->allow_access('users', 'extendedTags')) {
$allowedTagString .=3D $GLOBALS['core']->text->allowed_extra_tags; =
/*
Process all javascripted code to ensure comparison syntax doesn't get
stripped */ $text =3D
preg_replace("/(NOSCRIPT.*>)(.*)(<\/script>)/iseU", "'' . =
str_replace('\n',
'', PHPWS_Text::utfEncode('')) . ''", $text); } } $text =
=3D
preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'' . str_replace('\n', =
'',
PHPWS_Text::utfEncode('')) . ''", $text); $text =3D str_replace("'", =
"'",
$text); /* Deities don't get any tags stripped from their text */ =
if
($_SESSION['OBJ_user']->isDeity()) return $text; return
strip_tags($text, $allowedTagString); }=20
=20
=20
a beauty, isn't it?
=20
Note, that:
=20
- all the linefeeds are gone
- /(<script.*> got replaced by /(NOSCRIPT.*>
- \\1, \\2, etc. get removed alltogether -- without any replacement
- and probably a few other things, as I've already fixed the =
output-function
of the code-tag here.
=20
all of that happens in parseInput() of Text.php and in cleanArray() of
security.php.
=20
=20
=20
=20
=20
What I did to fix it (somewhat):
=20
in parseInput():
=20
- removed the line " $text =3D
preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'\\1' . =
str_replace('\n',
'', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);" to preserve =
linespaces
- removed "stripSlashQuotes"
=20
=20
in cleanArray():
=20
threw out all the preg_replaces and replaced them with a
htmlspecialchars_uni() that looks like this:
=20
function htmlspecialchars_uni($text) {
$text=3Dpreg_replace('/&(?!#[0-9]+;)/si', '&', $text);
return(str_replace(array('<', '>', '"'), array('<', '>',
'"'), $text));
}
that way, everything evil should be encoded but preserved. And do no =
harm,
right?
=20
I've also disabled the BBCode [code][/code] as it does nothing more but =
put
"<code></code>" around the text. This explains the formatting.
=20
Instead, I've used this in parseOutput(), which I've ported over from =
phpBB:
=20
=20
function parseOutput($text, $printTags=3DFALSE){
require_once("HTML/BBCodeParser.php");
=20
=20
=20
/* this algorithm has been brutally ripped out of phpBB */
=20
$match_count=3Dpreg_match_all("#\[code\](.*?)\[/code\]#si", =
$text,
$matches);
=20
$code_start_html=3D"<div class=3D'code_tag'>code:".
"<div>\n";
$code_end_html=3D"</div></div>\n";
=20
for($i=3D0; $i<$match_count; $i++) {
$before_replace=3D$after_replace=3D$matches[1][$i];
=20
$after_replace=3Dstr_replace(" ", " ", =
$after_replace);
$after_replace=3Dstr_replace(" ", " ", =
$after_replace);
=20
$after_replace=3Dstr_replace("<", "<", =
$after_replace);
$after_replace=3Dstr_replace(">", ">", =
$after_replace);
=20
$after_replace=3Dstr_replace("\t", " ",
$after_replace);
=20
$after_replace=3Dstr_replace("\n", "<br />\n",
$after_replace);
=20
$after_replace=3Dpreg_replace("/^ {1}/m", ' ',
$after_replace);
$str_to_match=3D"[code]".$before_replace."[/code]";
=20
=
$replacement=3D$code_start_html.$after_replace.$code_end_html;
=20
$text=3Dstr_replace($str_to_match, $replacement, $text);
}
=20
$text=3Dstr_replace("[code]", $code_start_html, $text);
$text=3Dstr_replace("[/code]", $code_end_html, $text);
=20
=20
=20
// Set up BBCodeParser
=20
/* WARNING !!
=20
you need to disable the code-tag in BBCodeParser.ini. Not =
doing
so
would result in a second iteration of code-tag-parsing. =
code-tags
within code-tags would be parsed which could result in =
uglyness.
*/
=20
$config =3D parse_ini_file(PHPWS_SOURCE_DIR . =
"/conf/BBCodeParser.ini",
true);
$options =3D &PEAR::getStaticProperty("HTML_BBCodeParser", =
"_options");
=20
=20
=20
=20
well, all of that fixes the display of the code-tag to a great extent. =
The
\\1, etc. are still eaten up though, maybe the template-classes are =
guilty
of that? They can be seen in the database. Also, the ' isn't =
preserved
literally but converted to a ' which is also bad. But it's a lot better =
now,
never the less.
=20
Did I open any security holes that haven't been there before? Any ideas =
how
to fix them? I'd really like to have a working code-tag but don't want =
to be
hacked again.
=20
vBulletin, InVision PowerBoard and phpBB can do it, so should we.
=20
=20
regards,
=20
Ren=E9!
|
|
From: Shaun M. <sh...@ae...> - 2005-10-17 14:59:40
|
In theory it should be fixed in the BB_Code PEAR classes rather than in phpWebSite though there may be some more work to be done in the core. I notice that there were some major changes to the PEAR class 3 days ago in CVS for the first time in 20 months. Mostly XHTML fixes. There's also some extremely nice code in the PEAR Text_Wiki parser such that it will colourize the output of different kinds of code so you can say [code=css] or [code=php] for instance and get sensible colours. That might be of some use. Rene, I'd vote against the <div class="code-tag"> from phpBB though. It should just use <code> otherwise you lose the semantics. If you want <code> restyled then restyle that in your css rather than create another class. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
|
From: <re...@ki...> - 2005-10-14 21:29:07
|
...but at what price? I'm not sure and like to call for a discussion =
about
it.
=20
feed for example the following as a message-body to phpwsbb:
=20
[code] function parseInput($text, $allowedTags=3DNULL){
$text =3D PHPWS_Text::stripSlashQuotes($text);
=20
=20
if(preg_match("/src=3D([\"']{0,1}).*(?<=3D[=3D\"']\?|index.php|module=3D)=
.*([\"']{0,
1})/Ui", $text) ||
preg_match("/onload=3D/i", $text))
$text =3D preg_replace("/<img.+>/Uei", "", $text);
=20
if ($allowedTags =3D=3D "none")
$allowedTagString =3D NULL;
elseif (is_array($allowedTags))
$allowedTagString =3D implode("", $allowedTags);
elseif (is_string($allowedTags))
$allowedTagString =3D $allowedTags;
else {
$allowedTagString =3D $GLOBALS["core"]->text->allowed_tags;
/* If the user is allowed to use an extended set of tags, add them =
in
*/
if ($_SESSION['OBJ_user']->allow_access('users', 'extendedTags')) =
{
$allowedTagString .=3D =
$GLOBALS['core']->text->allowed_extra_tags;
/* Process all javascripted code to ensure comparison syntax
doesn't get stripped */
$text =3D preg_replace("/(<script.*>)(.*)(<\/script>)/iseU", =
"'\\1' .
str_replace('\n', '', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);
}
}
=20
$text =3D preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'\\1' .
str_replace('\n', '', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);
$text =3D str_replace("'", "'", $text);
=20
/* Deities don't get any tags stripped from their text */
if ($_SESSION['OBJ_user']->isDeity())
return $text;
=20
return strip_tags($text, $allowedTagString);
}
[/code]
=20
this should be pretty much the parseInput function after applying the =
super
hack.
=20
Note, that the code-tag should preserve everything literally. All the =
code,
all the line feeds, all the tags. Everything.
=20
I've created a test-thread with about the same content at
http://www.kiesler.at/phpwsbb~PHPWSBB_MAN_OP~view~PHPWS_MAN_ITEMS~508~pag=
e~l
ast.html
=20
I've enabled anonymous posts, feel free to play around with it.
=20
=20
=20
Here's the result:
=20
function parseInput($text, $allowedTags=3DNULL){ $text =3D
PHPWS_Text::stripSlashQuotes($text);
if(preg_match("/src=3D([\"']{0,1}).*(?<=3D[=3D\"']\?|index.php|module=3D)=
.*([\"']{0,
1})/Ui", $text) || preg_match("/onload=3D/i", $text)) $text =
=3D
preg_replace("//Uei", "", $text); if ($allowedTags =3D=3D "none")
$allowedTagString =3D NULL; elseif (is_array($allowedTags))
$allowedTagString =3D implode("", $allowedTags); elseif
(is_string($allowedTags)) $allowedTagString =3D $allowedTags; =
else {
$allowedTagString =3D $GLOBALS["core"]->text->allowed_tags; /* If =
the
user is allowed to use an extended set of tags, add them in */ if
($_SESSION['OBJ_user']->allow_access('users', 'extendedTags')) {
$allowedTagString .=3D $GLOBALS['core']->text->allowed_extra_tags; =
/*
Process all javascripted code to ensure comparison syntax doesn't get
stripped */ $text =3D
preg_replace("/(NOSCRIPT.*>)(.*)(<\/script>)/iseU", "'' . =
str_replace('\n',
'', PHPWS_Text::utfEncode('')) . ''", $text); } } $text =
=3D
preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'' . str_replace('\n', =
'',
PHPWS_Text::utfEncode('')) . ''", $text); $text =3D str_replace("'", =
"'",
$text); /* Deities don't get any tags stripped from their text */ =
if
($_SESSION['OBJ_user']->isDeity()) return $text; return
strip_tags($text, $allowedTagString); }=20
=20
=20
a beauty, isn't it?
=20
Note, that:
=20
- all the linefeeds are gone
- /(<script.*> got replaced by /(NOSCRIPT.*>
- \\1, \\2, etc. get removed alltogether -- without any replacement
- and probably a few other things, as I've already fixed the =
output-function
of the code-tag here.
=20
all of that happens in parseInput() of Text.php and in cleanArray() of
security.php.
=20
=20
=20
=20
=20
What I did to fix it (somewhat):
=20
in parseInput():
=20
- removed the line " $text =3D
preg_replace("/(\[code\])(.*)(\[\/code\])/seU", "'\\1' . =
str_replace('\n',
'', PHPWS_Text::utfEncode('\\2')) . '\\3'", $text);" to preserve =
linespaces
- removed "stripSlashQuotes"
=20
=20
in cleanArray():
=20
threw out all the preg_replaces and replaced them with a
htmlspecialchars_uni() that looks like this:
=20
function htmlspecialchars_uni($text) {
$text=3Dpreg_replace('/&(?!#[0-9]+;)/si', '&', $text);
return(str_replace(array('<', '>', '"'), array('<', '>',
'"'), $text));
}
that way, everything evil should be encoded but preserved. And do no =
harm,
right?
=20
I've also disabled the BBCode [code][/code] as it does nothing more but =
put
"<code></code>" around the text. This explains the formatting.
=20
Instead, I've used this in parseOutput(), which I've ported over from =
phpBB:
=20
=20
function parseOutput($text, $printTags=3DFALSE){
require_once("HTML/BBCodeParser.php");
=20
=20
=20
/* this algorithm has been brutally ripped out of phpBB */
=20
$match_count=3Dpreg_match_all("#\[code\](.*?)\[/code\]#si", =
$text,
$matches);
=20
$code_start_html=3D"<div class=3D'code_tag'>code:".
"<div>\n";
$code_end_html=3D"</div></div>\n";
=20
for($i=3D0; $i<$match_count; $i++) {
$before_replace=3D$after_replace=3D$matches[1][$i];
=20
$after_replace=3Dstr_replace(" ", " ", =
$after_replace);
$after_replace=3Dstr_replace(" ", " ", =
$after_replace);
=20
$after_replace=3Dstr_replace("<", "<", =
$after_replace);
$after_replace=3Dstr_replace(">", ">", =
$after_replace);
=20
$after_replace=3Dstr_replace("\t", " ",
$after_replace);
=20
$after_replace=3Dstr_replace("\n", "<br />\n",
$after_replace);
=20
$after_replace=3Dpreg_replace("/^ {1}/m", ' ',
$after_replace);
$str_to_match=3D"[code]".$before_replace."[/code]";
=20
=
$replacement=3D$code_start_html.$after_replace.$code_end_html;
=20
$text=3Dstr_replace($str_to_match, $replacement, $text);
}
=20
$text=3Dstr_replace("[code]", $code_start_html, $text);
$text=3Dstr_replace("[/code]", $code_end_html, $text);
=20
=20
=20
// Set up BBCodeParser
=20
/* WARNING !!
=20
you need to disable the code-tag in BBCodeParser.ini. Not =
doing
so
would result in a second iteration of code-tag-parsing. =
code-tags
within code-tags would be parsed which could result in =
uglyness.
*/
=20
$config =3D parse_ini_file(PHPWS_SOURCE_DIR . =
"/conf/BBCodeParser.ini",
true);
$options =3D &PEAR::getStaticProperty("HTML_BBCodeParser", =
"_options");
=20
=20
=20
=20
well, all of that fixes the display of the code-tag to a great extent. =
The
\\1, etc. are still eaten up though, maybe the template-classes are =
guilty
of that? They can be seen in the database. Also, the ' isn't =
preserved
literally but converted to a ' which is also bad. But it's a lot better =
now,
never the less.
=20
Did I open any security holes that haven't been there before? Any ideas =
how
to fix them? I'd really like to have a working code-tag but don't want =
to be
hacked again.
=20
vBulletin, InVision PowerBoard and phpBB can do it, so should we.
=20
=20
regards,
=20
Ren=E9!
=20
|
|
From: David B. <byl...@ya...> - 2005-10-14 20:19:09
|
Check out my work on the skeleton module (now uses Manager and Item class and includes custom op and module settings. I've also written a simple code generator that reads a text file and writes custom modules based on the skeleton module. It's all at: http://scholarshipweb.sourceforge.net I'd welcome feedback and help on any aspect of this project. __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs |
|
From: Matthew M. <ma...@tu...> - 2005-10-12 17:01:17
|
Hello, A couple of our sites were tampered with today. The culprit was a weakness in 0.10.1. (some of our sites have not been updated). The hacker was able to get an admin password and brute force the hash. You can grab the security patch from: http://prdownloads.sourceforge.net/phpwebsite/phpwebsite_security_patch_20051202.tgz?download It contains an upgrade to security.php, Search.php, and Core.php. Basically the "module" variable was not getting parsed for foreign characters and injected directly into an SQL query. This was bad design on an older module. 0.10.2 contained code to prevent this, but you may want to install the patch anyway. If there are any problems with the patch, please reply to the list. If you are running 0.10.1, you will probably be safe if your password has mixed alphanumeric characters. We would still recommend changing your password after installing the patch. Thanks, phpWebSite Development Dudes -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Shaun M. <sh...@ae...> - 2005-10-12 12:11:34
|
That's what the create_temp() function does in layout/class/Box.php
I used that in an update to the announcement module to split the
view_small and view_full views from using the same content variable.
just call create_temp in update.php.
Yes it's a crap function name. One of the other modules did the same
in one of it's updates.
On 12 Oct 2005, at 13:00, Ken Nordquist wrote:
> Hey Everyone,
>
> I am putting the final touches on the v0.2.0 update to my Nakes module
> (Business / Organization Listings). I added a layout box so I could
> have a random business / organization show on the front page. This is
> not a problem for an original install, but was giving me problems with
> an update because there was no set way to update mod_layout_box.
> Following is the code which will do just that...
>
> And oddly enough, it works!
>
>
> **********
> $themeList = PHPWS_Layout::get_themes();
>
> foreach ($themeList as $theme){
> if(!$_SESSION["OBJ_layout"]->_addBox($theme, '*mod_title*',
> '*content_var*', '*theme_var*', 0)) {
> $status = 0;
> }
> }
>
> if (isset($_SESSION["OBJ_layout"])){
> $_SESSION["OBJ_layout"]->initializeLayout();
> $_SESSION["OBJ_layout"]->loadBoxInfo();
> }
> **********
>
> *mod_title*, *content_var*, and *theme_var* above are not literal,
> you will have to use variables or hard code the appropriate names.
> For my purposes, I hard coded mod_title, content_var, and theme_var.
>
> The next logical step would be to have a way to synchronize the box
> locations for all themes using a specific theme. For example, I
> just spent an hour or so arranging the boxes for one theme, then
> install a new theme and do not want to go through the process
> again... I can just synchronize the themes.
>
> HTH,
>
> Ken
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
>
Shaun
aegis design - http://www.aegisdesign.co.uk
aegis hosting - http://www.aegishosting.co.uk
|
|
From: Ken N. <ke...@co...> - 2005-10-12 12:00:29
|
Hey Everyone,
I am putting the final touches on the v0.2.0 update to my Nakes module
(Business / Organization Listings). I added a layout box so I could
have a random business / organization show on the front page. This is
not a problem for an original install, but was giving me problems with
an update because there was no set way to update mod_layout_box.
Following is the code which will do just that...
And oddly enough, it works!
**********
$themeList = PHPWS_Layout::get_themes();
foreach ($themeList as $theme){
if(!$_SESSION["OBJ_layout"]->_addBox($theme, '*mod_title*', '*content_var*', '*theme_var*', 0)) {
$status = 0;
}
}
if (isset($_SESSION["OBJ_layout"])){
$_SESSION["OBJ_layout"]->initializeLayout();
$_SESSION["OBJ_layout"]->loadBoxInfo();
}
**********
*mod_title*, *content_var*, and *theme_var* above are not literal, you will have to use variables or hard code the appropriate names. For my purposes, I hard coded mod_title, content_var, and theme_var.
The next logical step would be to have a way to synchronize the box locations for all themes using a specific theme. For example, I just spent an hour or so arranging the boxes for one theme, then install a new theme and do not want to go through the process again... I can just synchronize the themes.
HTH,
Ken
|
|
From: Verdon V. <ve...@ve...> - 2005-10-08 04:04:58
|
On 7-Oct-05, at 12:12 PM, Shaun Murray wrote: > Dance with the devil, get a pointy fork up your arse. LOL, Well put! But don't we all do it ;-) Seriously though, I do have some opinion too but have just made it home from a marathon trip to Toronto, finishing up with a 5 hour nasty drive home, so it'll have to wait til tomorrow. verdon |
|
From: Matthew M. <ma...@tu...> - 2005-10-07 17:20:20
|
Rene, > What do you think, any chances I can keep my URLs? I wouldn't mind an > additional (shorter!) URL-scheme, like described in an earlier mail. But I > need backwards-compatibility... There is a module in 1.x that allows you to alter your .htaccess files for reroutes. It also allows you to go to a page and create a shortcut to that page. The shortcut takes the form of 'some_name.html'. In short, we should be able to cover you. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Shaun M. <sh...@ae...> - 2005-10-07 16:12:57
|
On 7 Oct 2005, at 16:38, Ren=E9 C. Kiesler wrote: > > > Everything looks well to me. My personal main issue would be =20 > compatibility. > Not on an API level, but mainly on an URL level. > That's a good point. On established sites with forums and many pages, =20= there's lots and lots of embedded links in the content. It'll be a =20 major pain if we lose that. > I've got various URLs to my site all across the net. Some with "&" =20 > in them > (regular phpWebSite), some with "~" in them (Super Hack). And a lot =20= > with > articleXYZ.html. > Dance with the devil, get a pointy fork up your arse. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
|
From: <re...@ki...> - 2005-10-07 15:40:20
|
> Message: 1 > Date: Thu, 06 Oct 2005 10:46:07 -0400 > From: Matthew McNaney <ma...@tu...> > To: phpWebSite Developers > <php...@li...> > Organization: Appalachian State University > Subject: [Phpwebsite-developers] Easing into 1.x > Reply-To: php...@li... Hi Matt, > > - 1.x is released as a stand-alone product without backward > compatibility or branches > > - As software stabilizes, we begin testing with old modules. > > - Once old modules begin working, the branching capabilities are > written. > > - Final release announced to the general public containing all the > above. > > Does that meet with your approval? yes, absolutely > These are some things to ponder and I am interested in your > viewpoints. > I know Fallout has been in development for a loooooong time > and I appreciate everyone patiently (and not so patiently) > awaiting its release. I'd like this release to go smoothly. Everything looks well to me. My personal main issue would be compatibility. Not on an API level, but mainly on an URL level. I've got various URLs to my site all across the net. Some with "&" in them (regular phpWebSite), some with "~" in them (Super Hack). And a lot with articleXYZ.html. I have to support the URLs in one way or another. If they'd stop working, that would be a show-stopper for me. What do you think, any chances I can keep my URLs? I wouldn't mind an additional (shorter!) URL-scheme, like described in an earlier mail. But I need backwards-compatibility... thanks + keep up the good work, Rene! |
|
From: Shaun M. <sh...@ae...> - 2005-10-07 09:36:20
|
The 1.x roadmap seems fine (that's British for 'good'). I've got quite a few sites in production using branches and even a couple in development now so branches are crucial before I can even contemplate 1.x on some sites. And one set of sites is using Andrew Patterson's Single Sign On hack so that's going to be an interesting upgrade. I'm usually pretty conservative with hacks but I just needed that functionality. I'd voice again that we should be eating our own dog food so if there's any new forum then we should use phpwsBB and I'll volunteer for moderation duties if you need the extra help there. I'd also hope that that one module is where a lot of effort is made to keep compatibility as a lot of content gets shoved through forums. I don't think a conversion script will be ok here for many people so I'd imagine getting phpwsBB 1.03 (the latest) running on fallout with as few changes as need be for now would be the way forward, even if we have to drop stuff from phpwsBB that is problematic (eg. the avatar code). I don't know how far away we are with getting the wiki module functional enough that it takes over duties for the -comm wiki but that would be useful too. Perhaps Greg or Mike might like to say. Otherwise, giving the community more of a role than they've had in the past would seem to me to be crucial through this change. More reliance on -comm is good but I'd suggest we can go further once 1.0 has been hot-housed enough at appstate. Perhaps some of the in-house modules could be moved over to -comm for us to work on them rather than submitting patches. I'd also like to ask now what is to become of the 0.10.x code? Could this be released into the community now so that we can support that? CVS transferred to sourceforge? Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
|
From: Greg M. <drk...@co...> - 2005-10-07 06:52:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew McNaney wrote: > Greetings, > > We are easing into the use of 1.x (aka Fallout) here at the university. > > As the software becomes more robust, I am curious to how you guys and > gals would like to see the software released. Here is how I see it: > > - 1.x is released as a stand-alone product without backward > compatibility or branches By backward compatibility do you mean a conversion script? > > - As software stabilizes, we begin testing with old modules. Are you expecting most of the modules to break? > > - Once old modules begin working, the branching capabilities are > written. > > - Final release announced to the general public containing all the > above. I love transitional releases because you get the code out in user's hands and they start dreaming and seeing what can be done using the new code. > > Does that meet with your approval? > > My next question is when, where, and how should open bug and feature > requests? How should we handle documentation and at what point? Should > we open new forums in Sourceforge or have forums elsewhere until the > software is "legit"? I'd pick one place and stay with it. I do phpWebSite support as a hobby. The problem I see is that phpWebSite lends itself to everyone putting up their own support sign and trying to make a name for themselves. That's great because in the early 9x release is seemed like there weren't many options available. However, there is a balkanizing effect on the community. I'd use the SF forums or put up the phpBB at SF. However, the project won't get SF brownie points with phpBB but the dog food will taste oh so good. Get the users used to coming to one place for support. There's nothing wrong with putting up an Alpha forum. That will scare away many users. I also checked that both the forum name and description are modifiable for forums. So you can start off with alpha 1.x.x forums and rename them later to 1.x.x. You can have private forums but I am not sure how the work on SF. Your concerns are justified about the software being "legit" but you may rob the community of participating in the process or the excitement building up to the final release. Perhaps, bug days can be created like I have seen on other projects, etc. T-shirts can be won. The most bug reports triaged earn prizes, etc. > > Since this is a rebirth of code we have the opportunity to change how we > are handling things as well. Some issues: > These questions are entirely in the hands of the guy that looks in the mirror that wrote them. I think the school had a wonderful idea when they released phpWebSite under the GPL. The school benefited. The rest of the world benefited. The benevolent dictatorship has worked well but has slowed down the development process. Again looking at this from a hobbiest perspective, I don't understand why -comm had to exist at all!? I think all of -comm should be closed and moved to phpWebSite's project. Why can't the i18n, modules, and themes, the documentation wiki run under phpWebSite's SF project? These would be subprojects under phpWebsite. If you run this under -comm, then why would anyone want to go to phpWebSite-comm, when site x is just as good? Having these features under phpWebSite makes sense to me but it would appear that more people would have to be added to the phpWebSite SF project. There are controls in place to allow that level of participation. The proposal of leaving -comm or another location would continue the divisions in the community and make the phpWebSite community less effective than other communities such as drupal, etc. I think the examples of what Redhat did with Fedora and how the rest of the world responded with Open Suse, Open Solaris, etc shows how powerful growing the main phpWebSite community can be. I think one of the most illuminating quotes was this one on Distrowatch "...What its competitors can do right now is to learn from Ubuntu's success and incorporate some of the project's ideas into their own work. Building solid support infrastructure (user forums, mailing lists, Wikis, translation framework) with active participation of the distribution's developers absolutely essential for any project that intends to grow. Having a fixed release schedule and clearly stated support period (without changing them every few months) is equally important. It is amazing how many distributions neglect these two basic characteristics, then wonder why users start looking elsewhere! http://distrowatch.com/weekly.php?issue=20050404 > - How we handle i18n translation submissions (-comm cvs?) > - Decide upon a standard set of CSS rules > - Consolidate documentation in the -comm Wiki > > These are some things to ponder and I am interested in your viewpoints. > I know Fallout has been in development for a loooooong time and I > appreciate everyone patiently (and not so patiently) awaiting its > release. I'd like this release to go smoothly. > > Thanks, > Matt > > I am more concerned that the efforts of the community are diluted. Moving the work all under the phpWebSite project would hopefully focus the community. I'd say you have a chance to fix that with the 1.x.x release. Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDRhsdxyxe5L6mr7IRAisYAJwJldHL3T02T1UEsSaiAcxiOG45FQCfdo5g t1z2BT0/dK75i+uAK1g2AEk= =ZKHR -----END PGP SIGNATURE----- |
|
From: Matthew M. <ma...@tu...> - 2005-10-06 14:54:16
|
Greetings, We are easing into the use of 1.x (aka Fallout) here at the university. As the software becomes more robust, I am curious to how you guys and gals would like to see the software released. Here is how I see it: - 1.x is released as a stand-alone product without backward compatibility or branches - As software stabilizes, we begin testing with old modules. - Once old modules begin working, the branching capabilities are written. - Final release announced to the general public containing all the above. Does that meet with your approval? My next question is when, where, and how should open bug and feature requests? How should we handle documentation and at what point? Should we open new forums in Sourceforge or have forums elsewhere until the software is "legit"? Since this is a rebirth of code we have the opportunity to change how we are handling things as well. Some issues: - How we handle i18n translation submissions (-comm cvs?) - Decide upon a standard set of CSS rules - Consolidate documentation in the -comm Wiki These are some things to ponder and I am interested in your viewpoints. I know Fallout has been in development for a loooooong time and I appreciate everyone patiently (and not so patiently) awaiting its release. I'd like this release to go smoothly. Thanks, Matt -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Verdon V. <ve...@ve...> - 2005-10-05 10:33:56
|
Thanks Tony :) I was aware of your hacks, but didn't think to look there. Doh ! verdon On 5-Oct-05, at 1:33 AM, Ton en Anja Oosterhoff wrote: > Hi verdon, > I did the same search when making my category hacks for blockmaker and > menuman. > You can download them from www.oosterhoff.nu > For menuman the things you're looking for are in menuactions.php; for > blockmaker it's in runtime.php > > Regards, > Tony. > > -----Oorspronkelijk bericht----- > Van: php...@li... > [mailto:php...@li...] Namens > Verdon > Vaillancourt > Verzonden: woensdag 5 oktober 2005 1:23 > Aan: php...@li... > Onderwerp: [Phpwebsite-developers] Detecting categories > > hi all :) > > Has anyone worked out a simple/reliable method to detect the > category(s) of whatever content is currently being displayed in your > phpws site? > > I've come up with a few hacks that work in some mods and not in others, > and I've spent hours looking at the $_SESSION and $GLOBALS arrays for > something reliable, as well as the fatcat class files, but I haven't > been able to work out a bullet-proof method yet. All I'm really trying > to achieve is a way to capture the id of any fatcat categories the > curent content may belong to, in my theme.php file, so I can use this > variable. > > So far, I've been poking at things like this, just to see what'll > happen, but the results are pretty inconsistant... > > $cur_mod = $GLOBALS["core"]->requestModule; > $my_cats = $_SESSION["OBJ_fatcat"]->listModuleElements($cur_mod); > > foreach ($my_cats as $my_cat_title){ > $cat_title = $my_cat_title["title"]; > $cat_id = $_SESSION["OBJ_fatcat"]->getCatId($cat_title); > echo $cat_id . '<br />'; > echo $cat_title . '<br />'; > } > > Does anyone have any better ideas? > > Thanks, > verdon > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
|
From: Ton en A. O. <ton...@he...> - 2005-10-05 05:34:03
|
Hi verdon, I did the same search when making my category hacks for blockmaker and menuman. You can download them from www.oosterhoff.nu For menuman the things you're looking for are in menuactions.php; for blockmaker it's in runtime.php Regards, Tony. -----Oorspronkelijk bericht----- Van: php...@li... [mailto:php...@li...] Namens Verdon Vaillancourt Verzonden: woensdag 5 oktober 2005 1:23 Aan: php...@li... Onderwerp: [Phpwebsite-developers] Detecting categories hi all :) Has anyone worked out a simple/reliable method to detect the category(s) of whatever content is currently being displayed in your phpws site? I've come up with a few hacks that work in some mods and not in others, and I've spent hours looking at the $_SESSION and $GLOBALS arrays for something reliable, as well as the fatcat class files, but I haven't been able to work out a bullet-proof method yet. All I'm really trying to achieve is a way to capture the id of any fatcat categories the curent content may belong to, in my theme.php file, so I can use this variable. So far, I've been poking at things like this, just to see what'll happen, but the results are pretty inconsistant... $cur_mod = $GLOBALS["core"]->requestModule; $my_cats = $_SESSION["OBJ_fatcat"]->listModuleElements($cur_mod); foreach ($my_cats as $my_cat_title){ $cat_title = $my_cat_title["title"]; $cat_id = $_SESSION["OBJ_fatcat"]->getCatId($cat_title); echo $cat_id . '<br />'; echo $cat_title . '<br />'; } Does anyone have any better ideas? Thanks, verdon ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Phpwebsite-developers mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Greg M. <drk...@co...> - 2005-10-05 04:09:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the last few days I have been hacking on the wiki. I cleaned up some of the presentation. For example, please look at the sample of the Default theme's page. http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Default All of the themes that I knew of and had time to implement have the same look as the Default theme. There's more work to be done so no one should feel slighted. Here's a sample page without all the info http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Sharonica . In a similar fashion there's these sample pages for the modules http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Featuredphoto and http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Layout_Admin . The result of these changes are both a comprehensive theme catalog http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Third_Party_Themes and a comprehensive module catalog http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Third_Party_Modules . I am finding that many of the old contributions in either category have been lost. Also I don't know where all the current modules on SourceForge and other locations are located. Would ya'll please send any information to me or reply to this email? Likewise, I still have some more theme locations to churn through but any additional theme locations would be nice to know about too. I found that the 0.9.1 release has some themes that can be placed on phpWebSite-comm file release area. If php_net, php_net_green, and phptheme originally shipped with phpWebSite, then would there be any reason that they could not be put on the -comm release area? I still need to look through the other phpWebSite archives as they too may be hiding information. Anyone heard from phpgirl.com aka Spiggy? There's some interesting work she had that would be good for the wiki is she is willing to have it posted there. Speaking of layout, I also worked on the developer guide http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Developer_Guide . I ran into this question here http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Layout_System isn't there a limit to the number of boxes allowed in each section/sub-section? http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Layout_System#transfers.tpl I thought it was nine from memory but that doesn't sound right. Anyone know for sure what the number is of if there is a limit? When revising this page http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Modules I found that both RSS Feeds and phpBB were not included with the 0.10.2 release. Is that an oversight of the packaging or were they intentionally dropped? For now I removed them from the phpWebSite distribution list but I don't know if that is correct. Finally, many of the wiki pages were seeded by the readme.txt files that came with each module. The wiki pages are of sufficient quality now. At this point should there be another 0.10.x release before the 1.0.0 fallout release, I'd like to patch these text files. I'd like to put a URL to the corresponding wiki pages unless there's a reason I shouldn't do this. Please advise because if there is a planned release so that phpBB and RSS Feeds can be released with phpWebSite, then I'd like to have time to make all the changes. Regards, Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDQ1IExyxe5L6mr7IRAgjGAJ9+1bTolNRd00STTddqmXn74sp2vgCcCZmi G5aRPEoWIK83DPFO+cNaNOQ= =B5LE -----END PGP SIGNATURE----- |
|
From: Verdon V. <ve...@ve...> - 2005-10-04 23:22:48
|
hi all :)
Has anyone worked out a simple/reliable method to detect the
category(s) of whatever content is currently being displayed in your
phpws site?
I've come up with a few hacks that work in some mods and not in others,
and I've spent hours looking at the $_SESSION and $GLOBALS arrays for
something reliable, as well as the fatcat class files, but I haven't
been able to work out a bullet-proof method yet. All I'm really trying
to achieve is a way to capture the id of any fatcat categories the
curent content may belong to, in my theme.php file, so I can use this
variable.
So far, I've been poking at things like this, just to see what'll
happen, but the results are pretty inconsistant...
$cur_mod = $GLOBALS["core"]->requestModule;
$my_cats = $_SESSION["OBJ_fatcat"]->listModuleElements($cur_mod);
foreach ($my_cats as $my_cat_title){
$cat_title = $my_cat_title["title"];
$cat_id = $_SESSION["OBJ_fatcat"]->getCatId($cat_title);
echo $cat_id . '<br />';
echo $cat_title . '<br />';
}
Does anyone have any better ideas?
Thanks,
verdon
|
|
From: Matthew M. <ma...@tu...> - 2005-10-03 12:10:08
|
I need to keep this in mind for the university. Thanks Ken On Fri, 2005-09-30 at 21:24 -0400, Ken Nordquist wrote: > Hey Everyone, > > The second release candidate of the Classads module for phpWebsite is > ready. You can download here: > > http://geekystuff.net/files/classads-0.1.1rc2.tar.gz > > The Classads module is a phpWebsite module modeled after newspaper > classified ads. The structure is: Sections (parent) and Categories > (child). There is a central menu to select Sections without having to > move between screens. This also applies to the Classads records add / > edit function. The random classad function works, but the classads > block does not work yet. > > This is (hopefully) the last pre-final release. See BUGS_TODO.txt for a > partial list. > > Any and all feedback is solicited and welcomed. > -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Greg M. <drk...@co...> - 2005-10-02 23:25:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ken Nordquist wrote: > Hey Everyone, > > The second release candidate of the Classads module for phpWebsite is > ready. You can download here: > > http://geekystuff.net/files/classads-0.1.1rc2.tar.gz > > The Classads module is a phpWebsite module modeled after newspaper > classified ads. The structure is: Sections (parent) and Categories > (child). There is a central menu to select Sections without having to > move between screens. This also applies to the Classads records add / > edit function. The random classad function works, but the classads > block does not work yet. > > This is (hopefully) the last pre-final release. See BUGS_TODO.txt for a > partial list. > > Any and all feedback is solicited and welcomed. > Ken, Please let me know if there's some additional information that you wanted on these pages. Greg http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Third_Party_Modules#Third_Party_Modules_Released_Thorough_Other_Developers http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Classads http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Nakes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDPnlAxyxe5L6mr7IRAukoAJ93IA7XoTF4yTe3Yn5CSbeUJfBYhgCffYVl S1wL/kcGDZXGrvYLZMT50+s= =LJlA -----END PGP SIGNATURE----- |
5 messages has been excluded from this view by a project administrator.
