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

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

Awhile ago there was talk of getting Squirrelmail to work with phpws.  Has
there been any more development of this?

Mike Windsor

Hi!

On Wed, Feb 20, 2002 at 01:59:43 -0600, Bob Treumann wrote:
> On 20 Feb 2002 at 14:18, Matthew McNaney wrote:
> 
> > Why does it matter if static information is served up when the
> > content is always written in one language anyway?
> 
> Here are a few advantages:
[...]

The 4th point you mention seems to be a very strong point. Anyway,
here a few more thoughts on this, that came up in the past. And that
(partly) explain why it indeed _does_ matter to have the static stuff
served dynamically.

There was a thread started by Todd Owen on March 23rd 2001, the
subject was "Multi-lingual sites", that discusses some of the pros and
cons.

More recent is the thread started at the end of November 2001, where a
discussion about this emerged from "One among many" written by Matthew
McNaney. There Brian W. Brown lays out his thoughts in a message
titled "Re: the last crusade (is: Re: One among many)".

I have written a followup (Msg-ID: <200...@to...st>)
to this thread where I explain why switching languages on the fly is
(IMHO) needed even if we (yet) only have single-language content.

And Philip McAllister threw in some nice views about
internationalization/localisation from a professional point of view
which are worth a read.

> Well, personally I thought this would be a great benefit, but  I 
> won't push it.

Summing up: I am still supporting a dynamic language system. Even if
it means some impact on speed - we could wrap some caching around the
whole thing (see PEAR::Cache) to regain what we've lost.

Regards,
Karsten
-- 
fishfarm netsolutions - Karsten Dambekalns
Echternstr. 73 - 38100 Braunschweig

Tel. +49 531 1232902  mailto:k.d...@fi...
Fax. +49 531 1232906  http://www.fishfarm.de/
-----------------------------------------------------

On 20 Feb 2002 at 14:18, Matthew McNaney wrote:

> Why does it matter if static information is served up when the
> content is always written in one language anyway?

Here are a few advantages:

1. Ability to log severity of error messages

2. Hardcoded statements with hard coded translations are hard to 
change.   If you change one word in the program, for instance, to 
correct a spelling error, or clarify the message,  then all the 
language files have to be changed.  This means that mistakes in 
messages are less likely to be fixed.

3. If a site operator modifies the programs,  you either have to 
modify the source program, then generate the language version, 
requiring an extra step,  or, if you change the translated version 
and do a "diff" to the untranslated, your diff is so full of 
TRANSLATE differences that you can't find see your actual code 
changes.   It would make program updates easier.

4 In the new core, I understand the goal is to have one tree support 
multiple sites.    It wouldn't matter to me for my own uses, but in 
some uses, it would be necessary.   In Quebec, Canada, for instance, 
I believe French and English are required by law for most public 
businesses.     

Well, personally I thought this would be a great benefit, but  I 
won't push it.

Happy Coding!

--
Bob Treumann,  651-603-1245
Elmwood Solutions Inc. (St. Paul, Minnesota)
bo...@el...
http://www.elmwood.com
ORACLE Business Alliance Program Member

As stated before, we don't support this.

English version
<header>Welcome!</header>
<content>I entered all my content in English!</content>

French version
<header>Bienvenue!</header>
<content>I entered all my content in English!</content>

Italian
<header>Benvenuto!</header>
<content>I entered all my content in English!</content>

Why does it matter static information is served up when the content is
always written in one language anyway?

Even if it doesn't add delay, why create them if they are not needed?

Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493
ICQ: 141057403

Good points, but there may be good answers too.

Yes, it could be a bit slower, but since the entire site is database 
driven, how much difference would this really make?    If the 
calendar shows on every page, that is a pretty big hit on the 
database too.  Also the news blurbs in the right hand column.  All 
the pages are read from the database too.   Why would the language 
queries be special?

Also, there is a way to increase efficiency by storing frequently 
used phrases as session variables.

We would add one column to the language table to name the 
corresponding session variable.  Then instead of 
"show_program_message" we have "get_program_message", and return the 
value to the calling script.

Then, the language call would be:

if (!isset($sv_user_welcome)) 
   { $sv_user_welcome = get_program_message (mod=core,  
phrase='sv_user_welcome' )
 }

The session variable $sv_user_welcome is set inside 
get_program_message, and returned to the calling script.

This way, every individual language query is done once only per 
session.

On 20 Feb 2002 at 9:07, dyn...@us... wrote:

> Bob,
> 
>          Previously, the developers at Appstate mentioned that the
>          reason 
> they did not automate it in the script for others to control is
> because most people do not change their languages often.   It is a one
> time deal on average.
> 
>          The advantage is as you are thinking, but the disadvantage is
>          that 
> you would have to process that statement every time a user logs into
> the website.   This would slow down phpwebsite where it could be
> eliminated.   Of course this is all theoretical and maybe
> insignificant.    But I believe that was the logic for appstate to
> just translate it before it was downloaded.
> 
> 

--
Bob Treumann,  651-603-1245
Elmwood Solutions Inc. (St. Paul, Minnesota)
bo...@el...
http://www.elmwood.com
ORACLE Business Alliance Program Member

Bob,

         Previously, the developers at Appstate mentioned that the reason 
they did not automate it in the script for others to control is because 
most people do not change their languages often.   It is a one time deal on 
average.

         The advantage is as you are thinking, but the disadvantage is that 
you would have to process that statement every time a user logs into the 
website.   This would slow down phpwebsite where it could be 
eliminated.   Of course this is all theoretical and maybe 
insignificant.    But I believe that was the logic for appstate to just 
translate it before it was downloaded.

Ok how about this.  We will put everything together as soon as we move into
feature freeze.

-- 
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University

phpEasyAdmin (http://easyadmin.sourceforge.net)

On Wed, 2002-02-20 at 17:41, Jeremy Agee wrote:
> As we quickly are moving toward our next release I need to let the module and
> them people know what has changed.  This will hopefully allow for a smother
> migration of users to 0.8.2.  If you changes anything that will break a
> theme or modules let me know. I will also go over the expanded module api
> with the mod people.
Modules changes are described in both
docs/developers/module_installer_api.html and docs/mod_example

Themes changes: uhm...as far as I remember we changed:
 1) plug_check calling convenction
 2) a lot of variables previously found in config.php are now part of
the db (poll docking, for example)

Please note i still need to change some things in themes about polls
handling.

Bye,
Alessandro
-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

As we quickly are moving toward our next release I need to let the module and
them people know what has changed.  This will hopefully allow for a smother
migration of users to 0.8.2.  If you changes anything that will break a
theme or modules let me know. I will also go over the expanded module api
with the mod people.

--
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University

phpEasyAdmin (http://easyadmin.sourceforge.net)

Hi all
with this email I would proudly announce that Brian and Matthew
designated me as the official maintainer for the 0.8.x branch of
phpWebSite. I'll officially assume this role immediately after phpWS
0.8.2 will be released, while the most part of you will start work on
the new fallout core. I plan to release a 0.8.3 release approximately at
half of 2nd quarter 2002 (june) : it will contain mainly bugfixes (if
needed), some new features (like a revamped menu system and perhaps a
new setup system) and some cleanups; btw it is my intention to maintain
themes/modules compatibility with 0.8.2, since 0.8.2 still introduces a
lot of changes since the previous 0.8.1 release.
I do not plan to have any release more than 0.8.3 since I agree we need
to focus on 0.9.x and on porting actual code to it.

Please note that the feature/wish list for 0.8.3 is not yet opened and
the points described above are just raw ideas...any suggestion will be
welcome :>

I would say i'm proud of my new role and of being part of phpWebSite
Good work to all of you, guys :>

As usual, i'm available for any further comment/suggestion/whatever

Bye,
Alessandro
-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

See attached file for suggested redesign on language support.

--
Bob Treumann,  651-603-1245
Elmwood Solutions Inc. (St. Paul, Minnesota)
bo...@el...
http://www.elmwood.com
ORACLE Business Alliance Program Member

 Can users be enabled to submit their own
 calendar events without having to go through
 a moderator?  In other words, if we have say
 100 users, 5 admins, can we also have 20
 users with calendar-posting privileges?  In
 a larger sense, can different users have specific
 access to particular areas of phpWebSite?  Thanks
 folks, I need to know this.  Or you can direct
 me to the documentation.

 Richard in Baltimore
 Artmobile.net / MarylandArts.net

=====
__________________________________________________

Richard Tryzno Ellsberry
Ric...@Ma...

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

I have added the code as described below.   I have not found any
location where I can provide user documentation.  How should I do 
this?

There are a few things people will need to know to make this work, on 
their own site.

I have been very careful, but I would be happy to hear about and 
correct any bugs that might have crept in, so please notify me if you 
see any problem.

Thanks, and enjoy!   

   Bob T.

==================================
Modified Files:
  phpwebsite/admin.php
  phpwebsite/config.php
  phpwebsite/links.php
  phpwebsite/user.php
  phpwebsite/mod/userpage/index.php
  phpwebsite/mod/userpage/userpage.php
  phpwebsite/setup/install.php
  phpwebsite/setup/upgrade.php
Added Files:
  phpwebsite/mod/userpage/authors.php
  phpwebsite/mod/userpage/view_pages.php

This mod adds a feature to let users create their own web pages
with permisssion of the site owner.  They use the same interface
as the Admin user, but they cannot change the site menu.
The site owner may set a default page limit for the site, and
individual limits for individual users.

The new code includes TRANSLATE statments, but I haven't yet
edited the english translation files.

Even though I have tested extensively on my dev system,
I have left some markers in the comments ""bobt mod" so I can
quickly find my changes.   I will remove them after testing is
complete.

You can most likely (unless I am rebuilding something)
 see the code running at
  http://portal.dbserve.net/phpwebsite

First of all I would like to thank you for supplying this tarball!

For those of you, like me, running your php-dev machine with
warnings turned on you will get a lot of warnings. Most warnings
seems to be generated in the calendar module, to reduce the
amount of warnings to a more manageable number here a few hints.
The other warnings seems to come mostly from using variables
(indexes) that have not been defined.

(It is of course easier to just change the display warnings/errors
setting in php.ini. But if you, like me, persist in using a more
sensitive setting this is one way to go.).

/z

# Calendar module
/mod/calendar/language.php
you get warnings for all tran[text] => tran['text']
fix: replace $tran[ -> $tran[', replace ] -> ']
(this is easily done with any texteditors search and replace)

/mod/calendar/calendar_display.php
row1130-36: warnings undefined constant: date(G) -> date("G") etc.
row1441: $stuff .= -> $stuff =
row1874: $repeat_days not set

/mod/calendar/cal_block.php
row56: date(Ymd) -> date("Ymd")
row77: warning undefined constant: block_week -> 'block_week';
row193: date(Ymd) -> date("Ymd")
row242: warning undefined constant: block_week -> 'block_day';

# Others
/index.php
row9: $source_dir not set (should probably be $_SERVER
{'DOCUMENT_ROOT'}.'/fallout/')
row15: !empty($mod) && empty($module)

/mod/calendar/menu.php
row30: $menu_bullet is not set
fix: set it to ''

-------------------------------------------------
FREE E-MAIL IN 1 MINUTE!
 - you...@pc... - http://www.pc.nu

Due to the new core using the pear libs we will start to get people that do
not have any idea what there are or how to set it up. I have created a pear
install section that contains directions for root and non root users. These
libs are also available for download.  You can see everything under the
download page near fallout.  So now if you have a user that ask just point
them there so you do not have to explain everything.
--
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University

phpEasyAdmin (http://easyadmin.sourceforge.net)

On Sat, 2002-02-16 at 17:26, Geoff Staples wrote:
> Does this mean that 8.1 modueles will not be compatible with phpWebSite?
> 
> Geoff
Geoff: no
Please note: i'm talking about 3rd party modules
Explanation:
 - 1 : if a site will install with $table_prefix, a module which
       doesn't care about $table_prefix could do mess in the db.
 - 2 : pre-0.8.2 modules aren't provided with the new security
       capability, so it means they will be fully compatible but a
       malicious user could execute modulename_setup.php (if it exist)
typing
       a URL like:
http://www.phpws-powered-site.com/mod/modulename/modulesname_setup.php
and then mess up the db.
 - 3: pre-0.8.2 modules aren't compliant with the module-installer
      mechanism which means that they often aren't listed in the
"installed modules" list, nor they can be installed/uninstalled via
admin panel

Bye
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Does this mean that 8.1 modueles will not be compatible with phpWebSite?

Geoff

At 04:49 AM 2/16/2002, you wrote:
>Hi Bob, here is Alessandro speaking ;>
>At first, welcome into the phpWebSite Dev Team !
>Then....
>
>  1) about links.php : well done!
>  2) about modules you would like to merge before 0.8.2 will get out:
>     what kind of modules they are?
>     please also note _before merging_ them, that you need to make sure
>     they are both $table_prefix compliant and security-compliant.
>     For the second one (security-compliant) you may refer to the new
>     docs/developers/module_installer_api.html, chapter2, paragraph
>     "Security". Please note that you may also want you modules to be
>     take advantage of the new module_installer feature being compatible
>     with it (this is strongly suggested for core modules) : refer to
>     the same doc listed above.
>
>Bye!
>Alessandro
>
>--
>Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
>phpWebSite Development Team http://phpwebsite.appstate.edu
>INWO Project coordinator http://inwoproject.sourceforge.net
>
>"I will carry you through, hicking and screaming,
>  and in the end you will thank me"
>  - Tyler Durden [from "Fight Club"]
>
>
>_______________________________________________
>Phpwebsite-developers mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

Hi Bob, here is Alessandro speaking ;>
At first, welcome into the phpWebSite Dev Team !
Then....

 1) about links.php : well done!
 2) about modules you would like to merge before 0.8.2 will get out:
    what kind of modules they are?
    please also note _before merging_ them, that you need to make sure
    they are both $table_prefix compliant and security-compliant.
    For the second one (security-compliant) you may refer to the new
    docs/developers/module_installer_api.html, chapter2, paragraph
    "Security". Please note that you may also want you modules to be
    take advantage of the new module_installer feature being compatible
    with it (this is strongly suggested for core modules) : refer to
    the same doc listed above.

Bye!
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

The number of hits is important because it is used to order by popularity, 
which is a great feature.

One thing I think would be really great is a "sort by title" and a "sort by 
domain name" that sorts the ENTIRE list, ignoring the categories. Often a 
website is arbitrarily assigned to one of several categories that would be 
appropriate for the link. This makes it hard to find a particular website. 
These sorts would make it much easier to browse the links.

Geoff

At 08:58 PM 2/15/2002, you wrote:
>I'm new to the development group, and I want to start making some
>changes to the code.    I am starting with something really simple in
>the links.php script.  When links are displayed, they are not sorted.
>  I  am adding "order by title" to the query.
>
>I am thnking that should be an obvious improvement .. but what about
>other things?   For instance, I don't think we need to have the word
>"Description" in front of description.  I also don't think we need to
>display when it was added, or how many hits it has had, because the
>information is not useful, (at least to me).
>
>However, I am well aware that everyone may not share this opinion,
>but I don't know how you folks decide issues like this.
>
>Does anybody mind if I comment out the "Hits" and remove the
>"Description" label?
>
>When I get a bit braver, I want to add my code that allows users to
>create their own pages.   Any objections to this?  Support for this?
>
>Thanks!
>
>   Bob Treumann
>
>
>
>_______________________________________________
>Phpwebsite-developers mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers

I successfully added my first two mods to PWS.    I will continue 
with some other small mods, or mods that don't affect others.

I did not do any kind of build, but the only difference it seems to 
make is I have to put up with lots of "TRANSLATE" statements when I 
test.

Hope my short notes here don't bother anyone.  I don't know what kind 
of protocol you all use to communicate changes, so I apologize if I 
am being overcautious.

Bob T.

I'm new to the development group, and I want to start making some 
changes to the code.    I am starting with something really simple in 
the links.php script.  When links are displayed, they are not sorted. 
 I  am adding "order by title" to the query.

I am thnking that should be an obvious improvement .. but what about 
other things?   For instance, I don't think we need to have the word 
"Description" in front of description.  I also don't think we need to 
display when it was added, or how many hits it has had, because the 
information is not useful, (at least to me).

However, I am well aware that everyone may not share this opinion, 
but I don't know how you folks decide issues like this.    

Does anybody mind if I comment out the "Hits" and remove the 
"Description" label?

When I get a bit braver, I want to add my code that allows users to 
create their own pages.   Any objections to this?  Support for this?

Thanks!

  Bob Treumann

Everyone,
Instructions for creating a phpWS phpWiki module were just published by 
Stephen More. Do they meet the cvs snapshot (new 0.8.2) module specifications?

As Php Website Module
http://phpwiki.sourceforge.net/phpwiki/AsPhpWebsiteModule

--
Mike Noyes <mh...@us...>
http://sourceforge.net/users/mhnoyes/
http://leaf.sourceforge.net/content.php?menu=1000&page_id=4

Hi all folks!
this is just to communicate, i've just committed a modification to the
structure of modules which will offer security capabilities against
direct browser access to files like:
/mod/modulename/modulename_install.php , _uninstall.php, _upgrade.php,
_setup.php
This required a new piece of code to be put at the beginning of each of
the files listed above. This change is now also documented also in the
/docs/developers/module_installer_api.html document.
I tested the change with ALL our modules (userpage, mainpage, poll,
blocks, comments, hubit, calendar) and all worked fine with it (btw it
required hours to achieve this result ^_^)

Last but not least, I also fixed a wagon of bugs into module_installer,
which is now really fully functional (pheewwww! :)
I would thank expecially Ryan for his help pointing out all the bugs and
for acknowledging me about the potential security-issues in the (now
previous) structure of modules as the module_installer was requiring it
to be before this change :>

P.S.: now the hybrid module/index.php+module_install and _uninstall
structure is also accepted as fully legitimated choice (it not no more
marked "deprecated"/"not suggested") in
docs/developers/module_installer_api.html.

Hope this things will be useful as I thought implementing them :)
and now, please let me go to drink a barrel of coffee...YAWWWN! :>

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

Hi all,
this is to inform you i've just committed another document in
docs/developers: it describes the html_header_location() and the
form_options() functions and the itemfuncs system.
For those who haven't ever heard about them: they are wrappers and robot
functions to deal with HTML redirection and to automatically generate
forms and item tables. Hope you'll find them useful as I thought
creating them :>

Document is: docs/developers/automated_html_code_generation.html
PS: hope it is okay in english..feel free to fix it if needed :>

Bye,
Alessandro

-- 
Alessandro "TXM" Pisani - al...@ti... - ICQ #2209087
phpWebSite Development Team http://phpwebsite.appstate.edu
INWO Project coordinator http://inwoproject.sourceforge.net

"I will carry you through, hicking and screaming,
 and in the end you will thank me"
 - Tyler Durden [from "Fight Club"]

I'm new to the developer list, and have a question about the "PEAR 
standards"

I looked at the link and noticed to my dismay that the PEAR standards 
call for StudlyCaps in function names..  This is very strange since 
php itself uses lowercase names separated by undercores.

In the eighties, I was part of a Software Engineering methods team at 
Control Data.   We were working on next generation operating systems. 
 Our experience at that time led us to conclude that any standard 
that did not make coding and maintenance easier was detrimental to 
productivity.  At that time, as today, we had code to work with that 
was old, and followed different standards.  Fashions change, but 
there are and always have been people who want to impose their own 
preferences on others.   "Standards" groups seem to attract these 
people.     

We concluded that the coding standards should be limited to rules 
which made it easy to remember the names and understand the 
functions.   For instance, one rule was - no misspellings in function 
names.  It might be attractive to use the name  mv_to_outpt cuz its 
shorter than move_to_output() , but then you and everyone in the 
future needs to remember how you hacked down the words.

In the many projects I have been involved in since then, coding 
standards were followed ONLY if they were simple and limited to 
essential features. 

Complex and detailed standards are generally ignored, especially by 
the most valuable programmers.    Project managers are not going to 
risk missing schedule by trying to get skilled and experienced 
programmers to follow certain capitalization rules, for instance.

Productive programmers are too busy to come to standards meetings, so 
rules would often be designed out of ignorance.  A few years ago, I 
was consulting in a company that released standards saying the Oracle 
table names had to end in "_TBL" and views had to end in "_VW", a 
useless appendage that defeated the concept of tables and views.

PEAR also says: "Use an indent of 4 spaces, with no tabs. ".   I use 
spaces myself, but four is too many, and tends to push your lines too 
far to the right, and sometimes leads to ugly wrapping.   Two spaces 
is enough to show the logic. Even one space works visually.

The point to my question is, does the phpws team really mean to 
impose low level control over how contributors do their coding?  
Isn't it enough to say that coding style must be clean, readable, 
logicallly organized and consistent?  What difference does it make if 
one coder uses StudlyCaps and another doesn't?   

On 13 Feb 2002 at 20:30, Karsten Dambekalns wrote:

> In the article describing the new core are some examples exhibiting
> the php_short_open tag. Since this is "forbidden" by the PEAR coding
> standard (which we adopted for phpWS) that should be changed to
> <?php. Just nitpicking :-)
> 
> And the link to the PEAR coding standard on the coding standards page is
> broken. It now lies under:
>  http://pear.php.net/manual/en/standards.php
> 

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

phpwebsite-developers — For our development team.