You can subscribe to this list here.
2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:32
|
On Fri, Mar 23, 2001 at 04:55:44PM -0500, Todd Owen wrote: > Richard Rowell initially recommended ADODB. > [...] > Karsten and I then recommended PEAR. I thought it would be a better choi= ce > because it was poised to be more "official" and is being merged with phpl= ib. I like phplib, because it is very clean, simple and fast. Besides that, I worked with it and know my way around it's use. I looked at ADODB and it seems to have a sensible interface. I did not look under the hood, though. Has anybody some experience about ADODB's speed? That seems to be one of the most critical issues. > Maybe it's me, but I think PEAR can only be retrieved from CVS. We do ne= ed > to make a decision though. No, it should come with any PHP4 release (and it did on my setup). But I dislike the PEAR idea more and more. Not beacuse PEAR is bad itself, but because the actual PEAR:DB thing seems to be "slow by design". And we shouldn't really help Intel and AMD with their marketing :-) > I propose the developers consider this very important decision over the n= ext > week, but set a deadline of next Friday to make the decision. I will go with the majority, whatever result may come up. But please read my reply to Geoff Staples mail regarding phplib. Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:32
|
On Sat, Mar 24, 2001 at 12:14:07PM -0600, Geoff Staples wrote: > One of the problems with addons like phpLib is that it complicates the > installation process because you have to install phpLib before you can > install the application software. And, once you have your application You don't have to install a seperate version. Patrick Renaghan's (sp?!) bookmarker is an excellent example for that, and it seems to be widely used. You can bundle phplib with your application, phplib being packed in a subdirectory. You can then take the "include approach" instead of the "auto_prepend" approach. This way you can simplify installation, be sure of a working setup and have the ability to coexist with other phplib-aware tools on the same server. > But, here's the bigger question: Do we want phpWebsite to be dependent on > addon libraries that we don't control? It is OpenSource, you can take care of the code yourself, if need be. Plus the ability to use a "come along" version as laid out above, there is nothing "out of control". > something that can wait until PHP has native support. Is it something we can > write for ourselves and integrate into phpWebsite? Can we "steal" the > functionality from phpLib and integrate it into phpWebsite? I would consider this "duplicating coding efforts" - which is carp, IMHO. We can rely on phplib, and if need be - tehy are giving CVS access to anyone who seem to be able to contribute useful code. As it seems at the moment, the PEAR merge will take place, but there will be at least a 7.2d bugfix release and there might be a 8.0 release with PHP4 sessions and all that stuf natively built in. Notice that PHP4 sessions for phplib are available, although I haven't used them yet. Anyway, see the attached message from Kristian Köhntopp (one of the main phplib developers) for an explanation how he avoids using phplib nowadays. As to toss a vote on the phplib vs. ADODB thing: If we use phplib at all, we should use it's DB layer. If not, I don't care too much. ADODB seems to have a sensible interface, as far as I looked at it. I didn't look under the hood, though. Regards, Karsten -- Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w³: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:30
|
On Sat, Mar 24, 2001 at 11:05:57PM -0500, Todd Owen wrote: > BTW, having some XML in you project usually bumps you up at least one cool > factor anyway ;) Not too good a reason :-/ Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:29
|
On Sun, Mar 25, 2001 at 03:30:41PM -0500, Todd Owen wrote: > Jason, you're right about the .xlay files. I was looking at their .tmpl > files, which are html. HTML templates seem to be the best solution right now. I wrote an email to jason Campbell (and forwarded it to Brian later), but dind't get any response until now. I will elaborate on my ideas in details later. But again: HTML templates (combined with (PEAR:)Cache) are the way to go, IMHO. The use of XML to to the basic placement of blocks might make sense. But someone is working on arbritrary block positioning right now, right? So lets see what the results are, before jumping on the XML wagon just because it is cool. Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:28
|
On Sat, Mar 24, 2001 at 03:00:22PM -0800, g7c...@sn... wrote: > Sure, here is an example of what I mean (this is a sample from phpweblog, > which uses XML as it's layout format): > [...] > I am not an XML nor PHP wizard, but I think that XML would really help wi= th > making Themes easily designable. [...] > <item> > <element>FgColor</element> > <value>#000000</value> > </item> I think this is a "buzzword-only" use of XML. Defining colors could be done through CSS easier and with more clarity and performance I believe. XML used in conjunction with XSL might make sense, but XML in this way... I don't like the idea. Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:28
|
On Fri, Mar 23, 2001 at 04:36:55PM -0500, Todd Owen wrote: > As an ongoing project we should think about a better way to make phpWebSi= te > multi-lingual on demand. We are only multi-lingual before installation. > I'd like to see the user profile containing his/her default language > preference. I like the current way of doing this. I disliked it at first, but the reasons for the current approach are good (if you don't have to have multiple languages, it is (a lot) faster). But I see the need for on demand language switching. > phpmyadmin using the following language include file scheme: >=20 > english.inc.php > [...] > german.inc.php > [...] > Has anyone used this many DEFINE statements in an include file? Were the= re > any performance issues? I think this is the most common approach. To me it seems to have no deep impact on speed. But I would use a different scheme. I would include the appropriate language file, which would contain statements like $TRANSLATE["xxx"]=3D"fgdsfhsk"; This way we could introduce this very easily into the existing code base. In fact I am going to code this, and make it available as one more "language" when running makedistro.sh. Does anyone object on this? I think we should at least try this... Combined with a new theme engine, which really should have cacheing abilities, you could minimise the performance impact some more. And if you switch language files on the fly by using a prefix, you could even use the same prefix as databse prefix, theme prefix, whatever. This way you could even have language specific colours, content, ... Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Karsten D. <k.d...@tu...> - 2001-03-26 14:17:27
|
On Sat, Mar 24, 2001 at 07:32:56PM -0600, Geoff Staples wrote: > Add the following variable to config.php: >=20 > $dbp =3D ""; >=20 > $dbp can be set to a prefix for database tables. When it is empty, the > tables will be unchanged from their current "no prefix" names. Good. > Setup up a variable for every table in the system using the following > example as a model. Place them toward the bottom of config.php: >=20 > $tbl_stories =3D $dbp."stories" Good. > Edit all code in the system per the following example: > [...] > Do this for all SQL calls in the system. Good. > 1. Is "$dbp" an appropriate name for the database table prefix variable? I would say yes. If one would introduce the multilinugal approach I describe in my (other) mail, another prefix might be used, called $lang or whatever. I would add this through a patch being applied during makedistro.sh anyway, so we don't have to worry about htis right now. > 2. Is the config.php file the best place to put the "$tbl" variables? In a way, yes. If we decide on a database abstraction layer, we might introduce a seperate file with databse varibales, subclassing (in case of phplib) or whatever we need. We should put those definitions there, but until then... > 3. Is "$tbl_stories" the appropriate name for the variable to contain the > table name for the stories table? I would call them that way. By doing that all table related variables would show up in the same section of the phpdic element list, and one could always see at first glance, what the variable is for. BTW: If we have all the table names in a single file, it should be easy to give them more consistent names. Although it might be hard enough to settle on a definition of consistent :-) Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
From: Alain F. <al...@va...> - 2001-03-26 14:13:05
|
Hi, How about the "Developers Forum" on SourceForge, that has for some obscure reason been deleted ? ;) > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Matthew McNaney > Envoyé : lundi 26 mars 2001 15:55 > À : php...@li... > Objet : [Phpwebsite-developers] Communication > > > Hello all, > > I would like some feedback on perhaps getting and irc channel or even ICQ > to discuss the program. Please comment on how you folks would prefer to > communicate outside of email. > > Thanks, > Matthew McNaney > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
From: Matthew M. <mcn...@tu...> - 2001-03-26 13:58:24
|
Hello all, I would like some feedback on perhaps getting and irc channel or even ICQ to discuss the program. Please comment on how you folks would prefer to communicate outside of email. Thanks, Matthew McNaney |
From: Todd O. <to...@da...> - 2001-03-26 05:02:05
|
Make sure you set up a cvsroot first before logging in. >> *****CVS exited normally with code 0***** You're not doing anything wrong. Now you're logged in. You then have to type the following to actually get the files moving: cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot co phpwebsite 'co' = checkout http://www.cvshome.org --Todd |
From: Spiggy T. <th...@me...> - 2001-03-26 00:30:06
|
ok. with wincvs i type cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot login then follows the messages: (Logging in to anonymous@152.10.194.1) *****CVS exited normally with code 0***** the same result if i substitute the ip# with res1.resnet.appstate.edu so, what am i doing wrong? paivi |
From: Jason C. <cam...@xp...> - 2001-03-25 20:35:15
|
Looks to be a pretty good system to me for themes. I've seen some other nice stuff in Drupal which uses classes for alot core code of the engine. Pretty cool stuff thats for sure... > Jason, you're right about the .xlay files. I was looking at their > .tmpl files, which are html. > > --Todd > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Todd O. <to...@da...> - 2001-03-25 20:27:08
|
Jason, you're right about the .xlay files. I was looking at their .tmpl files, which are html. --Todd |
From: <g7c...@sn...> - 2001-03-25 19:42:30
|
phpweblog is great, but it looks like develpment has stalled a bit. And it does not provide user or calendar functionality. ----- Original Message ----- From: "Jason Campbell cam...@xp... XXXXXXXXXXXXXXXXXXX" <XXXXXXXXXXXXXXXXXXXXXXXXX> To: <XXXXXXXXXXXXXXXXXXXXXX> Sent: Sunday, March 25, 2001 11:42 AM Subject: Re: [Phpwebsite-developers] XML Themes > There are .XLAY files which I believe are XML based. At least they look > that way. phpweblog looks pretty damn good too for that matter. That > theme functionality is still alot better than what we have now. > > > > I've looked at phpweblog and that project uses HTML style > > templates/themes, which is better than what we're using now, but it's > > not XML either. > > > > --Todd > > > > > > > > _______________________________________________ > > Phpwebsite-developers mailing list > > Php...@li... > > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
From: Jason C. <cam...@xp...> - 2001-03-25 19:34:41
|
There are .XLAY files which I believe are XML based. At least they look that way. phpweblog looks pretty damn good too for that matter. That theme functionality is still alot better than what we have now. > I've looked at phpweblog and that project uses HTML style > templates/themes, which is better than what we're using now, but it's > not XML either. > > --Todd > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Todd O. <to...@da...> - 2001-03-25 18:57:10
|
I've looked at phpweblog and that project uses HTML style templates/themes, which is better than what we're using now, but it's not XML either. --Todd |
From: Geoff S. <Ge...@Ho...> - 2001-03-25 18:56:38
|
Todd: I'm using Wincvs. It appears to be finding your server and I get to the point of it requesting the password. I simply press enter (for anonymous) and then I get an error that userid doesn't exist. Geoff -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Todd Owen Sent: Sunday, March 25, 2001 12:18 PM To: php...@li... Subject: [Phpwebsite-developers] CVS access Geoff, the following is from the phpwebsite.appstate.edu website under downloads: pserver: cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot login Just hit enter (no password) cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot co phpwebsite You can just type this in from the command line on a Linux/BSD box. I use Windows most of the time, so it's WinCVS 1.2 for me. Also WinCVS won't take an IP address for the server so substitute res1.resnet.appstate.edu instead. I use the WinCVS admin command line and type in the unix style commands instead of using the GUI commands though. When you get CVS access, just substitute your username ('todd' in my case) for anonymous and enter your password when prompted (anonymous password is blank. The following link from cvshome.org discusses branches: http://www.cvshome.org/docs/manual/cvs_5.html --Todd Owen _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Geoff S. <Ge...@Ho...> - 2001-03-25 18:40:29
|
Cool! I thought we were using SourceForge, though. However, I still haven't heard back from Jeremy. Perhaps I'll try the userid and password I requested and see if I get lucky. Geoff 214.599.0260 Hostricity Web Hosting <http://www.hostricity.com/> -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Todd Owen Sent: Sunday, March 25, 2001 12:18 PM To: php...@li... Subject: [Phpwebsite-developers] CVS access Geoff, the following is from the phpwebsite.appstate.edu website under downloads: pserver: cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot login Just hit enter (no password) cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot co phpwebsite You can just type this in from the command line on a Linux/BSD box. I use Windows most of the time, so it's WinCVS 1.2 for me. Also WinCVS won't take an IP address for the server so substitute res1.resnet.appstate.edu instead. I use the WinCVS admin command line and type in the unix style commands instead of using the GUI commands though. When you get CVS access, just substitute your username ('todd' in my case) for anonymous and enter your password when prompted (anonymous password is blank. The following link from cvshome.org discusses branches: http://www.cvshome.org/docs/manual/cvs_5.html --Todd Owen _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Todd O. <to...@da...> - 2001-03-25 18:14:53
|
Geoff, the following is from the phpwebsite.appstate.edu website under downloads: pserver: cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot login Just hit enter (no password) cvs -z3 -d:pserver:anonymous@152.10.194.1:/home/cvsroot co phpwebsite You can just type this in from the command line on a Linux/BSD box. I use Windows most of the time, so it's WinCVS 1.2 for me. Also WinCVS won't take an IP address for the server so substitute res1.resnet.appstate.edu instead. I use the WinCVS admin command line and type in the unix style commands instead of using the GUI commands though. When you get CVS access, just substitute your username ('todd' in my case) for anonymous and enter your password when prompted (anonymous password is blank. The following link from cvshome.org discusses branches: http://www.cvshome.org/docs/manual/cvs_5.html --Todd Owen |
From: Jason C. <cam...@xp...> - 2001-03-25 05:04:42
|
Just got back from the hockey game and started reading this....Anyways.... Yea I like this idea for sure. If we could maybe store even the XML code into a table that would be cool too but using just one file would be fine. I was going to check out phpweblog's theme functions after I read somewhere they used XML. I think I'll look at that some more tomorrow. I'm at a stand still anyways until we decide what to change in the system before adding anything new to it. Jason Campbell Xplozive Media Technologies > Steven, this idea has merit; sort of like a CSS on steroids--of course > CSS entities would have to go in the XML too. What do you think about > this approach Jason? > > I assume we could use forms to create the XML or allow certain admins > to upload them directly once we decide on the keywords. Then we would > only have to store the XML filename and path in the database. Is there > anyone else besides Steven that would like to think on this some more? > > BTW, having some XML in you project usually bumps you up at least one > cool factor anyway ;) > > --Todd > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Geoff S. <Ge...@Ho...> - 2001-03-25 04:14:45
|
Todd: What I plan to do is Install the software on one domain and the database on a separate domain. Or, I will install multiple copies of the software in separate directories on the same domain. So, that would involve complete installs of the software (including the config file) for each "instance". I suppose that I could run multiple instances through the same copy of the software installed in a single location. But, I want to be able to customize each instance if I choose to. I haven't played with the software sufficiently to determine the extent to which I could customize with a single installation of the software. BTW: I have a question about CVS. I haven't used CVS before, so... I found a reference to SSH and downloaded it from ssh.com. But, I can't get it to login as anonymous and I don't have my CVS access yet. Can you tell me what I need to do to at least gain anonymous access? Thanks, Geoff -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Todd Owen Sent: Saturday, March 24, 2001 9:55 PM To: php...@li... Subject: Re: [Phpwebsite-developers] PHPlib & Multiple Instances Geoff, your logic looks good to me. I assume $dbp means "database prefix". My only question is how will $dbp be assigned? Will there be separate config files hard coded for each site? BTW, I don't have anything left to commit; you might check on Matt's calendar rewrite though. As I was writing up my long range goals, I ran across the opposite problem that Geoff had. What if your site(s) get too large for one database server to handle? Let's assume you're using the one table approach and you have 100,000 users and 1,000 sites on a single install. I can forsee the threaded discussion groups and mailing list archives for these organizations growing VERY quickly. I think we need to code with this in mind. I'm thinking about a server for core features and most plug-ins, but a separate database server for forums and list archives and possible a third for images (although not in a database). This can be solved by connecting to separate database servers once and passing the database handler to the appropriate objects in a similar way Geoff proposed abstracting the table name. Thoughts anyone, anyone? --Todd _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: Todd O. <to...@da...> - 2001-03-25 04:02:24
|
Steven, this idea has merit; sort of like a CSS on steroids--of course CSS entities would have to go in the XML too. What do you think about this approach Jason? I assume we could use forms to create the XML or allow certain admins to upload them directly once we decide on the keywords. Then we would only have to store the XML filename and path in the database. Is there anyone else besides Steven that would like to think on this some more? BTW, having some XML in you project usually bumps you up at least one cool factor anyway ;) --Todd |
From: Todd O. <to...@da...> - 2001-03-25 03:51:14
|
Geoff, your logic looks good to me. I assume $dbp means "database prefix". My only question is how will $dbp be assigned? Will there be separate config files hard coded for each site? BTW, I don't have anything left to commit; you might check on Matt's calendar rewrite though. As I was writing up my long range goals, I ran across the opposite problem that Geoff had. What if your site(s) get too large for one database server to handle? Let's assume you're using the one table approach and you have 100,000 users and 1,000 sites on a single install. I can forsee the threaded discussion groups and mailing list archives for these organizations growing VERY quickly. I think we need to code with this in mind. I'm thinking about a server for core features and most plug-ins, but a separate database server for forums and list archives and possible a third for images (although not in a database). This can be solved by connecting to separate database servers once and passing the database handler to the appropriate objects in a similar way Geoff proposed abstracting the table name. Thoughts anyone, anyone? --Todd |
From: Geoff S. <Ge...@Ho...> - 2001-03-25 01:33:01
|
Yes, I'll do it on a branch. But, following is my "specification" for the changes. Please review. I'd like to know that this approach is agreeable to everyone and that, assuming it is done correctly and isn't buggy, it will be accepted! Add the following variable to config.php: $dbp = ""; $dbp can be set to a prefix for database tables. When it is empty, the tables will be unchanged from their current "no prefix" names. Setup up a variable for every table in the system using the following example as a model. Place them toward the bottom of config.php: $tbl_stories = $dbp."stories" Edit all code in the system per the following example: Existing code: $result = mysql_query("SELECT sid, aid, title, time, hometext, bodytext, comments, counter, topic, informant, notes FROM stories ORDER BY sid DESC limit $storynum"); New Version: $result = mysql_query("SELECT sid, aid, title, time, hometext, bodytext, comments, counter, topic, informant, notes FROM $tbl_stories ORDER BY sid DESC limit $storynum"); Do this for all SQL calls in the system. Now, SEVERAL QUESTIONS TO BE ANSWERED: 1. Is "$dbp" an appropriate name for the database table prefix variable? 2. Is the config.php file the best place to put the "$tbl" variables? 3. Is "$tbl_stories" the appropriate name for the variable to contain the table name for the stories table? Finally, a housekeeping issue: I can make these changes in short order. So, I'd like to take the most current copy of the code, make the changes, and make them available for inspection before committing to the base code. What I don't want to do is get into a situation where the base code cannot be updated without merging a bunch of stuff. So, is there anything special I need to do other then grab the code out of CVS, make the changes and then make the branch available for review? Here's a list of all tables in the system: adminblock authors banner bannerclient bannerfinish omments counter ephem flags help image_category images lblocks links_categories links_links links_newlink links_subcategories main_page_content mainblock menu messages mod_cal_category mod_cal_events mod_cal_images mod_cal_location mod_cal_subcat new_referer page_content plugins poll_data poll_desc pollcomments queue quotes rblocks seccont sections stories template_icons topics user_pages users Geoff Dallas, Texas 214.599.0260 -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Todd Owen Sent: Saturday, March 24, 2001 2:46 PM To: php...@li... Subject: [Phpwebsite-developers] PHPlib & Multiple Instances I spoke with Jason by phone for about 30 minutes today and we are in TOTAL agreement that we need a good roadmap for the future of phpWebSite before significant changes are made (like database abstraction). The database design needs some more tweaking and the themes need to be rethought in a more object oriented approach. Jason and I think phpWebSite should have customizable themes in the database, not in php code. Steven, could you elaborate on your XML idea? Geoff, since this is such a sweeping change, please create a cvs branch for these changes and let us know the branch name. Everyone can review and test the branch code before committing it to the main repository. Since Karsten seems to be in charge of documentation, let's make sure our comments fit the phpdoc format. --Todd _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
From: <g7c...@sn...> - 2001-03-24 22:59:19
|
----- Original Message ----- From: "Todd Owen to...@ow... XXXXXXXXXXXXXXXXXXX" <XXXXXXXXXXXXXXXXXXXXXXXXX> >Steven, could you elaborate on your XML idea? > --Todd Sure, here is an example of what I mean (this is a sample from phpweblog, which uses XML as it's layout format): Then you could design a "Layout/Theme Admin" page that would simply use PHP's XML facilities to read/write the theme files. You would only need one php script then, which would simply read in the appropriate XML file. Does that make sense? I am not an XML nor PHP wizard, but I think that XML would really help with making Themes easily designable. ------------------------------------------ ample ------------------------------------------- <?xml version="1.0"?> <layout> <info> <author>Stephen</author> <description>Steves Office</description> <version>0.5.0</version> </info> <item> <element>BgURL</element> <value></value> </item> <item> <element>LogoURL</element> <value>/images/StevesOffice.jpg</value> </item> <item> <element>FgColor</element> <value>#000000</value> </item> <item> <element>LinkColor</element> <value>#000000</value> </item> etc.. |