The modules included in .760 which are templated, and taken direct from the .8 CVS are as follows:
Admin
Admin Messages
Autolinks
AvantGo
Blocks
Censor
Credits
Ephemerids
Groups
Header_Footer
Legal
Mailer
Members List
Messages
Modules
Permissions
pn_bbcode
pn_bbsmile
pnRender
Quotes
Ratings
RSS
Sniffer
Typetool
Xanthia
This represents a significant percentage of the .8 code, but there is still more to do. The aim of this article is to try and outline some of what remains to be done before we can consider a release of .8.
We have identified six main sub projects vital for a release of .8. These projects cover wide areas, and each are at different stages of completion. The six projects, in no particular order, are:
This article also includes a little information on some of the other new code to be introduced with .8 this is at the end, where we look at EZComments and the Error Handler.
The new Database layer reuses the existing pntables information to provide an
object representation of database rows. The advantage of this approach is that
it allows you to basically remove manually coded SQL statements and replace
with what's typically a 1-line statement. Some sample invocations of such code
are shown below:
These functions all return an associative PHP array, or in the case of array
functions, an array of arrays. The fields in this array are cleaned up in
the sense that any field prefixes have been removed. This DB API also
gives you the ability to have generate associative (object) arrays, expanded
arrays with other table fields joined in (which means that you can save SQL
lookup calls) as well as store/retrieve dynamic attributes without altering
the underlying table structure. Together this provides a highly flexible API
which can take care of all storage & retrieval operations.
On top of the DB layer sits the Object Layer. Objects provide a component model
which features transparent persistence facilities. Objects/Classees are loaded
though the Loader API though
and classes are searched for in <module>/classes and take the following naming
convention (for an object called foo):
The object layer is quite flexible; you can use it handle object persistence
but it's also capable of abstracting object class usage cases without providing
persistence. The object layer is built in such a way that for most typical
objects, providing a 5-line constructor is enough to implement the basic
DB persistence features needed. The object implementation provides a lot of
hooks to further customize the behaviour of (complex) objects. Since objects
provide a standard API, handling code (such as pnuser.php) can also be written
to use generic object which results in substantial code savings since 1
function can be built to handle (for example) retrieval of *any* object.
Together the database and object layer allow you to implement complex
functionality while writing very little code thus greatly facilitating and
speeding up module development while resulting in higher code quality since
most persistence operations are now handled by a standard library.
pnCategories is the new central PN category manager. It is based on a
path-based model because this can provide some semantic meaning to the
programmer. In a nested/set based model you would access your Category
through an ID (such as 5231) which has the drawback that 5231 (or any
other number) has no semantic meaning whatsoever. This category manager
uses a path-based approach since this gives allows you to do
which right away tells you "aha, I want the topics catgory". Due to
MySql limitations the path field is not indexed (MySql4 can only index
up to 255 Characters in a text field), however an alternative repesentation
exists internally which is a numeric path field, so that the above path
category retrieval can also be implemented as
This field is indexed and if you access something by a (string) Path, the
first resolution is done by (string) path and any subsequent gets are done
by the (integer) path. There are probably some more refienmens which can be
applied to this model, but fundamentally it works and has proven it's
usefulness since most of the OpenStar modules use this category manager without any
issues.
The category manager also provides 5 extra data fields which means that
the category manager can also be used to provide extended categories (think
of PostCalendar where each category also has a color code associated to it)
without having to write extra code. In short, this category manager has the
potential to get rid of a lot of small supporting tables.
In line with the aim of creating a slim core which can then be expanded on in customised releases, the installer has been recoded to increase the flexibility of the install process. The new installer is now in CVS, and you can test it out by downloading the latest CVS snapshot. The process now includes context driven help links, simplifying the install process for new users.
Xanthia in .8 will be given a major overhaul. The underlying code has been completely rewritten to turn Xanthia into a subclass of pnRender, thereby greatly reducing the size of the Xanthia module, and also giving a performance boost, especially under PHP5. Furthermore, the user interface will also be redesigned, and we are looking at a closer integration of Xanthia's block control and the Blocks module itself. These usability enhancements should help those new to Xanthia build up knowledge of the system quicker, and those already experienced in the use of the module should find that using Xanthia has become 'streamlined', and more intuitive.
One of the major tasks remaining for .8 is in the area of User management, and the user modules in general. This can be further sub-divided into three sections.
Some users of the third party modules pnGroups and pncGroups will already be familiar with the functionality enhancements the .8 Groups module could benefit from. We are investigating adding additional features taken from pnGroups and pncGroups as well as the enhancements already seen in the .760 Groups module.
Simply put, the Profiles module will display all the profile information for a user, in the way that the Users module does currently in .760. Franky Chestnut's advProfile module, as see at pnConcept is the base for this module. It supports Smarty plugins so that third party developers can take advantage of the profile functionality by adding their own information to the page. For example, a user's latest forum posts could be displayed if the correct plugin was available.
There are many feature requests in the NOC Feature Request Tracker that will be implemented into the users system. The key here is flexibility, in .8 we'd like to see the Dynamic Userdata become more usable, and as a result a separate module to handle this functionality has been created. There will also be the ability to search through the userbase for a specific user, and many other enhancements. New features should include:
As previously mentioned, many of the .8 content modules still need to be integrated into the categories system. There also remains further development to be done on some modules. This is a less critical area of development, as the content modules will no longer be included in the main distribution with .8, however all modules maintained by the core development team will be templated through pnRender and fully API compliant in the .8 release.
With the new Error Handler module in .8, a developer can now throw an error using the standard PHP function trigger_error() such as:
In this case the script is stopped immediately and the user will see "myvar is empty!". Normal notices E_NOTICE or warnings E_WARNING will not be shown unless the error handler is configured to do so. Should the user have administration permissions over the module that caused the error the lines of code causing the error will also be shown.
An extension of this might be to log all errors in a database table so that the Admin can check from time to time what went wrong, e.g. missing or duplicate defines that throw a notice, the use of an uninitialized variable or severe errors he has not been informed about by his users. It is also possible to dump all variables that were active when the error occured (which is still under review as ADODB stores passwords in plain text in its object).
We do not use exceptions because they are a feature of PHP 5 and we do not want to raise the minimum requirement for PostNuke from PHP 4.1.2 to PHP 5.x. And exceptions are not as easy to use as the error handler, a lot of code is needed to get them working, mainly in the modules that want to use this feature.
EZComments will replace the core Comments module for .8, removing the disparate and non-API compliant comments solution available in previous versions. The advantage of EZComments is that it provides a single solution to add comments functionality to all module supporting display hooks, and the module also includes advanced moderation features not present in the current version of the Comments module. The recently released RC version of EZComments (see the article on http://mods.postnuke.com gives a preview of the features to expect in the upcoming version. Should you wish to take advantage of EZComments functionality before .8, the News module in .750+ supports display hooks, however a patch is available in CVS for .761 to provide better integration with EZComments until .8 is released. You can download the patch here.
If you are interested in tracking PostNuke's progress towards .8, you can subscribe to the postnuke-cvsnotices mailing list. This send you each change made to the central CVS repository by email, so you can see the changes as they happen. We recommend this primarily for third party module developers. For more general use, the latest snapshots from CVS can be downloaded here. We endeavour to keep the CVS in a working state, however as the PostNuke code is constantly changing things will occasionally not work. If so, please submit an entry to the bug tracker (link below).
Useful Links