phpslash-devel Mailing List for phpSlash (Page 2)
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel — For developers of phpslash to communicate.
You can subscribe to this list here.
| 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: Joe S. <joe...@us...> - 2004-10-07 15:56:24
|
I've recently been porting applications to phpSlash and Back-End. If any of you are porting an application to phpSlash 0.8, speak up so we don't duplicate any efforts. If you have any questions, we can discuss it here or on IRC. There is hosting available on phpslashforge.org for any add-on to phpSlash or Back-End. Since almost the same requirements are needed to port applications to eGroupware, I'll be generating these downloads as well from the same codebase for some applications. The Coppermine module is the most tested. The phpBB module is being updated now. phorum5 needs authentication changes completed. There is no central list of modules, skins, etc. at the moment. If someone wants to add this to the website, good deal. Joe |
|
From: Joe S. <jo...@be...> - 2004-10-07 15:49:21
|
For users of eGroupware, you might find use for phpSlash inside eGroupware. You can download the module from sf.net: http://sourceforge.net/project/showfiles.php?group_id=10566&package_id=130606&release_id=269897 Joe |
|
From: Joe S. <joe...@us...> - 2004-10-07 15:44:57
|
Since email traffic has picked up, I thought a few more might be interested in this screenshot: http://www.php-slash.org/downloads/kcachegrind1.gif It was generated using Xdebug and kcachegrind. Here is another screenshot showing the profiler output: http://www.php-slash.org/downloads/kcachegrind2.gif Joe |
|
From: Joe S. <joe...@us...> - 2004-10-06 21:18:44
|
on 10/06/04 17:37 tobozo said the following: > Hi everyone > > I just typed the word 'slashSess' in google to see how many results it > returned, then found some modified versions of phpslash, some are 0.7 > based some are hybrid, and a few are 0.8, most of them have upload enabled. > Looking at those different mutations, I tried to access the login page > on a few sites I got from the google search results, using the well > known god/password access. > On most phpslash sites I got surprised by the fact God account it was > NOT disabled and password NOT changed... > > Because people stop to RTFM as soon as the phpSlash is up and running, > they miss the advice that tells them to delete the account, then it > becomes easy to get in any version (0.7x, 0.8x) by just collecting URL's > from google and give it a try. > good point. > Possible solution to fix this problem would be one of those : > - change the default admin username/pass before the next release of > phpSlash, and so on every next release > - generate default admin/username during the setup.php process using > random chars > - prompt user for renaming 'god' and changing pass once setup is complete > I had been thinking about the user entering their username and password in the install wizard and replacing the god/password user with it. Joe > Eventually add some helpers to the login/session core : > - display a warning on every page until one of the previous possible > solutions is applied (eg. phpMyAdmin displays a red warning when > connected to a database with blank password) These type of things are pretty simple to add now to add now. Look at these blocks brought from Back-End: http://cvs.sourceforge.net/viewcvs.py/phpslash/phpslash-dev/include/modules/admin/ They can be deleted at any time by the administrator too. later, Joe > - add password strenght tests and notification for all users (existing, > add, update) > > > be well > tobozo > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel |
|
From: tobozo <to...@ma...> - 2004-10-06 20:32:45
|
Hi everyone I just typed the word 'slashSess' in google to see how many results it returned, then found some modified versions of phpslash, some are 0.7 based some are hybrid, and a few are 0.8, most of them have upload enabled. Looking at those different mutations, I tried to access the login page on a few sites I got from the google search results, using the well known god/password access. On most phpslash sites I got surprised by the fact God account it was NOT disabled and password NOT changed... Because people stop to RTFM as soon as the phpSlash is up and running, they miss the advice that tells them to delete the account, then it becomes easy to get in any version (0.7x, 0.8x) by just collecting URL's from google and give it a try. Possible solution to fix this problem would be one of those : - change the default admin username/pass before the next release of phpSlash, and so on every next release - generate default admin/username during the setup.php process using random chars - prompt user for renaming 'god' and changing pass once setup is complete Eventually add some helpers to the login/session core : - display a warning on every page until one of the previous possible solutions is applied (eg. phpMyAdmin displays a red warning when connected to a database with blank password) - add password strenght tests and notification for all users (existing, add, update) be well tobozo |
|
From: Luis M <le...@gm...> - 2004-10-06 05:29:04
|
Sorry i use the term "addstory" instead of "newstory" (from
Story_admin.class). But in any case, you need to use "savestory" from
Story_base.class (include/modules/story directory). Essentially, you
could simply do:
Starting from line 676, these are the variables you will need in an $array:
$q = "INSERT INTO psl_story
(story_id,
user_id,
title,
order_no,
dept,
intro_text,
body_text,
date_available,
hits,
topic_cache,
story_options)
VALUES ('$ary[story_id]',
'$ary[author_id]',
'$ary[title]',
'$ary[order_no]',
'$ary[dept]',
'$ary[intro_text]',
'$ary[body_text]',
$ary[timestamp],
'0',
'',
'$serial_opts')";
// debug("Story_base::saveStory: insert query",$q);
$this->db->query($q);
$cmtcount = "INSERT INTO psl_commentcount
(count_id,
count)
VALUES ('$ary[story_id]',
0)";
...
The psl documentation for developers could help you further. I know
there is a link for it in php-slash.org, but I don't recall it. In any
case, there is a .sgml file inside the "doc" directory that contains
the information you need.
On Wed, 06 Oct 2004 01:11:16 -0400, Matt Wiseman <tro...@sh...> wrote:
> You got any documentation on the addstory() call?
>
>
> On Tue, 2004-10-05 at 09:28, Luis M wrote:
> > >I'm running the latest version of slash and am trying to import stories
> > >from another system into it.
> > >I can pull stories no problem, but if I just insert them into
> > >psl_stories everything breaks. What's the proper way for me to do this?
--
----)(-----
Luis M
System Administrator
LatinoMixed.com
"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb
No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html
|
|
From: Matt W. <tro...@sh...> - 2004-10-06 05:10:09
|
You got any documentation on the addstory() call? On Tue, 2004-10-05 at 09:28, Luis M wrote: > >I'm running the latest version of slash and am trying to import stories > >from another system into it. > >I can pull stories no problem, but if I just insert them into > >psl_stories everything breaks. What's the proper way for me to do this? > > > >-- > >Matt "TrollBoy" Wiseman > > You might have to check the form for creating new stories and see what > fields are required for every story. Then write you own script that use the > addstory() call from the classes ;-) > > Joe can correct me on this, but there are many variables that need to be > set/modified/increased when a new story is added. So, instead of trying to > write to the db directly, you are better off trying to use a PHP script > (from the command line maybe) that does this for you using the existing API. > > ----)(----- > Luis Mondesi > System Administrator > LatinoMixed.com > > "We think basically you watch television to turn your brain off, and you > work on your computer when you want to turn your brain on" -- Steve Jobs in > an interview for MacWorld Magazine 2004-Feb > > No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel > > |
|
From: Luis M <le...@ho...> - 2004-10-05 13:49:58
|
>I'm running the latest version of slash and am trying to import stories >from another system into it. >I can pull stories no problem, but if I just insert them into >psl_stories everything breaks. What's the proper way for me to do this? > >-- >Matt "TrollBoy" Wiseman You might have to check the form for creating new stories and see what fields are required for every story. Then write you own script that use the addstory() call from the classes ;-) Joe can correct me on this, but there are many variables that need to be set/modified/increased when a new story is added. So, instead of trying to write to the db directly, you are better off trying to use a PHP script (from the command line maybe) that does this for you using the existing API. ----)(----- Luis Mondesi System Administrator LatinoMixed.com "We think basically you watch television to turn your brain off, and you work on your computer when you want to turn your brain on" -- Steve Jobs in an interview for MacWorld Magazine 2004-Feb No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html |
|
From: Matt W. <tro...@sh...> - 2004-10-05 06:22:45
|
I'm running the latest version of slash and am trying to import stories from another system into it. I can pull stories no problem, but if I just insert them into psl_stories everything breaks. What's the proper way for me to do this? -- Matt "TrollBoy" Wiseman ------------------------- WebMaster: Shoggoth.net WebMonkey: Chaosium.com All around weirdo |
|
From: Joe S. <joe...@us...> - 2004-10-01 12:47:22
|
Where should an implementation of FCKeditor reside? Should it be alongside htmlarea3 in the sf.net cvs? Or instead be released separately on phpslashforge? FCKeditor has some nice built-in features such as cleanup Windows pasting. I have it ready to be committed. There is a problem with two textareas on the same page that could use more eyes. It may just be a FCKeditor bug with this type implementation. Joe |
|
From: Joe S. <joe...@us...> - 2004-09-29 14:28:27
|
Spurred on some by Mike Gifford I installed the php5 packages from dotdeb.org. Here are the results of my initial test: 1. The Story_base.class had one line that needed to check that an array was a string or an array. php5 throws a fatal error if a string is used as an array. php4 did not. 2. The calendar block ( or likely any block with dynamic titles) requires compatibility mode on. Changing the title to a text string allows the compatibility mode off. 3. mmcache broke it all completely. Don't know if it the packaging for php5 or the use as a PECL module instead of Zend extension. Didn't test any further. Hope this helps some. Joe |
|
From: Joe S. <joe...@us...> - 2004-09-27 14:41:06
|
on 09/18/04 06:39 Joe Stewart said the following: > On Sat, Sep 18, 2004 at 10:45:30AM +0100, Peter Cruickshank wrote: > >>On Thu, 16 Sep 2004 12:41:57 -0500 >>Joe Stewart <joe...@us...> wrote: >> >> <snip> > > >>I've got other CSS files that can be applied to ShankZen's templates. >>Would you be interested? How would they be included in a distribution? >> > > > Good question. > > At the very least - > > create a ShankZen directory in the styles ( like BE_Default) > put all your stylesheets there. > Put them in the header so that they can be chosen in the browser. > Well I didn't know that the stylesheet chooser had been removed from Firefox. It is nice to be able to choose from a list of stylesheets the designer makes available. Hopefully there will be an extension soon or the bugs fixed and it return. > This would get them included and show they could be used in the header template as > needed. > I'm bringing in a bunch of tiki templates much the same way. I think we can add a CSS tag and check if it is available. If not, stuff it with the SKIN name. What do you think? Joe |
|
From: Joe S. <joe...@us...> - 2004-09-20 11:38:19
|
On Sun, Sep 19, 2004 at 07:59:09PM +0100, Peter Cruickshank wrote: > On the phpslash-dev CVS, the output of find -iname '*auth*' currently > includes: > > ./class/authtypes/slashAuthCR.class > ./class/slashAuth.class > ./class/slashAuthLDAP.class > ./modules/auth/slashAuth.class > I started moving it all to the auth module directory: ./auth ./auth/authtypes ./auth/authtypes/slashAuthCR.class ./auth/authtypes/slashAuthLDAP.class ./auth/authtypes/slashAuth.class ./auth/slashAuth.class but haven't deleted anything in the class directory yet. I've been concentrating on getting my changes stable first. They should all be done except the login and reg forms still are generated in the class. The login page code has been moved to the auth directory. The regular login form has been updated. This will allow other auth methods, like LDAP, PAM, email, etc to use the password entered. I've got untested PAM and HTTP auth methods as well as a skeleton example. Should I go ahead and commit them? > Perhaps a little tidying up is still required - I'd have thought that > slashAuthCR.class and slashAuthLDAP.class should be in the same place, at > least? And we probably only need one slashAuth.class... > Mostly done except for the deletions. Joe > P > |
|
From: Peter C. <pe...@cr...> - 2004-09-19 18:48:57
|
On the phpslash-dev CVS, the output of find -iname '*auth*' currently includes: ./class/authtypes/slashAuthCR.class ./class/slashAuth.class ./class/slashAuthLDAP.class ./modules/auth/slashAuth.class Perhaps a little tidying up is still required - I'd have thought that slashAuthCR.class and slashAuthLDAP.class should be in the same place, at least? And we probably only need one slashAuth.class... P |
|
From: Joe S. <joe...@us...> - 2004-09-18 12:12:18
|
On Sat, Sep 18, 2004 at 10:45:50AM +0100, Peter Cruickshank wrote: > I split of my 0.9 thoughts because there seem to be a lot of them... > > On Thu, 16 Sep 2004 12:41:57 -0500 > Joe Stewart <joe...@us...> wrote: > > > For psl 0.9: > > > > Not an exhaustive list or even looking at the current Roadmap. > > > > bring as much that BE has developed into psl as needed. > > - subsections > Yes!! > I'm not sure about implementing exactly the same, but this feature is sorely needed. > > - sitemap > > > - subsites > How often would this be needed? Back-End might be more suitable solution > for sites that are big enough to need subsites. > good point. Just throwing stuff out. > > > - what else? > - pagination - I can't believe I forgot this one. - user page redesign - I like the author list in BE. > A thought: Allow for switching CSS while keeping the same skin without > using a dummy template directory + skin.ini > That is the current method. A css switcher block would be nice. > > Move old stuff like glossary, etc. out of the core? > > Makes sense. Having said that, space is probably not an issue. So maybe > just have glossary etc turned off by default. > Will do that for now. I don't think many people actually put it to good use. With all the skins we are at about 2 meg. Adding phplist makes it about 3meg. > > How much should be released with the core? > > > > Move the templates to a subdirectory of the module. This is supported > > now. But I'd like to get 0.8 out first. > > Makes sense > > > module install, register, update, remove method - including db setup, > > other required modules and version(s) required. > > Definitely. > > > Navbar administration? - This shouldn't be too bad. We can generate the > > navbars once per session/authentication cycle couldn't we? > > Definitely too. The current menu-config setup is not end-user friendly at > all... > I've been looking at tiki's menu admin - pretty nice. > > > Oh, enough for now. > > Here's my initial thoughts: > > PSL does a lot, but in a lot of places it's really ugly, and there's a lot > of legacy code lurking around. I think a lot of the work in the 0.9 cycle > should be focussed not on adding new features (PSL has already got a lot), > but making existing features more accessible/ understandable. > I get surprised sometimes seeing some of the legacy code. > Areas could include: > > A. Improvements to interface/interaction > Interface cleanup and/or redesign, particularly around block and section > administration (it should be possible to position blocks from the section > admin screen). > > Seagull (http://seagull.phpkitchen.com/) seems to have put a lot of thought > into their UI - with the result that a less functional application- > framework looks like it can do more than PSL. > > We may have to find some design type person to take some of this on. > > > B. Updated user documentation > Back-End's wiki manual has worked well (http://manual.back-end.org/) - > maybe we could do the same with phpSlash? > ah. I didn't see this before my other response. I installed a wiki already on php-slash.org but don't have much experience. > Good, clear instructions on troubleshooting the installation of a new > module should be a high priority! > I guess that might be me (: > > C. Cleaning up code > It would be nice to separate the data access, presentation and business > logic more consistently. From my experience with Back-End, it would be good > to do this *before* adding in new features like subsites and > multi-lingualness. > Thanks for bringing this up. eGroupware has this architecture. They use ui, bo, and db as there separation. dcl uses almost the same nomenclature. I'll probably add this to sf.net RFE pronto. > (Moving to a compiling/caching template system like smarty or Flexy might > be worth thinking about). > maybe so. Anyone seen any recent benchmarks? The last I saw still showed phplib templates faster. Curious if the phplib templates in PEAR bear this out as well. > There's a fair bit of duplicated code lurking around too (eg compare > Story::getStory() and Story::getStories()). Other stuff that comes to mind > are adding common datetime handling throughout the code (could be lifted > from Back-End) > > While we're at it, we could add consistent phpDoc comments, and make the > output available online somewhere. > I used to generate this and make it available. Here is the link for -ft: http://www.php-slash.org/phpdoc/phpslash-ft/ > And finally, there's XHTML compliant templates (and documentation of the > classes that are used - I've made a start on this but there's nowhere to > put that right now - see below) > > > > D. Move to PEAR (controversial?) > phplib provides a stable codebase, but development has pretty well stopped. > I have a feeling that it will make sense (at some point in the future - > possibly before PHP5 becomes the standard) to move to using PEAR db, > template and security handling at some point. On the other hand, if it > ain't broke... > I'm torn on this. I've found some versioning issues with PEAR. It's nice for us including phplib now. There has been talk of rewriting parts of phplib for php5 support. > > > Maybe we can discuss this on irc as well. > > Good idea. I'd like to participate, timezones permitting. > You don't seem to sleep anyway. Joe > Peter > |
|
From: Joe S. <joe...@us...> - 2004-09-18 11:39:53
|
On Sat, Sep 18, 2004 at 10:45:30AM +0100, Peter Cruickshank wrote: > On Thu, 16 Sep 2004 12:41:57 -0500 > Joe Stewart <joe...@us...> wrote: > > > phpSlash is not dead, maybe moving slow, but not dead. The Back-End > > folks, led by Mike Gifford have been making lots of progress. > > > > The psl 0.8 release cycle is about to speed up. I'm planning on another > > beta test, then when that proves fairly stable, get a release candidate > > out. I do not want a long release cycle on this. Most everything here > > has been proven. > > I've been using the alpha code for a while on a couple of sites with no > major problems. > me too. php-slash.org is now on the latest -dev snapshot release. I kinda hope the Wiki will turn into something similar to http://manual.back-end.org. I do like the current manual configuration on the site to allow comments, etc. We can even open up editing privileges to be available publicly like a wiki. Our rollback is cvs. > > I'd like to update the phpSlash Roadmap to be something that we can work > > toward. > > Excellent! I've split my thoughts on 0.9 into a separate email > > > For psl 0.8: > > > > - needs a printer css or printer friendly view. > Yup > > - the wap article pages are not available anymore either. > How much is this used - is this a show-stopper? > not a big problem to me. > > Both of these could be added back using the old code, but I'd like to > > see them improved. > > > > - I'd like to see someone familiar with phplist to configure it for a > > default setup to mimic our current headline mailer. Then we could just > > drop the current code. The phplist module is included in the current > > beta.- there is a css issue in the phplist admin page I haven't debugged. > > phpList might be a excessive for the situation where there are only a few > people signing up, and only basic functionality is required. Just a > thought. > Probably true. My concern is maintaing the existing code. If our efforts are to maintain a phplist module instead, it seems to be a better use of resources. > > - What skins should be included in the main download? > > - What modules should be included? > The ones I think it might sense to drop/turn off are glossary and poll. > comment might also be optional, but it's still hardwired in places in the > code, so we're stuck with it for now. > glossary is the one in particular I had in mind. The comments are almost to the point there could be other software used for this too. The Comments code is getting pretty long in the tooth. Ajay worked on the Comments and Poll. No one has adopted them since he moved on. > If some modules are NOT included, there needs to be some pretty clear > instructions on how to download them and add them. > This is true across the board. > > - Anything else? > > I wonder if this is a good point to create a new default database? > Yes. I've been thinking of splitting it out to two sql files - one core and one example data. > As for skins, I clearly have a bias towards ShankZen! But it would be good > to move to consistent use of style names. eg Where ShankZen uses > "psl-desc", basic uses "desc". I think the "psl-" prefix is good, because > it avoids namespace clashes with external modules... I'd be happy to update > basic if you agree. > a volunteer! great! How about a printer css? Most of the skins that I ported kept all their style names instead of conforming to your convention. > ShankZen's stylesheets could probably be simplified a little; again, I'd be > happy to do this. > There is an issue with the ShankZend htmlarea3 and one of the stylesheets now I think. This may have been resolved. > I've got other CSS files that can be applied to ShankZen's templates. > Would you be interested? How would they be included in a distribution? > Good question. At the very least - create a ShankZen directory in the styles ( like BE_Default) put all your stylesheets there. Put them in the header so that they can be chosen in the browser. This would get them included and show they could be used in the header template as needed. thanks, Joe > P > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel |
|
From: Peter C. <pe...@cr...> - 2004-09-18 09:35:33
|
I split of my 0.9 thoughts because there seem to be a lot of them... On Thu, 16 Sep 2004 12:41:57 -0500 Joe Stewart <joe...@us...> wrote: > For psl 0.9: > > Not an exhaustive list or even looking at the current Roadmap. > > bring as much that BE has developed into psl as needed. > - subsections Yes!! > - sitemap > - subsites How often would this be needed? Back-End might be more suitable solution for sites that are big enough to need subsites. > - block caches > - trackback > - multi language > - what else? A thought: Allow for switching CSS while keeping the same skin without using a dummy template directory + skin.ini > Move old stuff like glossary, etc. out of the core? Makes sense. Having said that, space is probably not an issue. So maybe just have glossary etc turned off by default. > How much should be released with the core? > > Move the templates to a subdirectory of the module. This is supported > now. But I'd like to get 0.8 out first. Makes sense > module install, register, update, remove method - including db setup, > other required modules and version(s) required. Definitely. > Navbar administration? - This shouldn't be too bad. We can generate the > navbars once per session/authentication cycle couldn't we? Definitely too. The current menu-config setup is not end-user friendly at all... > Oh, enough for now. Here's my initial thoughts: PSL does a lot, but in a lot of places it's really ugly, and there's a lot of legacy code lurking around. I think a lot of the work in the 0.9 cycle should be focussed not on adding new features (PSL has already got a lot), but making existing features more accessible/ understandable. Areas could include: A. Improvements to interface/interaction Interface cleanup and/or redesign, particularly around block and section administration (it should be possible to position blocks from the section admin screen). Seagull (http://seagull.phpkitchen.com/) seems to have put a lot of thought into their UI - with the result that a less functional application- framework looks like it can do more than PSL. We may have to find some design type person to take some of this on. B. Updated user documentation Back-End's wiki manual has worked well (http://manual.back-end.org/) - maybe we could do the same with phpSlash? Good, clear instructions on troubleshooting the installation of a new module should be a high priority! C. Cleaning up code It would be nice to separate the data access, presentation and business logic more consistently. From my experience with Back-End, it would be good to do this *before* adding in new features like subsites and multi-lingualness. (Moving to a compiling/caching template system like smarty or Flexy might be worth thinking about). There's a fair bit of duplicated code lurking around too (eg compare Story::getStory() and Story::getStories()). Other stuff that comes to mind are adding common datetime handling throughout the code (could be lifted from Back-End) While we're at it, we could add consistent phpDoc comments, and make the output available online somewhere. And finally, there's XHTML compliant templates (and documentation of the classes that are used - I've made a start on this but there's nowhere to put that right now - see below) D. Move to PEAR (controversial?) phplib provides a stable codebase, but development has pretty well stopped. I have a feeling that it will make sense (at some point in the future - possibly before PHP5 becomes the standard) to move to using PEAR db, template and security handling at some point. On the other hand, if it ain't broke... > Maybe we can discuss this on irc as well. Good idea. I'd like to participate, timezones permitting. Peter |
|
From: Peter C. <li...@cr...> - 2004-09-18 09:35:13
|
On Thu, 16 Sep 2004 12:41:57 -0500 Joe Stewart <joe...@us...> wrote: > phpSlash is not dead, maybe moving slow, but not dead. The Back-End > folks, led by Mike Gifford have been making lots of progress. > > The psl 0.8 release cycle is about to speed up. I'm planning on another > beta test, then when that proves fairly stable, get a release candidate > out. I do not want a long release cycle on this. Most everything here > has been proven. I've been using the alpha code for a while on a couple of sites with no major problems. > I'd like to update the phpSlash Roadmap to be something that we can work > toward. Excellent! I've split my thoughts on 0.9 into a separate email > For psl 0.8: > > - needs a printer css or printer friendly view. Yup > - the wap article pages are not available anymore either. How much is this used - is this a show-stopper? > Both of these could be added back using the old code, but I'd like to > see them improved. > > - I'd like to see someone familiar with phplist to configure it for a > default setup to mimic our current headline mailer. Then we could just > drop the current code. The phplist module is included in the current > beta.- there is a css issue in the phplist admin page I haven't debugged. phpList might be a excessive for the situation where there are only a few people signing up, and only basic functionality is required. Just a thought. > - What skins should be included in the main download? > - What modules should be included? The ones I think it might sense to drop/turn off are glossary and poll. comment might also be optional, but it's still hardwired in places in the code, so we're stuck with it for now. If some modules are NOT included, there needs to be some pretty clear instructions on how to download them and add them. > - Anything else? I wonder if this is a good point to create a new default database? As for skins, I clearly have a bias towards ShankZen! But it would be good to move to consistent use of style names. eg Where ShankZen uses "psl-desc", basic uses "desc". I think the "psl-" prefix is good, because it avoids namespace clashes with external modules... I'd be happy to update basic if you agree. ShankZen's stylesheets could probably be simplified a little; again, I'd be happy to do this. I've got other CSS files that can be applied to ShankZen's templates. Would you be interested? How would they be included in a distribution? P |
|
From: Mike G. <mi...@op...> - 2004-09-17 14:41:18
|
Hello Joe, On Thu, 2004-09-16 at 13:25, Joe Stewart wrote: > This message is crossposted to the Back-End developers and phpSlash > developers. Good to be working with the psl team.. > I'd like to get an IRC discussion going on what developments need to be > done to make BE/PSL more scalable and easier to deploy in a larger > website installation. Sounds very cool.. > While I'm not saying we should get away from the easy to install, easy > to deploy on a hosted account ideas, there is also a need for being able > to use the code on sites serving lots of page views from multiple servers. scalability is from the tiny sites to the massive ones, right? There are a few projects that we've worked with that have helped test and improve the scalability of BE. > I'd like to do this on IRC to get more of a real time discussion going. > Is there a good time for everyone? But I'm not opposed to discussion > here as well. Well, I'm usually pretty flexible.. But during the week 9am-4pm EST is usually the best.. I'll try to check into irc more often.. It can be a good way to keep abreast.. > This may seem a little soon in the next phpSlash release cycle for this > discussion, but after this is done, I'd like to get another discussion > on a more general roadmap for BE and PSL. Sounds very good.. Would be great if there was an instance of them running together even.. But since they share so much code having more communication is pretty critical.. > A couple of my ideas to throw out: Good to do.. > High Traffic Discussion > - Load Balancing front end So how does this differ from sticking squid in front of the server? > - db clustering, master/slave, read servers and write servers, etc. There was a good article in php-a this summer about MySQL's master-slave capacity, but I have yet to explore it.. Sounds like an excellent way to extend the code. > - memcache support in db reads, writes, html cacheing, etc. Explored this a bit more.. BE uses jpcache for page caching (Thanks Joe) and also another fragment caching app for storing arrays and html fragments (Thanks PeterC).. > - static file writing to support staging, pushing to multiple servers, > ease of serving, speed, etc. Having that capacity would be pretty cool indeed.. Are there other open source php/mysql apps we can draw on for this? Or is this beyond what's possible within a php/mysql environment.. We're talking multiple servers here so its safe to assume that other tools are available.. > - squid reverse proxy front end. > - Ian's block cacheing It's cool.. Certainly for the user level caching.. > - using a separate image server with thttpd or somebody like akamai This app here I assume: http://www.acme.com/software/thttpd/ I haven't actually wondered there before, but it looks hopeful.. Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://www.openconcept.ca Our Client's Election Sites: http://rantroom.ca http://election.cupe.ca http://fairvotecanada.org http://billblaikie.ca http://dickproctor.ca http://patmartin.ca http://brianmasse.ca ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Back-end-development mailing list Bac...@li... https://lists.sourceforge.net/lists/listinfo/back-end-development |
|
From: Joe S. <joe...@us...> - 2004-09-17 14:40:37
|
on 09/16/04 20:26 Mike Gifford said the following: > Hello Joe, > > On Thu, 2004-09-16 at 13:25, Joe Stewart wrote: > >>This message is crossposted to the Back-End developers and phpSlash >>developers. > > <snip> > > scalability is from the tiny sites to the massive ones, right? > Mostly my concerns are that both high daily traffic and traffic spikes can be handled. > There are a few projects that we've worked with that have helped test > and improve the scalability of BE. > > >>I'd like to do this on IRC to get more of a real time discussion going. >> Is there a good time for everyone? But I'm not opposed to discussion >>here as well. > > > Well, I'm usually pretty flexible.. But during the week 9am-4pm EST is > usually the best.. I'll try to check into irc more often.. It can be a > good way to keep abreast.. > That's pretty close to when I'm around too. As far as when, I don't care at all. I'd just like to keep the ball rolling. So it could definitely wait a week for Ian to return. > >>This may seem a little soon in the next phpSlash release cycle for this >>discussion, but after this is done, I'd like to get another discussion >>on a more general roadmap for BE and PSL. > > > Sounds very good.. Would be great if there was an instance of them > running together even.. But since they share so much code having more > communication is pretty critical.. > > >>A couple of my ideas to throw out: > > > Good to do.. > > >>High Traffic Discussion >>- Load Balancing front end > > > So how does this differ from sticking squid in front of the server? > When I think of sticking squid in front, it's more about using it as a transparent caching proxy. And I think of load balancer more for High Availability failover, and load sharing > >>- db clustering, master/slave, read servers and write servers, etc. > > > There was a good article in php-a this summer about MySQL's master-slave > capacity, but I have yet to explore it.. Sounds like an excellent way > to extend the code. > The memcache/LiveJournal guys talk about this too and the dangers when your writes reach a significant level. > >>- memcache support in db reads, writes, html cacheing, etc. > > > Explored this a bit more.. BE uses jpcache for page caching (Thanks > Joe) and also another fragment caching app for storing arrays and html > fragments (Thanks PeterC).. > > Just for clarity - this is not Turck mmcache. I didn't mention it but I find either mmcache, php-accelerator or something similar imperative. I think it really just should be part of php like in python. These basically store the compiled code so that step doesn't have to be repeated each pageview. In informal benchmarking mmcache using ab, I get about a 2x to 3x improvement in requests per second. This is memcache ( http://www.danga.com/mmcache) - It is an in-memory cache daemon. Developed for LiveJournal and used on Slashdot. An introductory article at Linux Journal by the author: http://www.linuxjournal.com/article.php?sid=7451 >>- Ian's block cacheing > > > It's cool.. Certainly for the user level caching.. > This is one place I think storing in memory would be nice. > >>- using a separate image server with thttpd or somebody like akamai > > > This app here I assume: > http://www.acme.com/software/thttpd/ > > I haven't actually wondered there before, but it looks hopeful.. > That's the server. I believe that it loads the pages/images in memory and retrieves them from there. How different this would be from the linux filesystem retrieval caching, I don't know. Joe > Mike |
|
From: Joe S. <joe...@us...> - 2004-09-16 20:17:57
|
phpSlash is not dead, maybe moving slow, but not dead. The Back-End folks, led by Mike Gifford have been making lots of progress. The psl 0.8 release cycle is about to speed up. I'm planning on another beta test, then when that proves fairly stable, get a release candidate out. I do not want a long release cycle on this. Most everything here has been proven. I'd like to update the phpSlash Roadmap to be something that we can work toward. For psl 0.8: - needs a printer css or printer friendly view. - the wap article pages are not available anymore either. Both of these could be added back using the old code, but I'd like to see them improved. - I'd like to see someone familiar with phplist to configure it for a default setup to mimic our current headline mailer. Then we could just drop the current code. The phplist module is included in the current beta. - there is a css issue in the phplist admin page I haven't debugged. - What skins should be included in the main download? - What modules should be included? - Anything else? For psl 0.9: Not an exhaustive list or even looking at the current Roadmap. bring as much that BE has developed into psl as needed. - subsections - sitemap - subsites - block caches - trackback - multi language - what else? Move old stuff like glossary, etc. out of the core? How much should be released with the core? Move the templates to a subdirectory of the module. This is supported now. But I'd like to get 0.8 out first. module install, register, update, remove method - including db setup, other required modules and version(s) required. Navbar administration? - This shouldn't be too bad. We can generate the navbars once per session/authentication cycle couldn't we? Oh, enough for now. Maybe we can discuss this on irc as well. Joe |
|
From: Joe S. <joe...@us...> - 2004-09-16 20:17:34
|
This message is crossposted to the Back-End developers and phpSlash developers. I'd like to get an IRC discussion going on what developments need to be done to make BE/PSL more scalable and easier to deploy in a larger website installation. While I'm not saying we should get away from the easy to install, easy to deploy on a hosted account ideas, there is also a need for being able to use the code on sites serving lots of page views from multiple servers. I'd like to do this on IRC to get more of a real time discussion going. Is there a good time for everyone? But I'm not opposed to discussion here as well. This may seem a little soon in the next phpSlash release cycle for this discussion, but after this is done, I'd like to get another discussion on a more general roadmap for BE and PSL. A couple of my ideas to throw out: High Traffic Discussion - Load Balancing front end - db clustering, master/slave, read servers and write servers, etc. - memcache support in db reads, writes, html cacheing, etc. - static file writing to support staging, pushing to multiple servers, ease of serving, speed, etc. - squid reverse proxy front end. - Ian's block cacheing - using a separate image server with thttpd or somebody like akamai Joe |
|
From: Joe S. <joe...@us...> - 2004-09-13 18:56:40
|
For all you wiki fans: A Wikka Wakka Wiki module is available for demonstration and download. the project/download site: http://phpslashforge.org/projects/psl-mod-wikka/ and demo: http://psl-mod-wikka.phpslashforge.org/modules/wikka/wikka.php?wakka= The link to the Wiki module is in the Navbar. have fun, Joe |
|
From: Joe S. <joe...@us...> - 2004-09-06 15:36:00
|
There is a new phpSlash 0.8 beta release. This snapshot includes installer, upgrade script, skins, PHPlist module, blog support, etc. Please hammer on it awhile. Don't depend on the upgrade for production use yet. Outstanding items: email this story and print story are not working. |
|
From: Peter C. <li...@cr...> - 2004-07-08 09:45:28
|
On Wed, 7 Jul 2004 14:17:25 -0500 Joe Stewart <joe...@us...> wrote: > On Wed, Jul 07, 2004 at 11:26:25AM -0700, Peter Cruickshank wrote: > > > + [E] debug() now uses backtrace if available to show details of > > file/class and+ line > > This looks to be very cool. Thanks. :-) > Have you had a need for the delayed viewing option for debug now? It's > handy for viewing variables used before cookies being set. I have in Back-End and it's definitely cool. phpSlash doesnt have much left in the way of debug statements at the moment. I've not used the debug mail option - but it occurs to me that it might be good to automatically defer all debugs til the page has been closed --> only one email per page > Now that you've pretty much gone through the code again. Any new > suggestions to make? I like phpSlash's general approach (still seems cleaner than most other CMSish systems even after all these years). Probably sections are the area that I'd want to work on next: - allowing selection and positioning of blocks from the section admin screen (hiding the complexities of block admin from those who don't need to know). - allowing hierarchical sections Other stuff (brain dump, in random order): - there's a lot of repeated code in the story classes (eg getStories vs getStory) which could be simplified - we could bring back from Back-End the common date/time input function. psl is currently pretty inconsistent - search still needs to be turned into a class. It's use of global variables needs looked at too. - infolog doesnt use the proper page generation methods and is now broken (I will fix this soon) - I'm not sure how relevant block/story level caching is now that we have jpcache. It would be good to keep the cached content away from structural settings stuff in the database. (This might be too fundamental to be worth looking at) - We need to create a new bare-bones database. After a while, the description of the features section begins to grate... - We need to define and document the stylesheet classes and ids that are used and then make sure that all the skins use them consistently (eg ShankZen uses class="psl-desc" whereas basic uses class="desc" or even id="desc" which is bad html) - The whole user interface/interaction thing needs cleaned up (nice error messages, cancel button on form screens etc). Introducing htmlArea has made a big difference to story input - it would be nice to make it the default method. - split out the menu definition stuff from the rest of config.php (keeps the designers away from the scary stuff). Probably as something like config_menu.php - it's too complex to be turned into a .ini file? Think that'll do for now... :-) Peter -- Peter Cruickshank peter cruickshank biz |
2 messages has been excluded from this view by a project administrator.
