phpwebsite-developers — For our development team.

[Phpwebsite-developers] PHPlib & Multiple Instances

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

I spoke with Jason by phone for about 30 minutes today and we are in TOTAL
agreement that we need a good roadmap for the future of phpWebSite before
significant changes are made (like database abstraction).  The database
design needs some more tweaking and the themes need to be rethought in a
more object oriented approach.  Jason and I think phpWebSite should have
customizable themes in the database, not in php code.  Steven, could you
elaborate on your XML idea?

Geoff, since this is such a sweeping change, please create a cvs branch for
these changes and let us know the branch name.  Everyone can review and test
the branch code before committing it to the main repository.  Since Karsten
seems to be in charge of documentation, let's make sure our comments fit the
phpdoc format.

--Todd

RE: [Phpwebsite-developers] PHPLIB guru's opinion wanted

[Geoff S. <Ge...@Ho...>]

I'm not a phpLib guru. But, I have used phpLib because I experimented with
phpSlash before going to phpNuke and now to phpWebSite. I have some general
observations that apply to phpLib as well as other addon libraries.

One of the problems with addons like phpLib is that it complicates the
installation process because you have to install phpLib before you can
install the application software. And, once you have your application
running, if there are problems, it can be very difficult to determine
whether it is a phpLib problem or an application software problem. Then,
when a new version of phpLib comes out, what if it breaks our code? What do
we say to someone who asks, "Your program requires phpLib version X and this
other application requires the newer phpLib version Y, what do I do now?"

There are very few things that are more frustrating then an application that
only works with particular versions of addon libraries, especially if they
are not the most recent versions.

I've actually used the php4 session functions for a few simple projects.
php4 Session Management seems to work fine.

But, here's the bigger question: Do we want phpWebsite to be dependent on
addon libraries that we don't control?

My preference would be to take best advantage of PHP. As PHP adds additional
functionality to future releases of the language, we can migrate phpWebsite
and add new features based on PHP language functionality.

In other words: Let's create a really great product that isn't reliant on a
bunch of extraneous stuff.

PHP4 is certainly stable enough to make PHP4 a minimum requirement for
phpWebsite.

There's nothing wrong with having a stable and functionally "frozen" PHP3
version of phpWebsite that is available to anyone who has php3 and can't
upgrade to php4.

When it comes to time to move to php5, there's nothing wrong with having a
stable and functionally "frozen" PHP4 version of phpWebsite that is
available to anyone who has php4 and can't upgrade to php5.

It is a mistake to try and make everything backwardly compatible to php3.
Let's make sure that the current version works well for php3, freeze it, and
move on.

NOW, if it turns out that there is a requirement that cannot be met without
using a third party library such as phpLIB, we need to seriously consider if
it is a REAL requirement or just something that would be nice. Is it
something that can wait until PHP has native support. Is it something we can
write for ourselves and integrate into phpWebsite? Can we "steal" the
functionality from phpLib and integrate it into phpWebsite?

Geoff

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
W.D.Sumilang
Sent: Saturday, March 24, 2001 6:47 AM
To: php...@li...
Subject: [Phpwebsite-developers] PHPLIB guru's opinion wanted


Don't know what's going on with PHPLIB and (not ripe)PEAR...
but with DB abstraction, session mgmt. including session and user variable
registration and authentication... this would seem like an xcellent
candidate
for integration with phpWS...
Any thoughts from anyone that's done lots more than just read the manual?
Like someone who's used it prior to php4 and now using it with php4 native
sessions?

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


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

RE: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Geoff S. <Ge...@Ho...>]

Todd:

I have a suggestion for you.

I've been invited to be a developer, but have not yet received my CVS
access. Jeremy asked me what userid and password I want, but, I haven't
heard back from him.

I'll go in, look at the code, and make a suggestion. I think it is a simple
search and replace -- remember that the SQL queries are all strings so
concatenating a prefix variable onto the table names should be more
mechanical find and replace then anything else. I'll look at the code and
provide a specification within the next 3 or 4 hours.

Once approved, I'd be happy to do the actual work.

The only problem here is that I have to put up a site on Monday or Tuesday
at the latest and I don't have CVS access yet. So, Jeremy, if you are out
there reading this...

One item: I really like what you have proposed for the administration
system. Even more then the OID aspect, I'm especially excited about the
prospect of having the following:

Giving some users that authority to post, delete, and modify their own
submissions.
Having multiple admins who can manage one or more topics, pages, etc.

I think that this will require having a user and admin "group" scheme in
order to make it work.

NOW: Here's a BIG concern that I mentioned previously and gotten no
response: I've looked at the database and there is no real database design.
And, of course, we all know that the code is sort of all grafted together.
SO, I'm hoping that we can take the time to do some serious modeling of the
system and come up with an architecture and a new data and function model.
(I'd call it "object-oriented," but, I don't want to confuse the issue with
coding technique.)

My suggestion would be this:

Do some analysis
Do the design
Build a new database
Build a new system framework consisting of source code files, classes (if
they are used), and function prototypes (Functions that have the function
name, the calling and return variables and values defined, but have no
procedural code in them).
Then, steal procedural code from the existing system to go into the new
functions and classes.
Write new code as needed.

My concern is that if we proceed "inside out" by trying to upgrade the
existing system in place, we will never achieve the goal of a system that is
powerful, extensible, and maintainable.

Geoff

Geoff,

> That means you must rely on the security in phpWebsite to control access
> if you segment by using an organization id (OID) in the tables. (Not that
> there's anything wrong with that.)

My philosophy is consistant with the statement above.  You are correct that
separate tables are the only way to use MySQL database security (row level
security would be a bear anyway).  Your observation that each "site" admin
could dump (and restore) their own tables is a good point.  My "combined"
table scheme would have "super" administrators, like root, that could
create, delete and modify site administrators, back-up data and so forth.
More on this later.

> I agree that having an organizational unit id would be a great idea.
> HOWEVER, that will not happen soon. I'd like to have the separate
> table enhancement, because it is dirt easy to implement.

The ouid scheme will happen soon, but not by April 15th (I'll grant you
that).

> Now, I think that BOTH of these techniques have their place and are
> appropriate for different circumstances.

Agreed.  We don't want a fork if both methods can coexist.  Can you lay out
more coding details for us to help you implement this?

--Todd Owen



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

[Phpwebsite-developers] Plug-in Problem???

[Mark N. <mj...@gm...>]

I am trying plug-ins with phpWebSite. They work fine - apart from one 
problem:

When I set the plug-in to 'Top Centre', the result is that there are a 
load of dots where the main content used to be and
the plug-in, the main content and the right blocks all under each other. 
This occurs on v0.7.6 of phpWebSite on Mozilla 0.7 (Linux).

I am new to phpWebSite, which I think is far superior to both phpNuke 
and Thatware. Thanks for such a great program!

Mark
(mj...@gm...)

[Phpwebsite-developers] Theme Using XML?

[<g7c...@sn...>]

Hi there, I was just wondering why the themes are not just XML files?

That way there could be a "Theme" admin page that would allow all of the XML
tags to be populated via a web page.

Does that make any sense, or am I just talking out of my *aa?


--
Stephen Lawrence Jr.
XXXXXXXXXXXXXXXXXXXXXX

[Phpwebsite-developers] Theme system thoughts...

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

Has anyone thought about modifying any part of the theme system as it 
stands now?  Is anyone working on modifying any part?  

I've been looking at it and trying to get my new block code setup in the 
themes by adding a function and having to add that function to every single 
theme is flat out stupid :).  

I've been thinking of new ways of doing themes and the only one that makes 
a little sense would be to move all the functions out of the theme.php file 
and make a new file called functions.php in the main installation 
directory.  In functions.php you'd have like the functions themesidebox, 
etc etc.  In a new file called layout.php for each theme would be the HTML 
code for the functions in functions.php assigned to variables.  You'd just 
use the correct variable to make the box.  This seems to work good for what 
I'm trying to do with the boxes but overall I'm not too sure.

I still haven't totally thought about how to go about changing the themes 
but this was one idea.  I HATE having functions for each theme it just 
doesn't make sense to me :)

Jason Campbell
Xplozive Media Technologies
www.xplozivemedia.com

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

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

Geoff,

> That means you must rely on the security in phpWebsite to control access
> if you segment by using an organization id (OID) in the tables. (Not that
> there's anything wrong with that.)

My philosophy is consistant with the statement above.  You are correct that
separate tables are the only way to use MySQL database security (row level
security would be a bear anyway).  Your observation that each "site" admin
could dump (and restore) their own tables is a good point.  My "combined"
table scheme would have "super" administrators, like root, that could
create, delete and modify site administrators, back-up data and so forth.
More on this later.

> I agree that having an organizational unit id would be a great idea.
> HOWEVER, that will not happen soon. I'd like to have the separate
> table enhancement, because it is dirt easy to implement.

The ouid scheme will happen soon, but not by April 15th (I'll grant you
that).

> Now, I think that BOTH of these techniques have their place and are
> appropriate for different circumstances.

Agreed.  We don't want a fork if both methods can coexist.  Can you lay out
more coding details for us to help you implement this?

--Todd Owen

[Phpwebsite-developers] PHPLIB guru's opinion wanted

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

Don't know what's going on with PHPLIB and (not ripe)PEAR...
but with DB abstraction, session mgmt. including session and user variable
registration and authentication... this would seem like an xcellent candidate
for integration with phpWS...
Any thoughts from anyone that's done lots more than just read the manual?
Like someone who's used it prior to php4 and now using it with php4 native
sessions?

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

RE: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

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

I agree that having an organizational unit id would be a great idea.
HOWEVER, that will not happen soon. I'd like to have the separate table
enhancement, because it is dirt easy to implement.

I'll take this one step further: I have a requirement that necessitates the
separate table in the same database solution. So, if the group doesn't agree
to it, I'm going to have to do it on my own and I'm REALLY going to hate
being in the position of having to maintain my own separate code base before
I've even set up my first phpWebsite. (I expect to have about 10 websites
running phpWebsite off separate tables within a single database by April
15th.)

Also, there is a security issue. If you setup separate tables for each sub
website, then you can grant access privileges separately to each sub-web. (I
don't think that mySQL implements row level security. Someone please correct
me if I am wrong about this!) If you store everything in the same set of
tables, you cannot use the mySQL security system because you can't assign
specific values in a column to a mySQL userid.

That means you must rely on the security in phpWebsite to control access if
you segment by using an organization id (OID) in the tables. (Not that
there's anything wrong with that.)

Now, I think that BOTH of these techniques have their place and are
appropriate for different circumstances.

The separate table technique allows separate database administrators to have
access to their data and no one else's via the database security system.
They could dump their data using a database utility, or whatever.

The OID technique provides user security, and admin security within the
context of phpWebSite. But, anyone who has access to the database userid and
password would have access to all of the data, not just their own.

So, BOTH of these techniques have their place in the design. The separate
table technique and the OID column technique can coexist without having any
impact on each other and will allow much more flexibility.

Now, here's another issue. I would like to be able to assign phpWebSite
administrators to various topics or pages within a website. This would allow
someone to setup a website and have an administrator for the "Linux" topic
and a separate administrator for the "Mandrake" topic. This would have to be
done programmatically through the phpWebsite administrative programs.

IMHO, all three of the above need to be part of the system.

Geoff
Hostricity.com
Dallas, Texas

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of
Jason Campbell
Sent: Friday, March 23, 2001 3:22 PM
To: php...@li...
Subject: Re: [Phpwebsite-developers] Table Naming Conventions and
Multiple Instances of phpWebSite


I remember that post about it too now that your brought it up.  Its a very
good idea to get phpwebsite to be scalable but its bigger than changing one
thing in the config, it would be better to do what Todd quoted from the
other message about this option.  I'd be willing to work on it with whoever
would want to do this on the dev team.

I remember someone saying a new version of ADODB was released, before we
use one or the other I think we'd have to know how stable each are and
which one is more widely used by other developers.  Did this get discussed
anymore on which one to use, PEAR of ADODB???

Jason Campbell
Xplozive Media Technologies
phpWebSite Developer

> I agree multiple phpWebSites should run in one database, but I
> _disagree_ with the proposed fix.
>
> I am with Aaron and Jason; the sites need to share common tables.  The
> following is an excerpt from a March 6th post to the list.
>
> __Multiple Organizations
> If we want to make phpWebSite scale to have multiple organizations in
> the same database, then we need to add an additional field to each
> table such as "ouid" (organizational unit id) ["oid" is reserved for
> object id in Postgres].  The primary key for each table would need to
> be changed to (cid, ouid) instead of (cid) alone.  To prevent ouid
> guessing or spoofing, the user access control list (ACL) would have to
> be consulted for each page access, which should be done anyway.
>
> Since this change affects just about every call to the database tables,
> it seems to be a good time to add the database abstraction layer while
> we're at it.  Will it be PEAR of ADODB?
>
> --Todd
>
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers



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

[Phpwebsite-developers] Database Abstraction

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

Richard Rowell initially recommended ADODB.

http://php.weblogs.com/ADODB

Karsten and I then recommended PEAR.  I thought it would be a better choice
because it was poised to be more "official" and is being merged with phplib.

http://php.net/manual/en/pear.php

Since the ADODB 0.95 release, I'm reconsidering.  ADODB appears to be an
excellent object oriented encapsulation layer with wide database support.
Maybe it's me, but I think PEAR can only be retrieved from CVS.  We do need
to make a decision though.

I propose the developers consider this very important decision over the next
week, but set a deadline of next Friday to make the decision.

--Todd

Re: [Phpwebsite-developers] Multi-lingual sites

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

I was looking at a source of another portal that implemented languages on 
demand.  I'll look at the source and see how its fully implemented 
throughout the code.

> As an ongoing project we should think about a better way to make
> phpWebSite multi-lingual on demand.  We are only multi-lingual before
> installation. I'd like to see the user profile containing his/her
> default language preference.
> 
> Large case statements are too slow.
> 
> phpmyadmin using the following language include file scheme:
> 
> english.inc.php
> $strAPrimaryKey  = "A primary key has been added on ";
> $strAccessDenied  = "Access denied";
> 
> german.inc.php
> $strAPrimaryKey  = "Ein Primarschlssel wurde fur folgendes Feld
> hinzugefegt: ";
> $strAccessDenied   = "Zugriff verweigert.";
> 
> Has anyone used this many DEFINE statements in an include file?  Were
> there any performance issues?
> 
> The php code would have to pull the user's session_id and get his/her
> language preference from the user database before including the
> appropriate language "define" file.
> 
> Who would like to toss ideas in on this one?
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Multi-lingual sites

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

As an ongoing project we should think about a better way to make phpWebSite
multi-lingual on demand.  We are only multi-lingual before installation.
I'd like to see the user profile containing his/her default language
preference.

Large case statements are too slow.

phpmyadmin using the following language include file scheme:

english.inc.php
$strAPrimaryKey  = "A primary key has been added on ";
$strAccessDenied  = "Access denied";

german.inc.php
$strAPrimaryKey  = "Ein Primarschlssel wurde fur folgendes Feld hinzugefegt:
";
$strAccessDenied   = "Zugriff verweigert.";

Has anyone used this many DEFINE statements in an include file?  Were there
any performance issues?

The php code would have to pull the user's session_id and get his/her
language preference from the user database before including the appropriate
language "define" file.

Who would like to toss ideas in on this one?

--Todd

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

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

I remember that post about it too now that your brought it up.  Its a very 
good idea to get phpwebsite to be scalable but its bigger than changing one 
thing in the config, it would be better to do what Todd quoted from the 
other message about this option.  I'd be willing to work on it with whoever 
would want to do this on the dev team.

I remember someone saying a new version of ADODB was released, before we 
use one or the other I think we'd have to know how stable each are and 
which one is more widely used by other developers.  Did this get discussed 
anymore on which one to use, PEAR of ADODB???

Jason Campbell
Xplozive Media Technologies
phpWebSite Developer

> I agree multiple phpWebSites should run in one database, but I
> _disagree_ with the proposed fix.
> 
> I am with Aaron and Jason; the sites need to share common tables.  The
> following is an excerpt from a March 6th post to the list.
> 
> __Multiple Organizations
> If we want to make phpWebSite scale to have multiple organizations in
> the same database, then we need to add an additional field to each
> table such as "ouid" (organizational unit id) ["oid" is reserved for
> object id in Postgres].  The primary key for each table would need to
> be changed to (cid, ouid) instead of (cid) alone.  To prevent ouid
> guessing or spoofing, the user access control list (ACL) would have to
> be consulted for each page access, which should be done anyway.
> 
> Since this change affects just about every call to the database tables,
> it seems to be a good time to add the database abstraction layer while
> we're at it.  Will it be PEAR of ADODB?
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

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

I agree multiple phpWebSites should run in one database, but I _disagree_
with the proposed fix.

I am with Aaron and Jason; the sites need to share common tables.  The
following is an excerpt from a March 6th post to the list.

__Multiple Organizations
If we want to make phpWebSite scale to have multiple organizations in the
same database, then we need to add an additional field to each table such as
"ouid" (organizational unit id) ["oid" is reserved for object id in
Postgres].  The primary key for each table would need to be changed to (cid,
ouid) instead of (cid) alone.  To prevent ouid guessing or spoofing, the
user access control list (ACL) would have to be consulted for each page
access, which should be done anyway.

Since this change affects just about every call to the database tables, it
seems to be a good time to add the database abstraction layer while we're at
it.  Will it be PEAR of ADODB?

--Todd

RE: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Yves P. <yv...@se...>]

I'm working on a billingual site. I like this idea a lot.

Yves Poirier
http://www.mileend.org

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of
> Jason Campbell
> Sent: March 23, 2001 3:31 PM
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Table Naming Conventions and
> Multiple Instances of phpWebSite
> 
>

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple

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

If you want to do that, I just thought of a way to do it.  It would just 
require a variable in the config.php file to use a single user table say 
like $share_user_table or something like that.  Thats with the database 
feature below added into the code already.

> Would this method allow a site to have multiple instances of phpWS, but
> share one user table?
> ---
> Aaron Adams
> 
> 
> 
> From: "Jason Campbell" <cam...@xp...>
> Reply-To: php...@li...
> Date: Fri, 23 Mar 2001 15:31:07 -0500 (EST)
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] Table Naming Conventions and
> Multiple Instances of phpWebSite
> 
> 
> I like this idea.  Unless anyone objects to this being added I could
> start work on this sometime this weekend.  Anyone else have any
> thoughts on this?
> 
> Jason Campbell
> Xplozive Media Technologies
> www.xplozivemedia.com
> phpWebSite Developer
> 
>> I would like to suggest that phpWebSite should have the ability to
>> create multiple phpWebsite databases in a single mySQL database.
>> Here's why: many if not most web hosts limit the number of databases
>> allowed on a single website.
>> 
>> So, if one wanted to create multiple, functionally separate instances
>> of phpWebsite on a single domain, it must be done within a single
>> database.
>> 
>> Here's my suggestion:
>> 
>> Add a configurable prefix onto each table name controlled by a
>> variable in the configuration file.
>> 
>> For example, Add a variable such as, "$dbp" to the configuration file.
>> Then when someone sets $dbp = "sales", then the author table, for
>> example, would have the name sales_author.
>> 
>> Then, what I can do is install the phpWebsite code into a domain
>>subdirectory called sales, set $dbp to "sales" and have a separate set
>>of tables for the "sales" website. I can then setup another
>>subdirectory called "techsupport", install the phpwebsite code into
>>that directory, and configure it with the $dbp variable set to "tech"
>>and have a
>>separate set of tables for this instance of phpWebSite.
>> 
>> I would design this so that is someone set $dbp = "" (empty), then
>> there would be no effect on the existing table names. This would
>> preserve code compatibility with existing sites.
>> 
>> There are other ways of doing this so that multiple websites can exist
>> in the same set of tables, but that would take a lot of design and
>> implementation work. The above approach can be quickly and easily
>> implemented.
>> 
>> Geoff
>> 
>> Geoff Staples,
>> Founder
>> Action Agenda <http://www.actionagenda.com/>
>> 
>> 3883 Turtle Creek Blvd., Suite 1812
>> Dallas, Texas   75219-4432
>> 214.599.0260
>> 
>> Action Agenda is hosted as a public service by
>> Hostricity Web Hosting <http://www.hostricity.com/>
>> 
>> ActionAgenda.com is a Community Center for progressive and liberal
>> activists to stay informed, find allies, and build support.
>> 
>> 
>> _______________________________________________
>> 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

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Aaron A. <aa...@wc...>]

Would this method allow a site to have multiple instances of phpWS, but
share one user table?
---
Aaron Adams



From: "Jason Campbell" <cam...@xp...>
Reply-To: php...@li...
Date: Fri, 23 Mar 2001 15:31:07 -0500 (EST)
To: php...@li...
Subject: Re: [Phpwebsite-developers] Table Naming Conventions and Multiple
Instances of phpWebSite


I like this idea.  Unless anyone objects to this being added I could start
work on this sometime this weekend.  Anyone else have any thoughts on this?

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

> I would like to suggest that phpWebSite should have the ability to
> create multiple phpWebsite databases in a single mySQL database. Here's
> why: many if not most web hosts limit the number of databases allowed
> on a single website.
> 
> So, if one wanted to create multiple, functionally separate instances
> of phpWebsite on a single domain, it must be done within a single
> database.
> 
> Here's my suggestion:
> 
> Add a configurable prefix onto each table name controlled by a variable
> in the configuration file.
> 
> For example, Add a variable such as, "$dbp" to the configuration file.
> Then when someone sets $dbp = "sales", then the author table, for
> example, would have the name sales_author.
> 
> Then, what I can do is install the phpWebsite code into a domain
>subdirectory called sales, set $dbp to "sales" and have a separate set
>of tables for the "sales" website. I can then setup another subdirectory
>called "techsupport", install the phpwebsite code into that directory,
>and configure it with the $dbp variable set to "tech" and have a
>separate set of tables for this instance of phpWebSite.
> 
> I would design this so that is someone set $dbp = "" (empty), then
> there would be no effect on the existing table names. This would
> preserve code compatibility with existing sites.
> 
> There are other ways of doing this so that multiple websites can exist
> in the same set of tables, but that would take a lot of design and
> implementation work. The above approach can be quickly and easily
> implemented.
> 
> Geoff
> 
> Geoff Staples,
> Founder
> Action Agenda <http://www.actionagenda.com/>
> 
> 3883 Turtle Creek Blvd., Suite 1812
> Dallas, Texas   75219-4432
> 214.599.0260
> 
> Action Agenda is hosted as a public service by
> Hostricity Web Hosting <http://www.hostricity.com/>
> 
> ActionAgenda.com is a Community Center for progressive and liberal
> activists to stay informed, find allies, and build support.
> 
> 
> _______________________________________________
> 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

Re: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

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

I like this idea.  Unless anyone objects to this being added I could start 
work on this sometime this weekend.  Anyone else have any thoughts on this?

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

> I would like to suggest that phpWebSite should have the ability to
> create multiple phpWebsite databases in a single mySQL database. Here's
> why: many if not most web hosts limit the number of databases allowed
> on a single website.
> 
> So, if one wanted to create multiple, functionally separate instances
> of phpWebsite on a single domain, it must be done within a single
> database.
> 
> Here's my suggestion:
> 
> Add a configurable prefix onto each table name controlled by a variable
> in the configuration file.
> 
> For example, Add a variable such as, "$dbp" to the configuration file.
> Then when someone sets $dbp = "sales", then the author table, for
> example, would have the name sales_author.
> 
> Then, what I can do is install the phpWebsite code into a domain
>subdirectory called sales, set $dbp to "sales" and have a separate set
>of tables for the "sales" website. I can then setup another subdirectory
>called "techsupport", install the phpwebsite code into that directory,
>and configure it with the $dbp variable set to "tech" and have a
>separate set of tables for this instance of phpWebSite.
> 
> I would design this so that is someone set $dbp = "" (empty), then
> there would be no effect on the existing table names. This would
> preserve code compatibility with existing sites.
> 
> There are other ways of doing this so that multiple websites can exist
> in the same set of tables, but that would take a lot of design and
> implementation work. The above approach can be quickly and easily
> implemented.
> 
> Geoff
> 
> Geoff Staples,
> Founder
> Action Agenda <http://www.actionagenda.com/>
> 
> 3883 Turtle Creek Blvd., Suite 1812
> Dallas, Texas   75219-4432
> 214.599.0260
> 
> Action Agenda is hosted as a public service by
> Hostricity Web Hosting <http://www.hostricity.com/>
> 
> ActionAgenda.com is a Community Center for progressive and liberal
> activists to stay informed, find allies, and build support.
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Geoff S. <Ge...@Ho...>]

I would like to suggest that phpWebSite should have the ability to create
multiple phpWebsite databases in a single mySQL database. Here's why: many
if not most web hosts limit the number of databases allowed on a single
website.

So, if one wanted to create multiple, functionally separate instances of
phpWebsite on a single domain, it must be done within a single database.

Here's my suggestion:

Add a configurable prefix onto each table name controlled by a variable in
the configuration file.

For example, Add a variable such as, "$dbp" to the configuration file. Then
when someone sets $dbp = "sales", then the author table, for example, would
have the name sales_author.

Then, what I can do is install the phpWebsite code into a domain
subdirectory called sales, set $dbp to "sales" and have a separate set of
tables for the "sales" website. I can then setup another subdirectory called
"techsupport", install the phpwebsite code into that directory, and
configure it with the $dbp variable set to "tech" and have a separate set of
tables for this instance of phpWebSite.

I would design this so that is someone set $dbp = "" (empty), then there
would be no effect on the existing table names. This would preserve code
compatibility with existing sites.

There are other ways of doing this so that multiple websites can exist in
the same set of tables, but that would take a lot of design and
implementation work. The above approach can be quickly and easily
implemented.

Geoff

Geoff Staples,
Founder
Action Agenda <http://www.actionagenda.com/>

3883 Turtle Creek Blvd., Suite 1812
Dallas, Texas   75219-4432
214.599.0260

Action Agenda is hosted as a public service by
Hostricity Web Hosting <http://www.hostricity.com/>

ActionAgenda.com is a Community Center for progressive and liberal activists
to stay informed, find allies, and build support.

[Phpwebsite-developers] phpNuke

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

Nuke has a new poll on their website. Check it out, it is quite interesting.

Matt

[Phpwebsite-developers] Let me introduce myself

[Stefan W. <ma...@sa...>]

Hi,=20
my name is Stefan Werny and I recently discovered PHPWebsite. After having=
 translated the German languagefile for PHPNuke 4.4 I discovered the unbel=
ievable speed of PHPWebSite and decided to give it a try (arghh - why didn=
't this happen vice-versa?).
Setup was a snap, the code produced is excellent (as far as I can tell) an=
d the speed is...well...I told you before :)

I want to make it work in a larger project I am currently working on. 600 =
pages have to be integrated and therefore I will need to work with subdirs=
=2E Could anyone provide me with a short example what I need to change to =
make it work my way?
Greetings from Germany
Stefan Werny

[Phpwebsite-developers] Thanks from the LEAF project

[Mike N. <mh...@us...>]

To all the phpWebSite developers,
Thank you for creating phpWebSite! Our SourceForge project is using it, and 
it's saving us a lot of work. Thanks again, and keep up the good work.

BTW, would a FAQ for installing phpWebSite on SF be useful? If so, I'll 
take a crack at creating one.

--
Mike Noyes <mh...@us...>
http://leaf.sourceforge.net/

[Phpwebsite-developers] Plug in installation

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

As soon as I finished the plugin design, Jeremy said "can't you put it in 
the plugin directory?" Well I could not because the install includes the 
mainfile to get the dbconnect function. mainfile then calls the config 
which is no longer in the working directory. In other words, it blows up. 
So I promptly ignored him :)

However, Jeremy was working on a neat little installation setup and was 
having problems accessing mainfile from a higher directory. He then had a 
moment of clarity, "Why not move the functions I need into my page?"

So anyway, the plugin setup should be able live in plugin directory if the 
dbconnect function is copied and called in the file along with the config. 
This will eliminate the setup program having to exist in the root.

Haven't tested it yet but it should work. Thanks jagee.

Matt
P.S. Trudging through calendar rewrite. Some neat stuff should port over 
into phpwebsite. For example, graphics don't have to be uploaded everytime 
you want to use them. Developers can contact me if you want a sneak peek.

[Phpwebsite-developers] Uninstall Plugin Script

[Tat <ta...@sn...>]

I have been working on an uninstall script for the plugins in the admin 
screen.   This would help remove plugins from the plugin table.

I am making modifications to the admin.php and user_admin.php files.   Will 
verify everything before submitting it in to have others view it.

Tat

[Phpwebsite-developers] Future theme

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

W.D.Sumilang said:
>While this is NOT a solution to the phpWS's problem with theme flexibility,
>it's cleaner than creating new functions that basically do the same 
thing...
>everything in phpWS is contained in the same "box" structure, so why
>not just pass the style class rules as arguments... hopefully this will
>lead in a better direction for themes ;o)

I agree Sumilang. I had to use this in the calendar plugin because I based
the first one on the default style sheet and the colors would get all 
messed up. There will have to be a system of separate theme functions or a 
way to set them up. For example, this theme function is a table-in-a-table 
to create thin lines. Not everyone might want this.

So do we go in a direction where a person edits a style sheets for fonts
and colors and phpWS creates the tables? Or will the user create the css in 
phpWS and create there own theme file? Or will phpWS do it all? I vote for 
the end option. I would like phpWS to create theme files that can be
distributed BUT at the same time they could be plugged in and altered. 
These files would handle everything (color, form, font, etc.).
Installation would be a snap with the user uploading the theme and then
the graphics.

Matt