PostNuke

First of all: Embedding videos into HTML pages seems to be one of the most 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]

I think this is a basis that should allow you to build your own video publication type. It's not too complicated and it works on several platforms and with several browsers.

Links: Riva FLV Encoder 2 Flash Video Player 3.6 Demo

Dot 8 evolving: language files progression and legacy functionality

Thanks to the testing of the community users (yes, YOU!), some legacy functions (residing in /includes/legacy/ have been updated by Simon to solve some bugs. This is another proof that we do need everyone to test the releases and help not only yourself to make this release a success! The following files have also been marked 'deprecated', with an accompanying comment in the DocBlock: admin.php, backend.php, banners.php, error.php, modules.php, print.php and user.php. These files shall be removed in the next (post-dot8) major release.

The overhaul of language files has also applied to the Groups, Theme, Users and Profile modules. These modules now have better multilingual options and (by using the pnML function), making it a lot easier to translate the package and showing better logic in grammar for localisations. Furthermore, lots of open bugs have been solved and the templates have been revised also. For example, the emails sent by the Users module can now be adjusted by just editing a template!

David Nelson has offered to completely review the language files for dot8, and we all have to thank Olaf Fichtner for helping revamp the current language constants. The PostNuke Languages Project is actively following the development!

Important change in the language strings is the use of the _CREATEDBY / _CREATEDON and the _UPDATEDBY / _UPDATEDON constants. For better support in other languages, these are replaced by the following:

• '_CREATEDBY', 'Created by %username%'
• '_CREATEDON', 'Created on %date%'
• '_CREATEDBYON', 'Created by %username% on %date%'
• '_UPDATEDBY', 'Last updated by %username%'
• '_UPDATEDON', 'Updated on %date%'
• '_UPDATEDBYON', 'Last updated by %username% on %date%'

System modules: pnForm and PageLock

Jørn has moved the pnForm framework to it's own module location within the system directory. Major reason for this is to properly save some pnForm specific javascript and style files. Usage of the module should be quite the same. In addition, some new context menu plugins have been added. These plugins create a popup menu to be used as a right-click context menu. More information can be found in the added files in the pnForm plugin directory, and at the pnForm Wiki Pages.

Also introduced by Jørn is a new system module. The PageLock module is a module that helps enforcing single user access to a specific page, by blocking access to other users when one has it open.
Example: User A opens article X for editing. This is registered on the server. User B tries to open article X for editing too. But as soon as the article editing window is opened, it is overlayed with a transparent dark film and a box in the middle tells the user "Sorry this page has been locked by user A - please wait or come back later".
Functionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open. When user A closes the window then the pinging stops and the lock times out. If user B chooses to wait then his page keeps pinging the server for the release of the lock (also Ajax) - and when that happens he gains access to the page. The module can be used on all pages that edites a single item - articles, user data, news items, book pages, permissions settings - you name it.
To use this system, a module author has to use API calls in their own code for adding or releasing a block: pnModAPIFunc('PageLock', 'user', 'pageLock', ...) and pnModAPIFunc('PageLock', 'user', 'releaseLock', ...). To see al this in action, grab the latest nightly snapshot and play around with the HowtoPnForm module: edit a recipe in one browser, and try to edit the same in another browser.

ValueAddons modules: Members_List and EZComments

The Members_List module has been revised by Mark West, with some added configuration options. It is now possible to set the number of (allowed) registered users, and some new blocks (featured user last seen and last x users) have been added. Check out the latest nightly build to see the functionality and options.

Mark has now finished the integration of categories into the user side of the Reviews, Pages, FAQ and News modules. This way, migration of .7x categories into the new Categories module is now supported and can be tested by our users who want to upgrade their .7 site to .8.
Finally, there have been added configuration options for categorization and category titles in the permalinks with these modules.

One hot issue at the moment is the increasing amount of spam that is on lots of websites at this moment. More and more features are to be found on the internet to prevent spam showing on your site. Akismet / Bad Behaviour are one of these. As some already know, Akismet has been applied in EZCommnents for a while. For testing purposes, Mark has implemented a bad behaviour (http://www.bad-behavior.ioerror.us/) function also for testing purposes (as Steffen has found that this could also be a good application). It does need some code hacking to pnApi.php at this moment, so only advanmced users willing to help integreating this feature are invited to test this and report any iussues to the EZComments tracker at the EZComments NOC project page.

Core and API: ThemeUtil and Categories

The pnTheme system has now been converted to the ThemeUtil class. With this conversion, all occurences in the core were updated too. Both the old and the new file are loaded in pnInit for backwards compatibility, but the old file (onTheme) and its functions are now marked as 'deprecated' and will be removed in the next major release.
Also added to the new ThemeUtil is a getModuleStylesheet method which contains the logic from the modulestylesheet plugin. You can do PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename')) to include the value of pnModGetVar('modulename', 'modulestylesheet') or style.css (in this order) or PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename', 'special.css)) to include the special.css file in your rendered page.

While unnecessary for correct functioning of the website, one is now allowed to turn off session regeneration completely. This is added because it may be helpful with a couple of undecided bugs in the tracker at the moment.

Module Development: information for 3rd party Devs!

Axel introduced a very nice application called EasyDist. This allows you to create your own PostNuke package easily. You can find it at modulestudio.de. It is still in a very early stage, but you should get the idea. This is all still in development fase and is just for testing purposes at this moment.

A preliminary for the (automatic) creation of packages using EasyDist is that module authors package their modules in a standard way. Right now, there are different file structures in the ZIPs or TGZs the authors distribute. We came to the conclusion that the preferred file structure inside the archive should be <ZIP> - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in the Guidelines for module developers (not finished as yet).

The work will still take some days as GForge does not not have a nice templating engine like PostNuke - it's more like a 5th grader inventing pnHTML anew. PostNuke 2002 BC :-D

But the NOC already looks a million times better and we would love to get some feedback on it via comment here or the forums.

PostNuke was the first open source project to offer something like the noc to their community. The NOC is the central repository for PostNuke development.

The advantages for modules developers are they can use the infrastructure with CVS or SVN, all the trackers and the forum without having to worry about updating their site or their layout.

Advantages for users, it's the first place to look for modules. And the ease of use because if a user knows how to report bugs or request features at one project they can do this for any other project and don't have to visit multiple sites or create multiple registrations to contact developers.

Another advantage to using a centralized repository is the community doesn't lose modules when developers abandon them. They remain at the noc until someone else picks up the work again.

In order to not turn the list into a normal support list, it will at least start as an invite only list. But archive is public.

We will also use this new developer network to coordinate our efforts regarding the organization of the developers community. For example first ideas about a better NOC are being discussed.

Links:

• Mailing List Archive

One of the new core features in PostNuke .8 is the "PageLock" module. This module can be used to restrict access to a certain page in such a way that only one user at a time has access to it. This can be used to avoid our classic concurrency problem:

1. User A starts editing an article.
2. User B edits the same article.
3. User A saves his work.
4. User B saves his work and thereby overwrites user A's work without knowing it.

If we add a page locking feature to the editing page then this would happen instead:

1. User A starts editing an article.
2. User B edits the same article. But the page is overlaid with a dark transparent skin that blocks the interface. In the middle there's a message "This page is locked by another user" plus some more detailed information about the lock.
3. User B waits until A is finished editing.
4. After some time user A commits his work and user B's window automatically reloads with the new data ready to edit.

This is what the PageLock module will do for you. When user A opens his window it will register it and start pinging the server (using AJAX) every X sec. to ensure the lock is kept. When user B opens his window then it is blocked, but keep pinging the server (also using AJAX) until user A releases the lock.

If you want to use this feature in your modules then please read more in the wiki.

The PageLock module has not yet been used in any of the AddOns modules except the HowToPnForms demo module. The reason is that it potentially may break something and we don't want yet another feature to postpone the .8 release.

Have fun!

CoType is a document editing module. With CoType you can create multiple documents with nested sections in it - just as if you created a DocBook XML file, a LaTeX document or a well structured Word document.

A document consists of nested sections, so you always end up with a structure like this:

Document
  +- Section 1
  |    +- Section 1.1
  |    |    + Section 1.1.1
  |    +- Section 1.2
  +- Section 2

CoType is designed to cover the grounds between a Wiki and a single document.

Wiki elements:

• With CoType you can collaborate on document creation since every person can edit their own sections (can also be open to anonymous users).
• With CoType you can easily link different sections (there is a toolbar button for this in the editor).
• CoType has a complete revision history for each section and you can see who edited what, when and from where.
• Everything is instantly online.
  

Single document elements

• All sections in a CoType document can be printed, exported or downloaded as one single document for off-line use (not feature complete yet).
• You get a nice structured table of content.
• You can read the text linearly from section one and forward.
  

Features:

• Create unlimited number of documents
• Add unlimited number of sections to documents
• Organization sections hierarchically by drag-and-drop
• Automatic table of contents
• HTML WYSIWYG editing using FCKEditor
• Insert cross references
• Support for PostNuke search API
• Complete revision history
• Only one person at a time are allowed to edit the same section. No more overwriting of other peoples work.
  

Future features/ideas:

• Working with images and figures using Mediashare
• Footnotes/end notes
• Bibliography
• Export to DocBook/Html/LaTeX/PDF/Word

You might ask "why a new wanna-be Book module - there's already one (and many other content modules)?". Well, there's a couple of reasons:

• First of all I was not satisfied with Book's interface.
• I wanted to create something that really shows how easy it is to create new modules with PostNuke .8.
  
• I wanted to improve PostNuke .8 with some new features - which is best done while creating something that uses them. So I have improved on the pnForm system in PostNuke .8, added content menus to pnForm, and added the "PageLock" module. The last is a module that restricts access to a single web page such that only one person at a time can edit it.
• No other content module (except Book) focuses on creating a content structure that can be exported or printed as one single document.

It all started with the need to create a book about outdoor sports together with some friends. This triggered the idea of a collaborative document editor, because managing a Word document on four different computers is g'dam awfull. Eventually the book idea died, but the module idea kept on - and here it is.

Download here. 

At last we need a disclaimer:

This is only a demo version - don't expect much support and don't expect your installation to be upgradable (it won't be!)

Support site: www.elfisk.dk.

Until later - happy writing :-)

/Jørn

The docs are auto-generated from the latest SVN code - so the infos are finally up-to-date again.

People interested in starting to work with .8's new libaries should take a look at DBUtil, DataUtil, and SecurityUtil which should be the most important of the new APIs. But they are only an offer - you can still use .7 code in .8 and then include one API at a time.

Links:

• PostNuke API