Configuration OverviewDisplays many site config settings including module, block and theme detection.
Database Access RecoveryRe-encodes database credentials for the config.php file.
Theme RecoveryResets default site theme and/or resets user-applied themes.
Disabled Site RecoveryYou wondered what turning your site off would do...now you know! This utility restores the site to the "on" state.
Modules Module RecoveryDeletes any Modules modules entries found in the database and freshly installs the Modules module to the System category.
Blocks RecoveryA chart displays important block data and allows for disabling and/or deleting any content blocks. Changing the state of multiple blocks at a time is supported.
PostNuke Site SearchA built-in search bar searches the PostNuke site for content by keywords. Searches for matches in the following modules at this time: pagesetter, users, downloads, weblinks, comments, ezcomments, all news stories/topics, and all forums.
PHP InformationPHP info is displayed by section via a tidy menu.
About The ApplicationA dedicated page that displays licensing, credit and other general information.
Additional Features
Cross-browser-compatible CSS layout.
Highly accessible onscreen display.
Visual, interactive, informative navigation.
Various (but few) core images used for aesthetic lists.
Succinct onscreen instructions for each utility.
All actions require confirmation and provide error/status messages.
All forms re-populate themselves upon error.
Applicable current settings are displayed on every page, before and after recovery.
Security
Utilities that are not needed intelligently disable themselves.
User input cleansing.
Filename can be changed without breaking the application.
Time-sensitive application lockdown.
Gracefully Degrades When
PostNuke version is less than .8x.
PostNuke initialization fails.
Application is under lockdown.
Application is uploaded to incorrect location.
Of Other Interest
Written as a PHP class.
Extremely commented code.
Output source is XHTML 1.0 Strict; tidy and skimmable.
Quietly runs with E_ALL enabled.
A big thanks to all who contributed to the original PSAK, which was the strongest inspiration behind this Recovery Console, and to those who contributed with ideas, feedback and testing of the PNRC, thanks for your time and effort!
Dot 8 evolving: language files progression and legacy functionality
Thanks to the testing of the community users (yes, YOU!), some legacy functions (residing in /includes/legacy/ have been updated by Simon to solve some bugs. This is another proof that we do need everyone to test the releases and help not only yourself to make this release a success! The following files have also been marked 'deprecated', with an accompanying comment in the DocBlock: admin.php, backend.php, banners.php, error.php, modules.php, print.php and user.php. These files shall be removed in the next (post-dot8) major release.
The overhaul of language files has also applied to the Groups, Theme, Users and Profile modules. These modules now have better multilingual options and (by using the pnML function), making it a lot easier to translate the package and showing better logic in grammar for localisations. Furthermore, lots of open bugs have been solved and the templates have been revised also. For example, the emails sent by the Users module can now be adjusted by just editing a template!
David Nelson has offered to completely review the language files for dot8, and we all have to thank Olaf Fichtner for helping revamp the current language constants. The PostNuke Languages Project is actively following the development!
Important change in the language strings is the use of the _CREATEDBY / _CREATEDON and the _UPDATEDBY / _UPDATEDON constants. For better support in other languages, these are replaced by the following:
'_CREATEDBY', 'Created by %username%'
'_CREATEDON', 'Created on %date%'
'_CREATEDBYON', 'Created by %username% on %date%'
'_UPDATEDBY', 'Last updated by %username%'
'_UPDATEDON', 'Updated on %date%'
'_UPDATEDBYON', 'Last updated by %username% on %date%'
and can now be accessed through the normal pnml plugin in the templates.
System modules: pnForm and PageLock
Jørn has moved the pnForm framework to it's own module location within the system directory. Major reason for this is to properly save some pnForm specific javascript and style files. Usage of the module should be quite the same. In addition, some new context menu plugins have been added. These plugins create a popup menu to be used as a right-click context menu. More information can be found in the added files in the pnForm plugin directory, and at the pnForm Wiki Pages.
Also introduced by Jørn is a new system module. The PageLock module is a module that helps enforcing single user access to a specific page, by blocking access to other users when one has it open.
Example: User A opens article X for editing. This is registered on the server. User B tries to open article X for editing too. But as soon as the article editing window is opened, it is overlayed with a transparent dark film and a box in the middle tells the user "Sorry this page has been locked by user A - please wait or come back later".
Functionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open. When user A closes the window then the pinging stops and the lock times out. If user B chooses to wait then his page keeps pinging the server for the release of the lock (also Ajax) - and when that happens he gains access to the page. The module can be used on all pages that edites a single item - articles, user data, news items, book pages, permissions settings - you name it.
To use this system, a module author has to use API calls in their own code for adding or releasing a block: pnModAPIFunc('PageLock', 'user', 'pageLock', ...) and pnModAPIFunc('PageLock', 'user', 'releaseLock', ...). To see al this in action, grab the latest nightly snapshot and play around with the HowtoPnForm module: edit a recipe in one browser, and try to edit the same in another browser.
ValueAddons modules: Members_List and EZComments
The Members_List module has been revised by Mark West, with some added configuration options. It is now possible to set the number of (allowed) registered users, and some new blocks (featured user last seen and last x users) have been added. Check out the latest nightly build to see the functionality and options.
Mark has now finished the integration of categories into the user side of the Reviews, Pages, FAQ and News modules. This way, migration of .7x categories into the new Categories module is now supported and can be tested by our users who want to upgrade their .7 site to .8.
Finally, there have been added configuration options for categorization and category titles in the permalinks with these modules.
One hot issue at the moment is the increasing amount of spam that is on lots of websites at this moment. More and more features are to be found on the internet to prevent spam showing on your site. Akismet / Bad Behaviour are one of these. As some already know, Akismet has been applied in EZCommnents for a while. For testing purposes, Mark has implemented a bad behaviour (http://www.bad-behavior.ioerror.us/) function also for testing purposes (as Steffen has found that this could also be a good application). It does need some code hacking to pnApi.php at this moment, so only advanmced users willing to help integreating this feature are invited to test this and report any iussues to the EZComments tracker at the EZComments NOC project page.
Core and API: ThemeUtil and Categories
The pnTheme system has now been converted to the ThemeUtil class. With this conversion, all occurences in the core were updated too. Both the old and the new file are loaded in pnInit for backwards compatibility, but the old file (onTheme) and its functions are now marked as 'deprecated' and will be removed in the next major release.
Also added to the new ThemeUtil is a getModuleStylesheet method which contains the logic from the modulestylesheet plugin. You can do PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename')) to include the value of pnModGetVar('modulename', 'modulestylesheet') or style.css (in this order) or PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename', 'special.css)) to include the special.css file in your rendered page.
While unnecessary for correct functioning of the website, one is now allowed to turn off session regeneration completely. This is added because it may be helpful with a couple of undecided bugs in the tracker at the moment.
Module Development: information for 3rd party Devs!
Axel introduced a very nice application called EasyDist. This allows you to create your own PostNuke package easily. You can find it at modulestudio.de. It is still in a very early stage, but you should get the idea. This is all still in development fase and is just for testing purposes at this moment.
A preliminary for the (automatic) creation of packages using EasyDist is that module authors package their modules in a standard way. Right now, there are different file structures in the ZIPs or TGZs the authors distribute. We came to the conclusion that the preferred file structure inside the archive should be - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in t
selection items come from on the home page. Where this is fine for the current system you will see in a moment why more is needed.
Web Links and Downloads
For multi-lingual selection results to work then obviously there would need to be fields in the link and download item tables to designate what language those items belonged to. So, when a user or admin adds a new item they will need to select via a pull-down which language. That's where the admin configuration of active languages would come in. Why not just have them all listed? Well I suppose you could. But to be honest I really don't want the pull-down to have languages like Klingon and Swahili, when I know for a fact they won't be represented in the results. It would be a waste.
Forums - Why duplicate Hierarchy?
The next idea is a little more radical as I haven't seen any sites or forums employing this yet. Using basically the same idea above. Create a language field in say the "topics" table. Anyone who creates a new topic would either select a language from the same pull-down, or the language would simply default to whatever their $currentlang setting was.
The benefits would be that for sites with a lot of hierarchal structure, that this would not have to be duplicated etc. to give users equal depth and categorization.
What about the Main Headings?
The one stumbling block (and perhaps this is why it has never successfully been done to date) are the name designations for the hierarchal structure. For example:
Web Links:
1. Cool Sites
2. Image Galleries
3. Web Development
a. PHP
b. MYSQL
In the above example you would need a way to be able to apply alternate name designations for the various languages your site supported. But...this is where that active language list would come into play again. If your site only has 2-10 languages then supplying names for each of the lang. versions would not be too cumbersome.
This system could also be applied to the Main Menu multi-lingual function in that case.
If anyone is willing to work on this from a development standpoint I would be happy to help with the project management and UI designs. I can hack code pretty well but this is more project than I am willing to take on by myself.
Primarily I would just like to see what everyone thinks of this idea. A similar point was just made on PHPNuke and it would be a shame to see them offer this functionality first.