phpwebsite-developers Mailing List for phpWebSite Content Management System (Page 140)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

This just in ...
i just got an email from NuSphere that mentions PHPWebsite as one of their
bundled packages...

OK cvs is now back up but at a new location.  You can now find it at 
res1.stddev.appstate.edu.  It is now on the academic network so there will 
be fewer problems with network stability.  Sorry for the inconvenience.

This guy is making very interesting use of XML-RPC

http://sourceforge.net/projects/weborganizer/

clayton

I just wanted to let every one know that we will be having some down time on
the cvs server.  It is on a separate network from tux(the webserver) so only
the CVS server will be down.  I am in the process of getting the cvs server
moved to the academic net and off of the resnet network.  I will let every
one know the new info they will need.  I am sorry for the inconvenience but
this is out of my control. I was not given any prior notice of the resnet
down time and there for was not able to do a smooth transition.

This showed up recently at Freshmeat & Hotscripts

http://www.miro.com.au/

the software is running the site. looks interesting...

clayton

This looks interesting, php/oop cms, documentation is sparse to null,
have to read the code, author references zope as an influence... it's
a quick read:
http://pecos.screwdriver.net/

BTW, anyone seen this template class:  http://sourceforge.net/projects/xtpl/
Cheers,
-WD

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

> This
> script will allow you to edit and comment php include files
> through a web page front end. You can find a better explanation
> and a demo here http://xhawk.net/iniread/

Yes, I think this could be useful.  Thanks Mike!

Brian

--
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

Maybe this has been brought up, but I found this little script that would be
very valuable to newbie admins to phpwebsite. This script will allow you to
edit and comment php include files through a web page front end. You can
find a better explanation and a demo here http://xhawk.net/iniread/

Thanks,
winzor

I was looking around and found this hack It looks promising the author posted it on the phpbb hacks forum and from what I hear, it is what they are working on to achieve for phpbb2 ..

The concept of the code is simple
You can now assign the table names you want phpbb to use.  I'm currently looking at it to see if it can work with the PWS user table as long as it is one database..

If any of the other developers want to check it out go to http://www.weero.f2s.com/phpBB the download is located at http://www.weero.f2s.com/.

Laterz
Trajick
phpWebSite Developer

> Part 2 will include roles and permissions and their relationship to users
> and groups.
>
> I didn't want the posts to be too long and deal with too many items at
once.
>
oh, i see.
 i dont know if you're dealing with the issue of group types, but i think
this should be addressed, as this can greatly simplify administration.

 for instance, when AppState upgrades to phpWS/2 and wants to add register
all their departments, all that should be needed is for the administrator to
select the group type "Department" from a pull down, give a name and other
basic info, and the system should insert the proper table entries and create
the necessary relations so that roles, permissions, etc, dont have to be
redone per department (assuming of course that all departments are similar).
IOW, "Department" would be specified as a group type, and we can associate
roles, etc with this group type (eg Faculty, Staff, Student, etc). this goes
for other similar organizations, where there are multiple groups of similar
structure.

clayton

Part 2 will include roles and permissions and their relationship to users
and groups.

I didn't want the posts to be too long and deal with too many items at once.

--Todd

confirm 438048

> What file extension will we use for included files?
> included.php, included.inc, included.inc.php, etc.

I vote for included.inc.php

>
> What file extension will we use for classes?
> included.class, included.class.php, etc.?

and included.class.php

> Does anyone have a comprehensive set of CSS descriptors we should use? ex.
> .big, .red, .bigred, .path, .smallnav, etc.
> ezPublish has a good start.  Should we use theirs?
> This will be a standard for the core and module programmers.

Contact Brian Lambeth regarding this - I have no problem adopting the ezPublish
CSS descriptors (especially since the current CSS descriptors leave *a lot to be
desired*) ;)

> P.S.  Can we change the term plug-ins to modules?

Originally, we choose the term "plug-in" to differentiate ourselves from Nuke's
"Add-ons" and felt the term implied a certain ease of use.  At a certain level I
don't care, but don't think the term "plug-in" is bad (maybe because it smells
so fresh?) I say let's post a survey and go with the majority...

--
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

Todd,
  good to hear from you. i was about to fire up a "call to action" email
before i saw your post.

> *Users table will be minimalistic
absolutely !

> * User_space and Group_space will be flat.
> A flat groupspace enables any user to be a member of any group.  This is
> great until you only want a subset of the Physics Dept (group) to be
> moderators on Physics Dept announcements.  I decided that instead of
FORCING
> a group tree hierarchy, I would let the individual site administrator make
> sure that only Physics group member were in the Physics-moderators group.

this can be simplified by allowing roles on the group membership table,
which to me is a necessity anyway in the cases your envisioning. in the
Physics Dept, for instance, i want to be able to set permissions on
different activities based on whether a person is Chair, Faculty, Staff,
Student or Moderator (administrator). the ACS code i ported accomodates
this, though i can probably simplify it a bit. more comments below ...

another idea that may make the administator's job easier is a group
membership queue with 1 click approval on the admin side. that way anyone
can try to join, but they're only in if approved. this can be made optional,
too.

> Groups table:
> group_id  INTEGER primary key
> name  VARCHAR(32)
> parent_id INTEGER [foreign key to group_id]
> [root has same group and parent id]
or parent_id == NULL

>
> group_membership table (matrix):
> group_id INTEGER [foreign key]
> user_id INTEGER [foreign key]
> index on group_id
> index on user_id
> index on group_id, user_id
> [speeds up membership searches significantly]

i think we should support roles for the reasons mentioned above. this should
help mitigate the effects of a flat user-space (at least as it relates to
group). as explained above, it allows more natural expression of other core
processes (access control/security and task partitioning, etc).

im trying to get an app out the door, but i'll post more as time permits.

clayton

*Users table will be minimalistic
Instead of adding everything in the world to the users table, only
_essential_ information will be provided like unique user_id, username,
first name, last name, email address, preferred language, timezone, etc.
Non-core information like department, personality profile, etc. can be
implemented in modules (and additional db table with user_id as the foreign
key [this id is used alot]).  A state field will have something like 1 for
active, 2 for disabled, 3 for suspended, etc.  A creation date will also be
added; last accessed will not be here since this is more of a read-mostly
table.  An authentication type field will be present with the following
philosophy: 1-database authentication, 2-affiliated site authentication (see
my previous xml-rpc post), 3-LDAP authentication, etc.  An auth field will
contain XML with is specific to the authentication type field selected as
follows:

Assume database authentication:
<password type="md5">3hjk7894kjkoldf9lkju8</password>

Assume affiliated site authentication:
<authURL>www.example.com/authenticate.php</authURL>
<methodCall>
      <methodName>authenticate.remote</methodName>
      <params>

<domain><value><string>phpwebsite.appstate.edu</string></value></domain>
        <username><value><string>user1</string></value></username>
      </params>
</methodCall>

Assume LDAP authentication:
<ldap_server>ldap.example.com</ldap_server>
<ldap_user>, etc.....

This core structure provides for writing only database authentication now
and adding many other types in the future, even using a SHA hash ;-)  **The
XML field provides this extensibility without lots of rarely used database
fields that must be added every time a new core authentication type is
added.**  You'll see my draw to XML database files throughout the project
for this very reason!

* User_space and Group_space will be flat.
After considering many alternatives for user and group space, I decided that
flat was best.  Of course a flat namespace for users and groups is the most
simple approach, I feared it would hinder administration for large
organizations like colleges or school systems, which may have 25,000 members
that must be _managed_.  This is unlike slashdot style sites where anyone
can join and userspace is _really_ flat.

A flat namespace also gives the most flexibility for use, although the
administration might be more involved.  Let's say App State has 10,000
students and faculty on their site and has 15 departments with different
administrators.  If the name and group space was in a tree hierarchy, how
would a Physics Dept student get to edit an English Dept document?  The
point is that you can administer a flat namespace as a tree, but not vice
versa.  Anyway, custom modules can be created for specialized administration
where needed.

A flat groupspace enables any user to be a member of any group.  This is
great until you only want a subset of the Physics Dept (group) to be
moderators on Physics Dept announcements.  I decided that instead of FORCING
a group tree hierarchy, I would let the individual site administrator make
sure that only Physics group member were in the Physics-moderators group.

This is my philosophy for the phpWebsite core: **Make it as Flexible as
Possible.**  I will add a parent field to the group db schema to provide for
those who want to write a custom module that will enforce the hierarchy
through administration, but not in the core!

Groups table:
group_id  INTEGER primary key
name  VARCHAR(32)
parent_id INTEGER [foreign key to group_id]
[root has same group and parent id]

group_membership table (matrix):
group_id INTEGER [foreign key]
user_id INTEGER [foreign key]
index on group_id
index on user_id
index on group_id, user_id
[speeds up membership searches significantly]

--Todd

Good to here from ya!  I've been working on some plug-ins using class 
structures and it works pretty damn good too!  We had someone submit a 
class structure to the site and then I went and just built a test plug-in 
with the referrer code and it seems to work just fine.  Can't wait to have 
some specs and info to look at!

Oh, and that "sick building syndrome" as they call it most of the time down 
here, it was at my High School down here my Senior year...that school is 
toast now, they've built a new one a few years ago and trashed the old one 
I went to.  But that crap has been in Tampa buildings, Polk County and a 
few other places in the Central FL area.  Its not that uncommon down here.  
We know we got sick from it in high school, there was just something about 
the building....

> I've been quiet the last few days because I am a principal with IMEC
> Engineers, an environmental engineering firm.  At the request of a
> local county, we took air samples and tested surface wipes at a local
> high school of 1200 students.  To make a long story short, the
> superintendent closed the school the day after we gave him the test
> results, which was last Thursday. Needless to say, the news coverage,
> angry parents and press conferences have kept me pretty busy.  You can
> read for yourselves (and watch some RealVideo too):
> 
> http://www.wsls.com
> http://www.wset.com
> http://www.wdbj7.com/scripts/heads.htm
> 
> Anyway, I did get the ear of Bedford County's technology director (who
> had to run sound for the press conferences).  He is really excited
> about using phpWebSite/2 throughout the county, when it is completed.
> 
> I am preparing several installments of my phpWS/2 master plan, which I
> will start releasing tonight or tomorrow.  I've collected the input
> from posts to this group, posts to the sourceforge forums and telephone
> conversations with others, as well as reviewed MANY other open source
> packages.  I am committed to make phpWS/2 an enterprise level product
> that is easy to use (not an easy task).  I've missed many hours of
> sleep working on a plan to get the rewrite up and running to keep
> everyone moving forward.  Therefore, I will be presenting specific
> design proposals for your review.  If you have strong objections to a
> particular point, please raise them here; otherwise, they'll be part of
> the core.
> 
> If you haven't already read Brian Brown's phpWebSite/2 Roadmap, please
> do so now (it's in the list archives).  Once these specific design
> features are decided, I will provide pseudo code, rough class
> definitions, module API details and db schemas for everyone's review. 
> Once this is OK'd, I believe phpWS/2 will reach critical mass and
> another freshmeat announcement should be made.  I trust other
> developers will see the master plan and want to join the project.  The
> core coding will then begin simultaneously with some of Jason's module
> work, since the API will be firm at that point.
> 
> --Todd Owen
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

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

I've been quiet the last few days because I am a principal with IMEC
Engineers, an environmental engineering firm.  At the request of a local
county, we took air samples and tested surface wipes at a local high school
of 1200 students.  To make a long story short, the superintendent closed the
school the day after we gave him the test results, which was last Thursday.
Needless to say, the news coverage, angry parents and press conferences have
kept me pretty busy.  You can read for yourselves (and watch some RealVideo
too):

http://www.wsls.com
http://www.wset.com
http://www.wdbj7.com/scripts/heads.htm

Anyway, I did get the ear of Bedford County's technology director (who had
to run sound for the press conferences).  He is really excited about using
phpWebSite/2 throughout the county, when it is completed.

I am preparing several installments of my phpWS/2 master plan, which I will
start releasing tonight or tomorrow.  I've collected the input from posts to
this group, posts to the sourceforge forums and telephone conversations with
others, as well as reviewed MANY other open source packages.  I am committed
to make phpWS/2 an enterprise level product that is easy to use (not an easy
task).  I've missed many hours of sleep working on a plan to get the rewrite
up and running to keep everyone moving forward.  Therefore, I will be
presenting specific design proposals for your review.  If you have strong
objections to a particular point, please raise them here; otherwise, they'll
be part of the core.

If you haven't already read Brian Brown's phpWebSite/2 Roadmap, please do so
now (it's in the list archives).  Once these specific design features are
decided, I will provide pseudo code, rough class definitions, module API
details and db schemas for everyone's review.  Once this is OK'd, I believe
phpWS/2 will reach critical mass and another freshmeat announcement should
be made.  I trust other developers will see the master plan and want to join
the project.  The core coding will then begin simultaneously with some of
Jason's module work, since the API will be firm at that point.

--Todd Owen

Hello developers!

Just a heads up...I have posted a demo of a new templating idea that I have
been working on for phpWebSite. Please feel free to go to
phpwebsite.appstate.edu and download the demo or go to
http://152.10.194.1/phpwebsite/adam/NEW to look at a running copy. Then dig
through the code a bit and send any ideas, questions, or comments you may
have to the developers list.

This demo basically consists of the following:

- a new templating scheme
- updated announcement handling
- new code structure

With the templating scheme being the main focus of the demo (I just
implemented the others as I was going to make my coding go a little easier).

This is a DEMO and as such we are not offering any technical support (ie:
setup, etc) but i assure you if you can setup phpWebSite, you shouldn't have
a problem with this.

Have a great weekend and take care,

Adam Morton
phpWebSite Developer
am...@ap...

(RE: xml-rpc, thought it was relevant. Found this on another list - WD)

    I've been lurking for a while, just thought i'd throw in something
I've learnt from experience to think about.
    If you are looking at using xmlrpc or other API to interface with
systems then you should really look at transaction queues / managers.
    For instance, say you need to hit three different systems - pull
data from the first system,  update data in the second system with the
data you just grabbed and fire an unrelated event to the third system.
Sounds easy enough right? What happens if each of these systems take
15 seconds to respond? You now have the user waiting 45 seconds for a
response - they'll probably hit refresh and kick off a second transaction,
corrupting your data.
    You can improve the response times by parallelizing the requests,
bundle the first two requests into a transaction and rund the third request
concurrently - the response time is now 30 seconds.
    Now suppose that the user won't be looking at the results, maybe
they just wanted to synchronise the systems and get back to using the
site. The response isn't relevent to the task the user is performing.
A further optimisation would be a fire and forget system. Example, put
the request on a queue and get an immediate response confirming the request.
When the transaction is complete, a callback could be used to return
success or failure, and in the event of failure a rollback could be attempted.
The work is still done and the user can go about their business without
long waits.
    Of course the implementation of something like this is where the
fun starts, it really stretches PHP but is possible I think.

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

Thats pretty interesting!  I've seen something else floating around similar 
to that, it might of been on hotscripts too.  Not too sure where I seen it, 
maybe SourceForge.

> this just showed up at Hotscripts :
> 
> http://www.unica.edu/uicfreesoft/php-js-webedit/info_php-js-
webedit_eng.html
> 
> 
> looks very interesting ....
> 
> clayton
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

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

this just showed up at Hotscripts :

http://www.unica.edu/uicfreesoft/php-js-webedit/info_php-js-webedit_eng.html

looks very interesting ....

clayton

On Thu, Apr 26, 2001 at 12:09:35PM +0200, Alain Fontaine wrote:

> That's what I thought too, but I checked the doc first before I was about=
 to
> post the same message as you did... unfortunately, you DO need access to =
the
> configuration file, because you need to tell PHP not to use the normal
> 'file' session handlers, but your own 'user' session handlers. And that
> needs to be set in php.ini.

Damn! I knew I would expose myself to laughter one day :-) But that is
indeed bad news. I didn't think about that (having your own server
makes life easier...).

> As for ini_set() and so on, I suppose most PHP hosting companies would
> disable that function for security reasons.

Well, are there any stats regarding that? Any experience anyone? And
what about .htaccess? Some hosters might let you use that. And last
not least they could check, right?

And what about those who want to set up a multiple organisation (read
big) phpWSII installation? I would think they have access to some
decent hosting environment... It can be bad to avoid using better
techniques just for the sake of some "standard home user". After all:
What is our target audience? Didn't see that in the roadmap :-)
Honestly, who shall be using phpWSII when it is ready and what can we
expect them to have on their server? Just PHP4? Or even some power? Or
root privileges? This is something we should think about, I guess.

In the end: Wouldn't it be possible to use files for session data per
default and let the user choose (if possible) to use a DB instead, if
he wanted/needed the features that provides? User John Doe, with his
100 hits per month would do good _not_ to enable a whosonline display
(it would read 1 visitor most of the time), and when it becomes
interesting to know the number of visitors you probably have enough
power over your server to enable user session handlers. (See my post
about the roadmap for another example of user choice: mailing lists.)

Just my 2 cents,
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

Hi,

That's what I thought too, but I checked the doc first before I was about to
post the same message as you did... unfortunately, you DO need access to the
configuration file, because you need to tell PHP not to use the normal
'file' session handlers, but your own 'user' session handlers. And that
needs to be set in php.ini.

As for ini_set() and so on, I suppose most PHP hosting companies would
disable that function for security reasons.

> -----Message d'origine-----
> De : php...@li...
> [mailto:php...@li...]De la part de
> Karsten Dambekalns
> Envoyé : jeudi 26 avril 2001 11:29
> À : php...@li...
> Objet : Re: [Phpwebsite-developers] phpWhosOnline
>
>
> [cut]
>
> void session_set_save_handler   (string open, string close,
> string read, string write, string destroy, string gc)
>
> See some of the native sessions tutorials at all those developer sites
> for some more on that. It gives you all the flexibility you need and
> still makes it possible to use the fast and easy session handling
> provided by PHP4
>
> And you don't need access to any configuration file (that does apply
> to other settings as well, there are ini_set and ini_alter).
>
> Regards,

On Wed, Apr 25, 2001 at 02:14:28PM -0400, Todd Owen wrote:
> Karsten wrote:
> > That does in no way contradict! You can register custom session data
> > storage containers with the native PHP4 sessions. So you can count the
> > records, and still use the natvive sessions. No problem :-)
>=20
> You can indeed select an alternative to /tmp/ file storage of session_id's
> in PHP4 using the native session routines.  However, this requires access=
 to
> the php configuration files, which many web hosting companies don't offer.
> Furthermore, you don't get the flexibility (in my opinion) of a session
> class you design yourself.

That is not what I meant, changing the session save path is in no way
a great improvement in fexibility. I was referring to the following
function and it's possibilities:

void session_set_save_handler   (string open, string close, string read, st=
ring write, string destroy, string gc)

See some of the native sessions tutorials at all those developer sites
for some more on that. It gives you all the flexibility you need and
still makes it possible to use the fast and easy session handling
provided by PHP4

And you don't need access to any configuration file (that does apply
to other settings as well, there are ini_set and ini_alter).

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

On Wednesday 25 April 2001 13:14, you wrote:
> Karsten wrote:
> > That does in no way contradict! You can register custom session data
> > storage containers with the native PHP4 sessions. So you can count the
> > records, and still use the natvive sessions. No problem :-)
>
> You can indeed select an alternative to /tmp/ file storage of session_id's
> in PHP4 using the native session routines.  However, this requires access
> to the php configuration files, which many web hosting companies don't
> offer. Furthermore, you don't get the flexibility (in my opinion) of a
> session class you design yourself.

Agreed.  Making PHPWebsite depend on third party libraries or require changes 
to the global php or apache config files are (IMHO) bad ideas.

_________________________
Richard Rowell
rr...@sh...

If Java had true garbage collection, most programs would delete themselves 
upon execution. - Robert Sewell 

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

phpwebsite-developers Mailing List for phpWebSite Content Management System (Page 140)

phpwebsite-developers — For our development team.