phpslash-devel Mailing List for phpSlash (Page 8)
Brought to you by:
joestewart,
nhruby
Menu
▾
▴
phpslash-devel — For developers of phpslash to communicate.
This list is closed, nobody may subscribe to it.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(45) |
Dec
(50) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(29) |
Feb
(49) |
Mar
(38) |
Apr
(22) |
May
(39) |
Jun
(21) |
Jul
(6) |
Aug
(9) |
Sep
(6) |
Oct
(26) |
Nov
(42) |
Dec
(19) |
| 2003 |
Jan
(15) |
Feb
(71) |
Mar
(40) |
Apr
(41) |
May
(28) |
Jun
(5) |
Jul
(25) |
Aug
|
Sep
(2) |
Oct
(50) |
Nov
(89) |
Dec
(19) |
| 2004 |
Jan
(21) |
Feb
(9) |
Mar
(5) |
Apr
(6) |
May
(7) |
Jun
|
Jul
(4) |
Aug
|
Sep
(14) |
Oct
(24) |
Nov
(3) |
Dec
|
| 2005 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Luis M <le...@ho...> - 2003-11-13 21:27:22
|
>Just a few things to keep in mind (I have to run; I will continue later >with this): > >1. when there is a database already setup but there is no table in it, the >script config_setup.php fails >2. if the server cannot write to the config.ini.php file, the >config_setup.php fails (no error printed) >3. config_setup.php seems to be very fragile... in other words, lots of >things can go wrong using $var+"string" to call a function. Especially >since $var is assigned from something submitted from a browser... >suggesting that it might fail if a browser mangles the strings or if users >inject something... etc... i'm sure we can find a million things why this >would not be wise. However, it works for now and we might change things >later to improve it. >4. users have to be reminded to remove the config_setup.php file from the >public site inmediately after setting the site up... if the script could >remove itself it would be even better >5. if writing to the server's config.ini.php is not an option, then i will >incorporate the code to push the file to the user's browser (as you >suggested Joe). >6. ... i have a lot more things, but I'll try to keep them in mind... A few things to bake your noodles..: a. apache segfaults (php 4.3.x and apache 1.3.x) with latest version (cvs) of phpslas-dev. The error is: [ error ] [Thu Nov 13 21:17:40 2003] [error] PHP Fatal error: Class jpcachedb: Cannot inherit from undefined class db_sql in /home/Shared/php/phpslash-dev/include/class/jpcache/type/phplib.php on line 13 [Thu Nov 13 21:18:27 2003] [notice] child pid 29835 exit signal Segmentation fault (11) [ end error ] b. if the database is already created, but the tables don't exist, the config_setup.php file doesn't work correctly. I modified it so that it picks the username/password from the already modified config.ini.php file, but this is not enough. Will look into that later. If anybody want the latest version of config_setup.php please let me know. I have not committed it to the CVS -- too experimental at this point. c. if the database is not already present, then it asks for another user that has rights to create/alter a database for mysql, which is nice, but after creating the database and populating it with the tables/0.8/slash-all.sql file, going to index.php fails because phplib is not set correctly :-D I guess Joe already knows this and I know the releases already have a working phplib directory inside "include", however, I think it should be a nice thing to allow the user to specify the path to their phplib directory when using config_setup.php. In a way that if the user leaves this blank, the default is used -- the way things work right not if one doesn't setup a phplib in config.ini.php. That's it for now... I see the M8 release is getting more and more sophisticated (htmlarea3 and so on...). Keep up the good work! ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Peter C. <li...@cr...> - 2003-11-12 11:56:07
|
On Wednesday 12 Nov 2003 6:19 am, Mike Gifford wrote: > Howdy folks, > > Been busy this week, so sorry for the delay. > > > Subject: Re: [Phpslash-devel] story save plugins > > From: Matthew Leingang <lei...@ma...> > > To: Joe Stewart <joe...@us...> > > > > > My thoughts are to provide a plugin script in the module/story > > > directory instead of incorporating it in the Story class. I'm not set > > > on either yet. The plugins would be in a subdirectory much as > > > blocktypes. > > > > OK, so what form does the data take in the database, though? If it's > > entered as wiki does it stay as wiki? > > What we did with BE is have content field & then a content_source field > for every text field which you could use wiki or text markup with. > > The html is stored in the content field for fast delivery, but when the > page is edited it is the content_source which is displayed in the format > it was entered in (be that html, wiki or plain text). > > It would be cooler to translate it both ways so that you could edit it > in a wiki, store it as html and then translate that html into a wiki > when you are editing it. That would allow you to switch markup types > mid-stream. I might be able to fit adding Wiki code to PSL in the current project I'm doing. If the client goes for it, or the budget allows. It would be good to have a common class that generates a textarea with appropriate input options. The class could then be used by the article, story, section modules, and we'd be sure of a common look and feel. And HtmlArea is a neat option for those who want that could be allowed. At first thoght, it seems a bit difficult to go from HTML back to Wiki (think about tables or links). I've not looked to see if someone's worked out how to do it already tho. In effect, the processed HTML is another level of data caching - and as such, maybe doesnt belong in the main tables. (It would be good to have a content caching strategy that allows the choice of filesystem or database, but that's another debate) > As far as a M8 goal, I'd also suggest running the code through something > like this to make it more consistently formatted: > http://sourceforge.net/projects/beautifyphp/ > > It's worked fairly well for BE. And it would make diffing between PSL and BE easier! Peter |
|
From: Mike G. <mi...@op...> - 2003-11-12 06:18:00
|
Howdy folks, Been busy this week, so sorry for the delay. > Subject: Re: [Phpslash-devel] story save plugins > From: Matthew Leingang <lei...@ma...> > To: Joe Stewart <joe...@us...> > > My thoughts are to provide a plugin script in the module/story directory > > instead of incorporating it in the Story class. I'm not set on either > > yet. The plugins would be in a subdirectory much as blocktypes. > OK, so what form does the data take in the database, though? If it's > entered as wiki does it stay as wiki? What we did with BE is have content field & then a content_source field for every text field which you could use wiki or text markup with. The html is stored in the content field for fast delivery, but when the page is edited it is the content_source which is displayed in the format it was entered in (be that html, wiki or plain text). It would be cooler to translate it both ways so that you could edit it in a wiki, store it as html and then translate that html into a wiki when you are editing it. That would allow you to switch markup types mid-stream. As far as a M8 goal, I'd also suggest running the code through something like this to make it more consistently formatted: http://sourceforge.net/projects/beautifyphp/ It's worked fairly well for BE. Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://www.openconcept.ca Stop Cdn Pension Plan War Investments -> http://coat.openconcept.ca/ Another world is not only possible, she is on her way -Arundhati Roy |
|
From: Joe S. <joe...@us...> - 2003-11-10 14:58:45
|
On Mon, Nov 10, 2003 at 01:28:48PM +0000, Peter Cruickshank wrote:
> On Monday 10 Nov 2003 12:39 pm, Joe Stewart wrote:
>
> > If not it sounds like you are describing two sections.
> ...
> I think so, now...
>
No. I've had more coffee now. If you've got separate scripts, like
glossary.php, feedback.php ,etc.
You should be able to assign the same section argument and applicable
module argument. This is the way the admin pages work. They are all in
the admin section.
> In the old days (ie before the move to module blocks), they could have been in
> the same section - the section was a way for ensuring that they had the same
> blocks surrounding the generated content. The benefit was that the number of
> sections could be kept under control, saving on admin time if you want to
> change what blocks appear on what page - this pays off if like me, you're
> using PSL as a site-building engine, rather than a news-blogger.
>
The limitation was that all the poll, mailinglist, glossary, about, etc
had the same blocks.
> I'm not saying to go back to the old set-up tho, and I know I may be in a
> minority.
>
> Slightly different topic - it's a hassle to delete sections, because you have
> to delete all the (many) blocks first. Maybe it's time to add to the section
> admin page some indication of what blocks have been assigned to the section +
> the option to add/remove them?
>
Yes it is a hassle. Doesn't it tell you when you try to delete the
section which blocks are assigned?
We could offer to force the removal of the section assignment to to those
blocks.
> > > 2. What contains the blocks in the top and bottom columns?
> > >
> > > The old navbar and topic bars were in slashHead.tpl and slashFoot.tpl. It
> > > now seems they are inserted between slashHead/Foot.tpl and
> > > index?col*.tpl.
> >
> > You're right.
>
> [...]
>
> > So if you don't use the topic bar or want to move the navbar to the left
> > blocks, you can do it right from the block admin.
>
> That's a cool new feature for sure.
>
> > uses:
> >
> > Got different ad zones?
> > I guess you could do away with the header file and have everything in the
> > index template if you edit html in a wysiwyg editor.
>
> That would also allow more design flexibility over how/where the topic and nav
> bars appear (eg some designs might need the topic bar before the site logo
> etc).
>
> Thinking aloud...
>
> slashHead + slashFoot are now embedded into the index*tpl files...
> Wouldnt it make more sense to generate pages from slashHead + index*tpl +
> slashFoot, with all the columns in index*.tpl files? (ie dont embed slashHead
> etc). That way, the {TOP} / {BOTTOM} elements in index.tpl could be enclosed
> by TABLE or DIV tags if that's what the design required.
>
This was one of the reasons for doing it this way. For your index
template, just move the {TOP} / {BOTTOM} where you need it. Or assign the
header/footer block to the top/bottom of the center column. And leave the
TOP and BOTTOM empty.
I grew frustrated trying to make a two and three column skin with just CSS
and no tables using a common footer location.
Joe
> ... it'd be easier for the programmer/designer interface IMO.
>
> But not a big deal...
>
> [...]
>
> Peter
> --
> The Macintosh is Xerox technology at its best.
|
|
From: Peter C. <li...@cr...> - 2003-11-10 13:10:25
|
On Monday 10 Nov 2003 12:39 pm, Joe Stewart wrote:
> On Mon, Nov 10, 2003 at 12:01:04PM +0000, Peter Cruickshank wrote:
> > Still getting my head round the pure-blocks approach to building the
> > site... a couple of questions:
> >
> > 1. Is there a way to get several modules to be in the same section?
> >
> > I'm thinking of say a 'General information' section, with common blocks,
> > but used by two modules:
> > - the glossary
> > - a feedback/contact us form
>
> Do you want the two modules shown on the same page?
>
> > It seems to me that I'll need to have separate Glossary and Feedback
> > sections,
> If not it sounds like you are describing two sections.
...
I think so, now...
In the old days (ie before the move to module blocks), they could have been in
the same section - the section was a way for ensuring that they had the same
blocks surrounding the generated content. The benefit was that the number of
sections could be kept under control, saving on admin time if you want to
change what blocks appear on what page - this pays off if like me, you're
using PSL as a site-building engine, rather than a news-blogger.
I'm not saying to go back to the old set-up tho, and I know I may be in a
minority.
Slightly different topic - it's a hassle to delete sections, because you have
to delete all the (many) blocks first. Maybe it's time to add to the section
admin page some indication of what blocks have been assigned to the section +
the option to add/remove them?
> > 2. What contains the blocks in the top and bottom columns?
> >
> > The old navbar and topic bars were in slashHead.tpl and slashFoot.tpl. It
> > now seems they are inserted between slashHead/Foot.tpl and
> > index?col*.tpl.
>
> You're right.
[...]
> So if you don't use the topic bar or want to move the navbar to the left
> blocks, you can do it right from the block admin.
That's a cool new feature for sure.
> uses:
>
> Got different ad zones?
> I guess you could do away with the header file and have everything in the
> index template if you edit html in a wysiwyg editor.
That would also allow more design flexibility over how/where the topic and nav
bars appear (eg some designs might need the topic bar before the site logo
etc).
Thinking aloud...
slashHead + slashFoot are now embedded into the index*tpl files...
Wouldnt it make more sense to generate pages from slashHead + index*tpl +
slashFoot, with all the columns in index*.tpl files? (ie dont embed slashHead
etc). That way, the {TOP} / {BOTTOM} elements in index.tpl could be enclosed
by TABLE or DIV tags if that's what the design required.
... it'd be easier for the programmer/designer interface IMO.
But not a big deal...
[...]
Peter
--
The Macintosh is Xerox technology at its best.
|
|
From: Joe S. <joe...@us...> - 2003-11-10 12:39:21
|
On Mon, Nov 10, 2003 at 12:01:04PM +0000, Peter Cruickshank wrote: > Still getting my head round the pure-blocks approach to building the site... a > couple of questions: > > 1. Is there a way to get several modules to be in the same section? > > I'm thinking of say a 'General information' section, with common blocks, but > used by two modules: > - the glossary > - a feedback/contact us form Do you want the two modules shown on the same page? > It seems to me that I'll need to have separate Glossary and Feedback sections, If not it sounds like you are describing two sections. > manually make sure that they have the same blocks... > > 2. What contains the blocks in the top and bottom columns? > > The old navbar and topic bars were in slashHead.tpl and slashFoot.tpl. It now > seems they are inserted between slashHead/Foot.tpl and index?col*.tpl. > You're right. The default data has: slashHead topic bar navbar center navbar slashFoot I think. So if you don't use the topic bar or want to move the navbar to the left blocks, you can do it right from the block admin. uses: Got different ad zones? I guess you could do away with the header file and have everything in the index template if you edit html in a wysiwyg editor. > To keep alignments neat, I find I'm having to remove the close/open table+div > code from slashHead/Foot and copy it to each of the index*.tpl files. Seems > messy... > I hate to hear this. > What approaches have you all taken? > A couple of the skins ported from other projects did this too. I changed some of them, but others left as is. > Peter > > > > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel |
|
From: Peter C. <li...@cr...> - 2003-11-10 11:42:47
|
Still getting my head round the pure-blocks approach to building the site... a couple of questions: 1. Is there a way to get several modules to be in the same section? I'm thinking of say a 'General information' section, with common blocks, but used by two modules: - the glossary - a feedback/contact us form It seems to me that I'll need to have separate Glossary and Feedback sections, manually make sure that they have the same blocks... 2. What contains the blocks in the top and bottom columns? The old navbar and topic bars were in slashHead.tpl and slashFoot.tpl. It now seems they are inserted between slashHead/Foot.tpl and index?col*.tpl. To keep alignments neat, I find I'm having to remove the close/open table+div code from slashHead/Foot and copy it to each of the index*.tpl files. Seems messy... What approaches have you all taken? Peter |
|
From: Joe S. <joe...@us...> - 2003-11-07 21:53:39
|
On Fri, Nov 07, 2003 at 03:09:49PM -0500, Matthew Leingang wrote: > On Fri, 2003-11-07 at 11:31, Joe Stewart wrote: > > I've been working to change the text modifiers ( plaintext, exttrans) into > > a general plugin system that could easily support wiki text, etc. > > Good idea. > > > My thoughts are to provide a plugin script in the module/story directory > > instead of incorporating it in the Story class. I'm not set on either > > yet. The plugins would be in a subdirectory much as blocktypes. > > OK, so what form does the data take in the database, though? If it's > entered as wiki does it stay as wiki? > > > There exists the ability to have the same ability for display time plugins > > too. Where the text would be as submitted but modified for display. > > Should these plugins be in the same directory and designated some other > > way? > > Maybe different directory. Is there where we could do "smart links"? I > mean like if a story mentions a user, the plugin would insert the link > to his story page? > Yes, we could annotate like this either on the front end when saving or at display time. Same for wiki markup. Mike or Peter - Does Back-End apply the wiki transformation and then save the result? Makes me think they should be in a common directory. The we can give input and output choices. > > Care has to be made if these are installed in a web accessible directory > > that they will be safe if called directly. Phorum had a security flaw in > > this regard. > > What about an OO approach? We could have StoryRenderer classes or > something, and each plugin could extend one of those. executing a class > file wouldn't have any security problems because it just declares the > class. > yeah. Its worked well for blocks. And we could minimize code duplication. The first plugins that I've thought about are just text filters. No other smarts. Joe |
|
From: Matthew L. <lei...@ma...> - 2003-11-07 20:09:51
|
On Fri, 2003-11-07 at 11:31, Joe Stewart wrote: > I've been working to change the text modifiers ( plaintext, exttrans) into > a general plugin system that could easily support wiki text, etc. Good idea. > My thoughts are to provide a plugin script in the module/story directory > instead of incorporating it in the Story class. I'm not set on either > yet. The plugins would be in a subdirectory much as blocktypes. OK, so what form does the data take in the database, though? If it's entered as wiki does it stay as wiki? > There exists the ability to have the same ability for display time plugins > too. Where the text would be as submitted but modified for display. > Should these plugins be in the same directory and designated some other > way? Maybe different directory. Is there where we could do "smart links"? I mean like if a story mentions a user, the plugin would insert the link to his story page? > Care has to be made if these are installed in a web accessible directory > that they will be safe if called directly. Phorum had a security flaw in > this regard. What about an OO approach? We could have StoryRenderer classes or something, and each plugin could extend one of those. executing a class file wouldn't have any security problems because it just declares the class. > Joe > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel -- Matthew Leingang Harvard University Department of Mathematics lei...@ma... |
|
From: Joe S. <joe...@us...> - 2003-11-07 20:02:20
|
On Fri, Nov 07, 2003 at 02:42:53PM -0500, Matthew Leingang wrote: > Hi Joe, > > This is the fun part; the "daydreaming" part of programming. > > > I think the best thing is to put all module-specific things inside the > module's directory. Otherwise it's not very modular! > > PHPGW has a directory structure like this. I can't remember what it was > and I'm having trouble reaching their site. (Maybe that's a reason not > to follow their lead, but I'm sure it's other problems). > Agreed that things should be as self contained as possible. Going from memory but the PHPGW guys had to write a script to try to find which modules needed translating, etc. They had kind of a headache with it. I really liked their API and module registration, upgrade, installation, etc. until I installed LDAP auth and address books. It got way too s-l-o-w and was abandoned. I've been impressed with webmin/usermin and its ability to check for upgrades and install new modules. It's in perl. Joe |
|
From: Joe S. <joe...@us...> - 2003-11-07 19:57:48
|
On Fri, Nov 07, 2003 at 02:45:32PM -0500, Matthew Leingang wrote: > On Fri, 2003-11-07 at 11:20, Joe Stewart wrote: > > How does this sound? > > > > We keep the current array in the config file for a core module ( like > > Blocks) and for those that like text file config. > > > > If the module block doesn't find the requested module in the _PSL array, > > it looks in a list of modules in a session array. The session array would > > require a db query on first use. > > Then what? Each module can have its own ini file? I'm not following > here. > Then it would have a filepath for a valid and available module. A site administrator could pick and choose modules from the web interface. Modules may be required for an ini or xml file for versioning,etc. Another issue is module installation needs such as sql. |
|
From: Matthew L. <lei...@ma...> - 2003-11-07 19:45:34
|
On Fri, 2003-11-07 at 11:20, Joe Stewart wrote: > How does this sound? > > We keep the current array in the config file for a core module ( like > Blocks) and for those that like text file config. > > If the module block doesn't find the requested module in the _PSL array, > it looks in a list of modules in a session array. The session array would > require a db query on first use. Then what? Each module can have its own ini file? I'm not following here. > The speed hit should be minimal. We should be able to quickly expand and > test module API and management. You can always move the definition to the > config file. > > The db table would allow module_id access too. > > > Joe > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel -- Matthew Leingang Harvard University Department of Mathematics lei...@ma... |
|
From: Matthew L. <lei...@ma...> - 2003-11-07 19:42:58
|
Hi Joe, This is the fun part; the "daydreaming" part of programming. On Fri, 2003-11-07 at 11:01, Joe Stewart wrote: > I started a M8 Group for Feature Requests. If you have any features that > are needed or wanted for release please add them or make a note of the > existing RFE. [snip. Will respond to the other topics in their e-mails] > pushed back from 0.7 - > DB Abstraction to allow any db to be used. > > [Expected Release: 3 - 4 months after 0.7] > > I want to give users the ability to have their own mini stories and crap > on their user page. This will highly rock and be really helpful in > forming a "community" feeling about the site. > User Stories will incur a lot of load so we'll need to make sure all the > SQL and logic are tight and fast. > The plug-in API should allow other app writers to be able to easily > communicate with phpSlash to share data across the website (ie: phorum, > IMP) > > Localization / Language / Internationization Support > > > > 'DB Abstraction to allow any db to be used'. - How high is this on your > list? I'd like to have postgres support but don't feel capable of the sql > portions. To get the issues defined, I've thought of adding a small > translation layer like pslgetText for problematic queries only. Then > while we maybe restructure the query to be standard sql, support for > postgres would still be available. This seems like it would be an easy job until you try to do it. I don't know for sure but I think the SQL flavors are different enough that translation is hard. Add to that the fact that the queries are built up dynamically and I don't know when the translation is supposed to happen. One possibility is a query class with methods like add_field and add_condition and which wouldn't write out an SQL string until the query is ready to go. Then you could have different implementations of the query class for different SQL flavors. But that seems like a lot of overhead. Or you could template SQL queries...? > 'I want to give users the ability to have their own mini stories and crap > on their user page. This will highly rock and be really helpful in > forming a "community" feeling about the site'. - Is this the same as user > blogs? I think we are very close with the existing structure. The user > group just needs permission to create stories for a "userblog" type > section. Their pages show using their author_id as an argument. Yep. > 'User Stories will incur a lot of load so we'll need to make sure all the > SQL and logic are tight and fast.' - Anyone got anything specific here. > Bryce sent me a note that something in the polls need indexing. I'll try > to find my note to remember this one. I heard a guy at PHPCon say "Somebody told me, 'PHP sucks! I wrote this script to present data from a database, and it's monstrously slow!' I showed him how an index would make his database return more quickly, and the script ran a lot better. He said, 'Wow! PHP's cool!'" > 'The plug-in API should allow other app writers to be able to easily > communicate with phpSlash to share data across the website (ie: phorum, > IMP)' - ? Some integration on the DB side would be possible if MySQL only supported views or triggers... :-( I think XMLRPC/SOAP is a step in this direction. But that's a huge project and maybe better for M9. > 'Localization / Language / Internationization Support' - Isn't this > largely done except now with split modules there is some decision making > needed. I think the best thing is to put all module-specific things inside the module's directory. Otherwise it's not very modular! PHPGW has a directory structure like this. I can't remember what it was and I'm having trouble reaching their site. (Maybe that's a reason not to follow their lead, but I'm sure it's other problems). > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel -- Matthew Leingang Harvard University Department of Mathematics lei...@ma... |
|
From: Joe S. <joe...@us...> - 2003-11-07 17:45:05
|
On Thu, Nov 06, 2003 at 05:10:21PM -0500, Luis M wrote: > >> >I backported Evan Hughes' install wizard for back-end to phpslash. It > >is > >> >in cvs now. If you do an anon checkout it may not be mirrored yet. > >> > >> yoohooo!! and I thought my migration process was going to be bad. That > >> sounds great. After using an Install Wizard, I'm thinking about simply > >> dumping my tables and moving my template dir to the new instalation; > >then > >> test and retest until I get things stable enough -- while taking notes > >and > >> fixing bugs as I go. That way I will have a more solid upgrade path for > >my > >> production sites. > >> > > > >No upgrade script for the tables yet. But yeah, I've been doing more and > >more from this base. > > Oh, it would be even better if you could just incorporate that into the > setup_config.php itself a la run-parts in debian :-D > say, have a directory called "post_setup", "pre_setup" or whatever, and e/a > file in this directory is considered as a php script that needs to be run > before and after setup respectively. That way sysadmins/webmasters can just > have those scripts ready to upgrade their sites when new releases come out. > Say that users diff the tables.sql file from the pass release against the > new one and note the new tables they have added to their sites... etc... > those directories could then be removed once the setup/upgrade is done. > > >> >Luis - can you see if you can add your download option? Currently if > >it > >> >can't write the ini file it displays it for cut and paste. Also see if > >> >maybe we could graft your editor on for modifying the other options, or > >> >expand the questions. It currently only does the bare minimum to get > >> >started. > >> > >> Not a problem. However so far I get this when doing "cvs update" > >> $> cvs update > >> ssh_exchange_identification: Connection closed by remote host > >> cvs [update aborted]: end of file from server (consult above messages if > >> any) > >> > >> So, I guess SourceForge is having problems, again. This might be the > >> begining of the end for such a nice project? Don't know for sure yet but > >> they are always having problems. > >> > > > >This is what I used: > > > >cvs -dj...@cv...:/cvsroot/phpslash co > >phpslash-dev > > > [snip] > It's already fixed. They had a hicup for a few minutes. I already found and > committed minor fixes. > Which brings this to mind, the config-dist.ini.php and config_setup.ini.php > are essentially the same file. We should be able to just move (rename) > config_setup.ini.php to config-dist.ini.php for now (in CVS) and change the > config_setup.php to use this file instead. That way we are not going to be > doing double work every time we add a new variable to the ini file. > > > > > >I've thought about that too. Just make the alpha release a dated > >snapshot. > > > >Joe > got it. i think it creates less fuzz in the CVS rep. > > Just a few things to keep in mind (I have to run; I will continue later > with this): > > 1. when there is a database already setup but there is no table in it, the > script config_setup.php fails I've introduced some notices and warnings too. Will look into this. > 2. if the server cannot write to the config.ini.php file, the > config_setup.php fails (no error printed) I got the output displayed for cut and paste. > 3. config_setup.php seems to be very fragile... in other words, lots of > things can go wrong using $var+"string" to call a function. Especially > since $var is assigned from something submitted from a browser... > suggesting that it might fail if a browser mangles the strings or if users > inject something... etc... i'm sure we can find a million things why this > would not be wise. However, it works for now and we might change things > later to improve it. I'm sure this is true. > 4. users have to be reminded to remove the config_setup.php file from the > public site inmediately after setting the site up... if the script could > remove itself it would be even better back-end nags at you if you login and these files are still there and/or the ini file is writable. Is this best or should we refuse to run? > 5. if writing to the server's config.ini.php is not an option, then i will > incorporate the code to push the file to the user's browser (as you > suggested Joe). good deal. > 6. ... i have a lot more things, but I'll try to keep them in mind... > > > > ----)(----- > Luis Mondesi > System Administrator > LatinoMixed.com > > le...@ho... > > "...The Mac does this so smoothly, it feels like an extension of your > mind." - Paula Speer, MacWorld Magazine 2003-04 > > Public signature: http://www.latinomixed.com/lems1/public-a.asc > > _________________________________________________________________ > MSN Search, le moteur de recherche qui pense comme vous ! > http://search.msn.fr/worldwide.asp > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Phpslash-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpslash-devel |
|
From: Joe S. <joe...@us...> - 2003-11-07 16:30:47
|
I've been working to change the text modifiers ( plaintext, exttrans) into a general plugin system that could easily support wiki text, etc. My thoughts are to provide a plugin script in the module/story directory instead of incorporating it in the Story class. I'm not set on either yet. The plugins would be in a subdirectory much as blocktypes. There exists the ability to have the same ability for display time plugins too. Where the text would be as submitted but modified for display. Should these plugins be in the same directory and designated some other way? Care has to be made if these are installed in a web accessible directory that they will be safe if called directly. Phorum had a security flaw in this regard. Joe |
|
From: Joe S. <joe...@us...> - 2003-11-07 16:20:40
|
How does this sound? We keep the current array in the config file for a core module ( like Blocks) and for those that like text file config. If the module block doesn't find the requested module in the _PSL array, it looks in a list of modules in a session array. The session array would require a db query on first use. The speed hit should be minimal. We should be able to quickly expand and test module API and management. You can always move the definition to the config file. The db table would allow module_id access too. Joe |
|
From: Joe S. <joe...@us...> - 2003-11-07 16:01:09
|
I started a M8 Group for Feature Requests. If you have any features that are needed or wanted for release please add them or make a note of the existing RFE. I think it's time to make a module management class and be able to register new modules through the we admin. I have more on this and will expand in a separate email. I'm working on making the text modifiers for story submittal be plug-ins. Such as exttrans, wiki text, phpBB code, phorumcode, etc. Also will send a separate mail for discussion. It would be a good time to backport from Back-End as much as appropriate. Also any module API needs to make their life easier. One thing that could be done quickly is htmlArea support. Here is the Roadmap in the Docs: phpSlash 0.8 -> Gordita pushed back from 0.7 - DB Abstraction to allow any db to be used. [Expected Release: 3 - 4 months after 0.7] I want to give users the ability to have their own mini stories and crap on their user page. This will highly rock and be really helpful in forming a "community" feeling about the site. User Stories will incur a lot of load so we'll need to make sure all the SQL and logic are tight and fast. The plug-in API should allow other app writers to be able to easily communicate with phpSlash to share data across the website (ie: phorum, IMP) Localization / Language / Internationization Support 'DB Abstraction to allow any db to be used'. - How high is this on your list? I'd like to have postgres support but don't feel capable of the sql portions. To get the issues defined, I've thought of adding a small translation layer like pslgetText for problematic queries only. Then while we maybe restructure the query to be standard sql, support for postgres would still be available. 'I want to give users the ability to have their own mini stories and crap on their user page. This will highly rock and be really helpful in forming a "community" feeling about the site'. - Is this the same as user blogs? I think we are very close with the existing structure. The user group just needs permission to create stories for a "userblog" type section. Their pages show using their author_id as an argument. 'User Stories will incur a lot of load so we'll need to make sure all the SQL and logic are tight and fast.' - Anyone got anything specific here. Bryce sent me a note that something in the polls need indexing. I'll try to find my note to remember this one. 'The plug-in API should allow other app writers to be able to easily communicate with phpSlash to share data across the website (ie: phorum, IMP)' - ? 'Localization / Language / Internationization Support' - Isn't this largely done except now with split modules there is some decision making needed. Sorry so long an email. Feel free to bring something else up or split the discussion. thanks, Joe |
|
From: Luis M <le...@ho...> - 2003-11-06 22:10:30
|
> > >I backported Evan Hughes' install wizard for back-end to phpslash. It >is > > >in cvs now. If you do an anon checkout it may not be mirrored yet. > > > > yoohooo!! and I thought my migration process was going to be bad. That > > sounds great. After using an Install Wizard, I'm thinking about simply > > dumping my tables and moving my template dir to the new instalation; >then > > test and retest until I get things stable enough -- while taking notes >and > > fixing bugs as I go. That way I will have a more solid upgrade path for >my > > production sites. > > > >No upgrade script for the tables yet. But yeah, I've been doing more and >more from this base. Oh, it would be even better if you could just incorporate that into the setup_config.php itself a la run-parts in debian :-D say, have a directory called "post_setup", "pre_setup" or whatever, and e/a file in this directory is considered as a php script that needs to be run before and after setup respectively. That way sysadmins/webmasters can just have those scripts ready to upgrade their sites when new releases come out. Say that users diff the tables.sql file from the pass release against the new one and note the new tables they have added to their sites... etc... those directories could then be removed once the setup/upgrade is done. > > >Luis - can you see if you can add your download option? Currently if >it > > >can't write the ini file it displays it for cut and paste. Also see if > > >maybe we could graft your editor on for modifying the other options, or > > >expand the questions. It currently only does the bare minimum to get > > >started. > > > > Not a problem. However so far I get this when doing "cvs update" > > $> cvs update > > ssh_exchange_identification: Connection closed by remote host > > cvs [update aborted]: end of file from server (consult above messages if > > any) > > > > So, I guess SourceForge is having problems, again. This might be the > > begining of the end for such a nice project? Don't know for sure yet but > > they are always having problems. > > > >This is what I used: > >cvs -dj...@cv...:/cvsroot/phpslash co >phpslash-dev > [snip] It's already fixed. They had a hicup for a few minutes. I already found and committed minor fixes. Which brings this to mind, the config-dist.ini.php and config_setup.ini.php are essentially the same file. We should be able to just move (rename) config_setup.ini.php to config-dist.ini.php for now (in CVS) and change the config_setup.php to use this file instead. That way we are not going to be doing double work every time we add a new variable to the ini file. > >I've thought about that too. Just make the alpha release a dated >snapshot. > >Joe got it. i think it creates less fuzz in the CVS rep. Just a few things to keep in mind (I have to run; I will continue later with this): 1. when there is a database already setup but there is no table in it, the script config_setup.php fails 2. if the server cannot write to the config.ini.php file, the config_setup.php fails (no error printed) 3. config_setup.php seems to be very fragile... in other words, lots of things can go wrong using $var+"string" to call a function. Especially since $var is assigned from something submitted from a browser... suggesting that it might fail if a browser mangles the strings or if users inject something... etc... i'm sure we can find a million things why this would not be wise. However, it works for now and we might change things later to improve it. 4. users have to be reminded to remove the config_setup.php file from the public site inmediately after setting the site up... if the script could remove itself it would be even better 5. if writing to the server's config.ini.php is not an option, then i will incorporate the code to push the file to the user's browser (as you suggested Joe). 6. ... i have a lot more things, but I'll try to keep them in mind... ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Joe S. <joe...@us...> - 2003-11-06 21:11:55
|
On Thu, Nov 06, 2003 at 03:11:18PM -0500, Luis M wrote: > [snip] > >> I have to ask tho.... is there any way to get an error message > >generated, > >> rather than the page just silently dying? If the template class error > >had > >> been shown, I'd have been able to get some productive work done today. > >(Or if > >> I was less careless, I know...) > >> > > > >I'd like that too. There may be some commented out, but I've had some > >problems with errors in the template class not being very forgiving. > >Yours should have simply shown the applicable fancybox.tpl. Seems a bug > >to me. > > You mean to spit errors to the browser right. I usually don't care about > those, what I do is activate the error_reporting() of php and read the logs > with "tail -f" > I think it's one of those errors you've seen with the -dev, that just simply doesn't show anything ( maybe a segfault). Joe |
|
From: Joe S. <joe...@us...> - 2003-11-06 21:10:51
|
On Thu, Nov 06, 2003 at 02:57:53PM -0500, Luis M wrote: > > >I backported Evan Hughes' install wizard for back-end to phpslash. It is > >in cvs now. If you do an anon checkout it may not be mirrored yet. > > yoohooo!! and I thought my migration process was going to be bad. That > sounds great. After using an Install Wizard, I'm thinking about simply > dumping my tables and moving my template dir to the new instalation; then > test and retest until I get things stable enough -- while taking notes and > fixing bugs as I go. That way I will have a more solid upgrade path for my > production sites. > No upgrade script for the tables yet. But yeah, I've been doing more and more from this base. > >Luis - can you see if you can add your download option? Currently if it > >can't write the ini file it displays it for cut and paste. Also see if > >maybe we could graft your editor on for modifying the other options, or > >expand the questions. It currently only does the bare minimum to get > >started. > > Not a problem. However so far I get this when doing "cvs update" > $> cvs update > ssh_exchange_identification: Connection closed by remote host > cvs [update aborted]: end of file from server (consult above messages if > any) > > So, I guess SourceForge is having problems, again. This might be the > begining of the end for such a nice project? Don't know for sure yet but > they are always having problems. > This is what I used: cvs -dj...@cv...:/cvsroot/phpslash co phpslash-dev > >Since I didn't tag the 0.8alpha release yet and I screwed up and put the > >templates in twice, I'm going to replace the download binary with a new > >one. If you've got any bug fixes, get them in. I'm going to try to get > >some new story text plugin changes done too. > > I guess that you could skip the tagging part and just take the snapshot > approach for "alpha" releases. And just note in the release somehow that > this came from CVS of date XXXX-XX-XX since the CVS server doesn't change > that often I guess that we can get away with that for now if we need to go > back to a specific point. > > I've thought about that too. Just make the alpha release a dated snapshot. Joe > ----)(----- > Luis Mondesi > System Administrator > LatinoMixed.com > > le...@ho... > > "...The Mac does this so smoothly, it feels like an extension of your > mind." - Paula Speer, MacWorld Magazine 2003-04 > > Public signature: http://www.latinomixed.com/lems1/public-a.asc > |
|
From: Luis M <le...@ho...> - 2003-11-06 20:11:24
|
[snip] > > I have to ask tho.... is there any way to get an error message >generated, > > rather than the page just silently dying? If the template class error >had > > been shown, I'd have been able to get some productive work done today. >(Or if > > I was less careless, I know...) > > > >I'd like that too. There may be some commented out, but I've had some >problems with errors in the template class not being very forgiving. >Yours should have simply shown the applicable fancybox.tpl. Seems a bug >to me. You mean to spit errors to the browser right. I usually don't care about those, what I do is activate the error_reporting() of php and read the logs with "tail -f" To globally turn on error_reporting(E_ALL) for all pages, take a look at config.php (about line 82); although right now it slips off my mind what else you needed to do... I know you have to send all errors to the logs using your php.ini but you might have to do other things via .htaccess files... In general though, it would be nice if you can also redirect the messages to the browser if you need to -- for as long as it's not turned on by default :-D ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/worldwide.asp |
|
From: Luis M <le...@ho...> - 2003-11-06 19:58:15
|
>I backported Evan Hughes' install wizard for back-end to phpslash. It is >in cvs now. If you do an anon checkout it may not be mirrored yet. yoohooo!! and I thought my migration process was going to be bad. That sounds great. After using an Install Wizard, I'm thinking about simply dumping my tables and moving my template dir to the new instalation; then test and retest until I get things stable enough -- while taking notes and fixing bugs as I go. That way I will have a more solid upgrade path for my production sites. >Luis - can you see if you can add your download option? Currently if it >can't write the ini file it displays it for cut and paste. Also see if >maybe we could graft your editor on for modifying the other options, or >expand the questions. It currently only does the bare minimum to get >started. Not a problem. However so far I get this when doing "cvs update" $> cvs update ssh_exchange_identification: Connection closed by remote host cvs [update aborted]: end of file from server (consult above messages if any) So, I guess SourceForge is having problems, again. This might be the begining of the end for such a nice project? Don't know for sure yet but they are always having problems. >Since I didn't tag the 0.8alpha release yet and I screwed up and put the >templates in twice, I'm going to replace the download binary with a new >one. If you've got any bug fixes, get them in. I'm going to try to get >some new story text plugin changes done too. I guess that you could skip the tagging part and just take the snapshot approach for "alpha" releases. And just note in the release somehow that this came from CVS of date XXXX-XX-XX since the CVS server doesn't change that often I guess that we can get away with that for now if we need to go back to a specific point. ----)(----- Luis Mondesi System Administrator LatinoMixed.com le...@ho... "...The Mac does this so smoothly, it feels like an extension of your mind." - Paula Speer, MacWorld Magazine 2003-04 Public signature: http://www.latinomixed.com/lems1/public-a.asc _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://www.msn.fr/msger/default.asp |
|
From: Joe S. <joe...@us...> - 2003-11-06 16:03:08
|
On Thu, Nov 06, 2003 at 04:01:19PM +0000, Peter Cruickshank wrote: > On Thursday 06 Nov 2003 3:11 pm, Joe Stewart wrote: > > On Wed, Nov 05, 2003 at 10:27:54PM +0000, Peter Cruickshank wrote: > ... > <snip> > > I think it would be useful at some point to turn on the debug in pslNew, and > see if objects are being created sensibly. Seemed to me there's a lot of > duplicate instantiation going on, and not just of slashDB (tho that's the one > with the big implications). > I've been playing with xdebug some too to see where maybe some bottlenecks are. Nothing concrete yet except loading all the classes from disk. This is where phpaccelerater, apc, etc. provide what php is missing that python provides built in. > Still, this has implications for how the basic block engine works - maybe not > for now... I think it is due a revist tho - it's been with us since I started > being interested in this project, way back in '00. > yes. It's very important the block code is optimized now since it displays everything. > One thought for example - I think it would make things run smoother if column > was moved from block_options to being it's own field in psl_block - column > has got a lot more central to PSL's operations over the years) > At one time this was big on my list. I can't remember why not now except that it's easy now to give different choices for individual sites. Joe > P > |
|
From: Matthew L. <lei...@ma...> - 2003-11-06 15:54:54
|
On Thu, 2003-11-06 at 10:11, Joe Stewart wrote: > On Wed, Nov 05, 2003 at 10:27:54PM +0000, Peter Cruickshank wrote: [snip] > > I have to ask tho.... is there any way to get an error message generated, > > rather than the page just silently dying? If the template class error had > > been shown, I'd have been able to get some productive work done today. (Or if > > I was less careless, I know...) > > > > I'd like that too. There may be some commented out, but I've had some > problems with errors in the template class not being very forgiving. > Yours should have simply shown the applicable fancybox.tpl. Seems a bug > to me. I too have caused spectacular errors with no clue to their origin by messing up the template class. I think the problem is that pslError() uses a template to display its error. So if the template class is broken and wants to call its own errors, you get an infinite stack of 'em. Not sure where to break the loop, though...a second lower-tech error function with no templating? That's what could be called inside slashTemplate. Could even be a method for template since that's the only time we'd need it. Or pslError could check to see if slashTemplate has properly loaded before using a template. Hmmmm.... --Matt -- Matthew Leingang Harvard University Department of Mathematics lei...@ma... |
|
From: Peter C. <li...@cr...> - 2003-11-06 15:43:08
|
On Thursday 06 Nov 2003 3:11 pm, Joe Stewart wrote: > On Wed, Nov 05, 2003 at 10:27:54PM +0000, Peter Cruickshank wrote: ... > > I'd miss-spelled the template name 'contentonly' as 'contentsonly'. > > > > I guess it took so long to pin down the answer because there have been so > > many changes I wasnt sure where to start looking. > > > > I have to ask tho.... is there any way to get an error message generated, > > rather than the page just silently dying? If the template class error had > > been shown, I'd have been able to get some productive work done today. > > (Or if I was less careless, I know...) > > I'd like that too. There may be some commented out, but I've had some > problems with errors in the template class not being very forgiving. > Yours should have simply shown the applicable fancybox.tpl. Seems a bug > to me. That's true... I'll keep it in mind to look at. Not sure I have the time right now though. ... > > PS It truly is fascinating how many times login.php seems to instantiate > > slashBD... > > Yeah. Did Ian get the queries cleaned up some? I think most people > won't notice a slight delay while logging in. After logging in the array > is in the session. Realised what I was seeing (I think) was the block engine going through and refreshing all the cached blocks. I think it would be useful at some point to turn on the debug in pslNew, and see if objects are being created sensibly. Seemed to me there's a lot of duplicate instantiation going on, and not just of slashDB (tho that's the one with the big implications). Still, this has implications for how the basic block engine works - maybe not for now... I think it is due a revist tho - it's been with us since I started being interested in this project, way back in '00. One thought for example - I think it would make things run smoother if column was moved from block_options to being it's own field in psl_block - column has got a lot more central to PSL's operations over the years) P |
2 messages has been excluded from this view by a project administrator.
