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/