PostNuke
Flexible Content Management System
News
Interview: Øivind Skau, PagEd
Since that first contact PagEd has made enormous progress. And it has some ingenious features - every module programmer should take a look at it's administration.
Tell me something about yourself and your projects.
The nick I normally use is Little. I am currently working on two modules. The main one is PagEd, a content management module for Postnuke and eNvolution. Secondly, there is Nubel, a tool intending to facilitate translation of language files, also under the two mentioned systems.
And where do you live?
Originally from Oslo, I now live in Bergen, Norway`s second largest town, on the west coast. Approximately 200 000 citizens, encircled by 7 mountains, pretty picturesque with lots of preserved old wooden houses.
What is your real-life job?
Dividing time between web site design and web application development is what I try to do. An integration of the two means being able to custom-make sites answering to the needs of different customers.
Tell me about your postnuke career.
Actually, the path into Postnuke was quite accidental. A couple of years ago I was searching for a way to let a customer update his site in a more easy way than having to send content to me. I tried a lot of solutions and also experimented with Frontpage before I discovered that there was something called PHPNuke. Being really green on this kind of system and installation, I couldn`t get it to run, and it boiled down to a PHP magic_quotes setting which made the installation process fail. Then Postnuke turned up and required the opposite setting, which was what my hoster had.
As for Postnuke compared to other systems, I have to be honest and say that I use it because it is what I know best, not having much real experience with other systems.
When did you start working on your own module?
Work on PagEd started in January this year. It really evolved from doing some minor hacking in another Postnuke content module, EZCMS, caused by frustration for not being able to add single images to news items in the standard Postnuke News module. EZCMS supported image upload, so I created a way of showing this module`s content as news excerpts on the front page. Then image resizing with NetPBM was implemented (inspired by Menalto Gallery), still as an EZCMS add-on, before it was time to cut the connection and build a new module. Users of EZCMS will probably recognize some of EZCMS in PagEd, although the modules are very different today.
What is your development like? How big is the impact of the community on your development?
The Postnuke community has a tremendous impact on developing PagEd. The module would not look anything near what it is today without substantial community contribution since the early testing days. There has been extensive user testing, resulting in numerous bugfixes; code alterations have been submitted, fixing bugs or enhancing usability; and many features included in the latest version started as suggestions in forum. Then there is translation work which is quite a job, due to a growing list of constants. Being a module developer with this kind of user participation feels a bit like being a focal point of a big lens. Enhancements in the graphical looks of the module? One user took his time to create an icon set for the editor panels. Adding flexibility to the news display? Another user submitted a complete smarty pack for PagEd. Regarding participation, I would also like to mention a local friend who has taken large interest in the module. The user interface layout and navigational feel is mostly to his credit.
Apart from moderating and pulling suggestions and reports from forum, I also make extensive use of the msn messenger channel, discussing in detail development frequently with several capable coders and users. Sometimes this results in brainstorming interface changes, sometimes obstacles in code are overcome after an hour`s chat.
Lastly, the developer site hosts a support request form where users in need can supply log-on information. Troubleshooting bugs has been greatly facilitated by many users letting the developer log on to their servers to see the problem in action.
To sum this question up, I would say that although coding itself has - up until now at least - been a one person job, development of PagEd has been open-source work at it`s best.
What is the biggest difficulty in your development? And why? Is it a Postnuke inherent problem?
I think the main difficulties in PagEd development are two, and the first one is entirely a problem of my own...:
Firstly, entering the module development world has, as was entering the Postnuke world, been a process of learning as you go along. Regarding coding a module, learning how to write the code it self has always been two steps ahead of learning coding dicipline, and the creation of a tidy structure around the work.
Illustrating this is the problem of those module upgrades which require database changes. Database upgrades and table structure changes require the successful execution of one or several sql queries upon first run, while at the same time preserving database content. Tricky business, especially when there must be correct upgrade routines for all existing and published versions of the module out there. Developing upgrade code suffers greatly from untidy coding habits and development environment, and when a module grows, things tend to get out of hand, causing errors and bugs. You get lost. But getting lost often results in the improving of coding habits and dicipline.
Another field which has suffered from to much attention to coding itself is CVS, which hasn`t been implemented in PagEd development at all. This of course makes organizing updates and versions a mess for both devs and users. But again, one can always learn along the way.
The second difficulty I would like to mention in development is more Postnuke related. As many might know, the surfacing of Postnuke as a fork of PHPNuke meant a change in CMS development from keeping everything in a controlled core to allowing for third-party delevopers to enhance the "system experience" (Of course, since those days PHPNuke has also made this move). I guess the decision on whether add-on work should be welcomed or not is a matter of taste and a question of priority. Both ways have their pros and cons. As for Postnuke, following development of both core and third-party modules is fascinating and gives a very dynamic impression. The bad thing is that rather than Postnuke giving the impression of a system which can be perceived and analyzed for module development, the overall feel is that of chaos, a chaos which changes every day. Specifically, there are many ways in which this sense of a vast jungle makes programming for the system difficult.
One thing is the lack of a main place to find out what has been done already. The download section at Postnuke.com is incomplete at best, full of really old material at worst. Getting an overview of existing modules is hard work and requires visiting many sites and forums. This also results in forums being packed with question like "I am looking for a module to do such and such" when one or two excellent ones are available at www.myobscure.site.com ...
Another disadvantage of "letting it all hang loose" is that there are as many third-party "coding philosophies" as there are modules - and modules therefore often conflict with each other in strange ways, causing errors which can take hours and days to hunt down.
Thirdly, when it comes to the flora of add-ons, is the fact that they rarely, if at all, talk to one another. You can have one article module, one calendar and one photo album, and if you want to, let`s say, create news of an event and you want this displayed in all three modules, you will have to go through three different processes. Not to mention that the "dynamical" aspect of Postnuke really is lost if you cannot for instance let changes made regarding this specific news event be felt in the three modules automatically by just making the change in one. As for conflicts and errors, many of these can of course be avoided by studying the Module Developer`s Guide and the API system - but the modules will just the same function like islands with no bridges between them.
What features should the Postnuke .8 core have to simplify your work?
I really do not have any specific needs here apart from the issues already mentioned, which apply more to the structure and nature of Postnuke`s presence on the net. Apart from that, it might be relevant here to express a general opinion on a couple of facets of Postnuke. One is the permission system, and the other is the menu system. Not going into detail here, I can only say that they both rely too much on users being extremely picky on syntax. A small left out dot or a paranthesis is all it takes to mess up something which is meant to work in a certain way, and since these two features of Postnuke often have to work together, the chances of getting it right are even smaller.
This said, I can see that especially the permission system can be a great and very advanced tool, but the price seems a bit high every time you read a forum post from somebody who is suddenly locked out of their own site because of a small mistake in configuring access. - One would really think that there has been some kind of development since the DOS days towards something more point-and-clicky, but there are aspects of Postnuke that do lag behind a bit. However, it does keep web maintainers in their job, cause while updating content can be easy, maintaining and altering site structure certainly isn`t.
Which route will Postnuke/your module in your opinion go in the future?
Both being open source products, predictions can be hard to make. If they were commercial products, you could try to analyze financial liquidity and the sellability of the product compared to competitors, but with Postnuke and PagEd it would be more a question of knowing the people behind the programs - how much time they are prepared to invest in development, how they cooperate, and whether there are differences in opinion on which path the applications should take, differences that may or may not lead to the evolvement of forks or completely new products based on the current code. As for the Postnuke product itself, I think a look at the upcoming 0.8 version will give some answers as to what future position the CMS will have in the growing and
exciting world of open-source web site systems.
Turning to PagEd, development will focus on improving the existing code in terms of stability and speed - but perhaps more relevant to the question of the future would be that we certainly would like to see the module work under more CMS systems, in addition to the current compatibility with Postnuke and eNvolution.
What should users of your module regard? What is the weakest/strongest point in your module?
Well, we`re working on a couple of weak points at the moment. Mainly this has been some shortcomings when it comes to handling large amounts of content - breaking it up into smaller pieces, and this goes for both text and images. And the image handling routines certainly are giving us hard times, always, since they rely on server/webhoster settings which come in a great variety of configurations. Another weak point is the lack of a user`s manual, which has been requested several times, but there never really is time to focus on it... In the "early days" there wasn`t more functionality than could be learned in a short time, but as the module grows, users perceive the module differently from devs, something which isn`t always easy to anticipate. An aspect which seems obvious to a dev can actually be the exact opposite to a new user.
As for strong points, I would have to mention again the user community. I need look no longer than the current surroundings of 0.90 development: Despite being a "use at your own risk" pack, an impressive number of users have taken the risk of installing it and reports are coming in.
Apart from that, PagEd has a few main focus areas which are at least intended to be it`s strong points: 1. An intuitive interface, 2. Friendlyness towards a wide variety of server environments, and 3. Practical handling of large numbers of content items, relying on topics and layout templates which are meant to be used as instruments for making "batch" changes in numerous content items at once.
Anything else you always wanted to say about Postnuke/your module?
Try it!
Visit PagEd at: http://paged.anubix.net/
Tell me something about yourself and your projects.
The nick I normally use is Little. I am currently working on two modules. The main one is PagEd, a content management module for Postnuke and eNvolution. Secondly, there is Nubel, a tool intending to facilitate translation of language files, also under the two mentioned systems.
And where do you live?
Originally from Oslo, I now live in Bergen, Norway`s second largest town, on the west coast. Approximately 200 000 citizens, encircled by 7 mountains, pretty picturesque with lots of preserved old wooden houses.
What is your real-life job?
Dividing time between web site design and web application development is what I try to do. An integration of the two means being able to custom-make sites answering to the needs of different customers.
Tell me about your postnuke career.
Actually, the path into Postnuke was quite accidental. A couple of years ago I was searching for a way to let a customer update his site in a more easy way than having to send content to me. I tried a lot of solutions and also experimented with Frontpage before I discovered that there was something called PHPNuke. Being really green on this kind of system and installation, I couldn`t get it to run, and it boiled down to a PHP magic_quotes setting which made the installation process fail. Then Postnuke turned up and required the opposite setting, which was what my hoster had.
As for Postnuke compared to other systems, I have to be honest and say that I use it because it is what I know best, not having much real experience with other systems.
When did you start working on your own module?
Work on PagEd started in January this year. It really evolved from doing some minor hacking in another Postnuke content module, EZCMS, caused by frustration for not being able to add single images to news items in the standard Postnuke News module. EZCMS supported image upload, so I created a way of showing this module`s content as news excerpts on the front page. Then image resizing with NetPBM was implemented (inspired by Menalto Gallery), still as an EZCMS add-on, before it was time to cut the connection and build a new module. Users of EZCMS will probably recognize some of EZCMS in PagEd, although the modules are very different today.
What is your development like? How big is the impact of the community on your development?
The Postnuke community has a tremendous impact on developing PagEd. The module would not look anything near what it is today without substantial community contribution since the early testing days. There has been extensive user testing, resulting in numerous bugfixes; code alterations have been submitted, fixing bugs or enhancing usability; and many features included in the latest version started as suggestions in forum. Then there is translation work which is quite a job, due to a growing list of constants. Being a module developer with this kind of user participation feels a bit like being a focal point of a big lens. Enhancements in the graphical looks of the module? One user took his time to create an icon set for the editor panels. Adding flexibility to the news display? Another user submitted a complete smarty pack for PagEd. Regarding participation, I would also like to mention a local friend who has taken large interest in the module. The user interface layout and navigational feel is mostly to his credit.
Apart from moderating and pulling suggestions and reports from forum, I also make extensive use of the msn messenger channel, discussing in detail development frequently with several capable coders and users. Sometimes this results in brainstorming interface changes, sometimes obstacles in code are overcome after an hour`s chat.
Lastly, the developer site hosts a support request form where users in need can supply log-on information. Troubleshooting bugs has been greatly facilitated by many users letting the developer log on to their servers to see the problem in action.
To sum this question up, I would say that although coding itself has - up until now at least - been a one person job, development of PagEd has been open-source work at it`s best.
What is the biggest difficulty in your development? And why? Is it a Postnuke inherent problem?
I think the main difficulties in PagEd development are two, and the first one is entirely a problem of my own...:
Firstly, entering the module development world has, as was entering the Postnuke world, been a process of learning as you go along. Regarding coding a module, learning how to write the code it self has always been two steps ahead of learning coding dicipline, and the creation of a tidy structure around the work.
Illustrating this is the problem of those module upgrades which require database changes. Database upgrades and table structure changes require the successful execution of one or several sql queries upon first run, while at the same time preserving database content. Tricky business, especially when there must be correct upgrade routines for all existing and published versions of the module out there. Developing upgrade code suffers greatly from untidy coding habits and development environment, and when a module grows, things tend to get out of hand, causing errors and bugs. You get lost. But getting lost often results in the improving of coding habits and dicipline.
Another field which has suffered from to much attention to coding itself is CVS, which hasn`t been implemented in PagEd development at all. This of course makes organizing updates and versions a mess for both devs and users. But again, one can always learn along the way.
The second difficulty I would like to mention in development is more Postnuke related. As many might know, the surfacing of Postnuke as a fork of PHPNuke meant a change in CMS development from keeping everything in a controlled core to allowing for third-party delevopers to enhance the "system experience" (Of course, since those days PHPNuke has also made this move). I guess the decision on whether add-on work should be welcomed or not is a matter of taste and a question of priority. Both ways have their pros and cons. As for Postnuke, following development of both core and third-party modules is fascinating and gives a very dynamic impression. The bad thing is that rather than Postnuke giving the impression of a system which can be perceived and analyzed for module development, the overall feel is that of chaos, a chaos which changes every day. Specifically, there are many ways in which this sense of a vast jungle makes programming for the system difficult.
One thing is the lack of a main place to find out what has been done already. The download section at Postnuke.com is incomplete at best, full of really old material at worst. Getting an overview of existing modules is hard work and requires visiting many sites and forums. This also results in forums being packed with question like "I am looking for a module to do such and such" when one or two excellent ones are available at www.myobscure.site.com ...
Another disadvantage of "letting it all hang loose" is that there are as many third-party "coding philosophies" as there are modules - and modules therefore often conflict with each other in strange ways, causing errors which can take hours and days to hunt down.
Thirdly, when it comes to the flora of add-ons, is the fact that they rarely, if at all, talk to one another. You can have one article module, one calendar and one photo album, and if you want to, let`s say, create news of an event and you want this displayed in all three modules, you will have to go through three different processes. Not to mention that the "dynamical" aspect of Postnuke really is lost if you cannot for instance let changes made regarding this specific news event be felt in the three modules automatically by just making the change in one. As for conflicts and errors, many of these can of course be avoided by studying the Module Developer`s Guide and the API system - but the modules will just the same function like islands with no bridges between them.
What features should the Postnuke .8 core have to simplify your work?
I really do not have any specific needs here apart from the issues already mentioned, which apply more to the structure and nature of Postnuke`s presence on the net. Apart from that, it might be relevant here to express a general opinion on a couple of facets of Postnuke. One is the permission system, and the other is the menu system. Not going into detail here, I can only say that they both rely too much on users being extremely picky on syntax. A small left out dot or a paranthesis is all it takes to mess up something which is meant to work in a certain way, and since these two features of Postnuke often have to work together, the chances of getting it right are even smaller.
This said, I can see that especially the permission system can be a great and very advanced tool, but the price seems a bit high every time you read a forum post from somebody who is suddenly locked out of their own site because of a small mistake in configuring access. - One would really think that there has been some kind of development since the DOS days towards something more point-and-clicky, but there are aspects of Postnuke that do lag behind a bit. However, it does keep web maintainers in their job, cause while updating content can be easy, maintaining and altering site structure certainly isn`t.
Which route will Postnuke/your module in your opinion go in the future?
Both being open source products, predictions can be hard to make. If they were commercial products, you could try to analyze financial liquidity and the sellability of the product compared to competitors, but with Postnuke and PagEd it would be more a question of knowing the people behind the programs - how much time they are prepared to invest in development, how they cooperate, and whether there are differences in opinion on which path the applications should take, differences that may or may not lead to the evolvement of forks or completely new products based on the current code. As for the Postnuke product itself, I think a look at the upcoming 0.8 version will give some answers as to what future position the CMS will have in the growing and
exciting world of open-source web site systems.
Turning to PagEd, development will focus on improving the existing code in terms of stability and speed - but perhaps more relevant to the question of the future would be that we certainly would like to see the module work under more CMS systems, in addition to the current compatibility with Postnuke and eNvolution.
What should users of your module regard? What is the weakest/strongest point in your module?
Well, we`re working on a couple of weak points at the moment. Mainly this has been some shortcomings when it comes to handling large amounts of content - breaking it up into smaller pieces, and this goes for both text and images. And the image handling routines certainly are giving us hard times, always, since they rely on server/webhoster settings which come in a great variety of configurations. Another weak point is the lack of a user`s manual, which has been requested several times, but there never really is time to focus on it... In the "early days" there wasn`t more functionality than could be learned in a short time, but as the module grows, users perceive the module differently from devs, something which isn`t always easy to anticipate. An aspect which seems obvious to a dev can actually be the exact opposite to a new user.
As for strong points, I would have to mention again the user community. I need look no longer than the current surroundings of 0.90 development: Despite being a "use at your own risk" pack, an impressive number of users have taken the risk of installing it and reports are coming in.
Apart from that, PagEd has a few main focus areas which are at least intended to be it`s strong points: 1. An intuitive interface, 2. Friendlyness towards a wide variety of server environments, and 3. Practical handling of large numbers of content items, relying on topics and layout templates which are meant to be used as instruments for making "batch" changes in numerous content items at once.
Anything else you always wanted to say about Postnuke/your module?
Try it!
Visit PagEd at: http://paged.anubix.net/
Germany: Registered Association for PostNuke (PostNuke e.V.)
Further original members are:
Jörg Napp (jn)
Alexander Bergmann (chasm)
Bernd Müller-Heitmann (Bernd)
Sebastian Frey (Traveller)
The fundamental idea for a development association emerged at the beginning of 2003. Mainly in the German language area we wanted to represent PostNuke. JUst now in the situation of ongoing discussions about the legal effect of the GPL in Europe and Germany it was our aim to build up an adequat institution together with the international project management.
Our idea based on the wish to strengthen the inner company of the community, to promote the cooperation of national and international developers and to build up a professional image.
We hope as a result a promotion of the development of additional modules and of PostNuke itself.
Our legal registration is stil pending at the local court in Berlin, Germany. So we will say more on this point at a later date.
The association is operator of post-nuke.net and there will not be any changes in services and support. We hope it will be as good as ever.
Jörg Napp (jn)
Alexander Bergmann (chasm)
Bernd Müller-Heitmann (Bernd)
Sebastian Frey (Traveller)
The fundamental idea for a development association emerged at the beginning of 2003. Mainly in the German language area we wanted to represent PostNuke. JUst now in the situation of ongoing discussions about the legal effect of the GPL in Europe and Germany it was our aim to build up an adequat institution together with the international project management.
Our idea based on the wish to strengthen the inner company of the community, to promote the cooperation of national and international developers and to build up a professional image.
We hope as a result a promotion of the development of additional modules and of PostNuke itself.
Our legal registration is stil pending at the local court in Berlin, Germany. So we will say more on this point at a later date.
The association is operator of post-nuke.net and there will not be any changes in services and support. We hope it will be as good as ever.
PNphpBBHacks - The #1 Source for PNphpBBHacks
This is not intended to rip any other sites, but more as a way to take the load off PNphpBB.com's forums with all the questions about converting mods. Here we will not only supply converted mods and themes but tell users how its done and give them any support needed.
Please if you know about phpBB mods and the way in which they can be used on PNphpBB, or have written any of your own, then come to PNphpBBHacks.com and help out.
- Phil Sturgeon
Please if you know about phpBB mods and the way in which they can be used on PNphpBB, or have written any of your own, then come to PNphpBBHacks.com and help out.
- Phil Sturgeon
Boston University Office of Career Services
Footnote: 1
Interview: pnCommerce-Team
Who belongs to the pnCommerce team?
Patrick Cornelissen: First of all there is Mario G. (gzuki) from Priesendorf/Bavaria in Germany who just finished his military service. Next is Frank Schummertz (Landseer) from Stuttgart, Germany. He works as IT specialist in a consulting company. JimHadfield (JimHadfield) is from Big Lake, MN, USA and works there as web designer. I personally live in Bonn, Germany and study computer science and software development. And Sebastian Schürmann, who already introduced himself in another interview ;-) Then there is David, he was also with us at the developer meeting, but his is afk atm so that he also didn't participate in this interview.
Let's begin where it alle started: How did your Postnuke career start?
Patrick.c: I started with Postnuke ~2 years ago. PN was much easier to install and the administrative stuff was/is very comfortable. PN has a lot of 3rd party modules too, that was very impressive.
gzuki: And the good api!
Landseer: End of 2002 I was asked to take care of the homepage of a German dog breeder club. This is a static page with only a few regular updates and my intention was to create a portal site where everyone can contribute something. So I started searching for such kind of system, stumbled upon phpwebsite and phpNuke and finally came to PostNuke. Unfortunately they never agreed to use this system so the site is still not nuked :-(
But at the moment I am working on a nuked website of the company I am working for. It will consist of a external part with information using some static sites with Xexpress and internal sites for the employees with forums, download, employee pages, tim recording and so on.
JimHadfield: I looked at several sites and finally ended up using PN for a group (http://oldihc.org) in Dec. 2001. It's been a success since the very first day. I have PN installed on several sites with some custom modules on some of them.
When did you start working on your own module?
Patrick.c: We started the project ~February 2003
gzuki: joined the team March/April???
Landseer: The breeders club website should contain a webshop for some dog related stuff and so I began evaluating PostKart when Rex stopped development and Pat asked for volunteers to fork. I had plenty of time and so I started working on pncommerce. From January to March I worked 8 to 10 hours per day on pnc. Since two weeks I am also working on the timerecording module pnHora, which will be used on the internal webpage of the company I am working for. It is currently in pre-alpha state.
JimHadfield: From the very beginning ~February 2003
What is your development like? How do you work together?
Patrick.c: Development is a lot of work, but with a good team it's possible to handle it. We communicate by chat, ML, Forums and sometimes by telephone. We also had a developer meeing in august too. I hope that the impact on the community is big :-) because the need for a good shopping cart is evident, so we hope to get positive feedback from the users out there and maybe some more help.
Landseer: PN module development teams consists of people, who normally never meet each other in real life so I work on my own as the others do also. Important decisions have been discussed in our internal dev mailinglist or in our daily chat in our EuIRC channel #pn-commerce. This and email are the most important ways of communicationg with each other. Another big thing is the CVS at sourceforge. CVS is the best thing ever invented for people working at different places :-) Mid of August our first DevMeeting took place in Würzburg, where four of the team met for the first time (generally). Via webcam our documentation guru Jim was also connected. The main development has been done by a couple of developers who could easily agree when we had to make such decisions.
The impact of the community is big, even bigger, after we released the first alpha version. Now the people know what pnc can do and so they can give us suggestions where to go to and what to implement also. Sometimes it's hard to say "Not possible at the moment" :-).
JimHadfield: The response from the community has been fantastic. CVS is a lifesaver!
What is the biggest difficulty in your development?
Patrick.c: One problem, we had, is the bad documentation. The Module Developers Guide has a lot of unclear points and the api documentation documents functions that are not written yet. Dabase has restarted the API Documentation project, so I hope it will get better soon, but this was one of the major problems from my point of view. The unclear information flow from the PostNuke leaders should be more open. We module dev's need all informations about comming changes in API, workflow or whatever as soon as possible, to be able to consider this in our strategy. We don't have time to invent the wheel 4 or 5 times because the layout system has changed for example.
Landseer: Personally the biggest problem is that I had to learn PHP and the Postnuke API at the same time. I started programming in the late 80's with Basic, Oberon and C on an Amiga so the basics are there and the step to PHP was not so difficult.
JimHadfield: My biggest problem (?) was working with a bunch of guys that were great to work with! I don't usually get that lucky!
What features should the Postnuke .8 core have to simplify your work?
Patrick.c: The SSL support for the modurl function we gave the dev team. And Smarty :-)
Landseer: The templating engine that will be in .8 simplifies our work dramatically. We are already porting pnc to Smarty and see, how much code we are going to get rid of in pnuser/pnadmin without minimizing the shop's capabilities. Another needed thing would be generic SSL support in .8, we made a suggestion to the core devs (really easy thing), which did not make it into the .726 package, but maybe in the next one.
Which route will Postnuke/your module in your opinion go in the future?
Patrick.c: Finish Smartification, add custom properties and add the missing small tweaks. After that maybe a compatibility layer to make it possible to use the module on different Postnuke-descendants. Custom properties is one of the most demanded features. You can create for example a tshirt product with it and assign different sizes. The whole thing is very complicated because there are a lot of thigs that we have to keep in mind, so it may take a while until this is completely working.
Landseer: I don't see a clear future for Postnuke (which does not mean that I do not see any future for PostNuke!!). The information politic by the projects leaders is very poor and can be heavily improved. The open module developers mailing list is dead (at least I do not get anything from there), compared to the Xaraya dev list it is more than dead. We can be glad that the community is strong and giving support where it is needed.
JimHadfield: I have to agree with Frank.. Sometimes it is real hard to truly see where PN is going with all of their internal bickering. We will still produce a igh quality product/module that will work with it and others.
What should users of your module regard?
Patrick.c: we have some difficulties with our plugin system and windows servers, the rest works fine most of the time. 75% of all problems occur because people have not filled out the main settings, wrong permissions or missing files.
Landseer: The strongest point is that pncommerce is completely modular and that it can be easily extended. This makes it a very powerful shopping cart solution which will even get better with Smarty, there you can do things which are not possible right now. The 0.82 version still looks to much like PostKart, this is going to change in the next version. Maybe this is the weakest point. But "under the hood" there is nearly nothing from the old program left over, I guess that more than 98% of the code have been changed to meet our requirements. I think that there will be a time when you can see two completely different shops that both use pncommerce, but with their own templates and their own layout.
JimHadfield: The biggest problem?? People do not read the docs...
Anything else you always wanted to say about Postnuke/your module?
Patrick.c: We hope to provide a good module to the community and help Postnuke to cover more areas. In return I hope to get more public informations about the PN development. We have really good programmers in the community, so it would be nice to discuss some changes in the public to get different views. The final decision should be made in the dev team after that. (Just a hint)
Patrick Cornelissen: First of all there is Mario G. (gzuki) from Priesendorf/Bavaria in Germany who just finished his military service. Next is Frank Schummertz (Landseer) from Stuttgart, Germany. He works as IT specialist in a consulting company. JimHadfield (JimHadfield) is from Big Lake, MN, USA and works there as web designer. I personally live in Bonn, Germany and study computer science and software development. And Sebastian Schürmann, who already introduced himself in another interview ;-) Then there is David, he was also with us at the developer meeting, but his is afk atm so that he also didn't participate in this interview.
Let's begin where it alle started: How did your Postnuke career start?
Patrick.c: I started with Postnuke ~2 years ago. PN was much easier to install and the administrative stuff was/is very comfortable. PN has a lot of 3rd party modules too, that was very impressive.
gzuki: And the good api!
Landseer: End of 2002 I was asked to take care of the homepage of a German dog breeder club. This is a static page with only a few regular updates and my intention was to create a portal site where everyone can contribute something. So I started searching for such kind of system, stumbled upon phpwebsite and phpNuke and finally came to PostNuke. Unfortunately they never agreed to use this system so the site is still not nuked :-(
But at the moment I am working on a nuked website of the company I am working for. It will consist of a external part with information using some static sites with Xexpress and internal sites for the employees with forums, download, employee pages, tim recording and so on.
JimHadfield: I looked at several sites and finally ended up using PN for a group (http://oldihc.org) in Dec. 2001. It's been a success since the very first day. I have PN installed on several sites with some custom modules on some of them.
When did you start working on your own module?
Patrick.c: We started the project ~February 2003
gzuki: joined the team March/April???
Landseer: The breeders club website should contain a webshop for some dog related stuff and so I began evaluating PostKart when Rex stopped development and Pat asked for volunteers to fork. I had plenty of time and so I started working on pncommerce. From January to March I worked 8 to 10 hours per day on pnc. Since two weeks I am also working on the timerecording module pnHora, which will be used on the internal webpage of the company I am working for. It is currently in pre-alpha state.
JimHadfield: From the very beginning ~February 2003
What is your development like? How do you work together?
Patrick.c: Development is a lot of work, but with a good team it's possible to handle it. We communicate by chat, ML, Forums and sometimes by telephone. We also had a developer meeing in august too. I hope that the impact on the community is big :-) because the need for a good shopping cart is evident, so we hope to get positive feedback from the users out there and maybe some more help.
Landseer: PN module development teams consists of people, who normally never meet each other in real life so I work on my own as the others do also. Important decisions have been discussed in our internal dev mailinglist or in our daily chat in our EuIRC channel #pn-commerce. This and email are the most important ways of communicationg with each other. Another big thing is the CVS at sourceforge. CVS is the best thing ever invented for people working at different places :-) Mid of August our first DevMeeting took place in Würzburg, where four of the team met for the first time (generally). Via webcam our documentation guru Jim was also connected. The main development has been done by a couple of developers who could easily agree when we had to make such decisions.
The impact of the community is big, even bigger, after we released the first alpha version. Now the people know what pnc can do and so they can give us suggestions where to go to and what to implement also. Sometimes it's hard to say "Not possible at the moment" :-).
JimHadfield: The response from the community has been fantastic. CVS is a lifesaver!
What is the biggest difficulty in your development?
Patrick.c: One problem, we had, is the bad documentation. The Module Developers Guide has a lot of unclear points and the api documentation documents functions that are not written yet. Dabase has restarted the API Documentation project, so I hope it will get better soon, but this was one of the major problems from my point of view. The unclear information flow from the PostNuke leaders should be more open. We module dev's need all informations about comming changes in API, workflow or whatever as soon as possible, to be able to consider this in our strategy. We don't have time to invent the wheel 4 or 5 times because the layout system has changed for example.
Landseer: Personally the biggest problem is that I had to learn PHP and the Postnuke API at the same time. I started programming in the late 80's with Basic, Oberon and C on an Amiga so the basics are there and the step to PHP was not so difficult.
JimHadfield: My biggest problem (?) was working with a bunch of guys that were great to work with! I don't usually get that lucky!
What features should the Postnuke .8 core have to simplify your work?
Patrick.c: The SSL support for the modurl function we gave the dev team. And Smarty :-)
Landseer: The templating engine that will be in .8 simplifies our work dramatically. We are already porting pnc to Smarty and see, how much code we are going to get rid of in pnuser/pnadmin without minimizing the shop's capabilities. Another needed thing would be generic SSL support in .8, we made a suggestion to the core devs (really easy thing), which did not make it into the .726 package, but maybe in the next one.
Which route will Postnuke/your module in your opinion go in the future?
Patrick.c: Finish Smartification, add custom properties and add the missing small tweaks. After that maybe a compatibility layer to make it possible to use the module on different Postnuke-descendants. Custom properties is one of the most demanded features. You can create for example a tshirt product with it and assign different sizes. The whole thing is very complicated because there are a lot of thigs that we have to keep in mind, so it may take a while until this is completely working.
Landseer: I don't see a clear future for Postnuke (which does not mean that I do not see any future for PostNuke!!). The information politic by the projects leaders is very poor and can be heavily improved. The open module developers mailing list is dead (at least I do not get anything from there), compared to the Xaraya dev list it is more than dead. We can be glad that the community is strong and giving support where it is needed.
JimHadfield: I have to agree with Frank.. Sometimes it is real hard to truly see where PN is going with all of their internal bickering. We will still produce a igh quality product/module that will work with it and others.
What should users of your module regard?
Patrick.c: we have some difficulties with our plugin system and windows servers, the rest works fine most of the time. 75% of all problems occur because people have not filled out the main settings, wrong permissions or missing files.
Landseer: The strongest point is that pncommerce is completely modular and that it can be easily extended. This makes it a very powerful shopping cart solution which will even get better with Smarty, there you can do things which are not possible right now. The 0.82 version still looks to much like PostKart, this is going to change in the next version. Maybe this is the weakest point. But "under the hood" there is nearly nothing from the old program left over, I guess that more than 98% of the code have been changed to meet our requirements. I think that there will be a time when you can see two completely different shops that both use pncommerce, but with their own templates and their own layout.
JimHadfield: The biggest problem?? People do not read the docs...
Anything else you always wanted to say about Postnuke/your module?
Patrick.c: We hope to provide a good module to the community and help Postnuke to cover more areas. In return I hope to get more public informations about the PN development. We have really good programmers in the community, so it would be nice to discuss some changes in the public to get different views. The final decision should be made in the dev team after that. (Just a hint)
Web Accessibility - An introduction
Accessibility - In General
According to the German federal law on equality of treatment of handicapped persons (BGG §4) ", constructions, means of transportation, technical commodities, systems of information processing, accustic and visual sources of information and communicative systems are accessible when they are accessible and usable for handicapped persons unaidedly, in the usual way and without special difficulty."
Basically, accessible web pages aren't only accessible for the average user
at his desktop pc with the latest browsers. Web-accessibility is not only considerate
of the various utilities that handicapped persons use to perceive a web page,
but also of users with older browser versions or with special access hardware.
Some figures to give an idea of the size of this group (statistics from Germany):
- 10% of the male population is color-blind. Web pages with low contrasts (eg. black fonts on dark-blue background) is for them practically unreadable. "Press the green button to verify" is meaningless to them.
- 5% of the population is blind or visually handicapped. They use special utilities and hardware like Braille-displays or screenreaders.
- 11% of the population is older than 65.
- 5% of internet users don't use Windows, but MacOS, Linux, PDAs or cellphones.
- Numerous sites, especially large ones, still have up to 20% users visiting them through 4th generation Netscape browsers.
If you don't only aim at gamer kiddies with 19" displays, you should start thinking about whom you exclude with your killer design. A blind person for example, who cannot use a company`s internet pages, will choose another vendor. But what can a blind person do when his registration office's internet site is not accessible?
The Legal Side
Since May 1st, 2002, the ordinance for accessible information technology (BITV) became effective. All federal institutions are obliged to make their internet sites accessible - in the sense of the word used in this article. Governments are called to work out similar state laws which oblige state and municipal institutions to follow accessibility guidelines.
BGG and BITV are based on the EU action plan "eEurope 2002", initiated in 1999 and finalised in 2000 by the European Council. eEurope aims at 3 main goals:
- A cheaper, faster and more secure internet
- Advancement of internet use
- Investment into persons and abilities
The latter comprises the participation in information technology of as big parts of the population as possible. Summarised under the term "eAccessibility", access to eCommerce, eGovernment and so on is to be made possible. This was to be implemented with the adoption of the Web Accessability Initative's guidelines.
Guidelines for Practical Use
Already in 1999 the World Wide Web Consortium (W3C) released the Web Content Accessibility Guidelines 1.0 and made it quasi-standard for accessible internet design. Since then many of the rules have proved too restrictive, irrelevant, incomprehensible or simply not representative of the state of technology anymore. Some of them even turned out to be not internationally applicable. For these reasons a version 2.0 is in the making. Since v. 2.0 is still in development, this text will only relate to WCAG 1.
The Web Content Accessibility Guidelines 1 are split up into 3 priorities:
Priority 1: A Web content developer must satisfy this checkpoint
Priority 2: A Web content developer should satisfy this checkpoint
Priority 3: A Web content developer may satisfy this checkpoint
If you violate a regulation of priority 1, many people will be excluded. A violation of priority 3 regulations excludes only few. There are 14 main regulations, with the priorities attached to all of their subcategories:
1. Provide equivalent alternatives to auditory and visual content.
2. Do not rely on color alone.
3. Use markup and style sheets, and do so properly.
4. Clarify natural language usage.
5. Create tables that transform gracefully.
6. Ensure that pages featuring new technologies transform gracefully.
7. Ensure user control of time-sensitive content changes.
8. Ensure direct accessibility of embedded user interfaces.
9. Design for device-independence.
10. Use interim solutions.
11. Use W3C technologies and guidelines.
12. Provide context and orientation information.
13. Provide clear navigation mechanisms.
14. Ensure that documents are clear and simple.
There is also a W3C-list of suggested Techniques for Web Content Accessibility Guidelines 1.0.
Testing Accessability
Several tools exist for testing the accessibility of your website:
http://www.w3.org/WAI/WCAG1AAA-Conformance
As a result you receive 3 levels of conformance:
Conformance Level "A": All Priority 1 checkpoints
are satisfied
Conformance Level "Double-A": All Priority 1 and
2 checkpoints are satisfied
Conformance Level "Triple-A": All Priority 1, 2,
and 3 checkpoints are satisfied
Internet sites of German federal instititions have to fullfil Double-A conformance. Recommended is Triple-A.
Not only for handicapped persons
A main problem with accessibilty is that a web site must cater to the needs of two different interest groups: On the one
hand, handicapped persons that already have to use the latest browser version
in cooperation with their hardware and utilities, and on the other hand, users
with old browsers.
This problem is however a perfect focus area for the idea behind CMS-es: The separation
of content and layout. It becomes possible to detect the user browser client, and in a manageable way offer
a classical HTML 3.0 page or a modern HTML 4.01 page, with the same content.
Practically speaking, modern web design means above all to do without tables for layout use. Tables have always been a crutch when it comes to creating layout, and more so today than ever. Modern layout is created via CSS. A nice example of how accessible design can be created can be found at http://www.inknoise.com/experimental/layoutomatic.php. This also shows that accessible web sites do not have to be plain text.
Tables should only be used the way they were originally intended: For example as an address table with columns and rows, column heads and so on. Used this way, also the tools of blind persons can make sense of them.
Accessibility and Postnuke
Making a Postnuke site accessible is practically impossible: While themes can easily be created with CSS, you will fail at the modules, which excessively use hardcoded tables. Not until the introduction of the Xanthia Templating Engine in Postnuke 0.8 will it be possible to make your site accessible for everyone. Then you can start developing accessible templates for all API-compliant modules, something which is currently possible only with third-party modules that use smarty, like PostCalendar or pnCommerce.
Until then the possibilities are limited when it comes to making at least some of your content accessible: The AvantGo module - originally designed to make the News accessible for PDAs - can also be used for accessibility. There seems to be an extended version of the Avantgo named Extravantgo, but during my researches the download page was inaccessible ;-)
German version of this article: post-nuke.net
Major re-launch of the PHP Hub site.
Footnote: 1
php-con West extends Early Bird to Oct. 10th!
- Fill in your registration and payment information
- Select “PostNuke†when asked “Which organization offered you this promotion?â€
- Type in priority code: “postn†when prompted
** Why you need to be at php-con West 2003 **
Why is php-con the destination of choice for PHP and web developers? Because php-con is about three things: Community. Code. Solutions.
Our entire program is filled with speakers selected as much for their contributions to the community as for their expert knowledge of PHP. Joining us at php-con West 2003 are:
* Keynote Speakers Zeev Suraski of Zend Technologies and Author Sterling Hughes
* PostgreSQL Core Team member Josh Berkus
* Yahoo! PHP Guru Michael Radwin
* MySQL evangelist Zak Greant
* Apache.com's Jim Winstead
* PHP.net's James Cox
* PostNuke's Vanessa Haakenson
* Industry experts George Schlossnagle, Wez Furlong and new speakers John Neil, Allie Micka, Frank Kromann, and Aaron Stone
* Authors Christian Wenz, John Coggeshall, Luke Welling and Laura Thomson
Whether you're new to PHP or dig your hands into it everyday, this is where you want to be.
php-con West 2003: Community. Code. Solutions.
October 21- 24, 2003
Biltmore Hotel
Santa Clara, California
www.php-con.com
- Select “PostNuke†when asked “Which organization offered you this promotion?â€
- Type in priority code: “postn†when prompted
** Why you need to be at php-con West 2003 **
Why is php-con the destination of choice for PHP and web developers? Because php-con is about three things: Community. Code. Solutions.
Our entire program is filled with speakers selected as much for their contributions to the community as for their expert knowledge of PHP. Joining us at php-con West 2003 are:
* Keynote Speakers Zeev Suraski of Zend Technologies and Author Sterling Hughes
* PostgreSQL Core Team member Josh Berkus
* Yahoo! PHP Guru Michael Radwin
* MySQL evangelist Zak Greant
* Apache.com's Jim Winstead
* PHP.net's James Cox
* PostNuke's Vanessa Haakenson
* Industry experts George Schlossnagle, Wez Furlong and new speakers John Neil, Allie Micka, Frank Kromann, and Aaron Stone
* Authors Christian Wenz, John Coggeshall, Luke Welling and Laura Thomson
Whether you're new to PHP or dig your hands into it everyday, this is where you want to be.
php-con West 2003: Community. Code. Solutions.
October 21- 24, 2003
Biltmore Hotel
Santa Clara, California
www.php-con.com
Interview: Shawn McKenzie
What module(s) are you working on?
AutoTheme
AutoTheme is a revolutionary multi-platform HTML Theme System for eNvolution, PHP-Nuke, PostNuke and MD-Pro CMSs. The current theme systems requires you to be somewhat familiar with PHP and the CMS architecture. If you are not very familiar with PHP and/or the CMS inner-workings, AutoTheme removes this complexity. It is not only simple, it is powerful. Much more control and many more customization options are possible with AutoTheme than are possible with the current theme code.
AutoTheme's primary benefit is providing users the ability to create themes in HTML using their favorite editor, with no use of PHP. In addition, AutoTheme provides easy customization of every part of your site including: block display, custom templates for the Home Page, User Pages and Admin Pages and individual modules, as well as, templating of blocks and control over when and where each block is displayed. The addition of AutoBlocks provides unlimited locations for your blocks. All AutoTheme settings are easily configured from a graphical administration interface that is integrated into the supported CMSs.
AutoTheme is packaged as a module and comes in two flavors: the feature packed, fully administration driven, commercial version and the free GPL AT-Lite. The commercial version (currently AutoTheme 1.7) provides template compiling and caching, an Extras (plugins) and Extra commands architecture for easily extending AutoTheme, as well as other premium features.
AT-Lite
AT-Lite (currently .7) is the free GPL version of AutoTheme described above.
PostWrap
PostWrap is a PostNuke module (also works with eNvolution and MD-Pro) that enables virtually any web content such as html, scripts (home pages, galleries, shopping carts, PHP, Perl, ASP, etc...) to be easily incorporated into your PostNuke site. Just call the PostWrap module with any URL and it will display it in the PostNuke main content area. I call it a content wrapper (takes any existing content anywhere and wraps your PostNuke site around it. Uses an <iframe> which must be supported by the browser and JavaScript to resize the <iframe> (optional). PostWrap works well with static HTML pages, but the main benefit is the
ability to incorporate scripts and full-blown web applications into your
site.
PostJump
PostJump is a quick and dirty PostNuke module (also works with eNvolution and MD-Pro) used to redirect to a URL. Why in the hell do you need to do this in PostNuke? The main use is in setting a module as your start page and being able to pass it variables (example: PostWrap). Under PostNuke Administration, Settings, you can set your Start Page (The module, index.php is pointing to), but the modules are in a dropdown box and that doesn't allow variables to be passed to the module.
Why do you prefer Postnuke over other CMS?
PostNuke seems to be more solid and professional than comparable systems with a more professional API, and it does everything that I need for now. Community is very important as well, and the PN community is awesome!
When did you start working on your own module?
I started building the first version of PostWrap a little over one year ago. Sometime in August of 2002. When I first wanted to build a family website, I started with phpWebSite and moved to PostNuke after evaluating the major Open Source CMSs.
What is your development like? Do other people help you? How do you work together? How big is the impact of the community on your development?
The community is everything to my development! Other than the first version of PostWrap, everything that I have written has been in response to what I see in the forums. Posters need this, they need that, how can I do this, etc. As far as other people, after I first released PostWrap, Yassen Yotov (a.k.a CyberOto) offered to help and do the coding to add administration. He did a great job!
Are you asking for help with coding? Documentation?
No coding help is needed at this time, however, I would welcome anyone wishing to help with documentation or tutorials for any of the modules.
What is the biggest difficulty in your development?
Of course the age old complaint of documentation, but that doesn't slow me down much anymore as you can learn as you go. My biggest difficulty is my real job ;-) and myself. I tend to keep going and going and add this and that as it occurs to me.
What features should the Postnuke .8 core have to simplify your work?
I actually haven't given that much thought. I'm sure something will come to me next time I start off to write a new module :-) I really enjoy coding and working through issues and banging my head against the monitor. If it were too simple it wouldn't be much fun.
Which route will Postnuke/your module in your opinion go in the future?
Hmmm... I'm not quite sure how to answer that, but they will both definitely go the successful route. PostNuke is a strong platform and continues to get better. The modules that I write that are beneficial and are a compliment to or enhance the value of PostNuke will always be a priority for me, and I'll ensure that they are successful.
What is the strongest point in your module?
For AutoTheme, I feel that the strongest point is that it is a drastic improvement to theme design and provides all users with the power and simplicity to design their own beautifully unique themes.
What is the weakest point in your module?
I'm sure documentation would be the weak point.
Anything else you always wanted to say about Postnuke/your module?
Read about the modules, see demos, get support and downloads at: http://spidean.mckenzies.net
AutoTheme
AutoTheme is a revolutionary multi-platform HTML Theme System for eNvolution, PHP-Nuke, PostNuke and MD-Pro CMSs. The current theme systems requires you to be somewhat familiar with PHP and the CMS architecture. If you are not very familiar with PHP and/or the CMS inner-workings, AutoTheme removes this complexity. It is not only simple, it is powerful. Much more control and many more customization options are possible with AutoTheme than are possible with the current theme code.
AutoTheme's primary benefit is providing users the ability to create themes in HTML using their favorite editor, with no use of PHP. In addition, AutoTheme provides easy customization of every part of your site including: block display, custom templates for the Home Page, User Pages and Admin Pages and individual modules, as well as, templating of blocks and control over when and where each block is displayed. The addition of AutoBlocks provides unlimited locations for your blocks. All AutoTheme settings are easily configured from a graphical administration interface that is integrated into the supported CMSs.
AutoTheme is packaged as a module and comes in two flavors: the feature packed, fully administration driven, commercial version and the free GPL AT-Lite. The commercial version (currently AutoTheme 1.7) provides template compiling and caching, an Extras (plugins) and Extra commands architecture for easily extending AutoTheme, as well as other premium features.
AT-Lite
AT-Lite (currently .7) is the free GPL version of AutoTheme described above.
PostWrap
PostWrap is a PostNuke module (also works with eNvolution and MD-Pro) that enables virtually any web content such as html, scripts (home pages, galleries, shopping carts, PHP, Perl, ASP, etc...) to be easily incorporated into your PostNuke site. Just call the PostWrap module with any URL and it will display it in the PostNuke main content area. I call it a content wrapper (takes any existing content anywhere and wraps your PostNuke site around it. Uses an <iframe> which must be supported by the browser and JavaScript to resize the <iframe> (optional). PostWrap works well with static HTML pages, but the main benefit is the
ability to incorporate scripts and full-blown web applications into your
site.
PostJump
PostJump is a quick and dirty PostNuke module (also works with eNvolution and MD-Pro) used to redirect to a URL. Why in the hell do you need to do this in PostNuke? The main use is in setting a module as your start page and being able to pass it variables (example: PostWrap). Under PostNuke Administration, Settings, you can set your Start Page (The module, index.php is pointing to), but the modules are in a dropdown box and that doesn't allow variables to be passed to the module.
Why do you prefer Postnuke over other CMS?
PostNuke seems to be more solid and professional than comparable systems with a more professional API, and it does everything that I need for now. Community is very important as well, and the PN community is awesome!
When did you start working on your own module?
I started building the first version of PostWrap a little over one year ago. Sometime in August of 2002. When I first wanted to build a family website, I started with phpWebSite and moved to PostNuke after evaluating the major Open Source CMSs.
What is your development like? Do other people help you? How do you work together? How big is the impact of the community on your development?
The community is everything to my development! Other than the first version of PostWrap, everything that I have written has been in response to what I see in the forums. Posters need this, they need that, how can I do this, etc. As far as other people, after I first released PostWrap, Yassen Yotov (a.k.a CyberOto) offered to help and do the coding to add administration. He did a great job!
Are you asking for help with coding? Documentation?
No coding help is needed at this time, however, I would welcome anyone wishing to help with documentation or tutorials for any of the modules.
What is the biggest difficulty in your development?
Of course the age old complaint of documentation, but that doesn't slow me down much anymore as you can learn as you go. My biggest difficulty is my real job ;-) and myself. I tend to keep going and going and add this and that as it occurs to me.
What features should the Postnuke .8 core have to simplify your work?
I actually haven't given that much thought. I'm sure something will come to me next time I start off to write a new module :-) I really enjoy coding and working through issues and banging my head against the monitor. If it were too simple it wouldn't be much fun.
Which route will Postnuke/your module in your opinion go in the future?
Hmmm... I'm not quite sure how to answer that, but they will both definitely go the successful route. PostNuke is a strong platform and continues to get better. The modules that I write that are beneficial and are a compliment to or enhance the value of PostNuke will always be a priority for me, and I'll ensure that they are successful.
What is the strongest point in your module?
For AutoTheme, I feel that the strongest point is that it is a drastic improvement to theme design and provides all users with the power and simplicity to design their own beautifully unique themes.
What is the weakest point in your module?
I'm sure documentation would be the weak point.
Anything else you always wanted to say about Postnuke/your module?
Read about the modules, see demos, get support and downloads at: http://spidean.mckenzies.net
Page 38 / 277 (371 - 380 of 2763 Total)
