PostNuke

Site search

Search results

Number of hits: 43

MediaAttach RC 1 released   (News)

Functional features

With the display and delete hooks file uploads become possible in all hook-capable modules.
Many different file types are supported (images, music, videos, archives, documents, ...)
The most formats can be displayed embedded.
Enhanced file information like for example ID3 tags are read and cached with pnRender.
Also emedding external videos (e.g. YouTube, Google or Dailymotion) is possible.
Users can send files to themselves in mails.


Security

Files can be stored outside the web root, which is advisable absolutely.
If this is not possible, a .htaccess file can be created automatically for protecting direct access.
Therefore all access is handled by module functions and permissions.
A quota support cares for bounded storage limits.


Integration

Users can manage their own files in the profile.
With a Scribite plugin for Xinha media can be inserted in the editor easily.
A support for needles in the MultiHook also provides possibilities to include files in other content.
A Guppy plugin for Pagesetter is enclosed as well to be able to define MediaAttach fields.
Also the Content module is being supported by a flexible plugin.
More profound integration possibilities for special modules exist with create and update hooks.


Migration

An import from the file system is possible.
Moreover import options for Downloads 2, Mediashare, PhotoGallery and pnUpper are ready.


Comfort

Direct support for Categories.
Images can be scaled down.
Space-saving multi uploader if JavaScript is available.
Thumbnails can be cut out individually if desired.
The new search functionality is being supported.
The creation of bit torrents for files is possible.
Comprehensive PDF manual.


MediaAttach can be used as easy as every other display hook module (for example EZComments). But if one engages in it, he quickly perceives that the strengths of this module are it's flexibility and it's adaptability. It not only unifies file management and media integration, but can also be used as a gallery for example. Different annexed template sets illustrate several possible applications.
Also interesting is that one can activate MediaAttach also for MediaAttach itself which leads amongst others to the possibility to attach media to other media items.
The module offers concluding dozens possibilities which can all be used, but may not. For this reason it is excellently suited for being employed in project-specific areas and is furthermore in line with our framework idea why it is going to constitute an enrichment certainly.

Links

Download
Bugtracker
Patches
Feature Requests


Have fun with testing and giving feedback :)

Generated on March 7, 2008.

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.

PostNuke - A Year in Review   (News)

Following on from that, we had the release of Milestone 3 in February, which we used to clear up many bugs in the .8 codebase.

Next, we saw the first release of Scribite, development of a high quality WYSIWYG solution for PostNuke sponsored by the German PostNuke Foundation (read about the latest, 2.0 release here). We also had the appearence of several 0.8 only modules - MultiHook, pnUpper (now renamed to MediaAttach) and Publish. More and more modules taking advantage of .8 technologies were developed throughout the year, and there is an ever increasing selection of modules ready to run with .8 when we release the final version next year.

PageLock, for managing concurrent edits of a page was introduced to PostNuke .8 in March. The PostNuke Recovery Console made an appearence in May, as a .8 replacement for the Swiss Army Knife. At the end of May, CoType (which our Docs team is using to author the new PostNuke .8 documentation) was released to the public.

Unfortunately, in June we hit the well publicised problems with the NOC, which continued for a couple of months and hit the development of .8, delaying RC1 until July. However, RC1 met with a good response and many bugs were fixed.

In August, a new Steering Committee was elected, and Jorn's new Content module (which just hit the 1.0 release) was announced. The 4th Annual pnMeeting convened in Osnabrück during September and there were many interesting talks and discussions held by the 30 or so attendees.

In October we had our first bug fixing weekend, followed by further problems with the NOC, forcing November to be a quiet month. However, on December the 12th we released RC2, which we wish to test over the Christmas holiday in preparation for RC3 or a final release early in the New Year.

So what's to come? I'll leave that for articles to be published in the New Year, but at the very least you can expect the release of .8 final, the unveiling of our new name and the rebranding which goes with it, further development of .9, and some results from our documentation project.

Finally, all that remains is to wish everyone a happy and prosperous New Year. Thanks for your continued support!


Simon Birtwistle [HammerHead]
PostNuke Steering Committe

Generated on December 27, 2007.

pnMeeting 2007: Mark West talks about .8/.9   (News)

system information module will make it easier for webmasters to collect the needed information in case they seek help in the forums.

The use of Ajax makes the handling of various modules far easier. You can drag and drop permissions or user information fields. And on the user side you can for example rate a content item using the Ratings hook using an Ajax function and not having to reload the whole page after rating it.

The new URL system add permalinks to .8 and make URLs nice and readable as you can already find them in other systems like Wordpress. The permalinks can be defined by the administrator and can be included into other modules. It already works for example with the News module and the Pages module. The Pages module in the Value Addons package is the successor of Mark's htmlpages.

Included into the new Theme module is a Theme generator that creates all the basic files and file entries you need to start working on a new layout.

A real enhancement compared to .7 can be found in the block control - Blocks can be dragged and dropped into place and various block setups can be set not only for modules but for single content items.

There are still 2 or 3 major bugs in the bugtracker that are already partly fixed but which must be fixed before RC2 can be releast. That shouldn't take too much time.

In his outlook on .9 Mark explained that all Postnuke releases after Feburary next year will at least require PHP 5.2 - so ask your hosting providers early enough for updates. The background of this decision is the move towards object orientation in the Postnuke codebase and the fact that PHP 5 is around long enough now to become standard.

The language system is the last big project on the roadmap towards Postnuke 1.0 - other PHP projects will be evaluated to find the best solution. In the same move the internationalisation of content will be improved. Direct translations for content must be possible - News articles with the same ID in different languages are the result. Again getText was discussed as a possible solution and the move to UTF-8.

One of the most complex parts of Postnuke today is the Permission system. It is powerful yet often to complicated. So soultions have to be found to solve standard permissions requirements.

Axel Guckelsberger requested an addition to the hooks system - hooks don't know the permissions a user has for the item they are hooked into. So if you want to download a files that is attached to a forum post the permissions to download would result from the a) the permission of the user to view the thread and b) the permission of the user to download files. Hooks are today blind for this. Mark agreed that this had to be changed for future releases.

While talking about hooks Frank Schummertz requested more hook types. Currently we have display, transform, create, update and delete hooks. A required new type is the init or pageload hook that hooks into the start of the system like the spam prevention system BadBehaviour for example that stops the loading of the page if it detects a spam bot.

Mark Ronchera asked for the use of OpenID in future releases which Mark West answered by explaining the flexibility of the .8

Generated on September 9, 2007.

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

Program Schedule and Deadline Dates

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


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

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

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

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

Here are a few suggested project examples:



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


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

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

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


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


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

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

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

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

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

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

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


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



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

Some examples include:


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

Generated on March 7, 2007.

Module Developers: Moving towards .8   (News)

Value_Addons is an example for all major new techniques being used. Most of all the use of the categories can be studied there.

And there are also the first 3rd party developers who started to work with .8 code:


Multihook - The SVN version of Frank Schummertz's Multihook will be 5.0 and is already .8 only. (NOC: Multihook)

pnUpper - Axel Guckelsberger made the upload hook-module far more flexible now and he completely rewrote it for .8 (NOC: pnUpper)

Publish! - Is one of the first modules solely written for .8. There is no release yet, but the SVN version basically works with MS3. Patrick Cornelissen plans to integrate a revision system before the first release. (NOC: Publish!)

If you are also already programming for .8 I would love to read something about it in the comments here or in your own articles.

Generated on March 3, 2007.

Did you know: Place Hooks wherever you like   (News)

now can be displayed everywhere in the template - you can even place the Ratings above your content and the comments right of it.

An exact "How to" can be found in the Developer Wiki"

Generated on March 1, 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.

New web forms framework (PN .8)   (News)

have fields for the title, the content, and an expiration date, and the title is mandatory, so the user *must* write something.

To do this you must go through the following steps:

1. Read the posted values one by one.
2. Verify that the title contains text (validation).
3. Verify that the date is really a date (validation).
4. Generate an error message if validation fails (error handling).
5. Regenerate the input form, but this time include the previous user input (state management)
6. Possibly convert the date to a format readable by the database (database access).
7. Transfer posted values to database.

All of these things must be done for each web form you create. This is very tedious and error prone work, which is why pnForms was introduced to PostNuke: pnForms address all of the 1-6 issues above, and with the use of PostNuke's DBUtil API you can start creating web applications with much much less programming than ever before in PostNuke.

Features
(excerpt from wiki docs):

First of all - pnForms is a clean extension to pnRender! You can do all the stuff you are used to, but you can also make life easier with the extensions.

pnForms is event driven - you supply an object (the page event handler) to the pnForms framework which will in turn call different methods on this object when interesting things happen, like for instance the click on a button.

pnForms builds on Smarty's plugin system and allows you to extend the framework with new plugins (like for instance a GPS input field for your next project). Plugins are heavy on object oriented programming which means you can reuse and extend existing plugins by simple OO-inheritance.

Plugins are also event driven like the page event handler, so your plugin will get notified when certain reactions are required such as rendering the plugin or reading data posted from the web form.

pnForms manages state for you - all variables in your page handler object is persisted accross different calls to the browser. So if you save an article ID in the event object during the first page rendering, well, then it's still available after the next postback of data from the form.

pnForms handles input validation - you just insert a plugin in your template and pnForms takes care of the rest. You will just have to ask the render whether the page is valid or not.

pnForms simplifies database driven data: you supply the database field name to the plugins (defaults to their ID), assigns data to the render's template variables, and then pnForms take care of the rest. If you also use PostNuke's database utilities (DBUtill) then there's very little work left to do for you.

Please read the rest of the article for a complete example.

Current state
All of the above is working now and mostly documented in both code and in the Wiki. So grab the current SVN snapshot of PostNuke .8 and start playing around with pnForms. Look in the Wiki docs for an introduction and pointers to complete code examples.

If you want to try out the user side then look at turmappen.dk which is 100% PostNuke .8 and pnForms based. You can also look into Frank's Multihook module (SVN version only) for ideas - it should already be converted to pnForms (so I was told at least).

If you have questions then please post them in the forums, but since I don't read these regularily I suggest you send a short notice to me at jw-at-fjeldgruppen-dot-dk.

Happy hacking to all of you guys and girls :-)

/Jørn (www.elfisk.dk

Generated on January 21, 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.

Page 1 / 5 (1 - 10 of 43 Total)