PostNuke

Site search

Search results

Number of hits: 24

Sitemaps Autodiscovery   (News)

Comprehensiveness and freshness are key initiatives for every search engine, and with autodiscovery of sitemaps, everyone wins:

· Webmasters save time with the ability to universally submit their content to the search engines and benefit from reduced unnecessary traffic by the crawlers
· The search engines get information with regards to pages to index as well as metadata with clues about which pages are newly updated and which pages are identified as the most important
· Searchers benefit from improved search experience with better comprehensiveness and freshness

In addition, Ask.com is now supporting submission of Sitemaps via http://submissions.ask.com/ping?sitemap=SitemapUrl.

Of course, neither autodiscovery nor manual submission guarantee pages will be added to the index. The pages must meet our quality criteria for inclusion in the index. And use of these submission methods does not influence ranking.

I will be talking about today’s announcement (along with my counterparts at Google, Microsoft and Yahoo!) during the SiteMaps and Site Submission session at SES in New York later this morning. If you aren’t able to join us, more information is available at http://www.sitemaps.org and http://about.ask.com/en/docs/about/webmasters.shtml#22.

We are excited about our participation with the Sitemaps via robots.txt protocol and look forward to our collaboration with Google, Microsoft, Yahoo! and others in furthering important initiatives that make search easier for webmasters and more powerful for users.

Source: http://blog.ask.com/2007/04/sitemaps_autodi.html

Generated on May 3, 2007.

Google Summer of Code 2007: This Year We Want to be Part of the Party!   (News)

Program Schedule and Deadline Dates

March 5: Mentoring organizations can begin submitting applications to Google
March 12: Mentoring organization application deadline
March 13: Google program administrators review organization applications
March 14: List of accepted mentoring organizations published on code.google.com; student application period opens
March 23: Student application deadline
Interim Period: Mentoring organizations review and rank student
proposals; where necessary, mentoring organizations may request further
proposal detail from the student applicant
April 2: List of accepted student applications published on code.google.com
Interim Period: Students learn more about/integrate with their project communities
May 28: Students begin coding for their Google Summer of Code projects;
Google begins issuing initial student payments
Interim Period: Mentors give students a helping hand and guidance on
their projects
July 9: Students upload code to the Google Summer of Code project
repository; mentors begin mid-term evaluations
July 16: Mid-term evaluation deadline; Google begins issuing mid-term
student payments
August 20: Students upload code to the Google Summer of Code project
repository; mentors begin final evaluations; students begin final program
evaluations
August 31: Final evaluation deadline; Google begins issuing student and
mentoring organization payments


This schedule is subject to change and taken directly from Google. For the latest schedule please see Google SOC 2007 Wiki

PN Project Goals
The general goals of Google are recognized and extended with our own goals. In short, we want to improve the innovation within the project by offering students the opportunity to propose PostNuke related topics. We aim to offer students an inspiring environment to do research, access to field experts, the ability to create proof-of-concepts and the opportunity to create working functional tools that can be used with PostNuke.

There is a limited list of program goals defined below. Please keep in mind this is an initial list of subjects we would like to shoot for and the final projects are open for discussion. It's important to understand we need guidelines for project proposal evaluation otherwise we'll end up with all nice initiatives, but no choice between the individual project.

The following are a few examples of the types of projects we'd like to see during the SOC 2007.

Here are a few suggested project examples:



Version management of content. Add features to PN, either via hooks or extensions to DBUtil, to allow control of versions of content items. Additionally add workflow processes via the existing workflow module
Translation management. Currently a translation of a content item is an entirely different and un-related item. A project to introduce a method of translating content while keeping the the relationship to the original item (and hence related content e.g. comments, ratings etc.).
Loudblog rewrite based on PostNuke's API
A second project could be the implementation of a better language system + the import of the old system.
OpenID Implementation
Universally implemented content versioning such that it's possible to revert back to old versions of specific content items. DBUtil contains a feature called object-logging which basically gives you the ability to log all changes to objects as they are altered (and even revert back to old versions of an obejct), but a proper GUI with some nice administrative features would be nice.
Integration of the categories system with the nested-set algorithm. The current implementation is path-based which works and carries with it some proper semantic information, but for performance reasons integrating the nested-set algorithm would probably be a good idea.
Implementation of additional features to the category system on the GUI side. This could be advanced AJAX controls, a better user-side editing system, etc.
Integration with Lucene and other search engines ideally through a generic search-engine interface which can then be extended to other backend systems.
A proper universal web services interface for PN.
A proper test suite including a performance testing framework.
A proper data import/export system with the ability to generate multiple data formats (CSV, XML, etc.) including a proper control GUI.


Project Organization
There will be two program guides (admins) that will provide all mentors and students with help and guidance throughout the project. The structure will be flat so there won't be a lot of red tape in the process. The mentors are expected to work closely with each student to accomplish each project's goal and objectives.

For each accepted project into the SOC program there will at least one mentor and one student. Along with the one-to-one support the student will have access to the developers list so they have access to the entire team to bounce ideas off of in the process.

Overview of Mentor Selection Process
The general "criteria" for mentors are:


Mentor is familiar with the PostNuke project and API.
Mentor is expected to work well with others.
Mentor should have knowledge about the topic he/she is going to mentor.
The mentor is responsible for working directly with the student.


Note, before volunteering you should be aware there is a time commitment. We estimate it will take at the minimum 3 to 5 hours per week of your time over a 3 month period. Mentors should also expect to encounter cultural and time zone differences making this a challenging experience on many different levels especially since this will be a virtual mentor/student experience.

Expectations
Commitment to the goals/objectives of your project, your time, mutual respect, and open communication.

Remember when you were a student -- you were there to learn. This is the same thing -- students are here to learn and may not be experienced in working on a team, and will less likely have experience working with someone virtually so as a mentor you're expected to introduce the student to the protocals of this environment.

Students, remember, no question is stupid, don't expect to know everything, and if in doubt ask! Communication is key in a virtual environment and never take anything for granted especially in text based communication since things can often be mis-read or interpreted.

If you are chosen a mentor then what do you get? You get to contribute to a great project, experience working on a virtual team with an international team of great/inspiring people.

Team/Mentor/Student Communications
This is most likely the most important part of the process -- communication is key especially in a virtual environment. And communicating/sharing will be important to the success of each project. So students are expected to put together a weekly report -- it doesn't have to be anything fancy -- just an email updating your mentor about your progress and any problems you working on or having. Mentors are expected to take the lead in solving any problems that might arise with timing, language or cultural barriers. Note, the default language for the program is English so all mentors and students are expected to be able to communicate clearly and effectively in English. When disagreements or conflicts arise within a project team members are encouraged to resolve disputes amongst themselves. If they can't resolve it between themselves then you can ask a program mgr to get involved to mediate the dispute.

Project Tools & Support
You will have access to the following software tools:


The PostNuke NOC (Network Operating Center) where all project related
resources will be housed
Google Project Page (including wiki)
Mentor Application from Google
Developers Mailing List



Student Info
Google provides some time to allow the student to familiarize themselves with the project and tasks. During this time the mentor can prepare the stucture and any documents that will help the student in the goals and objectives of the project.

Some examples include:


Action/Tasks planning so the student will have a clear idea of milstones
for the project.
Provide the student with your communication expectations - i.e., how can
the student communicate with you, skype, instant messenger, email etc.
Review time committments and goals/objectives for the project.
Model good behavior -- take the lead when you see the student needs the
extra encouragement and guidance.

Generated on March 7, 2007.

PostNuke and its future language system: a translator's viewpoint   (News)

1 What this article is about, and why I'm writing it
PostNuke has developed quite a lot since it forked from PHP-Nuke; many changes have already been implemented in 0.7.6.0, and many more will be reflected in 0.8. However, compared with other parts of the core code, the language system hasn't changed much. And what has changed recently might not always have been a good idea.
Most of the development work on PostNuke is done by speakers of European languages (predominantly English and German, but also Danish, French and Spanish, to name but some). Speakers of those languages might not be aware of the differences between their mother tongue and some of the more-exotic but widely-spoken languages in the world. Since I spend quite a bit of my time applying different languages, I'd like to show a few problems and make a few suggestions that perhaps could be further discussed.
I have looked through the PostNuke language files before, but it was only when I, together with two students, attempted to translate them into Chinese that we noticed how difficult a task that can be. Parts of PostNuke 0.7.6.0 actually cannot be translated meaningfully into Chinese or Japanese anymore.
When I was working on the translation, I happened to "complain" in the pnLanguages forum on PostNuke's NOC (Network Operations Center) about a few of the problems, and was answered by David Nelson of the pnLanguages team. He suggested I should put all my "frustration" (well, it isn't that serious, but some of the problems really are…) into an article, which is what I'm doing right here and now.
2 Current problems with PostNuke's language system
There is a thread [1] on the PostNuke forums, started by ColdRolledSteel, in which he raised a number of very important points. It was that thread that actually made me start thinking about the shortcomings of the current language system, and what the solutions might be.
If you read further on in that thread, you will find comments about 0.7.6.0. It's a long discussion, but if you're interested in PostNuke localization then I recommend you to read all of it, since many serious problems are mentioned. Good-quality localization into some languages may actually become very difficult unless the language system is overhauled.
Most PostNuke enthusiasts know that PostNuke forked from PHP-Nuke. With PHP-Nuke, not only do you have to pay to get access to the latest version of a GPLed software, but also many people would probably agree that there can be significant changes from version to version.
Not all of those changes may be approved-of by many, since the line of development of PHP-Nuke is decided by just one person: Francesco Burzi. You can read many posts in the PostNuke forums about the problems the PostNuke developers have had in fixing problems caused by PHP-Nuke code leftovers.
What seems to be forgotten is that, unfortunately, one of the legacies is the way PostNuke handles languages.
Here is a summary of problems raised in the above-mentioned thread and other threads, that I encountered:
too many files;
too many phrases used multiple times;
language files are hard to handle;
separation of grammatical particles can make it impossible to provide a good translation in some languages.
Again, please read the above-mentioned thread [1].
3 Suggestions
3.1 Files and folders
3.1.1 Simple structure instead of chaos
Instead of having one language folder for each language in every module folder, why not have just one central "language" folder with just one file for each language? The file could be an XML file, containing all the strings needed by the core system. If a new module is installed, the installation procedure could copy all needed variables and strings into that file. When a module is uninstalled, the de-installation procedure would then be responsible for removing those strings from the language file (in the same way that tables are created and deleted at present).
3.1.2 Why the current language system is chaotic
Does anyone know how many variables and strings are used in the core system alone? Maybe some of the developers will know (though I seriously doubt it); but, certainly, nobody who tries to produce a language pack knows. What they will soon learn, however, is that many strings show up more than once.
If I recall correctly, there are also a few different variables for the same purpose/string. All this is definitely not very motivating for those who want to translate PostNuke into another language. Plus, the translator may well not remember the exact phrase he/she used the last time this string was encountered a few modules ago. Just as there is often more than one way to express something, there is frequently also more than one way to translate a phrase. So, if you consider consistency in translation to be important, the present language system does not help achieve that.
It would also help if the above-proposed single language file could be processed by software. I mean, the year is 2005 and even translators are using computers these days. Every step that makes administering and translating strings easier will lead to better productivity, higher-quality output and availability in more languages. A translation tool (something like pnDefineMachine) should be included in the PostNuke core distribution, and should allow translation of core and third-party modules. To give translators more flexibility in working, it would be ideal if all identified strings could be exported to a file so that they can be worked on using other software and then re-imported.
3.2 Strings and variables
3.2.1 Simple, unique, short and distinct
All strings should be revised to check whether they are really necessary. They should also be as short and as clear as possible. If one single file were used, it would be easy to eliminate duplicate strings and variables.
Any variable output from the PostNuke code (a number, a user name, etc.) for incorporation within a natural language string should be included in the language file. It should also be possible to choose where in the string the variable is positioned.
In the past, developers often just created two language "defines" and the translator was left to guess what was missing between the two. Sometimes, due to the ordering of "defines" within the language file, the translator also had to realize that two "defines" were indeed used in conjunction, because they did not follow in succession. In such cases, some burrowing through software code files was needed for verification and understanding.
This problem is slowly being addressed. The age check string from the NewUser module's global.php language file is a good example. This "define" allows for free placement of $minage within the translated string:

define('_MUSTBE','You must be '.$minage.' or over, or have parental permission to register for an account on this site.');
All strings should compose a "meaningful phrase". The best would be a complete sentence, but in some cases single words or short phrases may be OK or are unavoidable. Just please, please don't separate any prepositions or similar grammatical particles.
3.2.2 Why translating current strings can be really frustrating
Imagine you tell someone, "Here, this is what you've got to translate. Some strings will show up twice; but some occur three, four or even five times. No, I can't tell you which strings. Just translate it. Oh, and you won't be getting any clues about what some of the cryptic, enigmatic phrases mean, nor where to find them on the site." How motivated do you think that person will be?
How happy will the translator or a webmaster be when he/she encounters something like the "define" below (from the Xanthia module's admin.php language file)?
define('_XA_CONFIGINFO','Simply enter the new value in the text area and click Commit, the changes will take effect immediately. Unfortunately, the ability to create and delete general configurations has been removed, as it was never fully implemented and now never will be.');
Translating a language pack should mean translating the user interface, not the story of PostNuke's life – that's something to include in documentation, no?
In addition, it would be helpful if developers do their best to make strings clear and understandable! This one that used to be in the Downloads module's global.php (now rectified) could phase a native English speaker, let alone someone else: "Let main vote summary decimal out to n places".
The general lack of informative and explanatory comments in the core code files and language files does not make a translator's work easy.
And dealing with problems is made harder when strings occur multiple times.
I know the code is advancing with every new version of PostNuke. But, unfortunately, this is not true from a linguistic point of view. 0.7.6.0 is a step backwards, although it was probably meant to take the language system forwards.
Let's look at some examples involving a number of languages: English, German, Chinese and Japanese, but some others are mentioned as well.
Many native speakers of a language may not be very familiar with all the theory behind their mother tongue's grammar. They may have had to learn it at school, but now they just use it naturally. For localization however, it may be necessary to dive into all that theory a bit.
The English language (along with many others) uses prepositions ("on", "in", "behind"...). But some languages don't have them. Hungarian, Finnish and Japanese use postpositions instead. That's right, they come after the object, not before it. In Chinese, there are prepositions, but many phrases use constructions similar to postpositions.
Let's look at the problems that this can cause. Let's take this sentence: "The book is on the table".
"The" is a definite article; "book" is a noun; "is" is a verb; "on" is a preposition; "the" is a definite article; and "table" is a noun.
"The book is on the table" is a simple sentence which, in German, translates to "Das Buch ist auf dem Tisch." It's hard to deny that German and English are somehow related.
But the same cannot be said of Japanese. "Book" in Japanese is "hon", and "table" is "tsukue". Since a book is not a living creature, the verb used will be "aru" or, in neutral politeness, "arimasu".
But how about "on"? The correct word here is "ue", but you can't just use it that way. "Ue" means "top", "above"; so, in Japanese, you have to say "on top of". "Of" would be "no"; "on top of" becomes "no ue ni" ("inside the top of something", so to speak). Did you notice the different order? Now here's the whole sentence: "Hon wa tsukue no ue ni arimasu." ("Wa" is just a particle marking a sentence's topic.)
While "book", as subject, is still at the beginning of the sentence, it is followed immediately after by the object, "table", then the postposition, and finally the predicate. Now imagine what incorrect or incomprehensible Japanese would be displayed if prepositions and other words for a given phrase or sentence are spread within separate "defines" in the language files. If you read through the forum thread mentioned at the beginning of this article, you will also find a few examples for Finnish. If you "turn the table" and try to make an English sentence translated word-for-word from the Japanese sentence structure, you would get something like "book table on is".
This is another reason why variables that will be processed by the PHP code, and rendered in an output form to be incorporated in the displayed string, should be included in the "define" for that string in the language files.
Let's take another simple example: in English (and many other languages), we say "A of B", as in the phrase "3 of 10 users". But in Japanese, it is "B no A" (and "B de A" in Chinese). So, simplification is a good thing but needs to be done the proper way, otherwise important parts of PostNuke could be practically unusable in a few languages in which the potential user base might be enormous [2]. Do you think a Chinese or Japanese would like a portal that tells him "10 of 3 users are currently on-line"?
By the way, did you notice that there are no articles in the Japanese example? English has one definite article (effectively one gender), French has two (for the masculine and feiminine genders) and German three (for the masculine, feminine and neuter genders) , so there are big differences between languages even for such an elementary point of grammar. But then consider the treatment of number and quantity in different languages: anyone who has examined the language files will know that there are different strings for "day" and "days", since singular and plural exist in English, German and many other languages. However, this isn't true for Chinese: "day" is "tian" in Chinese, and no matter whether you're talking about one, two or a million days, it's still "tian".
3.3 What we can do
3.3.1 Where we really can simplify and standardize
We could create standard "interfaces" for both code (variables) and strings. Since, in the system discussed herein, we would already have only one file, we could establish a list of standard actions like "delete", "create", "submit", etc. This list should be extendible, so that module authors can add any "special" actions for their module (although it would be nice if those "special" actions, too, could be managed by the core development team, otherwise duplication is likely to occur once again). But when already-available actions are used, the module developer would just use the existing variables in their code, and wouldn't have to worry about defining the corresponding strings, since they would already be available in the core "library". Obviously, that implies the existence of a good developer's guide that gives module and block developers proper information about the PostNuke programming API.
3.3.2 Separate what can be separated
So far, we have been advocating the use of language "defines" that contain complete phrases and sentences, incorporating any necessary variables (or, at least, place-holders for variables) for which literal values will be supplied by PHP. As from 0.7.6.0, the developers started to separate prepositions in the core language files. I just tried to show that this may not be a good move, but let's see what we actually can separate out.
It is not a good idea to strip grammatical particles, since grammar can be very different from language to language, and those particles are precisely that: particles. What we always need in order to properly construe a meaning is a semantic unit that conveys enough useful information to allow the receiver to understand the intended sense.
Let me explain this with the above book example: Someone tells you that the book is on the table. However, since a tram was passing by, or you were just distracted by a pretty woman or you were simply asleep, you didn't clearly understand all of it; so you ask that person to tell you the same thing again.
Now, that person may think you are a foreigner and don't understand much English, so he may think "let's make it simple for that poor fellow" and just tells you, "Book". Nice. Yes, I know what a book is. But does he want me to write a book, buy you a book or did I perhaps completely misunderstand and he wants me to book him on a flight to Alaska?
He repeats, "The book." Nice. Now at least I know that he doesn't want to go to Alaska. "Table," he adds. With much imagination, I might start to guess now that there is a table with a book on it. If I had heard the complete phrase just once more, there wouldn't have been any problem.
But how about single words then? In English, there is something called the "imperative mood" for its verbs. The verb itself does not change, since there is no flection. So, at least in English, you don't see a difference between the regular form of a verb and its imperative mood. However, you can shout "Shoot!" or "Fire!" and the receiver of that order will know what to do.
Not every language will use a verb to express this. German will use a noun, "Feuer". Japanese is closer to English this time, it also uses a verb: "Ute" is the imperative form of "utsu", which actually means "to beat". So, what we can strip are units that can stand alone semantically, and actions are one such thing.
It may happen that such an action is not always a single word in every language, but to organize them in a list and to standardize them system-wide would help to create a more consistent user interface. It would be a bit like function calls in a code library, but for strings.
3.4 Error messages
3.4.1 Error codes in one list
It is common in software design to assign codes to errors and to display a message corresponding to the code. As with the actions discussed above, we could create a list of error messages shared in common by any module and block throughout PostNuke.
3.4.2 It says "Xxx". What should I do?
I think everyone has seen "a few" posts in the PostNuke forums asking what this error or that error means. With the above method, a given error would produce the same message throughout the whole system. It would probably even be possible to provide a list of possible causes for each error, so that users can solve their problems more easily. But again, who would want to maintain a list of causes, if every module comes with its own error messages, each of which is phrased differently even though it pertains to what is effectively the same error?
Obviously, because a module often provides some special functionality that does not exist in other modules, there will probably be some module-specific errors. This problem could be solved by asking every module developer to apply for a block of error codes for that module. Again, the installation procedure of that module would have to take care of copying that block of "defines" and strings into the main language file.
3.5 Expand your horizon
PostNuke is GPL software, and so are many other content management systems [3] and portals that exist today. If they want to implement really-extensive internationalization [4] of their design, then they face the same problems as PostNuke. Some of their people may have come up with solutions nobody here thought of, so why not look around and see how they solved some of the problems PostNuke has to deal with?
One example could be Drupal [5], which has found a few solutions for language-related [6] problems [7] that could prove useful.
4 Conclusion
This document is far from being complete. It only takes a glance at a few languages: more input is needed from speakers of other languages. Also, the modifications I suggested may not always be the best and there are probably also other improvements that can be made. However, if PostNuke really intends to move towards broad internationalization, then it will be necessary to revise the language system and, possibly, other parts of its design. This article is intended to contribute to a thought process about that.
Obviously, nobody knows all the "features" and "traps" of all languages. That's why the pnLanguages team needs to have members from as many different nationalities and languages as possible, so that we can assemble guidelines that will allow the correct use of any language in which we have a user base.
Localization and translation are now recognized as key issues for the PostNuke project. When it comes to language and internationalization, more liaison between the pnLanguages team and the core development team will be very important.
Relevant links
1. http://forums.postnuke.com/index.php?name=PNphpBB2&file=viewtopic&t=24602
2. http://en.wikipedia.org/wiki/China#Demographics
3. http://www.opensourcecms.com/
4. http://www.debian.org/doc/manuals/intro-i18n/index.en.html#contents
5. http://drupal.org/
6. http://drupal.org/handbook/modules/locale
7. http://drupal.org/node/24593
8. pnLanguages project on PostNuke's NOC

Generated on September 11, 2005.

Kevin Hatch, Author of PostNuke Book   (News)

Question
Vanessa Haakenson: Kevin first let me thank you for taking the time to answer my questions. Tell us about yourself and what attracted you to PostNuke. How long have you been using PostNuke? Why didyou choose PostNuke?
 
Answer
Kevin Hatch: Well for what it’s worth, I’m a professional web developer. I’ve worn a lot of hats over the years with different sometimes-fancy titles, but overall I’ve mainly been a front-end UI guy in most of the teams I’ve been with. Lately I’ve been doing more programming and database development than Photoshop graphics, but I also freelance as a designer to help balance out the creative side.

I was first introduced to PostNuke early in 2003. My workplacewas primarily Microsoft when it came to web development, and my background at the time was much more with VB/ASP and early .NET. But we were starting a change to Linux servers, and it seemed clear ASP was on the way out. It was a coworker friend of mine that originally suggested PHP as a more universal solution, and without any particular preference for ASP I was happy to give it a shot. My experience with C++, Java, and JSP allowed me to pick up PHP pretty easily, and I quickly feel in love with language.

My first PostNuke site was actually an intranet portal. I’d converted all our other sites’ ASP pages to PHP, but we started looking at different PHP content systems to make the intranet development a little easier. I tried early alternatives like PHP-Nuke and phpWebSite, but PostNuke impressed me as a more mature system that also possessed a strong community of users.


 
Question
Vanessa Haakenson: What is the easiest and/or most difficult thing you encountered building your site?
  
Answer
Kevin Hatch: Funny thing, the most difficult thing about my current site was the choice of methods for publishing the content. There were too many options. I struggled with a number of different combinations of stock and third-party modules like PageSetter. I went all out, creating complex layouts and forms for my pages, but ultimately my needs just didn’twarrant all the trouble. I came back to the basic Sections module for most of the content, and the simpler solution gave me more raw control.
The easiest thing had to be my solution for the column layout using AT-Lite. My original theme was done with Xanthia, but I later tried it in AutoTheme to see how the layout features would work for what I needed. I found AT’s AutoBlock objects to be anabsolute dream for easy block-to-page assignment, and that’s what I ended up using.

Question
Vanessa Haakenson: When did the idea of a PostNuke book happen? What's the back-story?
  
Answer
Kevin Hatch: Early on as I worked with PostNuke I knew it was a project under development. It didn’t solve all my development needs, and I quickly started hacking and extending the code to get the extra features and customization I needed. In order to reproduce those hacks later as needed for other installs or upgrades, I documented the steps I took. I quickly had a great deal of good content collected, and I decided it ought to be posted online in case anyone else wanted to make the same custom changes I had. I wrote up the hacks as walk-through articles, and added them to my website.
I did post links to the guides now and then when answering a forum post that could use them, but just having the articles online ultimately prompted the book. The publisher Pearson Ed was looking to do some books on Content Management Systems, and in searching online for PHP-Nuke and PostNuke resources the editor came across my site. They liked the style and content of the articles, and asked if I’d be interested in writing a full book along those lines. I also have a formal writing background, and said I’d be happy to do it. That was back in November 2003.
After the approval of the book proposal I'd put together, the book itself was written over the course of the next ten months. Things were going fine with it till the surprise release of version 0.75. Sweeping changes were made to the content to add in the 0.75 changes, and some of the existing sections were no longer relevant and had to be cut. In the end there was also an overall length issue, where some of the other third-party modules I wanted to cover were also dropped. There are a lot ofgreat modules out there, but there just wasn’t the room to do them all.

Question
Vanessa
Haakenson: How
is
the
book
selling?
Are
you
going
to
do
a
follow-up/update
when newer
versions
of PostNuke
are released?
  
Answer
Kevin
Hatch: I
know
that in
the first
month over
two thousand
copies
were
sold, but
I don’t
know the
overall
sales figures
yet. I
did secondary
edits earlier
this year
for the
second
printing,
so the
first runs
seems
to have
done better
than their
initial
expectations.
There was
also talk
of doing
a German
translation
of the
text, but
I’ve
not heard
back from
that department
to know
if it’s
gone through.
I've been
very swamped
with
work lately,
so I've
honestly
not been
following
it closely
the last
few
months.
Whether
there’s
a follow-up
will probably
depend
more on
the long-term
book sales.
I’m
up for
writing
it if it
works out.
I’ve
also considered
doing a
shorter
book that
picks up
where PostNuke
Content
Management
left
off. I
think it
would be
useful
to have
a step-by-step
walk through
on the
development
of an API-compliant
module.
In the
first drafts
of my book,
there had
been a
section
at the
end just
on module
development,
but all
that made
it into
the book
was the
short API
functions
appendix.
The book
was targeted
well to
reach a
large audience,
but I do
with I’d
done even
more on
the advanced
side. I
think PostNuke
is a great
core
product,
but I’ve
never built
a site
with it
that didn’t
have third-party
modules
and custom
hacks.
It’s
like how
Firefox
is a great
core product,
but having
the right
few extensions
can literally
change
the way
your
browse.
PN already
does that;
there is
of course
the NOC
and many
great
developers,
but I’d
definitely
like to
see even
more. You
shouldn’t
have
to be a
coder to
get it
to work.
PostNuke
can become
anything
you want
it
to be,
but it’d
be easier
to have
all those
options
possible
in simple
add-on
modules.

Question
Vanessa
Haakenson: You
have
a great
site,
KevinHatch.com.
Tell
us
a little
bit about
the site
and how
you customized
it. What
modules
are you
using
for the
site? What
modules
were customized
or built
from scratch?
  
Answer
Kevin
Hatch: Well
my main
site’s
running
on PostNuke
0.75. As
I said
earlier
I’d
used a
variety
of third-party
modules
during
the development,
but I’m
currently
only running
AT-Lite
for the
theme.
The pages
have two
main content
areas,
and while
I began
with both
areas in
the “body” area,
my desire
to reuse
the side
column
for navigation
elements
prompted
me to
set it
up as a
separate
block area.
I created
an AT AutoBlock
object
for
each area
I wanted
to isolate,
like "Links" or "Homepage" for
example.
The
AutoBlocks
are displayed
in the
same place
in the
theme code,
but I
control
the visibility
of those
blocks
from within
AutoTheme
on a page
by
page basis
using the
AT Custom Modules
feature.
The
site does
have some
custom
code hacks,
but for
the most
part they
have
been used
to simplify
the PostNuke
install.
I normally
don’t
need most
of
the core
PN features
for my
personal
site, so
I removed
what I
didn't
need. The
links page
is the
most obvious
example.
That is
just the
core
Web Links
module,
but I changed
the display
of the
content
and removed
all
the user
features
that were
not needed
anymore.
I’ve
considered
writing
a
new links
module
from scratch
as well,
but for
the moment
just editing
the
core’s
working
fine, and
I do have
enough
other projects
to keep
me busy.
The KevinHatch.com
site is
really
not finished.
I’ll
be adding
a PNphpBB2
forum for
the application
support
in the
next couple
months,
and I need
to
finally
set aside
a weekend
to edit
and upload
some of
my other
guides
and
tutorials.
I plan
on expanding
the old
programming
guide content
to
include
information
on UI design
and Photoshop.
The site
is also
currently
a hybrid
of PostNuke
and raw
PHP using
server-side
includes
to pull
in the
PN theme
elements.
It was
simply
faster
at the
time to
set it
up that
way,
but eventually
the site
will be
completely
PostNuke.  

Thank You
Vanessa
Haakenson: Thank
you
for
sharing
your
thoughts
with
the community
and readers.
  
Answer
Kevin
Hatch: I’d
just like
to say
thanks
again to
all the
developers
who’ve
put in
so much
time to
keep this
project
going.
The open
source
movement
for me
has really
re-energized
my love
of online
development.
I
know things
don’t
always
get released
as quickly
as users
might want,
but
the focus
on producing
a quality
product
is quite
admirable.

  
About
Kevin Hatch
Kevin
Hatch is a
professional
web developer
specializing
in user
interface
design.
He has
more than
a decade
of
experience
in Internet
development
and has
worked
in a variety
of roles,
ranging
from graphic
designer
and interface
systems
analyst
to webmaster
and network
architect.
These days
he mainly
programs
in PHP
as a webmaster
and application
developer,
and freelances
as a graphic
designer
for select
projects.
He
has a combined
degree
in Computer
Science
and English.
He's experienced
in technical
writing
and is
the author
of a book
on the
PostNuke
CMS. He
currently
lives in
eastern
Iowa with
his wife
and their
nine pets.  
Related Links: KevinHatch.com
Purchase the book: PostNuke: Content Management System  

About
Vanessa Haakenson
Vanessa
Haakenson
brings
several
years of
experience
in developing
web based
instructional
products.
She is
an Open
Source
advocate
and contributes
her free
time to
managing,
promoting,
and working
with the
PostNuke
content
management
system.
She has
used PHP
for three
years and
has conducted
workshops
on PHP
basics.
Related
Links:
Designs4Nuke.com
(http://www.designs4nuke.com)
   



This work is licensed under a Creative Commons License.

 

Generated on April 25, 2005.

Interview: Carl Slaughter   (News)

Where do you live?

Bethalto, IL USA
Where in the world is Bethalto, IL, USA

What is your real-life job?

IT Manager/Supervisor for a Credit Union

Tell me about your PostNuke "career".

PostNuke was what I started with and I liked it, I have tried others but PN is what I'm most comfortable with and frankly I do not want to learn another unless its REALLY great, and I do not see that happening ;-)

When did you start working on your own module?

Jan, 2003

Please describe to the community what your development is like?

It’s really only I and Batpuppy (Patrick Peay). I do most of the coding and Patrick does the debugging and HTML.

We never intended it to be as big a success as it is, we just wanted a good forum module for our own PN sites. And well the rest is history ;-)

I use HTML-Kit, along with tools like Power Desk Tools, with file find, and Xampp for local web testing. For release development we use TortoiseCVS, and UNIX command line tools for file compares.

What is the biggest difficulty in your development?

The difficulty only rests in your own abilities and desire to learn as much as you can about the PN core, along with keeping with the changes. Knowledge of PHP, HTML, and cross browser coding is a must as well. You have to develop skills in every area, then of course you develop your own personal abilities to bring your own ideas to the code as well, remember there is usually 100 different ways to accomplish the same thing, but only a few ways to do it right ;-)

What features should the PostNuke .8 core have to simplify your work?

Module aliasing. Lower overhead for modules (usually the module's fault) however the PN core has a good amount that is has in memory then if you have a significant module like PNphpBB then you start scraping the top of the RAM ceiling.

Which route will PostNuke/your module in your opinion go in the future?

As PNphpBB matures it will become more and more integrated into PN, we will streamline the code and do away with all unused code from the core of phpBB. Possibly fork the entire code, because currently we have kept the same basic code of the current phpBB release so we can apply phpBB specific patches and admins can easily add mods designed for phpBB. This will eventually not be an issue as more and more people are writing mods for PNphpBB directly.

What is the weakest/strongest point in your module?

PNphpBB is a module version of the popular phpBB forum it does its best to stay true to all the features and functionality of its stand alone counterpart as well as offering those who use phpBB the ability to migrate to a CMS environment. Its weak points are since it is a port of a stand alone module, it has a lot of redundant code, its own DB functions, template/HTML output code and functions that are not necessary due to the fact it is contained within PostNuke as a module (login/registration is not used).

Thank you very much for you time.

Visit Carl and the pnPHPBB forum project at http://www.pnphpbb.com

Generated on December 16, 2004.

Interview: Mark West, Core Developer   (News)

Tell me about your postnuke "career".

I was looking for something a bit different to run a website for myself and a group of friends to orngaise our social lives - going to the pub, events, photo galleries etc. This was late in 2001. I installed postnuke, php-nuke and a few other dynamic website engines/content management solutions. At the time PN was on v.70x. Although I wasn't entirely happy with PN at this stage I read much about the direction of the project and the totally modular style proposed by the API and the general nature of where PN was heading. This fitted in with views on the required architecture for a site engine like PN hence I chose to wait for the .71 release and begin my work here.

.71 was released and many of the aims of my (little) project could now start to be realised. One necesssary feature was missing from my requirements. The core polling solution didn't fufill all of my requirements so I began coding. As with any new technology it was slow going at first - the API was brand new at this stage so the amount of people able to aisist wasn't as high as it is now. But I stuck at it and by june 2002 had the first version of my advanced polls module. At this stage I began to think about releasing
the code for the community. This was going to be my first ever code release and contribution to the open source community so it took a few weeks thinking to make sure that I had the time and commitment to support the module once released.

Hindsight says it was a good decision. The code was well recieved (despite some initial early bugs) and no public site. At this time I was asked if I would be interested in joining the core team. Unfortunately events of that summer meant that I never got to accept that offer - envolution and xaraya were born with PN continuing as well. At this stage I took at step back and concentrated on my own code and a full analysis (almost function by function) of the core code.

The new phpbb based forums came up and were a signifcant improvement on the old cyboards based forums, as has been shown by the success of these over the last 15 months. I began helping people out on the forums and with my analysis of the code on going began helping answer development questions. A few hours here and there became a lot more. By late january of this year i'd
reached a point whereby I felt I had a lot the offer the project and the community as a whole as well as having the time and commitment so stepped up again and volunteered to join the core team.

Since then i've been working more hours than i'd like to count helping shape what will be .8. The amount of work involved in the step that is .8 is something that I underestimated when joining the team. Taking that many modules to API compliance and fully templating the output has an proved to be a huge task.

What is your task in within pnCore?

My primary role is that of looking after the modules development. However I help anywhere where I feel I have something to offer. The main areas this doesn't involve are theming and anything requiring anything remotely graphical. I can write entire modules but get stuck with the admin icon ;)

What is your development like?

I'd probably descibe my development style as professional (due to the requirements of my job). Having taught programming; techniques, data strcutures and algorithms to first year undergrads at Kingston I would also say that I have a very strict style of programming - heavy on layout, consistency and style. Those that have taken a look at the .8 CVS should see a level of consistency of approach across all of the code I have written. I believe that the benefits of this strict, consistent and academic approach
to coding is a stronger, more stable and bug free end product.

The modular nature of PN has meant that even in the core team there hasn't been that much need to work very closely on individual code. Generally things revolve around a lot of discussion around the approach, style and form of a problem or solution before a line of code has been written and then one person goes away and produces that bit of code.

Community has a siginificant impact - I wouldn't be here doing this and spending the time I do if it wasn't for the community. I've made many friends across the world during my time on PN. I make a specific effort to be as prominent as I can on the forums. As coders we can often loose focus while our heads are in the code but time on the forums quickly re-focuses the mind. If people can't use or don't understand the product being produced then the development effort has been wasted. Much of the work I have done
has been centered around solving specific problems that i've encountered while helping others.

What is the biggest difficulty in your development?

The biggest difficulty I find is keeping the requirements of PN light due to my experiences with corporate style computing. PN has and always will work with some basic web hosting but this inherently limits the approach that a developer can take to a solution. For example there is always much talk about integrating product x with product y. If asked this question at work I would recommend directory enabling the product or selecting an alternative that already is. Clearly the average web hosting plan doesn't come with an
LDAP compliant directory.

Which route will Postnuke in your opinion go in the future?

I don't know that's really not up to me (well directly at least). The community will shape the direction based on thier feedback and experiences with the work that myself and others produce. The forums will again play a big part here. I'll soon know if something i've written isn't working as it should :)

What is the weakest/strongest point in PostNuke?

The strongest points are the community and the foundation that this provides. The weak point is documentation but then this is the case with 99% of open source projects and I have to admit that i'm as bad here as every developer that's been interviewed thus far.

Anything else you always wanted to say about Postnuke?

Aside from the name which i've always thought was kinda daft the only thing I can think of for the community to keep the suggestions and comments coming in and if anyone is thinking about wanting to help the team then I can always think of plenty of tasks assistence would be welcome on.

Thank you very much for you time.

No problem - happy to be able to answer a few question. I'll be off to the forums again....... Before I go though - if anyone

Generated on October 23, 2003.

pnSupport Site News: Where do I get help?   (News)

direct all your support questions to the pnForums, you will get an answer and you will provide a resource to future users who may encounter the same problem.

Thank you for your help!

Sincerely,

AlanA
pnCorps Staf

Generated on November 6, 2002.

Announcing pnDevelopers v 1.0   (News)

pnDev Site Features
This site is built around Postnuke and provides automatic logins and benefits from amazing packages like phpCollab, phpBugtracker, phpBB2, viewCVS, cvsnotices, and the Embedded PN and data bridge which makes it possible to share user data, permissions and many other functions.

We hope you like it and will become a part of it!

All this integrations and client applications are built around the Embedded PN v 0.2 technology, which allows us to share data and security among applications flawlessly under PN.


How does it work?
Well we have used a unified login system for all applications, this means you log in once and you automatically are granted access to all available user resources. So all you need to do is register and you will be able to use most services *as is*. It's just that simple one registration enables all services for you.

Later on you can request to be added to the developers group, while doing so you can also request CVS write access to the repository, these permissions are granted on a case by case basis, since they show a great degree of commitment and require you to take responsibility.

This assumes previous knowledge and experience with using CVS with write permission, with coding for Postnuke, and to follow coding guidelines and standards.

If you wish to become a part of the developers group, we would appreciate a brief summary of your knowledge and experience with PHP, mySQL, CVS and Postnuke of course.

A brief description of your goals and areas of participation in the core development, which appeal to you and why? This doens't have to be anything elaborate, just a basic outline of your skill sets. Having this information will help us set up your account with a smaller task force team.

Postnuke development is to branch into smaller task force teams, each being responsible for a a smaller part of the core, like a module, blocks, API, database abstractions layer etc.

Each team will then set goals and time lines, while maintaining close communication with other relevant task force teams in order to coordinate efforts and dependencies with one another.

The bugtracker is to serve as a way to debug, clean and correct code, and serve as the knowledge base, as it grows, to help new members find answers to common questions.

pnCollab, will allow management of each task force team and monitor its progress over time. As well as provide a good way to review the whole, but each smaller project will have unique members that will be in full command of their part of the project.

The forums have been greatly enhanced to include advanced tools that further promote collaboration and sharing (like file attachments, automatic thumbnail generation, calendar for events, mail subscription to any or all forums and more). Here is the place for debates, brainstorming and the second part of the knowledge and project log system.

The view CVS (concurrent versioning system) tool allows one to browse and interact with the repository in a flexible and useful way, annotations and all CVS operations are constantly being logged into mySQL, as well as automatically mailing it to the CVS-notices mailing list to which you can subscribe or peruse by using the CVS notices area.


There are of course a number of other useful tools like the forums/portal bookmarks which allows you to select content randomly and group it for later use, there are many easy ways to get updated information for your site too, the portal has enhanced backend RSS news feeds as well as the forums and the CVS portion of the site.


So you can see we have a lot of tools here and we are still working on enhancing the users details area to include pertinent details regarding each developer. And of course any additional tools or ideas will be implemented as we move forward, strong>this site is intended as a strong foundation / framework from which to build into the future.


Finally, we are also integrating new admin tools in order to streamline CVS access privileges to the repository. So in general this is the global overview of this site and its intended goals and methods.


The site can be found here http://developers.postnuke.com


We encourage any interested parties to register and send a private message to either MagicX, or Neo in order to sort out additional details. Also the forums need new categories that will host the different ongoing debates for the project and from there, we will define the projects development goals in the short, medium and long range.


Additionally the smaller task force teams will be created from all those who volunteer and new coordinators created for each that will in turn collaborate with their counterparts in order to keep things moving at a nice pace, in a concerted effort.


The summaries of all progress will be made public periodically so the community as a whole can be aware of what is going on at all times in a transparent and open fashion. This in the purest spirit of Open Source projects.


This is the dawn of a new era of unprecedented collaboration and progress, this is the time we all have been waiting for, we ask all of you interested to step in, and become a part of this project we all love so much, and help it grow and become what it deserves, and was always intended to be, no more, disputes, no more gossip, no politics, lets just work, let our actions speak louder, and make this the best CMS out there.

I once saw a movie that had as the main character the great actor "Kevin Costner", I believe in it he constantly heard a voice, that told him "Build it and they will come...." well its built come on in ;)


Thanks

Enjoy!

The Postnuke Development Team

Generated on September 24, 2002.

News stories: controlling
tags.   (News)

This simple hack to the news stories module will allow stories to be posted as text or HTML. It effectively lets you disable the
tags that add-story adds to news stories.

The zip file can be downloaded from here.

Instructions
Unzip the archive file, replacing the following files in your PN.72 installation:

- modules/ns-addstory/admin.php
- modules/ns-addstory/addstory_functions.php
- modules/ns-addstory/lang/eng/global.php

With this hack in place you will get extra options in the add/modify-story screens.

Note: this only works with the PN.72 pre-beta release. I hope to have it committed to CVS at some point. If you encounter any problems with this hack, let me know at jason.judge@academe.co.uk.

I'm looking for feedback on this change and am hoping it can be included in PN.72 series.

Generated on August 4, 2002.

PN.72: Banish pesky tags from stories.   (News)

Instructions
Unzip the archive file, replacing the following files in your PN.72 installation:

- modules/ns-addstory/admin.php
- modules/ns-addstory/addstory_functions.php
- modules/ns-addstory/lang/eng/global.php

Note: this only works with the PN.72 pre-beta release. I hope to have it committed to CVS at some point. If you encounter any problems with this hack, let me know at jason.judge@academe.co.uk.

Generated on August 3, 2002.

Page 1 / 3 (1 - 10 of 24 Total)