PostNuke

Site search

Search results

Number of hits: 99

OS History   (Content)

See http://www.gnu.org/philosophy/free-software-for-freedom.html for more explanation of the difference between the two movements.

The basic philosophy behind open source is very simple: When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, and people fix the bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.

There are many active Open Source Software projects but some may be thinking you get what you pay for, so if it's free there must be something wrong with it. Sometimes this is true but there are open source software projects providing stable, scalable applications. The key is to know where to look and what to look for when evaluating the stability and scalability.

Here are a few interesting facts and examples of Open Source projects:

Apache is the number one web server at nearly 62% of all installations. Second place was help by Microsoft at just under 27%. (Source: Netcraft)
GNU/Linux is the number two operating system at nearly 30% of all servers behind Microsoft operating system at nearly 50%. (Source: Netcraft)

Sendmail (a mail transport agent) sendmail has become one of the standards of the Internet's infrastructure (TCP/IP, Apache, sendmail).

BIND the Berkley Internet Naming Daemon responsible for mapping domain names to IP addresses ran on 95% of all public reverse DNS servers. (Source: Information Sciences Institute of the University of Southern California).
MySQL founded in 1995 by two open source veterans, Michael "Monty" Widenius and David Axmark, with the help of Allan Larsson and claims 4 million installations worldwide and 30,000 downloads of the software per day making MySQL by far the planet's most widely distributed open-source database. (Source: mySQL)

PHP is a widely used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML and as of May 2003 it was being used on 12,487,030 domains and 1,321,203 IP addresses. (Source: PHP)

Linux Operating System is over three years old and has grabbed 13.7 percent of the $50.9 billion market for server computers, and that figure is expected to jump to 25.2 percent in 2006, putting Linux in the No. 2 position. (Source: IDC)

SourceForge a site providing support tools and resources for the OSS/Free Software movement recently announced a major two year

Generated on February 27, 2009.

Development Update, 2008-01   (News)

.8 Final: the next step after RC3
Since the release of RC3, already a lot of bugfixes have been committed to the repository. The developers have agreed to address all new features to the .9 tree, where the two major changes (UTF-8 and gettext, see below) are already in active development. This should result in much shorter release cycles (and earlier release dates) also, and give module developers much more clarification on what to change in order to make their module work under the new major release. If needed, an final bugfizing weekend may still be organised for .8 final.
The upgrade from .764 installations on certain systems has been improved, by increasing the memory_limit to 64M. However, this only works for php version 5.2.1 and above.
Upgrading to .8 together with some 3rd party modules may raise problems when the modules upgrade process is not failsafe for .8 or if the upgrade function uses core functions of modules that are not available yet. Therefore the upgrade of 3rd party modules in general is avoided by following a white list of core modules.
Most site-specific data can already be easily overridden using the /config and /themes directories. The Multisites module however still needs some futher thought on the best way of running multiple sites from a single install. One method having multiple unrelated (i.e. non table sharing) sites of a single install would be to have config/site1, config/site2 etc., this will be postponed to a next release.
The Tour module is now in a state where it can be translated to other languages as well. Just translate the templates and put them in a subdir with the appropriate language abbrevation, all within the pntemplates directory.

MultiCategorization introduction and issues since
As earlier announced, a last fix for supporting MultiCategorization has been added to the core just before the release of RC3. Since those changes, another small fix was then required to be fully backwards compatible. On the module-devs list, the devs have discussed a lot on how to solve these issues. Chances are great that if the new (already committed) patches do not solve the problems, MultiCategorization might be postponed to later versions in order to fully test the new features.
For more information on MultiCategorization, visit this thread in the forum.

DOM extension to use correct paths in JavaScript
Some javascripts, eg. the lightbox, need to know the path to the system and the entrypoint as well (which can be configured in the settings), otherwise they may fail in case of short urls being enabled. Since dynamic javascript creation might be a performance problem, some inline javascript is added to the pagevars to extend the DOM:
- document.location.entrypoint: will be set to what is configured to be the entrypoint
- document.location.pnbaseURL: will point to the result of pnGetBaseURL();
Any ideas on how to make his more unobtrusive are very welcome!

PostNuke Upgrade Distribution
In previous articles and posts, the term '.8 upgrade pack' was used to represent a full .8 package, including 3rd party modules, to upgrade to .8 from an existing .764 installation. However, the term 'upgrade pack' is not quite correct and misleading, because it implies to be an upgrade package with changed files only, while the main parts remain as-is. The transition between .764 and .8 requires a complete exchange of all files, so the so called upgrade package is a complete distribution.
Now it remains what modules should be in an upgrade distribution, to be able to fully upgrade an existing .764 installation, including new versions of 3rd party modules. These include Downloads 2.2, pnMessages, Polls 2.0, bbcode / bbsmile, Weblinks, EZComments and MultiHook at least. This might need some additional testing with certain versions also.

Core changes and additions in the .9 tree
Mark has already overhauled some core API methods and calls. All systems modules are now using the Renderer Class instead of pnRender. Also, a first pass has been committed in changing all pn* function calls to new object method calls. For example, pnModGetInfo is replaced with ModuleUtil::getInfo and pnSecGenAuthKey is replaced with SecurityUtil::generateAuthKey.
For those who did not know: A class pnCompat.php still includes most oldstyle API calls for backwards compatibility.

GetText and Default DB Charset
Bernd is progressing rapidly on integrating gettext in de development tree, and has added po-files for all core modules. The required PHP version for .9 has already been set to a minimum of 5.1.6, and since version 5.0, MySql supports different character sets and corresponding collating orders. To run an application in UTF-8 (unicode) it is not sufficient to change the character set for PN; we needed to set the database encoding (actually server and client) to UTF-8 as well.
A user who wishes to run his site in multiple languages, needs to decide the database encoding at installation time. The default is UTF-8, because the current iso-8859-1 is restricted to too few language combinations. UTF-8 is a 'no-worry' setting because it will work with any language (as long as it is UTF-8 encoded.
This change is $PNConfig['DBInfo']['default']['dbcharset'] = 'utf-8';

To cache or not to cache, that's the question
Also discussed on the devs-list is the current (and future) state of output caching within PostNuke. Why should any application repeat the same processing tasks on a item that hasn't changed?
Not caching anything is fine if one has got infinite resources to throw at a site (and even then there are limits). But in reality there are finite resources and you need to take steps to ensure that those resources are effectively used. One method for that is not wasting precious resources repeating the same tasks time after time.
The key is effective cache management. Currently we put too much load onto the module to handle it's own caching. Once you then

Generated on March 2, 2008.

Using PostNuke and MySQL in Unicode (UTF-8)   (News)

MySql and UTF-8

by: Bernd Plagge
www.choicenet.ne.jp

MySql introduced support for different character sets and collating rules in version 4.1. While this has many advantages databases sometimes need to be migrated and then we have to ensure that the correct character code is set for the new database. We are mainly using UTF-8 and hence you may have to adapt this information to your situation!

What is the problem?

MySql uses as default Latin1, swedish flavour.
How do we check this?

run mysql.
mysql> show variables;

How to check the character set for a particular database?

run mysql.
mysql> show create table


The character code can be set in various places - so where is the best place for this?


We always use UTF-8
------------------------
In this case it makes sense to set the character code for the whole server to UTF-8. MySql actually sets the character code at different levels:
server
client
database connection
database

The character encoding for server, client and the connection work hand in hand to ensure that the data is interpreted correctly. It seems that MySql makes no effort to determine the correct character set but will convert data in accordance with it's configuration. This leads to problems for old databases if the database character code differes from the one configured.

The easiest way to configure MySql for UTF-8 is to put the configuration inot the main configuration file (/etc/mysql/my.cnf).
In my.cnf there are different file sections. So you can't put it just anywhere.

[mysqld]
character-set-server=utf8

[client]
default-character-set=utf8


Setting UTF-8 for one Database
--------------------------------------
You can check the default character code for a database either by dumping the data and then changing the schema file or you can do this online.
You use the 'alter table' statement to change the database using mysql.

run mysql
alter database
default character set utf-8
default collotion_name utf8-general_ci;

note: you may omit the word 'default'.


It is also worth noting that e.g. mysqldump silently adds the default character code when exporting data!
This can causes problems if the character code defined and the database content are different. In such cases MySqldump will try to convert data to it's default character code!
However, you can disable that by adding the character code option when using MySqldump.
e.g. mysqldump --set-charset.

In the same way you may explicitely set the character set.

mysqlimport --default-character-set = utf8
mysqladmin --defautl-character-set = utf8 create


Setting the character code at server start
-----------------------------------------------------
You can start the server with:
character-set-server
collation-server

The current values can be determined with the command

run MySql:
mysql> show variables;


Values may be changed with commands like:

set character_set_server = utf8;
set collation_server = utf8_unicode_ci


Setting the character code within Applications
----------------------------------------------------------
You want ensure that the correct character code is set when connecting to a particular database.

Connect to the database and issue the following SQL command:

mysql>SET NAMES utf8;


SET NAMES is equivalent to the 3 commands:
character_set_client
character_set_connection
character_set_results


How to run PostNuke in UTF-8
-----------------------------------
Several things have to fall into place for this to work correctly.

1) the database encoding needs to be set to UTF-8
2) the application language needs to be encoded in UTF-8
3) PostNuke needs to be told to use UTF-8

ad 1)
see above for details!

ad 2)
The character code for a given language is set in language//global.php (PN 0.76x) or in language//core.php (PN 0.8). Search and adjust the following 3 define strings:
define('_CHARSET','UTF-8');
define('_LOCALE','en_US');
define('_LOCALEWIN','eng');

Of course it is not sufficient just to change the _CHARSET to UTF-8. The text strings themselves need to be encoded in UTF-8. This can be done in a number of ways:
a) use 'recode' or 'iconv' on every language file
b) use the pnlwb (PN Language Workbench) to extract and convert all language files

ad 3)
Following the database initialization you need to issue a "set names to 'UTF-8'" command. As this is done in includes/pnAPI.php we need to patch that file.

PN 0.76x
----------

// load security functions.
include 'includes/pnSecurity.php';

// Load our language files
include 'includes/pnLang.php';
pnLangLoad();

//bplagge 2006-01-31 - charset fix for new MySql version
$dbconn =& pnDBGetConn(true);
$info=$dbconn->ServerInfo();
if ($dbconn->ErrorNo() != 0) {
echo "Error: "; echo $dbconn->ErrorNo();
}
// print_r($info);
$c = _CHARSET;
// Mysql uses non-standard name for UTF-8!
if ($c == 'UTF-8')
$c = 'UTF8';
$query = sprintf('SET NAMES \'%s\'', $c);
$dbconn->Execute($query);
if ($dbconn->ErrorNo()!=0) {
echo "Error: "; echo $dbconn->ErrorMsg();
echo "check pnAPI.php";
}
}
// end bplagge - mysql charset adjustment


PN 0.8
-------

if ($stages & PN_CORE_LANGS) {
// Load our language files
pnLangLoad();
}

# bp 2007-06-01
# need to "set names '' " to ensure correct data handling
$query = sprintf('SET NAMES \'%s\'', 'UTF8');
$result = DBUtil::executeSQL($query, -1, -1, true, true);

Please note that the MySQL character code names are NON STANDARD!

How to check?
----------------
I always found that phpMyAdmin is an excellent tool for MySQL databases. If the data entered in PostNuke is also correctly displayed in phpMyAdmin table browse mode I'm quite confident that everything is fine.

Generated on June 6, 2007.

Pre-Installation Server Compatibility Checker   (News)

server information beyond a limited span of time. Nonetheless, the file should be deleted from the server after use.Quick Rundown
Shows PostNuke's minimum requirements
Verifies and shows current PHP version
Verifies and shows current MySQL version
Provides pass/fail messaging
Displays many ini-related settings
Locks itself down after 20 minutes


Download the PostNuke Server Compatibility Checker utility.

Generated on May 17, 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, December 2006-06   (News)

MileStone 3
The Dev Team is proud to conclude that MileStone 3 is quite near for release (check the .8 Development Cycle for details). With an enormous amount of commits from Robert, Oracle, PostGreSQL and MsSQL support are close (but not quite complete). The entire distribution should be tested for support to ensure the functionality. For this testing, there is an additional Theme plugin added for better / additional sql debug tracing output / options (function.sqldebug.php).
Patrick started finalizing the Search module, which involves every module that provides searchable data to have a pnsearchapi.php file and two templates, module_search_options.htm and module_search_results.htm. For better functionality, each searchplugin is given its own "namespace" via the array functionality of html forms. When each module is compliant to this standard, much gain can be achieved because (for example) inactive modules will not be called for a search query. Also, modules do not need to check for formdata themselves. See also Module Programming Part 4.
Drak has worked on an upgrader for 0.76x. This incomplete first version of upgrade76.php prepares the core so the usual upgrade script process can run.

Categories
The Topics module has been discussed within the theme. As most of you already know, the Categories module is much more powerfull for assigning categories (or topics) to various content on a PN site. The Topics module is an old style module, however lots of modules still rely on the presence of the module (or at least its tables), allthough the modules write directly to the code.
The Dev Team is currently looking for a way to import current Topics into the Categories so that, with an upgrade, on does not have to add these manually. It is up to module developers to support the new categories module, and not rely on the deprecated Topics module anymore. The import process of the Topics module will belong to the Categories module init.
We would like to urge all our test users (not necessarily has to be a developer) to take a look at categories, play around with it, test it, use it and come up with a list of bugs and suggestions for improvements. For feedback, one could use the 0.8-MS2 Feedback and (as always) bugs can be reported to the bug tracker.

System
Discussed in the team is the addition of config.php.dist files. In short, PostNuke is supplied with a dist file which will be read and modified by the installer, and then saved as config.php. The advantage is that config files can not be overwritten anymore when one upgrades it's PostNuke version. The disadvantage is that the webserver user (for example apache) will be the owner of the file. No decision about this issue has been taken yet, so for this time the historic way of config files is still active.
Jörg has worked on a basic check for module directory consistancy. This means, if there are duplicate module names (like system/foo and modules/foo, or even modules/FOO and modules/foo), the administrator will be noticed about this issue.
Another change is that module vars are now all serialized in the database and there is no longer any need for module developers to serialize or unserialize data before making the database calls.
The modules and system directories, and their purposes, were discussed. The system directory should only contain modules that are not allowed to be removed (the system wouldn't work without them), and the modules directory should include ValueAddons and 3rd party modules that are not a vital part to the core of the PostNuke framework. When you upgrade a module, it is left in an unactivated state, which isn't desirable to system modules. Therefore, System modules are now allowed to transition directly to active state after an upgrade.
The Error Logging functionality has been extended. If a pnRender template does not exist this will also be logged, which could be quite usefull for module developers.
The LogUtil::registerPermissionError() and LogUtil::registerAuthidError() methods are added. These method calls registerError and then logs the failed permission check and failed AuthID check respectively, so that they can be analyzed later. DB errors are now logged by DBUtil and Log Events can now be viewed in the Security Center.
Added by Frank is the option in the Users module to deactivate a user account untill the user re-accepts the terms of use. If he is logged in when deactivating the account he will be logged out during the next page load.
The returned header for a non existing user page now returns 404 in stead of 200, and the age check has been simplified and harder to get around.
Frank also enabled the addition of a generic object attribution (a very nice feature of the ObjectUtil) for the users table. Using this, one can add any datafield to the users table (as long as it is a string with max. 255 characters ;-) )
E.g. it is possible for pnForum now to store user related data this way, which makes its own user table obsolete. If you, as a module developer, need a new datafield, just add it and it is there.
Example: You have an attribute 'someattribute' with 'somevalue'. The array returned by pnUserGetVars() now contains an item '__ATTRIBUTES__' which is an associative array itself with key 'someattribute' and value 'somevalue'.
More information and code snippets can be found in the Wiki after the coding has completed.
Finally, the functions includeOnce and requireOnce were added to the Loader class, which speeds up require_once and include_once by a factor of up to 9 times.

New and updated pnRender Plugins
All pnRender plugins in the core will be renamed to lower case. The parameters used should also be lowercase. The Dev Team would recommend all module developers to do the same.
The following plugins were added or modified:

add_additional_header plugin is replaced with the pnpageaddvar plugin.
moduleadminlinks plugin is modified to add capability of separate title attribute, and allow links to be 'disabled'
pndebugenvironment and pndebug plugins are extended with more info and multilingual support
makelinks outputfilter (theme) plugin is a replacement for pn_bbclick, to create clickable links from urls

Finally, Jörn is planning to use the ExampleDB module as an example for the use of the pnForm plugins also.

ValueAddons
Some deletions have been applied to the ValueAddons directory, as follows:

TypeTool: This editor hasn't been updated since ages, the corresponding sourceforge project seems to be inactive for a while, and the html code created by typetool is not following current standards.
Replaced by Xinha (download)
Autolinks and Censor
Replaced by MultiHook (Minimum version needed is MultiHook 5.0 alpha)
Downloads: Maintained by cmods-dev.de
Weblinks: Maintained by cmods-dev.de
Messages
Replaced by pnMessages (download)
Polls
Replaced by AdvancedPolls (download)


Translations / Language defines
Another 'standard' that the Dev Team would like to recommend to module developers is the use of a naming scheme for translations, as it would help a lot to create more multilingual modules.
Each module should use module specific prefixes in their constant defines, e.g. _FOR_SOMETHINGISMISSING for Formicula or _PNMSG_INBOXFULL for pnMessages. This makes it easier for pnDefinemachine and can lead to more consistent translations.
This also enables us to implement an updated pnml plugin/function that offers the same kind of possibilities that the MultiHook has. All translated defines (or missing defines) get a little button that allows the admin to work on the translaton online while surfing his site. Changes will be stored directly in the pnDefinemachine tables to create the language files later on. Here the prefix enables us to attach the translation to the correct module.
Of course looking up translations in the database is a performance hog, but this should be used during development or if someone is not satisfied with an existing translation.
The current SVN packages can be more and more used as a basis for the .8 language packs: dutch and german translations have already been updated for use with .8, and can either be checked out through SVN or be downloaded as an alpha package.

.8 Stabilization: We need you!
To finalize and stabilize the last MileStone release (and to offer a first release candidate as soon as possible), we need you (the community) to test the current codebase. Install and uninstall all available modules, create users, play with hooks, create and use themes, develop modules, and so on.
Please download the latest Snapshot and install it on your test system (either a webserver, or your local Xampp installation). Wether you have IIS, Apache, MySQL, PostGreSQL or MSSql, it is interesting for all of us. Please also use the ValueAddons package and do the same. You may notice that no real new features are added to them, but this will come when the core is functional and as bug free as possible. If at all you find unreported bugs or errors, please report them in the bug tracker.
As already said: The Core Dev Team is at first interested in a working bug-free core framework and a functional upgrade path from historic distriutions. After that, new features can be added to several ValueAddons and other content modules. One could also use the current Theme module to generate Xanthia 3.0 themes. A useful help for this can be found on Drak's Theme Generator. Module Developers can find a Module Generator on the OpenStar site.
BTW, the .8 Developer Docs in the Wiki may already be very usefull, allthough the provided information is not as complete as one would wish for. Users may find lots of usefull information in the .8 User Docs.
Reminder: Please do not use .8 on any live production site! With MileStone releases or Release candidates, there is no guarantee whatsoever that the quality and security of your site and the product is assured!
Also (as read from the German Community Site) there are a few modules released in alpha status for users to test in a .8 environment:

Formicula 2.0 alpha: Download (Bug reports)
pnUpper 1.0 alpha: Download (Bug reports)
pnTopList 1.0 beta: Download (Bug reports)

Generated on December 18, 2006.

Development Update, November 2006-05   (News)

New teamlist member: Ammodump
Ammodump was asked to join the team. As quoted from his introduction in the team: "I enjoy being a community member, and that often my comments hold weight. Sometimes my comments and advice are misguided, but sometimes it is hard to understand others questions ;-) ". With two main hobbies (PN and beer), Ammodump seems to be born for the support team here at the community website.

Remote code injection problem
As some people already know, there is a remote code injection problem with the language parameter as mentioned in the Feedback Forum. Both the .7 and the .8 versions have been updated to fix this security vulnerability, so everybody is urged to upgrade their PostNuke version to the latest release (see also Release Announcement). Some background information: The FormUtil::getPassedValue() function also accepts an input vector GETPOST now. It allows to ensure that the contents of _COOKIE are not taken into account when you get data (as it would be when you go through _REQUEST). The input domain is limited to _GET and _POST and not through _REQUEST / _COOKIE anymore. This is applied firstly to the newlang and thistheme parameters, and has been (and will be) applied to the rest of the core functions additionally.

Session handling
Some features have been added to the session handling in the core system:

Session id regeneration (random and on login/logout), making it even more difficult to hijack a session. This has been achieved without any extra writes to the database, so the feature has no overheads.
The ability to rename the session variable (always was POSTNUKESID), and changing from session file storage to session db storage has been enhanced.
Auth-id check to the user login screen (and block) - this has introduced a login bug which has been entered into the bug tracker and will be fixed by the release of MS3.

The session regeneration options are available in the (upgraded) Settings module.
Also fixed for both the 0.764 release as well as the 0.8 release are some PHP >= 5.2.0 issues due to session handling (See the forums, credits to fredatwork). It seems to solve the problems with PostNuke installations running on 5.2.0 or higher.

Minimum MySQL and PHP versions
The minimum version for MySQL has been raised to 4.1.x, due to some installer problems that are related to old 3.x databases. See also MySQL's lifetime philosophy at Planet MySQL. Due to security reasons, the recommended minimum php-version is at least 4.3.10.

Installer
Now fixed are some install problems with register_globals ON. In addition, there has been added a check for register_globals at the .76x install process for information only. The installation of PostNuke on these environments is nevertheless still possible. Sync with the .8 installer is to be done.

System and core modules
The internal variables statusmsg and errormsg are now arrays: it is now possible to capture (and display) multiple errors. Therefore, pnGetStatusMsg() is renamed to pnGetStatusMsgs() and LogUtil::getStatusMessagesText().
Float handling returns from Ajax has been discussed within the team. It appears that floats in the Non-US locales did not correctly set the decimal delimiters. Therefore, the locale has been set to en_US to ensure this. A solution for writing floats to the DB is still pending.
Robert has added the encryption / decryption methods, using the mcrypt library function, for use in the API.
In the Theme module, the plugins for showing the sitename, slogan and complete title have been altered to use multilanguage support.
The Settings module has some nice dynamic interface elements added to the Security and General function types, increasing useability in this one.
The magic_quotes_gpc recommendation for .8 has been changed. It should be off in stead of on. According to php security group, this feature is inconsistent in blocking attacks, and can in some cases cause data loss with uploaded files. Besides the revert of magic_quotes_gpc recommendation, the SysInfo module now also checks for allow_url_include (new in PHP 5.2) and the suhosin patch/extension.
Finally, all variables retrieved through FormUtil::getPassedValue() are now cached

ValueAddons modules
The Pages module now displays the category that each page belongs to in the overview.
The Error module (or Error handler, where error pages within PostNuke are handled) has been undergoing some changes. System errors, forbidden / not-found errors and specific API errors have their own templates and level of error reporting. A no-auth error will result in a more suitable 403 response rather than a 200-response with a status message. As a result, a lot of code has been altered to correctly use the new Log- and Error message handling.
The Wiki module has been renamed to more suitable 'Wiki_Code', as this module is a transform hook to enable Wiki formatting in content items.
The ExampleObj module has been reviewed, revised and updated by Robert. It should serve as a good example for any module writers

Generated on November 20, 2006.

News from the Core   (News)

said at the PostNuke Meeting in Stuttgart: PostNuke 0.8 is closer than ever and much has been done since the last Meeting in 2005.

Only the release of PostNuke 0.8 Milestone 1 was visible to the community - what you didn't see:

In one year the core team's mailing list counted 3500 mails
In the same time 5400 commits were made to the CVS and SVN - remember 1 commit is not always only 1 file!


If you followed the commits during the last few weeks you might have seen that the changes have become less and less essential. There are many changes that only affect templates and non-core modules.

Andreas Krapohl (larsneo) has enhanced the System Info module, originally committed to SVN by Simon some months ago. You can find out what changes Andreas made in the developers blog: Extended SysInfo in .8

The new categories module has been finished and it has become pretty cool: Every module can now have recursive categories without having to code a module specific solution.

The successor to Xanthia is virtually complete. It will be called "Themes" and Mark West has nearly 40 open source templates converted to the new system that have allowed him to test out theme implementation. The only thing remaining is to work out how to handle the legacy opentable and closetable functions. Creation of a basic theme from the admin panel is now possible (with correct file system permissions) and there are a few pre-done layouts available.

Postnuke 0.8 will be able to run on not only MySQL but also Postgres and Oracle as Frank Schummertz is currently checking out the Oracle compatibility. And Mark West is currently reviewing the feature requests looking to cover any feature requests that impact on the system db tables.

So you see, it's all cleaning up for .8 Milestone

Generated on August 17, 2006.

Multisite Analysis and Design Framework   (News)

Throttle-Status shows a critical analysis of Postnuke Multisite Scalability. Canada Ads Horses is out of the gate and pushing to catch up to the third genertion sequence demonstrated by Toronto. Reiteration improvements outlined briefly at this advancement describe the actual start date of the fourth generation sequence.

Lethbridge improved considerably as a direct database dump transfer over the previous second generation original creation Edmonton Work Wanted in the transfer to the Linux Guru domain. The main fault and subsequent end of life for municipality based linux advocacy and teaching sites arose from being replicated too much like the original.

First generation analysis of Swingerz was and still is the origin of thought for further analysis of multisite design. Each surviving platform gives clues as to what can be expected from the next generation. With a Black Diamond arriving in the heart of cowboy country this forth generation prototype takes its first cautious steps towards easy country living.

She's running the latest Regina post apocolyptic armagedon core. It consists of a highly customizable and extendable admin modular interface. The armagedon core prototype is slated to start undergoing basic sql preparations for advanced graphical user interface considerations almost immediatly.

Even in it's earliest infancy the post apocolyptic armagedon core proved invaluable in singular module replication affecting over three hundred websites with a one percent non-catastrophic failure rate. The armagedon core was in essence responsible for bringing the ads22Transfer.sql file to life after dump and proves that other data reiteration ideologies for Multisites are only hypothetical. Par for the reusable and simplistic module NS-MySQL_Tools

The practicality of of generating a large index of Multisites in one intall routine remains well tried according to this article. The data processed by the failure of the second generation reiteration concatenated with sequential envolution1-20 dot linuxguru.ca predisposed any notions of any glitzy bells and whistle transfers in the future. Neither is hand instantiation an option as evidenced in the heretofore previously mentioned article. It was the beginning of an unanswered and even unthought of question though.

It had something to do with creating an acceptable amount of content and community at an acceptable rate within standards applied by society. I find that having tried the blogging regression theories presented at this Drupal thread that I am still undergoing analysis of this project. The scope of my blogging content dissemination and aggregation theories reached a pitch with this announcement and slowly died an aggregating and aggravating RSS plague of duplicate destruction cumulating with the recinding of backend.php files from all root web directories.

With the creation of another advanced portal, very much like this one in many respects I continue to explore the bounds of Multisite

Generated on January 23, 2006.

The Road to .8 - Where are we, and where are we going?   (News)

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.

Six Main Projects for PostNuke Development
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:


Integration of Open Star object library and Database Utility
Integration of Open Star category management
Installer
Xanthia
User management
Finishing of content modules

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.
Integration of Open Star Object Library and Database Utility
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:

[code]
$myObj =& DBUtil::selectObjectByID (, $id);
$myObj =& DBUtil::selectObject (, $where);
$myObjArray =& DBUtil::selectObjectArray (, $where, $sort);
DBUtil::insertObject ($myObj, );
DBUtil::updateObject ($myObj, );
[/code]
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
[code]
Loader::loadClassFromModule (, 'foo') //

Generated on November 3, 2005.

Page 1 / 10 (1 - 10 of 99 Total)