phpwebsite-developers — For our development team.

[Phpwebsite-developers] mod maker

[Don S. <do...@se...>]

Is the idea with mod maker is that you add a module or edit a module and 
then to actually commit the changes you "Export Mod Info"?

Anyway I tried to create a simple module and it told me it was "Unable to
write to this module's setup directory" when I went to export it.  The 
phpws structure is all owned by apache.  *shrug*

Don.

Re: [Phpwebsite-developers] adding module

[Don S. <do...@se...>]

Hm well I installed my module via boost but when I come back to the 
"Modules" screen (logged in as a deity), I don't see my module listed 
anywhere.

eek.

Don.

On Fri, 3 Jan 2003, Don Seiler wrote:

> Eh I just saw the error.
> 
> I was developing with my module code in my home directory and was 
> sym-linking it in to the phpws mod directory.  This was giving me "stat 
> failed" errors in phpws/core/File.php on line 44 where it checks for 
> direcotries or files.  It doesn't like symlinks.  So I'm copying things 
> over for now.
> 
> Is it possible to change that file to allow sym links?  I realize I could 
> do it on my own but there might be others in the same boat.
> 
> Don.
> 
> On Fri, 3 Jan 2003, Don Seiler wrote:
> 
> > I'm a dunce or something.
> > 
> > How do I get phpws or boost to see my module?
> > 
> > Don.
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> > 
> > 
> > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

Re: [Phpwebsite-developers] adding module

[Don S. <do...@se...>]

Eh I just saw the error.

I was developing with my module code in my home directory and was 
sym-linking it in to the phpws mod directory.  This was giving me "stat 
failed" errors in phpws/core/File.php on line 44 where it checks for 
direcotries or files.  It doesn't like symlinks.  So I'm copying things 
over for now.

Is it possible to change that file to allow sym links?  I realize I could 
do it on my own but there might be others in the same boat.

Don.

On Fri, 3 Jan 2003, Don Seiler wrote:

> I'm a dunce or something.
> 
> How do I get phpws or boost to see my module?
> 
> Don.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

Re: [Phpwebsite-developers] adding module

[Matthew M. <ma...@tu...>]

> I'm a dunce or something.
> How do I get phpws or boost to see my module?

Seeing as we haven't bothered to write much documentation, you are
forgiven :)

Create a mod_info.php file in your conf directory.

Matt

[Phpwebsite-developers] adding module

[Don S. <do...@se...>]

I'm a dunce or something.

How do I get phpws or boost to see my module?

Don.

Re: [Phpwebsite-developers] I think I broke the demo

[Don S. <do...@se...>]

D'oh I knew that.  Of course I didn't want to leave the poor would-be demo 
users hanging for the possible 59 minutes that I had left it unusable.

Anyway is that a known issue with adding the Calendar?

Don.

On Wed, 1 Jan 2003, Jeremy Agee wrote:

> I didn't reply quickly because cron got this before i did. :-)  Cron is
> set up to redo the demos every hour on the hour so if you mess it up don't
> worry about it. Hope every one had a good new year.
> 
> > Sorry if I wasn't clear.  It was the 0.9.x demo at:
> >
> > http://phpwebsite.appstate.edu/demo/0.9.x/
> >
> > Don.
> >
> > On Mon, 30 Dec 2002, Don Seiler wrote:
> >
> >> I installed calendar (said it was installed succesfully), but when I
> >> tried  to go back to the admin menu screen, all I get is an all-white
> >> page with  only <html><body></body></html> in the source.  Same with
> >> any page now.
> >>
> >> Sorry.  :\
> >>
> >> Don.
> >>
> >>
> >> -------------------------------------------------------
> >> This sf.net email is sponsored by:ThinkGeek
> >> Welcome to geek heaven.
> >> http://thinkgeek.com/sf
> >> _______________________________________________
> >> Phpwebsite-developers mailing list
> >> Php...@li...
> >> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> --
> Jeremy Agee
> phpWebSite Development Team (http://phpwebsite.appstate.edu)
> Appalachian State University
> SF.net id: jagee or 94756
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

[Phpwebsite-developers] phpWebSite Updates

[Matthew M. <ma...@tu...>]

Greetings,

Well, I am back from a relaxing vacation and ready to get to work.

-------------------------
Special thanks to Adam and Steven for keeping the coals warm in CVS with
their new classes. I am anxious to see them in action. If they function in
reality as well as in theory, a huge chunk of work will be eliminated in
module development.

-------------------------

Also thanks to those who spoke up about the module adoption and
registration. Two thoughts on that.

I am not sure if module adoption will occur. If it does, here is what I
suggest.
1) Again, the module developer has to agree to the adoption.
2) The module has to be sponsored by an in-house developer. The sponsor
will work with the current developer and together they will be responsible
for the module.

I think the sponsorship should meet many of the concerns that people have.
The sponsor would keep the code to standard, suggest improvements, etc.
Should the developer and sponsor get it together, we will substitute or
add the module to our distributions. The sponsor will be responsible for
the upkeep of the module should the main developer decide they do not want
to support the module. The sponsor will be responsible for assigning
another sponsor should they be unable to remain with the in-house team.

Let me know if this would work for everyone.

-------------------------------
As for the registration, I agree that having a communication system with
our site is needed, but I agree that we do not want a thread created per
visit to check on it. Further discussion on this is warranted and I am not
sure it can be implemented by final release.

-------------------------------
foreach error on 262: If you are getting this error, please download the
Database.php file from CVS. This was a very strange error because it
worked fine on our side. By default, Pear assigns SQL queries in numeric
order instead of by association. The sqlSelect function was not setting
this to associative until after the query had taken place. The only reason
I can think of as to why it worked sometimes is that some Pear
installations had the associative default set instead of the numeric.
Anyway, I got back from break and I got the same error so I was able to
pinpoint the problem. Please let me know if this solves this problem.

--------------------------------
Plans for Next week

I would really like to press for a final release this upcoming week. This
release would include the upgrading of the phpwebsite home page. I also
want to implement the new core at a couple of university sites. I believe
this will accelerate working the kinks out. If anyone has any issues the
would like to see before final release, please post them.

Also if you are updating your module, please try to make an update package
to post to the update directory. I will be attempting one for calendar
that will include the week view and some bug fixes.

Best regards,
Matt

--
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
phpwebsite.appstate.edu
ess.appstate.edu

Re: [Phpwebsite-developers] Security Alerts/Update Notification

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

Geoff I'm not tying to shoot your idea down but i am going to continue to
play the devils advocate.  Thank for the input!

> Jeremy:
>
> I want to re-iterate the security breech comment I made previously.
>
> I'm suggesting a module that is part of the phpWS core for the purpose
> of  registering a phpWebsite and for receiving security updates.
>
> If the security notices are sent to the phpWS module of registered sites

This would mean our server would have to open an individual http process
to talk to all the site on the list.  What if it would not get there?  It
would also have to keep retrying on fail.  Also this is a lot of server
load.

>  and the phpWS forwards it to an email address specified by the admin on

You now have a client on all installed just sitting there listing.  You
will need to do lots of checks.  You could for example have something say
send the admin a message 1000000 times.  Or some other DOS attack to max
the server cpu.

> his  own site, this guarantees that you don't get the security alerts
> unless you  are actually running phpwebsite and you have registered your
> site.

This can be faked!  Yes it would probable eliminate a few script kiddy's
but this is not who we are really worried about.  It is even easer
considering they can see your code.

>
> This at least guarantees that anyone wanting to receive security
> information for nefarious purposes is running a registered phpWS. This
> won't stop the problem, but, it does put a significant obstacle in the
> way.  I suspect that many pranksters would simply go somewhere else with
> their  pranks because they didn't want to bother with setting up and
> hosting a  phpWS instance to be ready for any security breaches that
> occur.
>
> I figured that the registration / security module would provide a public
>  directory of phpWebsites and that each site admin could choose whether
> or  not they wanted their site listed in the public directory. It seems
> to me  that from a functionality standpoint the registration, security
> updates,  and public directory are closely enough related that a single
> module would  be best because it puts all of these functions in a single
> place for the  site admins.
>
> I like your idea of alerting to a security breach immediately before a
> fix  is available so that admins will know to be on the look out for the
> fix, to  back up their site if needed as protection, and to plan the
> time to  implement the fix when available.
>
> Geoff

-- 
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University
SF.net id: jagee or 94756

Re: [Phpwebsite-developers] Security Alerts/Update Notification

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

Jeremy:

I want to re-iterate the security breech comment I made previously.

I'm suggesting a module that is part of the phpWS core for the purpose of 
registering a phpWebsite and for receiving security updates.

If the security notices are sent to the phpWS module of registered sites 
and the phpWS forwards it to an email address specified by the admin on his 
own site, this guarantees that you don't get the security alerts unless you 
are actually running phpwebsite and you have registered your site.

This at least guarantees that anyone wanting to receive security 
information for nefarious purposes is running a registered phpWS. This 
won't stop the problem, but, it does put a significant obstacle in the way. 
I suspect that many pranksters would simply go somewhere else with their 
pranks because they didn't want to bother with setting up and hosting a 
phpWS instance to be ready for any security breaches that occur.

I figured that the registration / security module would provide a public 
directory of phpWebsites and that each site admin could choose whether or 
not they wanted their site listed in the public directory. It seems to me 
that from a functionality standpoint the registration, security updates, 
and public directory are closely enough related that a single module would 
be best because it puts all of these functions in a single place for the 
site admins.

I like your idea of alerting to a security breach immediately before a fix 
is available so that admins will know to be on the look out for the fix, to 
back up their site if needed as protection, and to plan the time to 
implement the fix when available.

Geoff


At 06:36 PM 1/1/2003 -0500, Jeremy Agee wrote:
>Ok none of his is set in stone but lots of things talked about here have
>been on the drawing board for a while.  I have posted before on some of
>theses subjects so see old email for back info (module master list/running
>phpws master list).
>
>First I would not like to see a user forced to list his site on the list
>just to get security/update advisory's.  If someone does not want to list
>there site they should have the right too.  Basically the who is running
>phpWebSite list should remain separate.
>
>Now to the user part of update/security. We have had plains to build a
>master list for both users and developers.  This list will allow anyone to
>both see/browse modules and to get usefully info (latest version/home
>page/mod developer contact, etc).  This would also be the place where
>developers would make releases/security advisory's.  Any developers would
>have there module/themes/other associated with there account on phpws and
>could be able to update there info on the fly.  The module would then do
>the work to send out updates/advisory's.  Boost would also work with the
>backend of this to allow users on the admin side of there site the same
>flexibility.
>
>I'm going to play devils advocate on the privileged user list for security
>advisories.  There is no way we can control who sees this.  Some one bad
>could just as easily get this information and use it agents every one.
>Not telling every one at once will always have this problem.  I do however
>thank you are right about users having time to get their sites updated and
>secure and not getting blindsided be a cracker.  I would propose this.  We
>have an advisory go out lets say 24 hours ahead of time to simply
>announcing there will be a security update that should be applied.  It
>will not contain any useful info but will be a reminder to people that
>they need to do an update in a day. A full advisory's would follow on the
>release of the patch/upgrade.
>
>Now on to distributing phpWebSite updates and advisory's. I propose that
>we use mailman (mailing lists) for this part.  It means we do not have to
>worry about bounce stuff or any other part of email.  Mailman will do our
>work but will receive its info from the module on the master list system.
>These lists will not be available to receive any email from others.
>Second it will give users a more flexible way of receiving info.  They can
>get digest, each email, ...  There would be two lists the updates list and
>the security list.
>
>Last but not least boost.  Boost will always be a more active client.
>Matt can talk more on this subject but boost will have the ability to be a
>true "update" client.
>
>I would like to add a small side note on licensing of this module.  This
>is not very important now but may need to be discussed.  If this is
>licensed under the GPL commercial/non GPL module will not be able to take
>advantage of this system.  If it is LGPL they will be able to user it.
>This only means more use if it is LGPL so no one will really notice.  It
>would also insure phpWebSite user that are using commercial software will
>stay secure/up2date too.  Remember security is only as good as your
>weakest link!
>
>--
>Jeremy Agee
>phpWebSite Development Team (http://phpwebsite.appstate.edu)
>Appalachian State University
>SF.net id: jagee or 94756
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Phpwebsite-developers mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Security Alerts/Update Notification

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

Ok none of his is set in stone but lots of things talked about here have
been on the drawing board for a while.  I have posted before on some of
theses subjects so see old email for back info (module master list/runnin=
g
phpws master list).

First I would not like to see a user forced to list his site on the list
just to get security/update advisory=92s.  If someone does not want to li=
st
there site they should have the right too.  Basically the who is running
phpWebSite list should remain separate.

Now to the user part of update/security. We have had plains to build a
master list for both users and developers.  This list will allow anyone t=
o
both see/browse modules and to get usefully info (latest version/home
page/mod developer contact, etc).  This would also be the place where
developers would make releases/security advisory=92s.  Any developers wou=
ld
have there module/themes/other associated with there account on phpws and
could be able to update there info on the fly.  The module would then do
the work to send out updates/advisory=92s.  Boost would also work with th=
e
backend of this to allow users on the admin side of there site the same
flexibility.

I=92m going to play devils advocate on the privileged user list for secur=
ity
advisories.  There is no way we can control who sees this.  Some one bad
could just as easily get this information and use it agents every one.=20
Not telling every one at once will always have this problem.  I do howeve=
r
thank you are right about users having time to get their sites updated an=
d
secure and not getting blindsided be a cracker.  I would propose this.  W=
e
have an advisory go out lets say 24 hours ahead of time to simply
announcing there will be a security update that should be applied.  It
will not contain any useful info but will be a reminder to people that
they need to do an update in a day. A full advisory=92s would follow on t=
he
release of the patch/upgrade.

Now on to distributing phpWebSite updates and advisory=92s. I propose tha=
t
we use mailman (mailing lists) for this part.  It means we do not have to
worry about bounce stuff or any other part of email.  Mailman will do our
work but will receive its info from the module on the master list system.=
=20
These lists will not be available to receive any email from others.=20
Second it will give users a more flexible way of receiving info.  They ca=
n
get digest, each email, ...  There would be two lists the updates list an=
d
the security list.

Last but not least boost.  Boost will always be a more active client.=20
Matt can talk more on this subject but boost will have the ability to be =
a
true =93update=94 client.

I would like to add a small side note on licensing of this module.  This
is not very important now but may need to be discussed.  If this is
licensed under the GPL commercial/non GPL module will not be able to take
advantage of this system.  If it is LGPL they will be able to user it.
This only means more use if it is LGPL so no one will really notice.  It
would also insure phpWebSite user that are using commercial software will
stay secure/up2date too.  Remember security is only as good as your
weakest link!

--=20
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University
SF.net id: jagee or 94756

Re: [Phpwebsite-developers] I think I broke the demo

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

I didn't reply quickly because cron got this before i did. :-)  Cron is
set up to redo the demos every hour on the hour so if you mess it up don't
worry about it. Hope every one had a good new year.

> Sorry if I wasn't clear.  It was the 0.9.x demo at:
>
> http://phpwebsite.appstate.edu/demo/0.9.x/
>
> Don.
>
> On Mon, 30 Dec 2002, Don Seiler wrote:
>
>> I installed calendar (said it was installed succesfully), but when I
>> tried  to go back to the admin menu screen, all I get is an all-white
>> page with  only <html><body></body></html> in the source.  Same with
>> any page now.
>>
>> Sorry.  :\
>>
>> Don.
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Phpwebsite-developers mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>>
>>
>>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers


--
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University
SF.net id: jagee or 94756

Re: [Phpwebsite-developers] Module Substitution

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

Adam:

As someone who has programmed in God-only-knows how many languages over the 
last 30 years, I can tell you that phpWebSite will die a slow and agonizing 
death unless you maintain architectural and programming standards. Here's why:

As a system ages, bugs are fixed, features are added, and things are 
changed for dozens of reasons. If the work is simply done to meet a 
deadline without any real thought to architecture and standards, eventually 
(and I guarantee this will happen) the code becomes so patched and so 
unwieldy and so tied-in-together weird ways that no one actually knows how 
the code really works and changing one thing will break another seemingly 
unrelated thing. Programmers make it even worse by changing code that looks 
like it should have something to with what they are working on for extra 
insurance. At this point, you can only program the system by folklore and 
eventually you have to do a complete re-write of the system because it is 
so cumbersome, nothing can be done.

So, when folks complain about you pushing them on standards and 
architecture, tell them to shut their traps and get back to work!

By the way, this usually works: "OK, you can code this any way you want as 
long as you agree to be available 24 hours a day 7 days a week for as long 
as your code is part of this system." (That's not really a good bargain for 
you because the code usually affect other areas of the system as well.)

Geoff

At 08:25 PM 12/31/2002 -0500, ad...@tu... wrote:
>Doh!  I guess I missed this before I posted my last mail.  I like this
>idea, especially the part about "Continues to reflect architecture and
>coding standards".  I'm sure the guys hate me sometimes since I'm kind of
>the defacto standards and structure dude and I get onto peeps about their
>code.
>User interface can be flexible as far as how it looks since all modules in
>the future should template ALL their output.  This will allow admins, or
>Phil :), to setup their user interfaces anyway they wish ().
>
>+1 from me Geoff
>
>Adam
>
> > Also, if the module becomes part of the distribution, then the in-house
> > developer is de facto responsible for it even if the original developer
> > is  still involved. The in-house developer takes on responsibility to
> > insure  that the module:
> >
> > 1. Continues to reflect architecture and coding standards.
> > 2. Maintains consistent user interface.
> > 3. Enhancements meet the approval of the in-house team.
> >
> > Seems to me there ought to be three levels of module:
> >
> > 1. Those developed in-house or "taken over" as part of the distro. 2.
> > Those that meet  a certification standard and are considered "official"
> > modules developed by a third-party.
> > 3. Those that work with phpWebsite but which have not been reviewed and
> > approved.
> >
> > Geoff
> > www.hostricity.com
> >
> >
> > At 01:46 PM 12/28/2002 -0500, Matthew McNaney wrote:
> >>This is not in direct response to Eloi's new module (good job btw) but
> >> just a question that needs consideration for the future.
> >>
> >>Suppose someone creates a better content module than one produced
> >> in-house. I know that many of the developers here have several things
> >> going on at one time (I can think of two huge ones off the top of my
> >> head). Perhaps, if an outside developer is willing, we could ask if
> >> they would like their module to become part of our distro.
> >>
> >>Here is the rub though.
> >>- We would all need to agree it should be done.
> >>- The in house developer would need to agree
> >>- The outside developer would have to guarantee support.
> >>
> >>Again, this may not come up, but I know that there are some modules we
> >> are working on that might have a more dedicated developer outside the
> >> unversity.
> >>
> >>Please discuss with pros and cons for both sides.
> >>
> >>Matt
> >>--
> >>Matthew McNaney
> >>Internet Systems Architect
> >>Electronic Student Services
> >>Appalachian State University
> >>Phone: 828-262-6493
> >>phpwebsite.appstate.edu
> >>ess.appstate.edu
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Phpwebsite-developers mailing list
> >>Php...@li...
> >>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Phpwebsite-developers mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
>---------------------------------------------------------------------
>Adam Morton
>Developer - Electronic Student Services
>http://phpwebsite.appstate.edu
>Founder - Appalachian Linux Users Group
>http://alug.appstate.edu
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Phpwebsite-developers mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Hello again

[Don S. <do...@se...>]

I'm just wondering how would boost know of other modules?

Scenario:

Joe Blow downloads phpws 0.9.0.  Will boost have a button for installing, 
say, my fantasy football module?  Just wondering if module developers 
should "register" their modules with a central repository.  I think I 
brought this up before and would like to know how this is going to be 
handled.

Don.

On Tue, 31 Dec 2002 ad...@tu... wrote:

> Hello folks!
> 
> I've been doing the holiday thing and just tried to catch up on everything
> that's been going on while I was gone.  I have a few things in my head
> that I want to get on the list.  Some are thoughts, some are opinion.  If
> they need a little more explanation, let me know :)
> 
> 1. Outside module developement:  Our goal with the phpwebsite core was to
> make module developement as easy as possible.  The main reason for this is
> to see a huge surge in outside module developement and make phpwebsite the
> standard platform for web based application developement. Any constructive
> feedback on the API or structure of the core would be GREATLY appreciated.
> 
> 2. I do not agree with having an outside module become part of the
> phpwebsite distro.  We attempted this in the past and it blew up in our
> faces several times.  Mostly because the developers of the module
> abandoned either their module or the phpwebsite project all together
> (names? nah! :) ).  However, I do believe we need to draw attention to any
> outstanding modules that are developed by volunteers.  This will hopefully
> be a tradition carried on by the current phpwebsite modules site
> (sourceforge?).  If not, I would be more than happy to pick up that torch.
> 
> 3. No BBQ please Matt....we love res :)
> 
> 4. Steven and I have been coding our butts off over the break implementing
> 2 new core classes and a new 0.9.x module that I think everyone will want
> (it may become part of the main distro).  I just want everyone to have a
> heads up on the 2 core classes since they are the future for module
> developement in phpwebsite.
> The classes are PHPWS_Item and PHPWS_Manager.  The code currently in cvs
> is in beta.  Steven and I are testing and revising it as we develop a
> module using these classes.  The code is very well documented and a
> developers manual is in the works. I'll be sure to post when everything is
> available for wide use.
> 
> 5. Eloi! The bug you posted about on this list had the class name
> PHPWS_ArticleManager in it.  Is this not your module?
> 
> OK I'll quit typing now...
> 
> Happy New Year!
> Adam
> 
> ---------------------------------------------------------------------
> Adam Morton
> Developer - Electronic Student Services
> http://phpwebsite.appstate.edu
> Founder - Appalachian Linux Users Group
> http://alug.appstate.edu
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

Re: [Phpwebsite-developers] Module Substitution

[<ad...@tu...>]

Doh!  I guess I missed this before I posted my last mail.  I like this
idea, especially the part about "Continues to reflect architecture and
coding standards".  I'm sure the guys hate me sometimes since I'm kind of
the defacto standards and structure dude and I get onto peeps about their
code.
User interface can be flexible as far as how it looks since all modules in
the future should template ALL their output.  This will allow admins, or
Phil :), to setup their user interfaces anyway they wish ().

+1 from me Geoff

Adam

> Also, if the module becomes part of the distribution, then the in-house
> developer is de facto responsible for it even if the original developer
> is  still involved. The in-house developer takes on responsibility to
> insure  that the module:
>
> 1. Continues to reflect architecture and coding standards.
> 2. Maintains consistent user interface.
> 3. Enhancements meet the approval of the in-house team.
>
> Seems to me there ought to be three levels of module:
>
> 1. Those developed in-house or "taken over" as part of the distro. 2.
> Those that meet  a certification standard and are considered "official"
> modules developed by a third-party.
> 3. Those that work with phpWebsite but which have not been reviewed and
> approved.
>
> Geoff
> www.hostricity.com
>
>
> At 01:46 PM 12/28/2002 -0500, Matthew McNaney wrote:
>>This is not in direct response to Eloi's new module (good job btw) but
>> just a question that needs consideration for the future.
>>
>>Suppose someone creates a better content module than one produced
>> in-house. I know that many of the developers here have several things
>> going on at one time (I can think of two huge ones off the top of my
>> head). Perhaps, if an outside developer is willing, we could ask if
>> they would like their module to become part of our distro.
>>
>>Here is the rub though.
>>- We would all need to agree it should be done.
>>- The in house developer would need to agree
>>- The outside developer would have to guarantee support.
>>
>>Again, this may not come up, but I know that there are some modules we
>> are working on that might have a more dedicated developer outside the
>> unversity.
>>
>>Please discuss with pros and cons for both sides.
>>
>>Matt
>>--
>>Matthew McNaney
>>Internet Systems Architect
>>Electronic Student Services
>>Appalachian State University
>>Phone: 828-262-6493
>>phpwebsite.appstate.edu
>>ess.appstate.edu
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Phpwebsite-developers mailing list
>>Php...@li...
>>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers


---------------------------------------------------------------------
Adam Morton
Developer - Electronic Student Services
http://phpwebsite.appstate.edu
Founder - Appalachian Linux Users Group
http://alug.appstate.edu

[Phpwebsite-developers] Hello again

[<ad...@tu...>]

Hello folks!

I've been doing the holiday thing and just tried to catch up on everything
that's been going on while I was gone.  I have a few things in my head
that I want to get on the list.  Some are thoughts, some are opinion.  If
they need a little more explanation, let me know :)

1. Outside module developement:  Our goal with the phpwebsite core was to
make module developement as easy as possible.  The main reason for this is
to see a huge surge in outside module developement and make phpwebsite the
standard platform for web based application developement. Any constructive
feedback on the API or structure of the core would be GREATLY appreciated.

2. I do not agree with having an outside module become part of the
phpwebsite distro.  We attempted this in the past and it blew up in our
faces several times.  Mostly because the developers of the module
abandoned either their module or the phpwebsite project all together
(names? nah! :) ).  However, I do believe we need to draw attention to any
outstanding modules that are developed by volunteers.  This will hopefully
be a tradition carried on by the current phpwebsite modules site
(sourceforge?).  If not, I would be more than happy to pick up that torch.

3. No BBQ please Matt....we love res :)

4. Steven and I have been coding our butts off over the break implementing
2 new core classes and a new 0.9.x module that I think everyone will want
(it may become part of the main distro).  I just want everyone to have a
heads up on the 2 core classes since they are the future for module
developement in phpwebsite.
The classes are PHPWS_Item and PHPWS_Manager.  The code currently in cvs
is in beta.  Steven and I are testing and revising it as we develop a
module using these classes.  The code is very well documented and a
developers manual is in the works. I'll be sure to post when everything is
available for wide use.

5. Eloi! The bug you posted about on this list had the class name
PHPWS_ArticleManager in it.  Is this not your module?

OK I'll quit typing now...

Happy New Year!
Adam

---------------------------------------------------------------------
Adam Morton
Developer - Electronic Student Services
http://phpwebsite.appstate.edu
Founder - Appalachian Linux Users Group
http://alug.appstate.edu

Re: [Phpwebsite-developers] Security Alerts

[Matthew M. <ma...@tu...>]

I agree. Originally it was going to be built into the install. I'll see if
this is something that can be built in before final release.

Matt

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
phpwebsite.appstate.edu
ess.appstate.edu

Re: [Phpwebsite-developers] Security Alerts

[Philip M. <lis...@li...>]

+1 from me, would love to get security updates.

-- 
Philip McAllister < uk . co . liquidsand @ phil >
  "All I ask is the chance to prove that money can't make me happy"
  - Spike Milligan

Re: [Phpwebsite-developers] I think I broke the demo

[Don S. <do...@se...>]

Sorry if I wasn't clear.  It was the 0.9.x demo at:

http://phpwebsite.appstate.edu/demo/0.9.x/

Don.

On Mon, 30 Dec 2002, Don Seiler wrote:

> I installed calendar (said it was installed succesfully), but when I tried 
> to go back to the admin menu screen, all I get is an all-white page with 
> only <html><body></body></html> in the source.  Same with any page now.
> 
> Sorry.  :\
> 
> Don.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

[Phpwebsite-developers] I think I broke the demo

[Don S. <do...@se...>]

I installed calendar (said it was installed succesfully), but when I tried 
to go back to the admin menu screen, all I get is an all-white page with 
only <html><body></body></html> in the source.  Same with any page now.

Sorry.  :\

Don.

Re: [Phpwebsite-developers] Security Alerts

[Eloi G. <el...@re...>]

+1

Sounds cool.  Sounds like a modified links module.

Re: [Phpwebsite-developers] Security Alerts

[Don S. <do...@se...>]

+ infinity + 1

Don.

On Mon, 30 Dec 2002, Geoff Staples wrote:

> Here's another one to be batted around.
> 
> I'd like to see a registry of all sites using phpWebsite. The registry 
> would include contact information for the proprietor and whether the site 
> should be listed in a public directory of phpWebsites or not.
> 
> One purpose of the registry would be so that when security issues are 
> discovered, an alert can be sent to registered sites a day or two before 
> the security issue is published publicly on phpwebsite.appstate.edu.
> 
> If this is done by a module in phpWebsite that receives the information and 
> then emails it to the proprietor, only active websites would receive the 
> alert. This would prevent anyone from registering just to get the security 
> updates. (They'd at least have to have a running phpWebSite).
> 
> Theoretically, this gives phpWebSite proprietors an opportunity to fix 
> their sites BEFORE the security breach is made public. I'm pretty sure that 
> two of my sites were defaced because the person who did the dirty deed 
> found out about the breach by reading about it on phpwebsite.appstate.edu 
> before I did.
> 
> I realize that there are hacker sites, etc. that publish this stuff and 
> which we have no control. However, just making sure that all registered 
> sites are alerted as quickly as possible would be a big help.
> 
> I discussed this with Brian Brown months ago and his take was "something 
> like that would be great but, I'm not sure that it is workable."
> 
> By the way, a counter could be incorporated so that we could say 
> "phpWebSite now has 876,477 active sites."
> 
> So, having worked through this, here's my suggestion for a registration module:
> 
> Registration module would:
> 
> Allow admin to register site with the phpWebSite registry.
> 
> Specify whether or not site will be listed in the public directory at 
> phpwebsite.appstate.edu.
> 
> Allow admin to receive notification of updates to phpWebSite and to modules.
> 
> Allow admin to receive communications from phpwebsite.appstate.edu such as 
> security alerts (admin specifies an email address. The website receives the 
> communication and forwards it to the email address. That way, if the site 
> is no longer running, or, no longer using phpwebsite, the message doesn't 
> go to that person.)
> 
> Maintain a count of all phpWebsites.
> 
> Maintain a public directory of all phpWebSites that want to be listed.
> 
> Geoff
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

[Phpwebsite-developers] Security Alerts

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

Here's another one to be batted around.

I'd like to see a registry of all sites using phpWebsite. The registry 
would include contact information for the proprietor and whether the site 
should be listed in a public directory of phpWebsites or not.

One purpose of the registry would be so that when security issues are 
discovered, an alert can be sent to registered sites a day or two before 
the security issue is published publicly on phpwebsite.appstate.edu.

If this is done by a module in phpWebsite that receives the information and 
then emails it to the proprietor, only active websites would receive the 
alert. This would prevent anyone from registering just to get the security 
updates. (They'd at least have to have a running phpWebSite).

Theoretically, this gives phpWebSite proprietors an opportunity to fix 
their sites BEFORE the security breach is made public. I'm pretty sure that 
two of my sites were defaced because the person who did the dirty deed 
found out about the breach by reading about it on phpwebsite.appstate.edu 
before I did.

I realize that there are hacker sites, etc. that publish this stuff and 
which we have no control. However, just making sure that all registered 
sites are alerted as quickly as possible would be a big help.

I discussed this with Brian Brown months ago and his take was "something 
like that would be great but, I'm not sure that it is workable."

By the way, a counter could be incorporated so that we could say 
"phpWebSite now has 876,477 active sites."

So, having worked through this, here's my suggestion for a registration module:

Registration module would:

Allow admin to register site with the phpWebSite registry.

Specify whether or not site will be listed in the public directory at 
phpwebsite.appstate.edu.

Allow admin to receive notification of updates to phpWebSite and to modules.

Allow admin to receive communications from phpwebsite.appstate.edu such as 
security alerts (admin specifies an email address. The website receives the 
communication and forwards it to the email address. That way, if the site 
is no longer running, or, no longer using phpwebsite, the message doesn't 
go to that person.)

Maintain a count of all phpWebsites.

Maintain a public directory of all phpWebSites that want to be listed.

Geoff

Re: [Phpwebsite-developers] Module Substitution

[Don S. <do...@se...>]

So would you guys like us to discuss modules we want to develop first?  I 
guess I missed the beginning of this thread.

I do think it's a good idea, to avoid overlap and then to combine 
resources.

I personally have 3 modules on my plate.  First one I can't really discuss 
yet.  Second one is a full-fledged contact database that will take 
sub-modules to turn it into things like an alumni database to rival 
pay-for-play services like classmates.com and alumni.net.  Third is the 
big papa.  A fantasy-sports module that will allow a single host to run 
(in theory) infinite leagues of varing sports.

The contact project is on sourceforge as aevum.  The fantasy project is on 
sourceforge as ffl.  If anyone wants to help or even offer suggestions or 
testing (although all projects are in alpha planning at the moment), my 
co-developers and I would welcome you.

Thanks,
Don.

On Mon, 30 Dec 2002, Eloi George wrote:

> +1 for Geoff's 3-tier structure.
> 
> Since I can really only explain from the viewpoint of my module, let me give
> some background.  The idea for Article Manager was born from a feature
> request that I posted on SF. After some thought, I realized that bugging
> Matt & Adam for features that probably only I needed would take their time
> away from the vastly more important and difficult task of creating what I
> think is the greatest CMS ever.  So I learned PHP & started writing.
> 
> I later sent Adam a msg saying that I'd like to send my code up for possible
> development as the new PageMaster, but then I ran across a few messages on
> 'Nuke boards from people saying that phpWS looks promising, but there're
> only a few third-party modules available.  This struck me because it was the
> same concern I had when I first discovered phpWS.
> 
> Announcements & PageMaster are wonderful modules.  They're easy to install
> and the average admin can get started without clicking on the help buttons
> to find out what a "publication date" is used for.  Article Manager is
> geared more for "enterprise" sites, like schools, online 'zines, and
> information repositories.  Still easy to use, but overkill for a web newbie
> wanting to put up a blog.  This week I'll finish the Import/Export functions
> so that you're never locked into any particular module.
> 
> I'd be estatic if Article Manager became a part of the distro, but and the
> end of it all I'd be happier if instead of people saying "phpWS is great,
> but there's no 3rd-party modules for it",  they start saying "phpWS offers
> excellent ease & functionality out of the box, and once you start plugging
> in those 3rd-pary modules -- Wow!"
> 
> I also agree with Geoff's assertion.  I am committed to supporting my
> modules and the source code is heavily commented so anyone else can get up
> to speed pretty quickly, but heaven forbid a shark gets me (more likely
> 'cause I live on a tropical island) development of the core phpWS shouldn't
> get set back.
> 
> -Eloi George-
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
> 

Re: [Phpwebsite-developers] Module Substitution

[Eloi G. <el...@re...>]

+1 for Geoff's 3-tier structure.

Since I can really only explain from the viewpoint of my module, let me give
some background.  The idea for Article Manager was born from a feature
request that I posted on SF. After some thought, I realized that bugging
Matt & Adam for features that probably only I needed would take their time
away from the vastly more important and difficult task of creating what I
think is the greatest CMS ever.  So I learned PHP & started writing.

I later sent Adam a msg saying that I'd like to send my code up for possible
development as the new PageMaster, but then I ran across a few messages on
'Nuke boards from people saying that phpWS looks promising, but there're
only a few third-party modules available.  This struck me because it was the
same concern I had when I first discovered phpWS.

Announcements & PageMaster are wonderful modules.  They're easy to install
and the average admin can get started without clicking on the help buttons
to find out what a "publication date" is used for.  Article Manager is
geared more for "enterprise" sites, like schools, online 'zines, and
information repositories.  Still easy to use, but overkill for a web newbie
wanting to put up a blog.  This week I'll finish the Import/Export functions
so that you're never locked into any particular module.

I'd be estatic if Article Manager became a part of the distro, but and the
end of it all I'd be happier if instead of people saying "phpWS is great,
but there's no 3rd-party modules for it",  they start saying "phpWS offers
excellent ease & functionality out of the box, and once you start plugging
in those 3rd-pary modules -- Wow!"

I also agree with Geoff's assertion.  I am committed to supporting my
modules and the source code is heavily commented so anyone else can get up
to speed pretty quickly, but heaven forbid a shark gets me (more likely
'cause I live on a tropical island) development of the core phpWS shouldn't
get set back.

-Eloi George-

Re: [Phpwebsite-developers] PHP 4.3 and PEAR

[Don S. <do...@se...>]

My intent was more or less to notify of PEAR 1.0.  I'm not sure if PEAR 
1.0 would require PHP 4.3.  Hopefully not.

Don.

On Sat, 28 Dec 2002, Geoff Staples wrote:

> I saw the "my provider won't upgrade to PHP 4.3" complaint.
> 
> Apologies to all for stating the obvious!
> 
> As a web host, I can tell you that we won't upgrade to PHP 4.3 for awhile. 
> In a production environment, it is considered prudent to wait for the bugs 
> to be shaken out before upgrading.
> 
> Within a few weeks or months, we will upgrade based on the field experience 
> of others.
> 
> Here's what needs to happen:
> 
> phpWebSite needs to be tested on 4.3 with native Pear AND on PHP 
> 4.2.whatever with the locally installed PEAR library for some indefinite 
> period of time. That way, everyone currently using phpWebSite who wants to 
> migrate to 0.9.0 will be able to do so.
> 
> At some point in 2003 we should be able to abandon testing on PHP 4.2 with 
> local PEAR.
> 
> HOWEVER, there may still be an issue with web hosts that have upgraded to 
> PHP 4.3, but have not installed the native PEAR libraries. Normally, this 
> would not happen unless there are problems with the native PEAR libraries. 
> So, we won't know for a while whether phpWebSite will have to be tested 
> with PHP 4.3 and locally installed PEAR.
> 
> Eventually, the problem will resolve itself. In the mean time, we need to 
> make sure that phpWebSite doesn't leave loyal users behind because of a 
> temporary bump in the road.
> 
> There will come a point when the appropriate answer to "my host won't 
> upgrade" is "find a new host". But, until that time, we need to do a little 
> hand-holding.
> 
> We are currently on PHP 4.2.2 so I we will be testing phpWebSite 0.9.rc3 in 
> this environment with the PEAR library locally installed.
> 
> Geoff
> www.Hostricity.com
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> 
> 
>