phpwebsite-developers — For our development team.

Re: [Phpwebsite-developers] Another project

[Todd O. <to...@da...>]

I've reviewed http://www.roadsend.com/siteManager/ and
http://www.binarycloud.com and offer the following.

Roadsend has come a long way in two months and I see a few ideas in the code
(like code plates) that could benefit us.  I encourage everyone to read this
one; it's short too.  BinaryCloud's r2 spec is out.  The code here isn't as
completely developed as many of the other projects mentioned however.

Roadsend introduces additional/custom tags into their templating scheme.
Does anyone like this idea in lieu of the {braces} style?

--Todd

[Phpwebsite-developers] Another project

[W.D.Sumilang <wa...@on...>]

Someone posted this link on the binaryclound list...
haven't dug thru the code but its completely OO based and fully documented,
maybe its a relevant source for more ideas =)

The url is http://www.roadsend.com/siteManager/


__________________________________________________
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com

Re: [Phpwebsite-developers] New version and Roadmap [long]

[Benji S. <bsp...@mo...>]

Before I start, I would like to give a little background as to what we are 
looking to use phpWebsite for.

We are an educational institute that is looking to use a CMS for the 
various internal departments. We have the typical educational areas like 
Undergraduate, Student Development, Graduate, and Admissions, but we also 
have 15 radio stations (and other various radio programs), a magazine, 
retail operations, and other areas that we want to migrate to a CMS. Our 
needs differ from those of an ISP. We have a number of clients, but they 
all are internal clients.

Because of that, the number of db's vs. number of tables issue isn't a big 
one. Each content area will have its own CMS installation (be it under the 
current phpWebsite, with one installation per content area, or under the 
future phpWebsite, which can handle multiple OUs under one umbrella). A 
bigger question for us would be which option is a better use of the 
database and which is better from a management standpoint? If there any 
performance difference between having a number of databases, with a number 
of tables in each, or having one database, with lots of tables in?

Which is better from the php standpoint? Would the connection load (via 
pconnect) be less if everything was in database?

Which would make management easier?

just some thoughts from non-ISP side.

benji


---
Ben Spencer
Web Support
bsp...@mo...
x 2288

Re: [Phpwebsite-developers] New version and Roadmap

[Jeremy A. <ja...@tu...>]

> Hi,
> Just want to confirm a few things. Since the release of the roadmap,
> has the rewrite begun?  I see Adam has a start, is that the beginning?

Just to answer the question about Adam in CVS.  This is just a proof of 
concept for templates.  It is not the rewrite.

> I've been asked and the question has been asked on Sourceforge, "Are
> you really doing a rewrite?".  I would like to answer some of these
> people but I'm unsure about whether this is supposed to be kept quiet
> or what?  What is the projected release of the final phpWebSite 0.8.0?
> I'm not trying to hurry anyone, I just want to keep those looking for
> info informed.
>
> Thanks,
> winzor
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Another project for Review

[clayton c. <cc...@ca...>]

I dont know if someone else has made the suggestion, but have a look at the
R2 specs for BinaryCloud

http://www.binarycloud.com/documentation/

Some good ideas are being discussed, and im anxious to see how they are
implemented. At the very least, their archictectural model can serve as an
example we can borrow from. i especially like the idea of "managers".

clayton

Re: [Phpwebsite-developers] New version and Roadmap [long]

[clayton c. <cc...@ca...>]

Alain,


> That would mean to have users, groups that users can belong
> to, and "user and group roles". For instance: in order to post a news
item,
> you need to have the "news editor role". If the user alain either has the
> "news editor role", or is member of a group having the "news editor role",
> he can post a piece of news. That wouold be very flexible actually.
>
the code i ported from ACS (currently at Todd's website) will allow us to do
this.

RE: [Phpwebsite-developers] New version and Roadmap [long]

[Jason C. <cam...@xp...>]

I like this idea too.  I thought this was how we were going to do the 
administrative engine but I could be wrong.

As for one database having multiple sites in it, I'm all for that for the 
people that want it.  I just don't see why a big ISP would want say 40 
customer sites in one database.  I know I won't be doing that for my 
customers.  Everyone is having a separate database because I think its 
safer that way in the long run.  What happens if someone corrupts their 
database for some reason?  That could corrupt all the tables for all the 
sites in some way.  Also, having them all have their own login/pw for each 
table of theirs in the database is a pain to have to do compared to just 
assigning a login/pw to a database.  I'm just not on the "go" side for 
having multiple sites in the same database as you can tell :)  Someone make 
me a believer of this concept because I see no point in it.  If I had a 
customer that wanted to run two phpWebSite installations then I'd give them 
another database /w login/pw for that site as well.  I wouldn't include the 
first and second site in the same database.  Anyways, thats my thoughts on 
it.....


> 2. About the permissions problem you were referring to (one or two 'r'
> here? I can have it wrong, I'm a Luxembourger). I really like the
> Windows NT/2000 platform :). And what I most like about it, is the very
> powerful and flexible permissions system. Can't we somehow do something
> along those lines for phpWebSite? That would mean to have users, groups
> that users can belong to, and "user and group roles". For instance: in
> order to post a news item, you need to have the "news editor role". If
> the user alain either has the "news editor role", or is member of a
> group having the "news editor role", he can post a piece of news. That
> wouold be very flexible actually.
> 
> Thanks for reading !
> 
Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer

RE: [Phpwebsite-developers] New version and Roadmap [long]

[Alain F. <al...@va...>]

Hello Todd,

I have deleted your quote and I'll get straight to the point :).

1. I am unsure about the idea to have more OU's from a single database.
Having a single database for many different OU's will not make tasks like
backups and restores easier! Also, what is wrong with the idea to provide
some kind of interface between the various databases that would allow you to
exchange information easily between the various OU's? Although I can
understand your idea about the single database for many OU's, practise shows
that this is very often combined with administrative nightmares (backups,
optimization, relocation to a new machine, etc).

2. About the permissions problem you were referring to (one or two 'r' here?
I can have it wrong, I'm a Luxembourger). I really like the Windows NT/2000
platform :). And what I most like about it, is the very powerful and
flexible permissions system. Can't we somehow do something along those lines
for phpWebSite? That would mean to have users, groups that users can belong
to, and "user and group roles". For instance: in order to post a news item,
you need to have the "news editor role". If the user alain either has the
"news editor role", or is member of a group having the "news editor role",
he can post a piece of news. That wouold be very flexible actually.

Thanks for reading !

Re: [Phpwebsite-developers] New version and Roadmap [long]

[Todd O. <to...@da...>]

Yes there will be a rewrite, and no it has not begun yet (at least any
coding).  This mailing list is the official forum to discuss details of the
rewrite.  Over the past several weeks you can see our discussions, which
have dealt mainly with changes to the architecture.  phpWS was built from a
phpNuke core; phpWS(II) will be conceptually different.

The next step for phpWS(II) is to submit a very detailed architectural plan
for everyone to review.  Once the rev2 Roadmap is "approved" by the
developers, then we'll split into teams to begin coding.  The final section
of Brian's Roadmap "Development Team Organization/Management" details this
process well.

I am preparing a software engineering plan for review, but I'm stuck on two
issues.  One of my design goals is to allow a single phpWS installation to
support multiple organizations (500 organizational units [OUs] lets say)
without separate database tables sets.  My original design was a very
structured tree with a branch for each OU; this worked great until I added
the goal of allowing (even encouraging) members of the different OUs to
collaborate on common projects.  Now leaves farther down in the tree
structure (members) have a relationship with leaves in adjacent branches.
Now we don't have a tree, but a mesh!  How do you provide authentication and
control ownership and permissions in this situation?  (I'm working on this
now)

Secondly, how do I allow multiple databases (lets say with 500 OUs each) to
talk with one another for collaboration across database boundries?  I
believe spending the design time to create a distributed scheme will pay off
immeasurably as the project scales.

Many of you may think this is overkill for what you want phpWS to do.  If
you only want to host a single OU, then you don't need this extra
architecture--granted.  The point is that many developers want this
flexibility, which is not available in ANY content management system that I
know about.  I believe this feature will attract many additional developers
in the future, which will improve ALL areas of phpWS.

Right now I don't want to start coding phpWS(II) without thoroughly
considering these design goals.  The code for these "scalability" features
may be written after the rest of the phpWS core, but we don't want to
redesign the core again to add them.  *_It's the difference between a web
SITE and a web application development enviroment._*  Contrary to what many
may be thinking now, I do not believe these design goals will add much
complexity to the project (possibly an additional abstraction layer).

Some perspective:
Last May I met the two high school students that wrote Squirrelmail at the
International Conference on Computing and Missions (iccm.org).  We joked
about how it came to be named after a squirrel, etc.  They wrote the
software for a small missions agency to give a web based alternative to
POP3.  They GPL'd the code and even entered it in ICCM's "Best practices for
missions technologies" where they placed fifth out of five.  If anyone would
have told them or me in May 2000 that Squirrelmail would ever be the number
one PHP web mail product, we would have laughed.  Now Squirrelmail is being
integrated into almost every php portal project around, like phpGroupWare.
They're getting press coverage in many web journals and have an incredible
developer community.

My point is that phpWebSite will be even more successful than Squirrelmail,
if we work hard to produce a project with good architecture and solid code.
In contrast to the constant hacks on phpNuke to add and change
functionality.

Enough pep talk for now.  I'm sure none of you can tell how excited I am
about phpWebSite's ongoing development ;-)

--Todd Owen

[Phpwebsite-developers] New version and Roadmap

[Mike w. <wi...@ce...>]

Hi,
Just want to confirm a few things. Since the release of the roadmap, has the
rewrite begun?  I see Adam has a start, is that the beginning?  I've been
asked and the question has been asked on Sourceforge, "Are you really doing
a rewrite?".  I would like to answer some of these people but I'm unsure
about whether this is supposed to be kept quiet or what?  What is the
projected release of the final phpWebSite 0.8.0?
I'm not trying to hurry anyone, I just want to keep those looking for info
informed.

Thanks,
winzor

Re: [Phpwebsite-developers] OO vs. Procedural Programing

[Todd O. <to...@da...>]

I believe that OOP is the natural next step for phpWebSite.  phpGroupWare,
ezPublish and PEAR are already there.  Since we have decided to use PEAR
whenever possible, we will be using objects anyway.  Why not do the whole
project this way?

Well, two observations.  One, from my experience OO projects take longer to
code than procedural ones--to a point, then OOP wins.  Since I see phpWS as
a major project and not just a hack, I believe the extra overhead (which I
consider small) is justified.  Otherwise, it may be hard to keep phpWS from
migrating back to phpNuke--a LARGE hack.  In the not-so-long-run, class
structures force good coding practices on the project and make it (in my
opinion) easier to go modular.

The second observation was the use of AppState students on the project.  I
don't know about the rest of you, but OOP wasn't on the computer science
radar screen when I was in college (1987-1991).  When Borland's Turbo C 1.0
was released in 1988, I was so relieved.  After reading Kernigan and
Ritchie, I never wrote in Fortran again, unless forced to by some of the
older Electrical Engineering professors.  My compile times dropped by a
factor of 20.  After reading a Borland C++ book in 1993, I was hooked on
OOP--It just made sense.  To make a long story short, I think today's
computer science students are so much sharper than when I went to college
that they can code in anything, anyone can throw at them.  I don't see OOP
as an obstacle to the students.  I see phpWS as an opportunity to
participate in a REAL, ongoing project that won't die at the end of a
semester.

Anyway, this is my case for an object oriented approach and I promise not to
harp any longer.  I continue to be excited about the PEOPLE assembling
themselves into the phpWS group.  We can make phpWS(II) whatever we think it
can be, considering the talent assembled.

Happy Easter,
--Todd

Re: [Phpwebsite-developers] Coding Standards & Internationization

[Todd O. <to...@da...>]

>Well, since the roadmap states we will write our own templating system,
>(which I don't _really_ understand, since being dependant on a GPL template
>system gives you all security against the developers giving up their
product
>you need, plus you can ship a "certified" copy with your product)...

I don't think Brian was saying we should reinvent the wheel as far as
templating is concerned.  There are only a few good templating systems out
there anyway (fasttemplate, phplib, smarty).  My vote is for Smarty.  I
think Brian is saying we should integrate the Smarty code (let's say) into
phpWS so WE are familiar enough with it to continue on if the original
project stalls.

Karsten, you're correct that we shouldn't use an internationalization
technique that requires specific compile time options to implement it.  I
wasn't aware gettext required that.

FYI, phpWS is #7 on the HotScripts.com's PHP  most popular list.  Other PHP
content management systems are up there with us with Nuke at #1.

http://www.hotscripts.com/PHP/

--Todd

Re: [Phpwebsite-developers] Coding Standards & Internationization

[Karsten D. <k.d...@tu...>]

On Sat, Apr 14, 2001 at 10:22:06PM -0400, Todd Owen wrote:
> Has anyone looked at the following for internationalization?
>=20
> http://www.gnu.org/software/gettext/

Well, since the roadmap states we will write our own templating system,
(which I don't _really_ understand, since being dependant on a GPL template
system gives you all security against the developers giving up their product
you need, plus you can ship a "certified" copy with your product)... I think
gettext won't get accepted: It requires even one more thing, and thios time
it must be compiled into PHP, which is a major drawback considering the
amount of people being hosted at (sic!) mass/cheap hosters.

Although it might be interesting to look into the issue :-) Just for the
sake of "knowing what you are talking about" :-)

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

Re: [Phpwebsite-developers] Coding Standards & Internationization

[Todd O. <to...@da...>]

Has anyone looked at the following for internationalization?

http://www.gnu.org/software/gettext/

FYI, Postgresql 7.1 was just released today and contains some great new
enhancements !!!

Keep you eyes on phpShop.org for some interesting changes.  They're taking
their ecommerce package and making it a module for their new shop Core.
Although they use phplib, I believe their upcoming Commerce module could be
converted for use in phpWS--it's a great ecommerce tool.

--Todd

RE: [Phpwebsite-developers] Ideas for current phpWebSite version

[Geoff S. <ge...@ho...>]

Jason:

Right now the config.php file is in the phpwebsite directory. On my servers
that is the public directory which is also the home directory. The owner of
the website has ftp access to their home directory and therefore to the
phpwebsite directory (since they are the same directory). They can fry their
phpwebsite installation if they want to. But, I want to protect their data.
On some of my hosting contracts, the owner manages the website, but, I
manage the database. So, I don't want the website owner to have access to
the database userid and password. In that situation, I need to put the
config.php file in a different directory so that the website owner can't
obtain the database userid and password.

Jason said:

If a user has FTP access, you should have them locked down to not being
able to get out of their own directory.  If thats what you were talking
about.  I've got my Freebsd server locked where only my account can SSH in,
no one can telnet.  Users can ftp but they are chrooted into their home
directory and can't get out of it.  Not sure if thats what your talking
about but thats how I have mine setup...no one will ever view mine...

Geoff said:
> Are we going to put the database prefix variable update into the next
> release?
>
> Also, I have one more suggestion:
>
> I'd like to see the config.php file addressed via a variable so that it
> can be placed somewhere other then the main phpwebsite directory.
>
> There's actually a good reason for this: It contains database userids
> and passwords. I'd like to put the config.php file elsewhere so that if
> a use has ftp access, they still can't get to the config.php file and
> to the database Userid and password.
>
> Geoff
>
>
>
> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> Brian W. Brown
> Sent: Friday, April 13, 2001 2:22 PM
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Ideas for current phpWebSite
> version
>
>
>> 1) Moving all the plugin admin files under the admin directory and
>> under that either have just one directory "plugins" or have "plugins"
>> and then a sub directory for each plugin.  Either way works for me.  I
>> think this is
> a
>>  MUST before we can declare a final 1.0 sometime in the future.
>
> Hmmm... not sure about this. Please discuss this with Matt and Adam and
> see what
> they think.
>
>> 2) Moving all the admin files that are in the main installation
>> directory under the admin folder to get that all cleaned up.
>
> Yes.
>
>> Also, once the calendar is made a plugin, we can remove all the extra
> files
>>  in the main installation directory for that also....
>
> And yes.
>
>> We just have way too many files in the main installation directory and
>> I think it needs cleaned up anyone agree with me on this???
>
> Talk to Adam about this, I tend to agree, but discussion will need to
> occur in
> regards to where to consolidate.
>
>> I'm willing to do all the work on this but I didn't want to start
>> doing it until it was decided by the group.
>
> Thanks for the offer.  Everything is fine by me as outlined above.
>
> --
> Brian W. Brown
> Internet Systems Architect, ESS
> Student Development
> Room 269, John Thomas Hall
> Appalachian State University
> Boone, NC 28608
>
> vox: 828-262-7124
> fax: 828-262-2585
>
>
> _______________________________________________
> 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


Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer


_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Coding Standards & Internationization

[Karsten D. <k.d...@tu...>]

On Sat, Apr 14, 2001 at 03:23:13PM -0400, Todd Owen wrote:
> Are we planning to standardize on Perl or POSIX-extended regular
> expressions?  I thought someone said one was faster than the other, but I
> don't remember which.

Perl! Perl! Perl! They are 1) faster 2) more powerful
                  and 3) way more cool :-)

Unless you do simple replacements, then str_replace can't be beaten. But I
have already seen people who do nl2br with preg_replace :-( Seems as if PHP
offers way too much functions! :-P

> I am excited about this project offering internationalization, although I
> only know English.  However, most of what I've seen has only been European
> support.  How difficult would it be to offer Asian and Arabic character
> support via Unicode?  Having never done this before, I don't know what's
> involoved.  Can someone fill me in?

No knwoledge about that issue on my side :-/

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

[Phpwebsite-developers] Coding Standards & Internationization

[Todd O. <to...@da...>]

Are we planning to standardize on Perl or POSIX-extended regular
expressions?  I thought someone said one was faster than the other, but I
don't remember which.

I am excited about this project offering internationalization, although I
only know English.  However, most of what I've seen has only been European
support.  How difficult would it be to offer Asian and Arabic character
support via Unicode?  Having never done this before, I don't know what's
involoved.  Can someone fill me in?

--Todd

[Phpwebsite-developers] Variable References

[Todd O. <to...@da...>]

The two links below should clarify the variable reference issue (note the
change in 4.0.4).  This issue affects both "normal" variables and objects
equally.

http://php.net/manual/en/html/language.references.whatdo.html
http://php.net/manual/en/html/language.references.arent.html

--Todd

RE: [Phpwebsite-developers] Ideas for current phpWebSite version

[Jason C. <cam...@xp...>]

If a user has FTP access, you should have them locked down to not being 
able to get out of their own directory.  If thats what you were talking 
about.  I've got my Freebsd server locked where only my account can SSH in, 
no one can telnet.  Users can ftp but they are chrooted into their home 
directory and can't get out of it.  Not sure if thats what your talking 
about but thats how I have mine setup...no one will ever view mine...


> Are we going to put the database prefix variable update into the next
> release?
> 
> Also, I have one more suggestion:
> 
> I'd like to see the config.php file addressed via a variable so that it
> can be placed somewhere other then the main phpwebsite directory.
> 
> There's actually a good reason for this: It contains database userids
> and passwords. I'd like to put the config.php file elsewhere so that if
> a use has ftp access, they still can't get to the config.php file and
> to the database Userid and password.
> 
> Geoff
> 
> 
> 
> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> Brian W. Brown
> Sent: Friday, April 13, 2001 2:22 PM
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Ideas for current phpWebSite
> version
> 
> 
>> 1) Moving all the plugin admin files under the admin directory and
>> under that either have just one directory "plugins" or have "plugins"
>> and then a sub directory for each plugin.  Either way works for me.  I
>> think this is
> a
>>  MUST before we can declare a final 1.0 sometime in the future.
> 
> Hmmm... not sure about this. Please discuss this with Matt and Adam and
> see what
> they think.
> 
>> 2) Moving all the admin files that are in the main installation
>> directory under the admin folder to get that all cleaned up.
> 
> Yes.
> 
>> Also, once the calendar is made a plugin, we can remove all the extra
> files
>>  in the main installation directory for that also....
> 
> And yes.
> 
>> We just have way too many files in the main installation directory and
>> I think it needs cleaned up anyone agree with me on this???
> 
> Talk to Adam about this, I tend to agree, but discussion will need to
> occur in
> regards to where to consolidate.
> 
>> I'm willing to do all the work on this but I didn't want to start
>> doing it until it was decided by the group.
> 
> Thanks for the offer.  Everything is fine by me as outlined above.
> 
> --
> Brian W. Brown
> Internet Systems Architect, ESS
> Student Development
> Room 269, John Thomas Hall
> Appalachian State University
> Boone, NC 28608
> 
> vox: 828-262-7124
> fax: 828-262-2585
> 
> 
> _______________________________________________
> 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


Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer

RE: [Phpwebsite-developers] Ideas for current phpWebSite version

[Geoff S. <ge...@ho...>]

Are we going to put the database prefix variable update into the next
release?

Also, I have one more suggestion:

I'd like to see the config.php file addressed via a variable so that it can
be placed somewhere other then the main phpwebsite directory.

There's actually a good reason for this: It contains database userids and
passwords. I'd like to put the config.php file elsewhere so that if a use
has ftp access, they still can't get to the config.php file and to the
database Userid and password.

Geoff



-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Brian W. Brown
Sent: Friday, April 13, 2001 2:22 PM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Ideas for current phpWebSite
version


> 1) Moving all the plugin admin files under the admin directory and under
> that either have just one directory "plugins" or have "plugins" and then a
> sub directory for each plugin.  Either way works for me.  I think this is
a
>  MUST before we can declare a final 1.0 sometime in the future.

Hmmm... not sure about this. Please discuss this with Matt and Adam and see
what
they think.

> 2) Moving all the admin files that are in the main installation directory
> under the admin folder to get that all cleaned up.

Yes.

> Also, once the calendar is made a plugin, we can remove all the extra
files
>  in the main installation directory for that also....

And yes.

> We just have way too many files in the main installation directory and I
> think it needs cleaned up anyone agree with me on this???

Talk to Adam about this, I tend to agree, but discussion will need to occur
in
regards to where to consolidate.

> I'm willing to do all the work on this but I didn't want to start doing it
> until it was decided by the group.

Thanks for the offer.  Everything is fine by me as outlined above.

--
Brian W. Brown
Internet Systems Architect, ESS
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608

vox: 828-262-7124
fax: 828-262-2585


_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Ideas for current phpWebSite version

[Brian W. B. <br...@ap...>]

> 1) Moving all the plugin admin files under the admin directory and under
> that either have just one directory "plugins" or have "plugins" and then a
> sub directory for each plugin.  Either way works for me.  I think this is a
>  MUST before we can declare a final 1.0 sometime in the future.

Hmmm... not sure about this. Please discuss this with Matt and Adam and see what
they think.

> 2) Moving all the admin files that are in the main installation directory
> under the admin folder to get that all cleaned up.

Yes.

> Also, once the calendar is made a plugin, we can remove all the extra files
>  in the main installation directory for that also....

And yes.

> We just have way too many files in the main installation directory and I
> think it needs cleaned up anyone agree with me on this???

Talk to Adam about this, I tend to agree, but discussion will need to occur in
regards to where to consolidate.

> I'm willing to do all the work on this but I didn't want to start doing it
> until it was decided by the group.

Thanks for the offer.  Everything is fine by me as outlined above.

--
Brian W. Brown
Internet Systems Architect, ESS
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608

vox: 828-262-7124
fax: 828-262-2585

Re: [Phpwebsite-developers] OO vs. Procedural Programing

[Todd O. <to...@da...>]

>
> For example:
>
> > later versions of PHP (post 4.04pl1) have the following syntax
> > $myObject =& $thatObject;
> >
> > $newObject =& new Widget;
> >
> > to deal with this issue
>
> does not really create a "true" reference because they don't
> point to the memory
> the other variable is occupying; PHP only interprets these variables as
> references and acts differently.  The copy syntax is still being used.

http://marc.theaimsgroup.com/?l=php-dev

After several hours reading the php-dev mailing list above, I gathered that
the 4.0.4pl1 "fix" resolved this reference issue.  Brian, could you provide
more detail about the lack of a "true" reference?  As I understand, the fix
IS addressing the same memory space.  FYI, one item I did learn from the
list is that parent class constructors are not automatically called when a
child class object is instantiated; you must call the parent constructor
explicitly--to date, no developer is planning to change this "feature".
[Knowing is half the battle]

Note that the php-pear mailing list changed to pear-general, pear-dev and
pear-cvs on March 15th.  pear-db is great for those interested in database
abstraction issues.  All archives at the site above.

--Todd

[Phpwebsite-developers] Ideas for current phpWebSite version

[Jason C. <cam...@xp...>]

I know we should stick to fixing bugs and other things with the current 
version, but I also think we should do a few things to clean up the main 
installation directory.  

1) Moving all the plugin admin files under the admin directory and under 
that either have just one directory "plugins" or have "plugins" and then a 
sub directory for each plugin.  Either way works for me.  I think this is a 
MUST before we can declare a final 1.0 sometime in the future.

2) Moving all the admin files that are in the main installation directory 
under the admin folder to get that all cleaned up.

Also, once the calendar is made a plugin, we can remove all the extra files 
in the main installation directory for that also....

We just have way too many files in the main installation directory and I 
think it needs cleaned up anyone agree with me on this???

I'm willing to do all the work on this but I didn't want to start doing it 
until it was decided by the group.  

I also found a few places where the new table naming convention in the CVS 
version wasn't addressed in the sql calls in the admin functions.  Those 
should also be cleaned up.


Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com
phpWebSite Developer

Re: [Phpwebsite-developers] xml-rpc

[Todd O. <to...@da...>]

http://www.phpbuilder.com/columns/luis20010329.php3

--Todd

[Phpwebsite-developers] Core Features

[Eric W. <eri...@us...>]

I have just a quick question about the "core" of phpWebSiteII.  I know that
the email module will be included and enhanced.  But do we plan to include a
"print article" feature as part of the core.  I think this is a valuable
tool that we should include.

As I learn more about PHP, I look forward to contributing some plug-ins.

Thanks,
Eric

===================================================================
 Eric T. Wallace
 eri...@us...
===================================================================
 "To educate a man in mind and not in morals
  is to educate a menace to society" -- Theodore Roosevelt