phpwebsite-developers — For our development team.

RE: [Phpwebsite-developers] Some responses

[Simon R. <si...@ai...>]

Hiya,

> If you want things to change in the calendar, PLEASE make suggestions
> here.

I think it'd be really useful if the calendar had a really simple mode,
where it could just show all the upcoming "system" events, plus any personal
events, in a single view :

Date/Time        Event
Tue March 20th   King of Ruapuna, Race 3
Sat March 24th   National Series, Round 4
Fri March 30th   Personal: meeting with sponsors, 3pm
Sat March 31st   South Island Cup
...

etc. With an option to see all the events, just yours, old events etc.

Cheers, Simon

Re: [Phpwebsite-developers] Some responses

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

On Tue, Mar 06, 2001 at 09:12:17AM -0500, Matt McNaney wrote:

> them. If anyone is wondering why we have to change them, nl2br converts
> newlines (\n) to break tags <br>. Unfortunately, <br> is not XHTML
> compatible so the tag needs to be <br />.
> As for alerting the php developers, no we haven't done that yet. Please
> alert them and we will as well. In the meantime, I'll change ereg's to
> str_replace.

I mailed to the php-dev list and got a reply _fast_! This is laready done in
CVS and will be out with the upcoming PHP 4.0.5. So we can change everything
back to nl2br - if we rely on people installing the new PHP release. Should
we do that? Why not? Any thoughts on this?

I would prefer using native functions (nl2br in this case) because they are
faster and less error prone.

> >No offense :-)
> None taken ^_~

Fine :-)

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

[Phpwebsite-developers] Some responses

[Matt M. <mcn...@ap...>]

I will respond on some of the issues I know about. Others from the team
will answer on their area of expertise (e.g. Adam is the upload image
guru, Brian is the user pages coder).

>Richard Rowell said:

>I discovered PHPWebsite the other day, and I like it save for a few minor 
>things.  These things, listed in ever increasing levels of annoyance, are as 
>follows:
...
>-Sub category system in the calendar is somewhat awkward.
>-MySQL only.

We will be recoding the calendar as a plug-in. Since we will be up to
the elbows in the code, expect major changes. The calendar was centered
squarely on a particular department on campus. Therefore, yes, it is
awkward. This will change. The following is what is planned so far:
1) Categories, subcategories, and locations will be options and not
mandatory,
2) Java windows will open when you click on an event. If Java is not
supported, the info window will open instead,
3) 24 hour time schedule option and the option to not assign a time at
all (All Day events)
4) Changes in the corner calendars. Month view will highlight days that
have events, others will be blank.
5) Overall structure changes, less files, more options, etc.

If you want things to change in the calendar, PLEASE make suggestions
here. 

Karsten Dambekalns sez:

>I was about to try to update from CVS, but it seems that the machine is down
>(browse CVS isn't working either). Anyone else experiencing this?

The CVS server is on a different router than phpwebsite. Unfortunately,
we do not have much control over this. Occasionally you can't access it
but if it makes you feel any better neither can we! Trust me, we are
much more upset about this than anyone else. We are sorry if it causes
people problems and hope it improves in the future.

Karsten Dambekalns notes:
>But then: why ereg_replace()? preg_replace() is faster than that, and in th=
>is
>simple case str_replace() woulb be even faster and no less appropriate! And
>if you change that, then why leave nl2br() in just a few lines below in teh
>code?

I used to use str_replace but I changed to ereg_replace. Don't know why
exactly... But in any case, if str_replace is faster, I will change it.
There are still some nl2br lines out there and I am trying to change
them. If anyone is wondering why we have to change them, nl2br converts
newlines (\n) to break tags <br>. Unfortunately, <br> is not XHTML
compatible so the tag needs to be <br />.
As for alerting the php developers, no we haven't done that yet. Please
alert them and we will as well. In the meantime, I'll change ereg's to
str_replace.

>No offense :-)
None taken ^_~

Finally, the tarball should come out before the earth gets sucked into
our dying sun. Once it does, please review the plugin format and print
feedback.

Best regards,
Matthew McNaney



-- 
Matthew McNaney
Systems Administrator
Career Development Center
mcn...@ap...
Office 828-262-2180
Fax    828-262-2834

Re: [Phpwebsite-developers] Database abstraction layer

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

I too read the concern about PEAR, but think it may be some sour grapes too.
I encourage everyone to read the PEAR archives for themselves (several
hundred messages per month, but has search capabilities):

http://www.php.net/support.php

I agree that the HTML "documentation" is worse than poor and gives most the
impression that it's vaporware.  I think rolling our own DB wrapper would be
a mistake in light of other projects with the same goal.

Does the project already have volunteers who want to take on this portion of
the project?

--Todd Owen

Re: [Phpwebsite-developers] Database abstraction layer

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

On Sun, Mar 04, 2001 at 03:10:08PM -0600, Richard Rowell wrote:
> On Saturday 03 March 2001 17:11, you wrote:
> > Richard, I tend to agree with Karsten that we should use PEAR or someth=
ing
> > else "standard", if there is such a thing, or phplib.
>=20
> My major conecerns with PEAR are:
> A.  It is mosty vapor at the moment. (check for yourslef http://pear.php.=
net/)

Well, as far as I got it, the code is more advanced than documentation and
website.

> B.  The write up I saw on the PHPBuilder site
> (http://www.phpbuilder.com/columns/allan20010115.php3)

Quickly read that, and I think it sounds fairly good... But I did not read
the comments on the article, maybe there is some hard criticism in them.
More worries are caused on my side by an email on the phplib mailing list I
got today (phplib will be merged into PEAR, that is the plan so far). Let me
quote a little bit:

=3D=3D=3D=3D=3D=3D=3Dsnip=3D=3D=3D=3D=3D=3D
> Yes, there are some problems with PEAR (and PHPLib) now. PEAR seems to
> choose not the right way (IMHO) - making well-organized (that's well),
> but almost unusable stuff. PEAR::DB (the main thing in the PEAR now,
> that could be used in the real life) is obviously too slow compared to
> the PHPLIB counterpart, missing obvious things (like affected_rows,
> which almost every DB supports, num_rows for Mysql, for example).  =20
> I consider it a bloatware (sorry, Stig).

I buy nearly all of this, the PEAR stile tends to overdo things and make
code too slow. I currently have problems to keep out all that from the
new cache stuff as people already ask for more hidden addslashes() when
saving cache data to and for error handling 1 + 1... But instead of
complaining, who will tell this to Stig and Chuck? Who will start the
argue?
=3D=3D=3D=3D=3D=3D=3D=3Dsnip=3D=3D=3D=3D=3D=3D

The unsupported stuff is probably going to be added and/or fixed over time,
but the speed issue is something that worries me. More comments on that see
below...

> C.  Almost zero documentation (relates back to A)

That's a point.

> I haven't looked at PHPLib, I will do so and venture an opinion.

OK, as far as phplib is concerned: it works very well, is quite complete,
simple and fast. But it is scheduled to be merged into PEAR (as mentioned
above), so it might not be the best idea to use it for a (new) project.

Has anyone looked at metabase by manuel Lemos? It can be found at
phpclasses.upperdesign.com and claims to be more or less the db abstraction
layer with the most complete feature set and has some very nifty features
(like XML based database description, allowing to initialize all supported
databases from on XML description file. This makes all those xxxxx.sql file
superflous). But I didn't really look into this yet.

Bye,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] For discussion...

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

Posted as News to phpwebsite.appstate.edu - not really news, so not posted. 
But thought it might be worth some discussion here...

Kind Regards,
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


+---------------------------------------------------+

More elaborate table names in db would be an asset!

While trying to slip into my flame suit, I'd really like to inform the
community here at phpWebSite about the fact, that I kind a like this product
and the communities style considering the openness of the development
process. This product seems to try to meet the needs of its users. Ok,
zipper closed. Ready for  opinions?  

In my experience nearly every software just using sql for a part of its job,
does it in a horrible way. Try to install seven web-products in a hosted
environment with just one db granted access to, and enjoy the chaotic usage
of those seven uniquely named users, comments, article, authors, you-name-it
tables.  Or imagine to wanting use e.g. phpWebSite, ***nuke, etc. in
multiple separate instances each for a different purpose or community, how
to now separate those tables, if having only one db? And if you did, look
forward, next update won't be too smooth. 

Since the language forks might render a patch of 0.75p2 useless for
integrating into the master tree, how might one - possibly me - help? What
do the users think of eg transformations a la:

db table users is renamed phpwebsite_users? 

Also the intro of a phpwebsite_version table might be interesting. Since the
db structure as of 0.75p2 as defined in (german fork's) phpwebsite.sql is
quite simple (no views, rules, triggers and such) the work to be done is in
the embedded (or constructed) sql-statements of the php-code. I did it a few
weeks ago with ***nuke, no problem. By the way there seems to be a high
ratio of common code base between the two products when it comes to the real
work behind the scenes. Any opinions? 

                                    
The wisdom above is automatically combined from components of the foreigners
english framework version 19740701T110000Z. The author considers himself not
responsible, if e.g. the language used does not conform to actual standards.
He does not take any responsibilty for having missed quite some updates. Its
far too late for major patches anyway. 

Re: [Phpwebsite-developers] Database abstraction layer

[Richard R. <rr...@sh...>]

On Saturday 03 March 2001 17:11, you wrote:
> Richard, I tend to agree with Karsten that we should use PEAR or something
> else "standard", if there is such a thing, or phplib.
>
> The sourceforge list archives are still down so I don't have the benefit of
> reading the old messages.  I too would like to know who is working (or in
> charge) of what in the code base.  This would be helpful for sub-team
> collaberation.

My major conecerns with PEAR are:
A.  It is mosty vapor at the moment. (check for yourslef http://pear.php.net/)
B.  The write up I saw on the PHPBuilder site
(http://www.phpbuilder.com/columns/allan20010115.php3)
mentioned support for the trivial stuff, but left out the harder, but 
important stuff like:
  1.  Escaping strings (IE in Postgres a ' must be escaped \' and in MSSQL it 
is escaped '')
  2.  Handling dates (Every database handles them differently, thank the SQL 
standard for that)
C.  Almost zero documentation (relates back to A)

I guess I'm in favor of a best of bread approach.  However, if the powers 
that be would rather go with the (currently) vapor "standard" then so be it.  
I'm hopefull that PEAR will improve as time goes on.  Besides, I'm not a big 
fan of the ASPish syntax of ADODB anyway but it doesn't have any of the 
problems I mentioned above concerning the PEAR stuff.

I haven't looked at PHPLib, I will do so and venture an opinion.

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

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

Re: [Phpwebsite-developers] Database abstraction layer

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

Richard, I tend to agree with Karsten that we should use PEAR or something
else "standard", if there is such a thing, or phplib.

The sourceforge list archives are still down so I don't have the benefit of
reading the old messages.  I too would like to know who is working (or in
charge) of what in the code base.  This would be helpful for sub-team
collaberation.

--Todd

Re: [Phpwebsite-developers] Database abstraction layer

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

On Fri, Mar 02, 2001 at 04:05:25PM -0600, Richard Rowell wrote:

> > .. Database abstraction layer (I prefer Postgres)
> I just did a quick poke around freshmeat, and I found "ADODB" which is a =
GPLd=20

Well, I am following PEAR development a bit, and if it is in any usable
state, we should go for that! It will be in every PHP distribution in the
future, has (good) coding guidelines and naming conventions and is actively
developed. Take a look at pear.php.net (although there isn't much to see) or
better yet, browse CVS at cvs.php.net and look for the PEAR packages.

> I didn't get much feedback on my questions yesterday.  Is there a project=
=20
> "leader" or some kind of HNIC for this project?  An email address or phon=
e=20
> number maybe?

Well, if you follow teh About us... link on phpwebsite.appstate.edu, you
will find Brian W. Brown, along with his phone number. He seems to be
something along the lines of "project leader". Also the SourceForge page
lists admins and developers (on the upper right side of the summary page).

> If Java had true garbage collection, most programs would delete themselve=
s=20
> upon execution. - Robert Sewell=20

That is soooo true! :o)

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

[Phpwebsite-developers] Database abstraction layer

[Richard R. <rr...@sh...>]

On Friday 02 March 2001 05:33, you wrote:
> .. Database abstraction layer (I prefer Postgres)

I just did a quick poke around freshmeat, and I found "ADODB" which is a GPLd 
(PHP) wrapper class that in theory supports MySQL, Postgres, MSSQL, Oracle, 
Interbase and ODBC.  Has anyone heard of another such project to provide a 
standard API for database access under PHP?  Perhaps if it is usable and 
stable...

Also:
I didn't get much feedback on my questions yesterday.  Is there a project 
"leader" or some kind of HNIC for this project?  An email address or phone 
number maybe?

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

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

Re: [Phpwebsite-developers] CVS down?

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

We had a little network trouble that was out of our control.  The webserv=
er
and the cvs server are on separate networks so that is why both were not
down.
> Hi!
>
> I was about to try to update from CVS, but it seems that the machine is
> down (browse CVS isn't working either). Anyone else experiencing this?
>
> Karsten
> --
> Why do we have to hide from the police, daddy?
> Because we use emacs, son. They use vi.
> -----------------------------
> mailto:k.d...@tu... w=B3: http://www.k-fish.de/
> gpg: http://www.k-fish.de/mykeys.gpg

Re: [Phpwebsite-developers] Re: Several Questions

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

I do most of the work for the OS and server stuff so my comments on develper
stuff will be limited.  
> As a new member to the project as of this week, let me make a few
> observations.  I have spoken directly with Brian Brown at Appalachian
> State and he is very interested in outside developer input such as your
> own.  At this point we are reviewing the plug-in API for 0.8 and I
> believe momentum will pick up significantly after that is complete.  I
> guess we need a procedure for giving CVS write privileges.
> 
> My goals, as I've shared with Brian on the telephone are as follows,
> most important at list end:
> 
> . Database abstraction layer (I prefer Postgres)
This is a logicl step.  We do want phpwebsite to be versital and used by any
sql system.
> . Port of phpBB for forum system discussions
This would be a great plugin.  We have had others ask about this.
> . System to integrate or port phpgroupware plug-ins
We also us phpgroupware here and love it.  As a system person It would be
nice to have ldap for all autherazation(phpgroupware has this as i am sure
you know).
> . Abstraction system or table field additions to allow multiple
> _independent_ organizations/departments to exist using the same
> installation and database tables (so management is easy), but content
> remains isolated.
> 
> --Todd Owen
> 
> 
> 
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Re: [Phpwebsite-developers] Re: Several Questions

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

On Fri, Mar 02, 2001 at 06:33:16AM -0500, Todd Owen wrote:
> My goals, as I've shared with Brian on the telephone are as follows, most
> important at list end:
>=20
> . Database abstraction layer (I prefer Postgres)

Ack.

> . Port of phpBB for forum system discussions

Have you looked at Phorum? What do you think about that?

> . System to integrate or port phpgroupware plug-ins

Now _that_ would be cool!

Regards,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] Updated developer docs

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

Hi everybody!

I updated the (mostly) unofficial developer docs at
http://www.k-fish.de/krabutzig/phpwebsite/

Feel free to comment on them!

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

Re: [Phpwebsite-developers] CVS down?

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

On Fri, Mar 02, 2001 at 04:24:13PM +0100, Karsten Dambekalns wrote:
> Hi!
>=20
> I was about to try to update from CVS, but it seems that the machine is d=
own
> (browse CVS isn't working either). Anyone else experiencing this?

Answering myself... it is up and running again. And the code is changing
steadily!

A few remarks: On some places nl2br was changed to ereg_replace to get
XHTML-style <br /> tags. Is this communicated to someone over at the PHP
developer's side? Would be nice if this would become the default output of
PHP's nl2br function.

But then: why ereg_replace()? preg_replace() is faster than that, and in th=
is
simple case str_replace() woulb be even faster and no less appropriate! And
if you change that, then why leave nl2br() in just a few lines below in teh
code?

And some of the new code was absolutely "de-indented" (does everyone
understand what I want to say with that?)

No offense :-)

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

[Phpwebsite-developers] CVS down?

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

Hi!

I was about to try to update from CVS, but it seems that the machine is down
(browse CVS isn't working either). Anyone else experiencing this?

Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg

[Phpwebsite-developers] Re: Several Questions

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

As a new member to the project as of this week, let me make a few
observations.  I have spoken directly with Brian Brown at Appalachian State
and he is very interested in outside developer input such as your own.  At
this point we are reviewing the plug-in API for 0.8 and I believe momentum
will pick up significantly after that is complete.  I guess we need a
procedure for giving CVS write privileges.

My goals, as I've shared with Brian on the telephone are as follows, most
important at list end:

. Database abstraction layer (I prefer Postgres)
. Port of phpBB for forum system discussions
. System to integrate or port phpgroupware plug-ins
. Abstraction system or table field additions to allow multiple
_independent_ organizations/departments to exist using the same installation
and database tables (so management is easy), but content remains isolated.

--Todd Owen

[Phpwebsite-developers] Several questions

[Richard R. <rr...@sh...>]

WHY:
I discovered PHPWebsite the other day, and I like it save for a few minor 
things.  These things, listed in ever increasing levels of annoyance, are as 
follows:

-Doesn't thing .png is an image file
-Sub category system in the calendar is somewhat awkward.
-MySQL only.
-A static number of sections for each user defined page is insufficient for 
my needs.

WHAT:
I took a very short peek under the hood and #4 looks easy to fix.  I would 
like to:

layout.php:
Eliminate much of the redundancy...  There are 6 functions that do nearly the 
exact same thing, just a few lines of code difference in each.  Clean this 
up, and make it so it displays all of the page_content(s) that are associated 
with the user_page.

userpage.php
Modify get_page_data to show either the default number of "sections" or the 
current number of sections + 1 or 2 blanks (whichever is greater).  T

In database:
Couldn't user_pages.num_sections go away?  It can be determined dynamically.


NEED:
Anyway, this would allow an arbitrary number of sections for user pages which 
will scratch my immediate itch.  Ok, here is why I mailed the list:

1.  Is anyone else already cleaning this up?  I don't want to duplicate 
efforts.

2.  Is page_content.level just specifying the placement of the section in the 
page (IE level 1 is section 1, level 2 is section 2, etc?)

3.  I don't want to spend time customizing such OSP and not have my changes 
incorporated as it is likely to evolve quickly leaving me stranded.


WHEN:
Responses are much appreciated.  I plan to "fix" this stuff over the weekend, 
so if anyone wants to point out the light of why this stuff was done this way 
and I should leave it alone, please do so now.

DISCLAIMER:
I don't want to step on any toes, or patronize anybody's work.  I am just 
here to try to help make something that looks promising better.

TIA!
_________________________
Richard Rowell
rr...@sh...

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

Re: [Phpwebsite-developers] Archives

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

I thought I turned this option on at sourceforge but it seems not to be
working.  I am working on it however.  If any one has done this at
sourceforge before any pointer would be appreciated,
> Does anyone know why the list archives aren't working?
>
> --Todd Owen
>
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

[Phpwebsite-developers] Archives

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

Does anyone know why the list archives aren't working?

--Todd Owen

[Phpwebsite-developers] The plugin feature

[Matt M. <mcn...@ap...>]

With today's (hopefully) tarball, we will include the beginnings of the
the plugin module. You will notice that this is not version 0.8.0
however for the reason that we want feedback on its functionality.

Here is a summary of how it works before you go into the code.

First, there is a new table entitled 'plugins'.  Here is the structure:

|  plug_id  |  name  |  source_file  |  img   |  plug_dir  |  block_pos 
|  block_file |

|  admin_only  |  user_only  |  admin_inc  |  about  |

This structure is open to change and suggestions.

plug_id: The index of the plug-ins
name: The name of the plug-in. Appears in the admin menu.
source_file: name of the the one file that is in the root of your web
directory.
img: The icon for your plugin. Appears in the admin menu.
block_pos: If the plugin fills in a block, this is where it appears.
1=left, 2=top center, 3=right, 0=not at all
block_file: name of the file that fills in the data of the plug in box.
admin_only: if = 1, block only appears for the admin
user_only: if = 1, block only appears for users
admin_inc: the include function sent to source_file that points it to
the administrative functions for that plugin.
about: information about the author(s) and the plugin

phpWeather
I used an existing program to make a plugin. It is named phpweather and
written by Martin Geisler at gim...@gi....

Now the short coming of me using a rather simple program (simple in its
implementation, not its coding =-) ) is that I may have overlooked
problems down the road with plugins. We shall see after you guys and
gals test it.

There are a few components to a plugin.
1) weather_setup.php - The setup file. I am staying away from forcing
users to perform SQL imports by telnet or command line. This program
inserts itself into the plugins table and creates a new table named
'metar' for its operation. I had some problems getting this file to run
from the /webdir/plug-ins/phpweather/ directory. You could run a file
from its plug-in directory but holding the theme in the setup page
caused problems. In that case, your plugin setup page would chuck the
css just for the install. I like the setup the way I have it because you
have to login as an admin to get it to function. It has been suggested
that the page automatically search for new plugins and lead you through
the install. The downside to this I see is that it has to do a file
search everytime the admin logins in. You could chron job but that is
IMHO a waste of cycles. Of course, I may be overlooking something and
you can give me information on another way to do this. Again, it needs
to be web-based and simple.

2) weather_admin.php - This is an idea Adam came up with. One file, in
the main directory, with all the function includes. So, here is that
file. It is the file pointed to by the icon in the admin menu.
phpweather did not have admin functions so I wrote this quick and dirty
file to perform some of the tasks I wanted to have in its display. It
moves the box around and decides who gets to see it. This 'admin' file
could do anything. It doesn't have to move a box around, these are just
examples.

3) phpweather directory - We want all the other pages in their own
directory. I need some feedback of whether all folders should sit under
a central 'plug-ins' directory or just under the root. I prefer this
way.

The install
So the user gets the plugin and unzips/untars it. It should write the
main file in the root along with the install file. It will also create
the phpweather directory under the plug-ins directory. You can then
either start the SQL install or FTP it.
Now they need to login as the admin and type in the name of the install
file. It takes them through a confirmation and then it writes the
database info. That's it. If they run the file again, they get an error.
Now the weather should appear for Boone, NC. I did not do multiple city
setup, because this is an example ONLY. If someone wants to make a full
featured weather plugin, then by all means =) If you want to change it,
just look in phpweather.php, it is easy to change.
On the admin side, phpWebSite will find the SQL record and put up the
icon for the plugin. Clicking on the icon takes you to the setup screen.
Some things not included but considered: an uninstall file, a function
to automatically delete the setup file.

Conclusion
I have tried to make this plugin ability as clean and easy as possible.
Again, you are free to suggest modifications or ideas to make it better.
We would like to finalize a standard by version 0.8.0.

Thanks for the help from everyone supporting this product, the
developers that want to join us, the great group I work with, and
finally PHPPLUGIN which is the code I stole and then just slapped my
name on. ;-)

Matthew McNaney

[Phpwebsite-developers] Re: Phpwebsite-developers digest, Vol 1 #3 - 1 msg

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

Yeah!  

Jeremy gets it working!

Kudos...

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