PostNuke

Site search

Search results

Number of hits: 10

DIY: Including Video in Your PN Site   (News)

complicated things there are. Netscape introduced the embed-tag with theit Navigator 2.0 but it never became part of the html standard.

Moreover a patent exists that forced Microsoft to implement embed even more complicatedly.. But there is an existing JavaScript-solution that functions as a nice work-around.

There are several reasons that make Flash Video the best choice for the video encoding: The quality is good enough for most purposes and the flash plugin is the most common. Every other method is limited to an operating system (wmv -> Windows) or to rarer plugins (Real, Quicktime aso.) Jeroen Wijering wrote a nice article about Flash Video.

I used Riva FLV Encoder 2 for the encoding. It is free and supports the codecs I needed.

Jeroen Wijering not only wrote an article about FLV he also wrote the Flash Video Player which can be used to embed the videos into your site.

I use Pagesetter to store the metadata. My publication type has three fields: title, description and filename. Filename is im my case also a string because the videos are too big to upload them via HTML forms. We upload them into a predefined directory and only enter the filename into the form field.

The flashplayer is stored inside the themes folder:
themes/myTheme/flash/flash_flv_player

And you have to add a javascript call to the site's header:
[code][/code]

The -list.html-template of the publication type looks something like this:
[code]

Generated on April 3, 2007.

Development Update, February 2007-02   (News)

release, and some is part of the current nightly build from SVN. The items that are part of the MS3 package are indicated with a (*).

Installer and upgrade path
The installer for .8 now also checks for a web-user writable pnTemp directory. Before, only it's subdirectories had to be writable. However, more and more modules need a (temporary) writable directory of their own (for example cache directories for image creation or rss feeds). With a writable pnTemp, these modules are now easily allowed to create that directory themselves if it does not exist. (*)
The upgrade path from the historic .7 family has been updated: Some code has been added to migrate blocks placements into the new block_placements table. (*)
Furthermore, old style (legacy) blocks can now be stored in the /config/blocks directory. The specific files do need to be copied manually from the old /includes/blocks directory to it's new location. (*)

Core (API) and environment variables
In the core pnAPI, get_magic_quotes_runtime() was called lots of times for different purposes. With an internal caching method, the result is stored in the global PNRuntime array. Big advantage is that the site's speed has been significantly improved. (*)
Robert has added an enhancement to allow the pnSessionGet/Set/DelVar functions to accept an (optional) path argument (arguments 'autocreate' and 'overwriteExistingVar'). This will allow for easy setting of complex array structures. The change only adds extra arguments to the existing functions and are backwards compatible. At this moment, no direct usage has been committed yet.

PostNuke Object library
At this stage of development, a lot of changes are (and have been) made to the object library. Most of them are 'simple' bug fixes, but some changes are worth mentioning here (additional functionality or changed methods).
In the DBUtil class, there now exists a new method to increment a field with the function incrementObjectFieldByID. This can be used by module authors for updating read counts of content items for example. (*)
Additionally, the function selectScalar has been added (which takes a SQL quesry as argument). This is mostly useful for places where you want to do a "select count(*)" or similar scalar selection.
The utf8 conversion functions (convertFromUTF8 and convertToUTF8) have moved from AjaxUtil to DataUtil when solving a bug to keep the users input in Ajax driven fields as they are intended.
While solving a Google AdSense script bug, where the script tags were automatically cleaned by the safeHTL output filter, a new feature has been added to FormUtil: Before cleaning posted input on an already installed site, the FormUtil now checks if the current user has overall admin permissions. This allows site admins to input potentially harmful tags (javascript for example), but it's their site after all!
Jörn has improved CSS style handling in pnForm plugins, as he has changed some pnForm classes to be derived from pnFormStyledPlugin, which in itself is derived from the original pnFormPlugin.
Because it's better to read the languages directory first for available languages and compare that result against the full list of languages in stead of the other way around, the LanguageUtil has a new function getInstalledLanguages. This now significantly reduces the number of directory checks.
To ensure that most commonly used plugins are found as early as possible, the order in the pnRender class, where the system is searching for plugins, has been modified. The current correct order for the 0.8 distribution is:

system/pnRender/plugins
system/Theme/plugins
config/plugins
current theme-directory/templates/modules/$module/plugins
current theme-directory/plugins
current module-directory/pntemplates/plugins

Furthermore, two new variables can be added to the rendered output page using the PageUtil class. First is 'description', which is default set to the current site slogan. Second is 'footer', with the ability to add custom content just prior to the closing body tag. The latter function is applied as an outputfilter.
Finally, an additional parameter 'display' is added to the pager plugin, which can be set to either 'page' or 'offset'. This is (why am I explaning, isn't this rather self-explanatory?) to allow paging by pages, rather than offsets. It also mirrors the 'show' parameter that exists in many templates (based on the example module) but was never actually implemented.
Last but not least, the Theme class has now added support for a filters section in a page configuration file. This allows for loading of, in the first instance, custom output filters. Note there is no user interface to the functionality the moment.And, why not, the Atom theme has been updated to Atom 1.0

Module modifications
The following modules have been updated for improved .8 compatibility, or just to make administering those modules easier.
The User module now has the long awaited alpha pager for browsing users. (*)
All occurences of the block rendering APIs (read by the Blocks module) have changed from the old style call "return themesideblock" to "return pnBlockThemeBlock". (*)
To the Settings module there has been added a configurable separator for permalinks (*)Furthermore, a switch to globally disable JS Quicktags (which adds a set of buttons for common html tags to enabled textareas) is now part of the Settings module. (*)
Both the Ratings and the Multisites module are modified to meet the new standards of coding and templating. Work still needs to be done to both modules, so testing functionality for these modules may not be that worthwhile as yet. (*)
The Theme module takes over from the Xanthia module in an upgrade. This doesn't mean that it is not Xanthia anymore: it still is actually the Xanthia 3.0 engine (*).
To the Recommend_Us module a display hook has been added. This will add a list of social bookmark links, like the Diggers plugin also does.

Language files overhaul
The language defines in some modules have been reviewed and adjusted to the naming conventions of .8 (see also Dev Update 2006-06). This means that module-specific language defines start with a module-name specific prefix. Additionally, some new general language strings (using the pnML function) have been added to the core language file. The major effect this will have is to subtantially reduce the number of strings that need translating.These changes are applied to the following system modules: Admin, Admin_Messages, AuthPN, Blocks, Mailer, legal, Settings and SysInfo. ValueAddons modules will follow later.

PostgreSQL DBMS testers wanted
The .8 DBUtil class, as mentioned many times before, makes it possible to run PostNuke on different DBMS platforms, like PostgreSQL,

Generated on February 20, 2007.

Development Update, September 2006-02   (News)

Design Team
In the past we've discussed the option of having an official 'design team' to work on the core templates and themes. The aim for this team is to enhance usability and aesthetics of the core PostNuke distribution, add further template improvements, write a dedicated admin theme and maybe write an official styleguide for module developers. This idea has been brought up again and the search for members for this team has been started.
Changing the Module names
A mechanism has been added to allow module developers to rename their modules while retaining the existing module id. Before, the modules db had to be handled manually and documentation covering how to rename the module had to be written. Or users had to backup data and then remove the old module and add the new one. In short: "Who wants to do this?"
So you can now add your old modulename to an oldnames-array in pnversion.php and the modules module will detect the relationship between the two modulenames, updating the database accordingly.
The rationale for looking at this now is that there exist a few modules that have misleading or confusing names. Also, the development team would like to encourage module developers to drop the pn prefix for modules. An exception for this are the modules that also exist as a stand alones, like pnWikka, pnMantis, PNphpBB2, ...
For renaming of tables, the a module author can raise the version number and write the appropriate "copy code" for his tables.
Icon sets
The aim of the pnicon plugin is to have multiple icon sets in the future without worrying about image filenames like when using the pnimg plugin. The pnicon loads the icon set config.php file, and selects the filename of the image by a 'type' parameter passed to the plugin.
Comment Spam
In the last couple of weeks, many posts have appeared on the community forums about spammers that login and post comments with their credentials obtained from the user registration mail. To prevent this, a check has been added for the useragent during registration at the User and NewUser module, which is an additional protection against spam-accounts by PERL agents like lwp and libwww. Of course, this is not a guarantee that these kind of registrations do not happen ever again, but it should at least help to prevent it.
Also (but still in test phase), optionally a question can be added to the registration process (comparable with the anti-spam option in formicula 1.0). This Q/A combination is freely configurable in the user administration.
For more information, discussion and Proof of Concept, please visit the forum.
System updates
The Profile module has now enhanced client-side (using prototype-driven validate.js) and server-side (to show messages on the same page) input validation.
The Extended Menu Block supports sorting via drag&drop (using scritaculous) and a utility link is also present in the menu to automatically add the current URL to the extended menu block. This is of course restricted to administrators only. It is also planned to make tree menus using this block.
The categorisation within the Admin area has been changed to a more logical sense. There now exist 7 categories:

'System': Admin Panel, Mailer, Modules, Settings
'Layout': Blocks, Themes, pnRender
'Users': Permissions, Groups, Users, Profile
'Content': Admin_Messages, Categories, legal, Search, blank
'3rd-party': Empty categorie for newly installed modules
'Security': SecurityCenter, SysInfo
'Hooks': Censor

ValueAddons updates
The Sections module has been renamed to the (more suitable and logical) Pages module. Intuitively, this module does what one might guess: serve static information on different pages.
The Top-List module is currently hardcoded to working with just the core modules, and planned is to move it to some sort of plugin architecture (using special plugin API files and call specific functions in them). This is in progress.
Miscellanious updates
We now have a html installation guide with a CSS based on http://community.postnuke.com, and an html upgrade guide is separated from it in its own document. Second, the legacy file config-old.php is removed from the repository. Furthermore, there were some problems when adding the pnTemp directory in config.php as an absolute path. This has been fixed in the current SubVersion repository, there shouldn't be any problems now. Finally, the sessions table is

Generated on September 4, 2006.

Moving on: Better PostNuke ShortURLs   (News)

PostNuke sites well, while making the URLs hard to post to people in email or in forums. For instance, a news link looks like this:
/index.php?name=News&file=article&sid=123&mode=thread&order=0&thold=0

For some time now, PostNuke users have cried out for better Search-Engine Friendly URLs, and for the past few years, the only thing available has been a theme hack first detailed by Karateka (possibly E. Soysal before that, the links in the article are dead) way back in 2002, since worked on by ColdRolledSteel (Craig Saunders), and consequently me.
The advent of the ShortURL hack has seen sites hosted on Apache servers with the URL Rewriting module (mod_rewrite) enabled get URLs like
/Article123.html

for the above link, where certain assumptions have been made about the default settings for mode, thread and threshhold. A big improvement, but not very descriptive, and it comes at the cost of heavy post-processing of the site's content for links. Also, Search Engines use link keyword relevance in their rankings, and Article123 doesn't say much about the link, except that it's an article with the id 123.
As Karateka pointed out at the time in his article, a problem in implementing friendlier URLs with virtual directories is that all paths in PostNuke are relative, ie relative to the site root folder where index.php is located, and fixing it then would have required extensive changes in the core. That is, a URL like /Example/view.html would result in the browser looking for all links relative to its present location, ie in the nonexistant subfolder called Example, and subsequently it would fail to find the linked stylesheets, images etc, and all links from the page would similarly fail.

Unfortunately this situation has not changed in the intervening years, but as PostNuke modules are becoming API-compliant, they reference the same system function to build their URLs, so fixing this function and other associated functions to use root-relative links(1) will fix all compliant module URLs. But that leaves all other links, like images, Javascript, and stylesheets. The move to templating with Xanthia (for themes) and pnRender (for modules) is also making it easier, since Xanthia templates use a Xanthia variable to reference the theme's image directory path. So fixing Xanthia and pnRender will fix most paths in Xanthia themes. The exception are stylesheet and Javascript link paths and any links in the theme header, for which new path variables need to be introduced, so some updating of Xanthia themes is required. This makes the transition period to PN 0.8 an ideal time to introduced these changes, since few Xanthia themes have been released so far, and core modules are only just being converted to pnRender.
I stopped work on ShortURLs some time ago (before pn0.75) on the advice that a core module was being developed; however I have seen no evidence of this to date, and there is no indication in the upcoming PN 0.76 or CVS that there is anything coming. I got curious a month or so ago, and was somewhat dismayed at what I found.

Since then no progress seems to have been made on PostNuke ShortURLs. In fact, the current Xanthia filter hack has regressed, becoming bloated with complex and wholly unnecessary Regular Expression rules, many badly written with duplication and a number of bugs, especially in the accompanying htaccess file, going from the 15 rules proposed by Karateka to a massive 89. So, I set out to try and fix it, but ended up revisiting the idea of a core implementation using virtual directories to more logically structure the URLs in a way that is not only Search-Engine Friendly, but more User-Friendly.

Along the way, I've also been sidetracked and made a direly-needed new themable tab system for the Administration area based on AlistApart.com's Sliding Doors technique and consequently overhauled most of the Admin templates and a few User templates too, partly out of necessity due to the new Adminpanel, partly because they badly needed it. Those of you who have tried the pn0.76 Release Candidates would know that the templated output in them leaves something to be desired, drab and somewhat unprofessional-looking due to all the styling and CSS-classes having been ripped out, leaving a basic grey and white look with overly large headings and no theme tables for backgrounds. Hardly what you would call of Release Candidate quality. So pnRender and its plugins have been fixed to allow the use of Xanthia-like theme-colour tags as well as a tag for root-relative paths needed for ShortURLs, and the opentable functions have been fixed so that proper themed borders can be used. In fact most of the changes are in fixed templates, plugins, and module files.

My proposed implementation still retain the Xanthia filter for backwards compatibility with older themes, modules and blocks, but has been wholly rewritten and pared down to 24 rules, including a rule to fix all links to be root-relative. As PostNuke is in transition to be fully pnAPI-compliant by PostNuke 0.8, the remaining ones can gradually be removed altogether as themes, modules and blocks are updated. There's also a version for AutoTheme.

This particular scheme is experimental and may be tweaked or improved upon. It seeks to reduce the reliance on the Regular Expression(2) post-processing for links and introduce more user-friendly URLs that have more relevance for people and search engines alike by using virtual directories to visually distinguish sections of the site by module and function, such as
/Example/View.html

and for the News articles introduce Category, Topic, and Title information in the link:
/Category/Topic/ArticleXXX-title-of-story.html

For instance for a news story in the category Computers and the topic Postnuke called "PostNuke Shorturls", you'd have the URL
/Computers/Postnuke/Article123-PostNuke-Shorturls.html

This is a clear, concise and informative link that tells the user and search engine alike something about the link before going there, while retaining backwards compatibility with links of the old ShortURL scheme. It more closely emulates the way we think and organise information, using the folder analogy where we have a clearly-labelled Computer category folder, under which we have the various sub-categories - Topics - with various articles. In this case, we're using a virtual file anchored by the word "Article", clearly identifying it as such, followed by the article number and title. There is backwards compatibility, so that older links for Article123.html will still work.

In this instance I've excluded the News keyword altogether for brevity in favour of the Category and Topic keywords which insinuate News anyway, though there is nothing against being consistent with all the other ShortURLs and having the Module appear first, as in
/News/Computers/Postnuke/Article123:-PostNuke-Shorturls.html

This is for the special case of the core News module though, a more generic method is needed overall for URLs with various unknown parameters passed in the query string. This implementation uses the scheme:
/Module/Function-Param1:Value1-Param2:Value2... -ParamN:ValueN.(p)htm(l)
where the Query string parameters are tagged onto the virtual filename grouped by colons and separated by hyphens, the idea being to use commonly-used characters we might normally use in a list to make it look as natural and readable as possible. It may be a less-commonly used character than the hyphen is needed, like the tilde ~ character, since some parameter values may use a hyphen, in particular usernames. This is not a problem if passed as the last parameter, where it may contain any character. So if the module developer kept this in mind, it might not be an issue. I'm not aware of it being one so far. The PostCalender ShortURL plugin deliberately places uname, if present, last.

The extension is not necessary, but used for convenience. The 3 types used are either one of html, htm, or phtml, the latter useful to distinguish when you want to link to real HTML files on the site. The extensions as well as the option to use ShortURLs or not is set in the Settings panel, though I've only offered the option of html and phtml, since frankly the MS DOS-holdover extension htm annoys me.
Older URLs are marked with a + before the Function name, as in
/PNphpBB2/+profile-mode:editprofile.html

so that the server can translate it correctly. If the directory doesn't actually exist, entering
/Example/

will redirect to the Example module main page (Apache only)
/Example/main.phtml

which in return gets rewritten invisibly to
/index.php?module=Example&func=main

Otherwise, if it does exist, the index file of the relevant directory will be opened.
Similarly, with
/HTML/filename.html

if the file exists, it will be opened, else PN will look for
/index.php?module=HTML&func=filename

It is still possible to tag on query strings like
/ModName/main.phtml?theme=seabreeze

or
/ModName/main-theme:seabreeze.phtml

will both be translated to
/index.php?module=ModName&func=main&theme=seabreeze

There are any number of possible ShortURL systems, the simplest being to simply chop the URL into virtual directories, like /News/123/ from the above News example as some do. Xaraya uses a variant of this for news, though it doesn't use mod_rewrite, so appears like
/index.php/news/123

Again, this is concise, but contains few meaningful keywords other than the module name News. You can combine the two methods for News and have
/News/Category/Topic/123/title-of-article

which works very well, but loses some of the elegance of the above philosophy, since the latter part breaks up the virtual file into 3 with no anchor words, which is not how we organise information.
For generic URLs, there are a number of methods; for instance Mambo, another CMS, use generic ShortURLs like
/component/option,com_newsfeeds/catid,5/Itemid,7/

for a News URL like
/index.php?option=com_newsfeeds&catid=5&Itemid=7

where the querystring values are grouped by commas and separated by forward slashes (virtual directories). It is a ShortURL, though in this case not shorter, and doesn't have any useful keywords, other than "newsfeed", and is not very human-readable. For a generic URL, this is somewhat unavoidable, but can be better than that.
This implementation also contain a way to customise ShortURLs on a per-module basis through a file called shorturls.php placed in the module folder (see the Example module), such as the News URLs, or 3rd party modules like PostCalendar, which instead of the full URL like
/index.php?module=PostCalendar&func=view&tplview=&viewtype=day&Date=20050405&pc_username=&pc_category=&pc_topic=&print=

with the above generic ShortURLs would be rendered as
/PostCalendar/view-viewtype:day-Date:20050405.html

but with customised URLs become
/Calendar/05-04-2005/day.html


The beauty is, though, once we've created the groundwork in the core of PostNuke, any implementation will be fairly easy.

1) Root-relative links: Links relative to the server site root (eg /nuke/filename.html), which stays static, as opposed to relative to the present file (eg filename.html).
2) Regular Expression (RegEx): A complex pattern-matching language that can look a bit like a mathematical formula, used in the Xanthia ShortURL filter at /modules/Xanthia/plugins/outputfilter.shorturls.php.


----------------------------------------------------------------
If this were Mambo, I'd charge you 80 Euros for all this (the price for SEF Advance), but because you're all such nice people (except that guy up the back, you know who you are :) ), I'll let you have it for free.

A PDF of the ReadMe included in the package, but with additional screenshots, is found here (570kb).

I've also written a more technical ReadMe on installing ShortURLs, included in the package under the docs folder, and also found here.

here's a test of the tab system using the Aqua theme. It also comes with an XP-styled theme and the default-CSS-based one. I hope you like it, because it took a lot of work to perfect.

OK, screenshots: Well, no point having screenshots of URLs, so here's some of the tab system and modified SeaBreeze and PostNukeBlue themes' Admin templates instead:

1. The main adminpanel in PostNukeBlue with the Aqua-themed tabs, hovering over the Settings panel.
2. Same as above, but with the Theme Override set under Modify Config and with a tabs.css stylesheets in the theme's style folder. The rounded corners are only visible in Mozilla/FireFox.
3. The Luna tab theme in SeaBreeze, hovering over the 3rd Party tab.
4. The Xanthia Admin tabs using Aqua tabs in PostNukeBlue, hovering on Theme Settings.


And finally, the downloads:
I started out fixing PN0.75, so there are 2 downloads: One for PN0.75, and one for PN0.76rc4. I'll update it once the PN0.76 final is released.
Please backup your site before installing these patches, since a lot of system files are replaced. The PostNuke 0.76rc4 ShortURL package is rather large, consisting of some 400 files in a 1Mb zip file. The PN0.75 package has some 170 files and is around 800kb. Most of the changes are drop-in changes that doesn't necessitate updating of modules, but there are some exceptions in the PN0.76 package, in particular the Settings and Polls modules, where you need to first go to the Module list, regenerate, and update. Specific patches for popular 3rd party templated modules like AutoTheme and PNphpBB2 are included, but only a limited number of 3rd party modules have been tested with this package. No changes are made to the database, but it is still a good idea to back that up as well. You have been warned.

PostNuke 0.75 ShortURL package (833kb)
PostNuke 0.76rc4 ShortURL package (1Mb)

Two of the updated core themes:
PostNukeBlue (249kb)
SeaBreeze (120kb)


Feel free to discuss this proposal in the forums.

Enjoy!


Martin Andersen 8/7/200

Generated on July 9, 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: Øivind Skau, PagEd   (News)

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

Generated on October 16, 2003.

Search engine friendly URLs revisited.   (News)

Why common methods to enable search engine friendly dynamic websites do not apply for PostNuke
Search engine friendly URLs for dynamic websites are always a hot subject.
There are several nice solutions: PHPBuilder dealed with this subject and the force type solution several times [1 2]. However, PostNuke can't benefit from Tim's solution, because all paths in PostNuke are relative. So, if you have an URL such as http://www.postnuke.com/article/1/, postnuke will try to find the topic image in http://www.postnuke.com/article/images/topics/some_fancy_topic.gif, but the picture is located in http://www.postnuke.com/images/topics/some_fancy_topic.gif
So, without a core rewrite that would change all relative to absolute paths, this method does not apply for us.

Prerequisites for my proposed method
E. Soysal has covered this subject twice for Nuke-Sites [1 2].
A lot has changed in PostNuke and the way URLs are being built since then, so it might be a good idea to revisit this subject.
To successfully use this method, you need apache as a webserver and mod_rewrite enabled. Now, if you don't know if you have this on your host, please ask your system administrator. If not, it might be an idea to collect hosts that have mod_rewrite enabled in the comments to this article. Don't forget: you can always ask and talk to your server admins and maybe even convince them. :)

What we want to achieve
Did you ever try to tell your friends about a Web_Links directory on a postnuke site? Chances are high that you gave up on it, because the URL was too long.
Did you look up your site on Google? How much of your site was really indexed by Google? It's very likely that if you are using 0.7+, only the mainpage was indexed by Google.
So, our goal is to make your site more user friendly and search engine friendly at the same time, without touching the PostNuke core or slowing down your system's performance too much.
So, we want to have an URL like http://www.postnuke.com/Web_Links.html rather than http://www.postnuke.com/modules.php?op=modload&name=Web_Links&file=index.

Time to dive into the code
You may wonder how to achieve our goal without touching the core. Well, themes are not considered as core files, so themes/yourtheme/theme.php is our candidate for a hack. :)
There are 4 steps that you need to take:

1) We will first start to buffer your output. We do this by adding the following line in your function themeheader:
ob_start();

2) Now, go to the end of your themefooter function and add those lines:

$contents = ob_get_contents(); // store buffer in $contents
ob_end_clean(); // delete output buffer and stop buffering
echo replace_for_mod_rewrite($contents); //display modified buffer to screen

3) replace_for_mod_rewrite() needs to be explained as well:
Add the following function above your first function in your theme:

function replace_for_mod_rewrite(&$s)
{
$in = array("'(?
In $in, we have an array of patterns that we want to replace. In $out, we have the array of new patterns.

So, I'll try to explain what some of these patterns do, so that you can start from there to do your own changes or extensions to this.

"'(?
- sid=([0-9]*) indicates that you may have any digit from 0 to 9 after sid=, the occurrence may be 0 to unlimited times.
- mode=([a-zA-Z]*) indicates that you may have any alphabetical character after mode=, from 0 to unlimited times.

So, we have managed to convert the links on the fly, what is missing now is the appropriate apache directives.

4) Basically all converted URL-calls need to be reverted by apache with mod_rewrite. You will only need a .htaccess file for this. For your convenience, just copy and paste the code below into a .htaccess and upload it to the webroot of your PostNuke installation.


RewriteEngine On

#Articles
RewriteRule ^article([1-9][0-9]*).* modules.php?op=modload&name=News&file=article&sid=$1

#Topics
RewriteRule ^Topic([1-9][0-9]*)-all.* modules.php?op=modload&name=News&file=index&catid=&topic=$1&allstories=1
RewriteRule ^Topic([1-9][0-9]*).* modules.php?op=modload&name=News&file=index&catid=&topic=$1

#FAQ
RewriteRule ^FAQ([1-9][0-9]*)-([0-9]*).* modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=$1

#Sections
RewriteRule ^Sections([1-9][0-9]*).* modules.php?op=modload&name=Sections&file=index&req=listarticles&secid=$1
RewriteRule ^Sections-article([1-9][0-9]*)-page([1-9][0-9]*).* modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=$1&page=$2
RewriteRule ^Sections-print-article([1-9][0-9]*).* modules.php?op=modload&name=Sections&file=index&req=printpage&artid=$1

#NS-type modules
RewriteRule ^NS-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).* modules.php?op=modload&name=NS-$1&file=index&$2=$3&$4=$5
RewriteRule ^NS-Polls-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).html modules.php?op=modload&name=NS-Polls&file=index&req=$1&pollID=$2
RewriteRule ^NS-Polls-([a-zA-Z0-9_]*).html modules.php?op=modload&name=NS-Polls&file=index&pollID=$1
RewriteRule ^NS-([a-zA-Z0-9_]*).html modules.php?op=modload&name=NS-$1&file=index

#General Stuff
RewriteRule ^([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).* modules.php?op=modload&name=$1&file=index&$2=$3&$4=$5&$6=$7&$8=$9
RewriteRule ^([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).* modules.php?op=modload&name=$1&file=index&$2=$3&$4=$5&$6=$7
RewriteRule ^([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).* modules.php?op=modload&name=$1&file=index&$2=$3&$4=$5
RewriteRule ^([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).* modules.php?op=modload&name=$1&file=index&$2=$3
RewriteRule ^([a-zA-Z0-9_]*)-([a-zA-Z0-9_]*).html modules.php?op=modload&name=$1&file=$2
RewriteRule ^([a-zA-Z0-9_]*).html modules.php?op=modload&name=$1&file=index


Finally, you can see my proposed solution in action on the following (test) sites so far:
http://www.mountainwatersspa.com/
http://www.lobosoft.com/

I'm not claiming that my code is the best solution, maybe even not for this method, but it works.
So, there you have an example and some basic instructions, now go and conquer Google et al and don't forget to mention other

Generated on April 4, 2002.

How I updated my themes from .64 to .70 rogue.   (News)

The theme explanation mentions things like:
$info = genArticleInfo($row)
$results = getArticles(where, order, limit)
$links = genArticleLinks($info)
$preformat = genArticlePreformat($info, $links)

Screw that. I didn't need any of it. Try to follow these instructions, I appologize if they're kind of rambling... :) All themes are not made the same, so I can't into specifics, but if you figured out the old theme system, this is a piece of cake once you sit and work with it a bit.

First step.
BACK UP YOUR THEME! Once you update your functions they will not completely work until you finish updating each variable.

Next
Look through your theme. Anywhere you have a variable - such as $informant, $title, or $comments, more than likly you will replace it with either a call to $info[informant], $preformat[title], or $links[comment].

Now, a brief explanation of the differences between them:
Items in $info contain JUST test. No formating.
ex: $info[topicimage] is just "announcements.gif" (no quotes)
Items in $links contain just the URL. Again, no formating.
Items in $preformat are formatted and already contain links and everything. Very handy.
$preformat[title] already figured out story id, and title name and formats it so that it's already clickable

Here we go...
Look at function themearticle()
Remove everything in the parenthesis of themearticle() and replace it with "$links, $info, $preformat." It should now look like: function themearticle($links, $info, $preformat)

Ok, your theme will be completely broken for now. I hope you saved. I made one change at a time and checked the results. Things should start appearing one by one.

Replace each variable ($cid, $hometext, $notes, informant) with the corresponding variable below. Note: if you use any of the $info or $links variables you will probably have to use them along with HTML to get links or formatting.

for instance: modules.php?op=modload&name=News&file=article&sid=$sid&mode=&order=0 will become modules.php?op=modload&name=News&file=article&sid=$info[sid]&mode=&order=0 or use $preformat[title]

If you have lengthy sections of code for formatting your article body, changes are you can just use $preformat[fulltext]

Be creative. Once you do a few, you'll be amazed at how easy it actually is.

Admin Check
Instead of using if ($admin) for your [Edit] [Delete] lines, use the following bit of code:

if (authorised(0, $storyComponent, '::', ACCESS_ADMIN)) {
echo " [ < a href="admin.php?op=EditStory& sid=$info[sid]">"._EDIT."< /a> | < a href="admin.php?op=RemoveStory&sid=$info[sid]">"._DELETE."< /a> ]n";
}

Note: I added spaces in the < a href> and < /a> statements


List of variables from themes.postnuke.com:

$info variables are NOT formatted. They're just raw information from the database.
$info[bodytext] - the main text of the story
$info[briefdatetime] - short version of the date and time the story was published
$info[briefdate] - short version of the date the story was published
$info[catandtitle] - the category and title of the story, in the format 'Category: Title' if the story is in a particular category
$info[cid] - the ID of the category the story is in
$info[catid] - the ID of the category the story is in (deprecated)
$info[cattitle] - the name of the category the story is in
$info[comments] - the number of comments the story has
$info[fulltext] - home text, then body text, then notes
$info[hometext] - the header text of the story
$info[informant] - the person who submitted the story
$info[longdatetime] - long version of the date and time the story was published
$info[longdate] - long version of the date the story was published
$info[maintext] - home text, then body text
$info[notes] - any editorial notes on the story
$info[sid] - the story ID
$info[tid] - the topic ID
$info[topic] - the topic ID (deprecated)
$info[topicd] - the topic ID (deprecated)
$info[title] - the story title
$info[topicname] - the name of the topic
$info[topicimage] - pathname to the topic image
$info[topictext] - description of the topic
$info[unixtime] - the Unix timestamp of the story
$info[version] - the version of the array. This can be used to see if sepcific variabels exist in the array or not.
$info[withcomm] - if the story allows comments to be posted with it


$links variables are just that. Just the URL. They are not formated.
$links[category] - list of items in the same category as the story
$links[comment] - comments on the story
$links[fullarticle] - the story itself
$links[print] - print the story
$links[send] - send the story to a friend
$links[version] - the version of the array. This can be used to see if sepcific variabels exist in the array or not.


$preformat variables are basically plug and play (uhg! Sorry!) They're already formatted and ready to be clicked. All AutoLinks have been inserted and everything. You're probably use these the most.
$preformat[bodytext] - main body of text, including autolinks if any
$preformat[bytesmore] - 'bytes more' link (for back-compatibility)
$preformat[category] - list of items in the same category as the story
$preformat[cattitle] - the title of the story, preceded by it's category (if any)
$preformat[comment] - info on current number of comments
$preformat[fulltext] - home text, then body text, then notes
$preformat[hometext] - initial text, including autolinks if any
$preformat[maintext] - home text, then body text
$preformat[more] - single generic status link (for back-compatibility)
$preformat[notes] - any editorial notes on the story
$preformat[print] - print the story
$preformat[readmore] - 'read more' link
$preformat[send] - send the story to a friend
$preformat[title] - the title of the story
$preformat[version] - the version of the array. This can be used to see if specific variabels exist in the array or not.

The new theming system is VERY powerful, and once you realise the theory behind it, you see it's pretty easy.

I hope this helps someone.

Generated on January 10, 2002.

=-Rogue-= Theme Function   (News)

Obtaining Article Information, Links, and HTML Fragments

1. Getting raw article information

$results = getArticles(where, order, limit)

This function takes three parameters, and returns an array of arrays, each holding information on a particular article. The where, order, and limit variables do not need to specify their initial keywords.

Example:

$results = getArticles("topic=4", "counter DESC", "5");

this will get the five most-read articles in topic 4

Note that the information passed back is pretty much directly from the database. The only real exception to this is that some values are duplicated for backwards-compatibility. These are:

topicid = tid
topic = tid
catid = cid

2. Getting processed article information

$info = genArticleInfo($row)

This function takes a row as returned from getArticles() and does some simple parsing of it to make it more acceptable to PostNuke. The specific textfields created are listed in the user documentation for genArticleInfo(). The operations carried out on the array are as follows:

. add a number of date/time strings
. validate the informant string
. provide a 'Category: title' type article header
. sanitize (and transform) the article title and bodies

3. Getting article links

$links = genArticleLinks($info)

This function takes information as returned from genArticleInfo() and creates a number of links from it suitable both for themes and internal use. The specific links created are listed in the user documentation for genArticleLinks(). The links are 'pure', in that they are straight URLs and have no HTML tags around them.

4. Getting preformatted HTML

$preformat = genArticlePreformat($info, $links)

This function takes information as returned from genArticleInfo() and links as returned from genArticleLinks() and creates a number of preformatted HTML fragments suitable both for themes and internal use. The specific fragments created are listed int he user documentation for genArticlePreformat(). The fragments normally include formatting information and are complete and self-sufficient HTML.


5. Putting it all together

Here is a really simple example that gets a bunch of articles, generates, the relevant information, and uses it to print out a list of headlines.

// Get the latest 10 articles by author ID 5 in descending time order $articles = getArticles("aid=5", "time DESC", 10); foreach ($articles as $row) {

// Generate information for row
$info = genArticleInfo($row);
$links = genArticleLinks($info);
$preformat = genArticlePreformat($info, $links);

// Print a clickable title (with category, if any) and date of the
// story
echo "$preformat[catandtitle] ($info[briefdate])";
}




--------------------------------------------------------------------------------

PostNuke Theme Information

themeindex() and themearticle()

themeindex() and themearticle() take a number of legacy parameters, but also three arrays which hold pretty much all of the information that a user should need to create full-featured themes, and supercede the old parameters. The three separate arrays, and their current contents, are outlined below.

info

info holds raw information. Most of this comes direct from the database query on a story, however some extras are also added. info is guaranteed to have at least the following items:

. bodytext - the main text of the story
. briefdatetime - short version of the date and time the story was published
. briefdate - short version of the date the story was published
. catandtitle - the category and title of the story, in the format
'Category: Title', if the story is in a particular category
. cid - the ID of the category the story is in
. catid - the ID of the category the story is in (deprecated)
. cattitle - the name of the category the story is in
. comments - the number of comments the story has
. fulltext - home text, then body text, then notes
. hometext - the header text of the story
. informant - the person who submitted the story
. longdatetime - long version of the date and time the story was published
. longdate - long version of the date the story was published
. maintext - home text, then body text
. notes - any editorial notes on the story
. sid - the story ID
. tid - the topic ID
. topic - the topic ID (deprecated)
. topicd - the topic ID (deprecated)
. title - the story title
. topicname - the name of the topic
. topicimage - pathname to the topic image
. topictext - description of the topic
. unixtime - the Unix timestamp of the story
. version - the version of the array. This can be used to see if sepcific variabels exist in the array or not.
. withcomm - if the story allows comments to be posted with it

links

links holds a set of 'pure' URLs for a spcific story. These are used to provide ad-hoc links where required by the themer. links is guaranteed to have at least the following items:

. category - list of items in the same category as the story
. comment - comments on the story
. fullarticle - the story itself
. print - print the story
. send - send the story to a friend
. version - the version of the array. This can be used to see if sepcific variabels exist in the array or not.

preformat

preformat holds a set of pre-formatted HTML fragments that fit a standard format. These are generally considered 'intelligent', so for instance a preformat that contains a comments link will contain the correct text relating to how many comments have been previously posted. Pretty much all preformatted text contains URLs. preformat is guaranteed to have at least the following items:

. bodytext - main body of text, including autolinks if any
. bytesmore - 'bytes more' link (for back-compatibility)
. category - list of items in the same category as the story
. cattitle - the title of the story, preceded by it's category (if any)
. comment - info on current number of comments
. fulltext - home text, then body text, then notes
. hometext - initial text, including autolinks if any
. maintext - home text, then body text
. more - single generic status link (for back-compatibility)
. notes - any editorial notes on the story
. print - print the story
. readmore - 'read more' link
. send - send the story to a friend
. title - the title of the story
. version - the version of the array. This can be used to see if
sepcific variabels exist in the array or not.

Example

The PostNuke theme uses these arrays to generate a lot of content, please look at this as an example of how the arrays can be

Generated on November 25, 2001.

Some suggestions...   (News)

With CSS disable and images loading OFF, Post-Nuke is a bit less readable. I mean, it's not easy to see where the previous story end and where the new one start.
Maybe a few extra blank lines or a

---

separator would help ?
With images loading OFF, the layout is different (and sometimes look like a big mess). This is because there are missing WIDTH, HEIGHT and ALT attributes for the IMG element. Beside the aspect, rendering a page is slower too because the page has to be re-rendered each time a new image is loaded.
IMHO, the WIDTH, HEIGHT and ALT attributes should ALWAYS be present.
There are some case where the WIDTH and HEIGHT size cannot be determined at coding time. But here is a suggestion I made several time on PHP-Nuke.org to bypass this problem (I discussed this with hombergs on phpnuke.org's Bug Fix forum when it was alive).
In mainfile.php, add this function:

function GetImgTag($dir, $image, $alttext=" ", $border=0) {
  global $language;

  $path = "$dir/$language/$image";
  if (!file_exists($path)) {
    $path = "$dir/$image";
  }
  $size = GetImageSize ($path);

  $ImgTag = "path"";
  if ($size[0]) {
    $ImgTag .= " width="$size[0]"";
  }
  if ($size[1]) {
    $ImgTag .= " height="$size[1]"";
  }
  $imgTag .= " alt="$alttext"";
  $ImgTag .= " border="$border"";
  $ImgTag .= ">";

  return($ImgTag);
}

Now, if you want to build a IMG tag but you don't know what the size of the image will be, you can just call the function like this:
echo "...something..." . GetImgTag("PicDir", "Image.png", "Alternative text") . "...something...";
To make sure the user name stored in the cookie is EXACTLY the same as stored in the users table (and thus, have a workaround for the savetheme problem); change in the user.php file, login() function, the lines:

  $result = mysql_query("select pass, uid, storynum, umode, uorder, thold, noscore, ublockon, theme, commentmax from users where uname='$uname'");

by:

  $result = mysql_query("select pass, uid, uname, storynum, umode, uorder, thold, noscore, ublockon, theme, commentmax from users where uname='$uname'");

and:

  docookie($setinfo[uid], $uname, $pass, $setinfo[storynum], $setinfo[umode], $setinfo[uorder], $setinfo[thold], $setinfo[noscore], $setinfo[ublockon], $setinfo[theme], $setinfo[commentmax]);

by:

  docookie($setinfo[uid], $setinfo[uname], $pass, $setinfo[storynum], $setinfo[umode], $setinfo[uorder], $setinfo[thold], $setinfo[noscore], $setinfo[ublockon], $setinfo[theme], $setinfo[commentmax]);

In admin/modules/settings.php, the themes list is built using the following code:

  $handle=opendir('themes');
  while ($file = readdir($handle)) {
    if ( (!ereg("[.]",$file)) ) {
      $themelist .= "$file ";
    }
  }
  closedir($handle);

assuming that anything in the themes/ directory that don't have a "." (dot) in its name IS a theme directory; which is bad, bad, bad !!!
(Directories CAN have dots in their names, and files names CAN have no dots at all !)

Someone told me that the is_file() and is_dir() PHP functions were not supported on Windows platforms.
(Why aren't people definitively dropping Windoz ? ;-) )

So, here is another solution:

  $handle=opendir('themes');
  while ($file = readdir($handle)) {
    if (!ereg("^[.]{1,2}$",$file)) {
      if ($test = @opendir("themes/$file")) {
        closedir($test);
        $themelist .= "$file ";
      }
    }
  }
  closedir($handle);

Since PHP-Nuke 5.0, a sumitted story is formatted with the nl2br() function. I don't think it's a good idea, especially when the story already contains HTML tags.
I guess you've done that to find a solution for people who don't know about HTML and wish to have their stories published as they have submitted them ? Well, why not offer the choice then: submit as TEXT or HTML (with TEXT being default).
For text stories, use the PRE element to keep them as is.
As for comments, IMHO:
 - exttrans should keep HREF links as is, convert any conformant URL (starting with the protocol !!!) to link too, ignore (STRIP) any other HTML tags, THEN apply the nl2br() function.
 - plaintext should be just that, no HTML interpretation (so apply the htmlspecialchars() function here, not in exttrans); use the PRE element.
 - html: well, allowed HTML.
The 'lang' cookie (Haa, that awful annoying cookie...) ;-)
Please drop that lang cookie; there's already too much cookies floating around, and this one is not always very usefull (Try to login WITHOUT the lang cookie...).
I personnally find it very annoying to have to tell my browser: "No, I don't want this cookie" for each page I load, whereas the default language of a site suit my needs.
IMHO, the language selection should be a feature offered to registered users only. The prefered language of a user should be a field in the user cookie (yet another good reason to register!), and this will be set only ONCE at loggin time, or when the user decide to change his preferences. No needs for another cookie.
Now, here is how PHP-Nuke should check for the user's prefered language: for each HTTP request,
 - check from the user cookie if a lang is set and use it
 - IF NOT, check if the browser has sent a lang preference in the HTTP header, and use that
 - IF NOT, use the default language for the site.

Ok, I guess it's easier to say it than to do it; so I'll try to provide an alternative for a better language auto-selection. Here is the idea (not tested, I'm writing this as I think about it).
In mainfile.php, replace:

  if (isset($newlang)) {
    if (file_exists("language/lang-$newlang.php")) {
    setcookie("lang",$newlang,time()+31536000);
    include("language/lang-$newlang.php");
    } else {
    setcookie("lang",$language,time()+31536000);
    include("language/lang-$language.php");
    }
  } elseif (isset($lang)) {
    include("language/lang-$lang.php");
  } else {
    setcookie("lang",$language,time()+31536000);
    include("language/lang-$language.php");
  }

by:

  if (!SetUserLang()) {
    if (!SetNavLang()) {
      include("language/lang-$language.php");
    }
  }

(and bye bye the 'lang' cookie... hurray !!!) ;-)

Now, add these functions to mainfile.php (or functions.php ?):

  function SetUserLang() {
    $usercookie = $HTTP_COOKIE_VARS["user"];
    if ($usercookie != "") {
      $usercookie = base64_decode($usercookie);
      $usercookie = explode(":", $usercookie);
      $userlang = $usercookie[10];
      if ($userlang != "") {
        if (file_exists("language/lang-$userlang.php")) {
          include("language/lang-$userlang.php");
          return TRUE;
        }
      }
    }
    return FALSE;
  }
 
  function SetNavLang() {
    $navlang = getenv("HTTP_ACCEPT_LANGUAGE");
    if ($navlang != "") {
      $navlang = explode(",", $navlang);
      for ($i=0; $i < sizeof($navlang); $i++) {
        $tmplang = ltrim($navlang[$i]);
        if ((eregi("^en", $tmplang)) AND (file_exists("language/lang-english.php"))) {
          include("language/lang-english.php");
          return TRUE;
        }
        elseif ((eregi("^fr", $tmplang)) AND (file_exists("language/lang-french.php"))) {
          include("language/lang-french.php");
          return TRUE;
        }
        elseif ((eregi("^de", $tmplang)) AND (file_exists("language/lang-german.php"))) {
          include("language/lang-german.php");
          return TRUE;
        }
        elseif ((eregi("^es", $tmplang)) AND (file_exists("language/lang-spanish.php"))) {
          include("language/lang-spanish.php");
          return TRUE;
        }
        elseif ((eregi("^nl", $tmplang)) AND (file_exists("language/lang-dutch.php"))) {
          include("language/lang-dutch.php");
          return TRUE;
        }
        elseif ((eregi("^it", $tmplang)) AND (file_exists("language/lang-italian.php"))) {
          include("language/lang-italian.php");
          return TRUE;
        }
        elseif ((eregi("^pt-br", $tmplang)) AND (file_exists("language/lang-brasilian.php"))) {
          include("language/lang-brasilian.php");
          return TRUE;
        }
        elseif ((eregi("^pt", $tmplang)) AND (file_exists("language/lang-portuguese.php"))) {
          include("language/lang-portuguese.php");
          return TRUE;
        }
        elseif ((eregi("^no", $tmplang)) AND (file_exists("language/lang-norwegian.php"))) {
          include("language/lang-norwegian.php");
          return TRUE;
        }
        elseif ((eregi("^da", $tmplang)) AND (file_exists("language/lang-danish.php"))) {
          include("language/lang-danish.php");
          return TRUE;
        }
        elseif ((eregi("^sv", $tmplang)) AND (file_exists("language/lang-swedish.php"))) {
          include("language/lang-swedish.php");
          return TRUE;
        }
        /* And so on for other languages available... */
      }
    }
    return FALSE;
  }

Last, you can now drop the old interface language selection, and offer something else to registered users (Eg.: in the user's preference page). This time not creating a 'lang' cookie, but setting a new 'prefered language' field in the 'user' cookie (from this example code, it could be the 10th field in the 'user' cookie).

Off-topic note: Has anyone tried MakeLang on Post-Nuke yet ? How does it work ?


AmigaPhil at ping.be

Generated on July 17, 2001.