-
pnRender cheatsheet
(News)
-
Working with pnRender was espacially complicated: Some stuff you best read at http://smarty.php.net and you also always have to have an open pnRender plugins directory so you can open the plugins you need and look up the exact syntax.
I tried to put the basic smarty stuff and the most frequently used pnRender stuff on just one page. And the great thing is: I am willing to share it with the community.
Personally I already love the cheatsheet - It contains the syntax with the backticks! And the date specifiers!! And the parameters for pnmodurl, pnmodfunc, pnmodapifunc aso!!! And I always forget in which order truncates parameters are. That's all on that on sheet!
I hope you like it too.
Download: pnRender cheatsheet 1.0
Generated on May 28, 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.
-
PHP 5.0.1 Released!
(News)
-
Version 5.0.1
12-Aug-2004
* Changed destructor mechanism so that destructors are called prior to request shutdown. (Marcus)
* Rewritten UNIX and Windows install help files. (Documentation Team)
* Updated several libraries bundled with the windows release which now includes libxml2-2.6.11, libxslt-1.1.7 and iconv-1.9.1. (Rob, Edin)
* Improved and moved ActiveScript SAPI to PECL. (Wez)
* Fixed unloading of dynamically loaded extensions. (Marcus, kameshj at fastmail dot fm)
* Fixed ReflectionClass::getMethod() and ReflectionClass::getProperty() to raise an ReflectionException instead of returning NULL on failure. (Sebastian)
* Fixed convert.* filters to consume remaining buckets_in on flush. (Sara)
* Fixed bug in mysqli->client_version. (Georg)
* Fixed bug #29606 (php_strip_whitespace() prints to stdout rather then returning the value). (Ilia)
* Fixed bug #29577 (MYSQLI_CLIENT_FOUND_ROWS undefined) (Georg)
* Fixed bug #29573 (Segmentation fault, when exception thrown within PHP function called from XSLT). (Christian)
* Fixed bug #29522 (accessing properties without connection) (Georg)
* Fixed bug #29505 (get_class_vars() severely broken when used with arrays). (Marcus)
* Fixed bug #29490 (.Net object instantiation failed). (Michael Sisolak).
* Fixed bug #29474 (win32: usleep() doesn't work). (Wez)
* Fixed bug #29449 (win32: feof() hangs on empty tcp stream). (Wez)
* Fixed bug #29437 (Possible crash inside array_walk_recursive()). (Ilia)
* Fixed bug #29431 (crash when parsing invalid address; invalid address returned by stream_socket_recvfrom(), stream_socket_getname()). (Wez)
* Fixed bug #29409 (Segfault in PHP functions called from XSLT). (Rob)
* Fixed bug #29395 (sqlite_escape_string() returns bogus data on empty strings). (Ilia, Tony)
* Fixed bug #29392 (com_dotnet crashes when echo'ing an object). (Wez)
* Fixed bug #29368 (The destructor is called when an exception is thrown from the constructor). (Marcus)
* Fixed bug #29354 (Exception constructor marked as both public and protected). (Marcus)
* Fixed bug #29342 (strtotime() does not handle empty date string properly). (Ilia)
* Fixed bug #29340 (win32 build produces invalid php_ifx.dll). (Edin)
* Fixed bug #29335 (fetch functions now use MYSQLI_BOTH as default) (Georg)
* Fixed bug #29291 (get_class_vars() return names with NULLs). (Marcus)
* Fixed bug #29264 (gettext extension not working). (Edin)
* Fixed bug #29258 (variant_date_from_timestamp() does not honour timezone). (Wez)
* Fixed bug #29256 (error when sending large packets on a socket). (Dmitry)
* Fixed bug #29236 (memory error when wsdl-cache is enabled). (Dmitry)
* Fixed bug #29147 (Compile Error in mnoGoSearch functions). (Sergey, Antony)
* Fixed bug #29132 ($_SERVER["PHP_AUTH_USER"] isn't defined). (Stefan)
* Fixed bug #29119 (html_entity_decode() misbehaves with UTF-8). (Moriyoshi)
* Fixed bug #29109 (SoapFault exception: [WSDL] Out of memory). (Dmitry)
* Fixed bug #29061 (soap extension segfaults). (Dmitry)
* Fixed bug #28985 (__getTypes() returning nothing on complex WSDL). (Dmitry)
* Fixed bug #28969 (Wrong data encoding of special characters). (Dmitry)
* Fixed bug #28895 (ReflectionClass::isAbstract always returns false). (Marcus)
* Fixed bug #28829 (Thread-unsafety in bcmath elementary values). (Sara)
* Fixed bug #28464 (catch() does not catch exceptions by interfaces). (Marcus)
Generated on August 13, 2004.
-
Templating system for PostNuke chosen
(News)
-
The decision was reached through the following 6 criteria.
Performance
The chosen system performed considerably better than both the existing theming engine and the Encompass engine. Testing indicated a performance increase of 15% compared to the existing engine and 95% compared to the Encompass templating engine. Further gains due to optimization are likely. Benchmark results are appended at the bottom. Please note that while great care was taken to benchmark all contenders in the best possible way, there is always room for discussion with benchmark results. The results support the verdict with a satisfactory margin of error however.
XML syntax
Having a good XML story is crucial going forward, with XSLT and related technologies replacing HTML longer-term. The chosen engine uses XML Namespaces to prepare PostNuke for a point in time where it will be feasible to turn over some of the rendering duties to the client. Furthermore, XML increases readability and provides less of a learning curve than Smarty's syntax. XML syntax also allows easy development of templates within WYSIWYG HTML editors.
Small codebase
An important consideration in the decision was overall code size. Smaller code has a large maintenance advantage, and thus weighted heavily in the decision. The Blocklayout engine weighs in at 15KB, the Encompass engine weighs 227KB - 400KB, depending on what is counted.
Hierarchial templating
Templating should be hierarchial for maximum expressive power. This allows to compose page layouts from small building blocks. The chosen engine embodies this concept.
Directory structure
Encompass stores all templates in one folder, regardless of type. Blocklayout separates templates by classification.
1) pages/ - Full page skeletons
2) blocks/ - Block templates
3) modules/(modname)/(functype)/(funcname)/ - Module output templates;
there can be multiple, interchangeable templates for the same module
function even within the same theme. If one is not present the module
uses its own internal default.
Integration with Roadmap
PostNuke has been evolving very rapidly over the course of the last year. The future will bring more changes still. It is imperative that the templating system be able to cope with changes. One way to do that is to have a clear plan where the future direction is concerned. Another is to have a team that is in constant communication with the
PostNuke team.
Information on Blocklayout
Templates
There are 3 kinds of templates in Blocklayout, Master, Slave, Internal. Masters define the overall layout of the page. Slaves "dress" each piece of centent in the theme. Internals lay out the actual content.
Template Locations
Modules and Blocks are distributed with an Internal template for each function that deals with output. These templates are used if there is no correspoding template in the theme. Themes are not required to contain Internal templates.
In fact, I suggest that themes don't. Internal templates in themes is intended as a way for each individual site owner to customize their site even more; the ability of theme designers to include Internals in their theme is a bonus. Obviously, it would be impossible for a theme to include templates for every module.
Themes are only required to contain Master and Slave templates. The Master templates remove the limitation of the 5 zone layout PostNuke currently has. Slave templates replace and extend certain functions within theme.php, such as
themesideblock() and OpenTable() / CloseTable().
Having a standard set of CSS classes will ensure that any properly designed module will integrate with any theme, without the need for any theme to contain Internal templates. This also gives PostNuke the ability to be laid out completely with CSS. Other classes can be added by the theme designer. This also reduces reliance on theme variables such as colors.
Blocklayout Specification
http://www.thedragonsforge.com/postnuke/blocklayout_40.html
Benchmark Results
Encompass:
ab -n1000 -c2 site1
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: 8.hostnuke.com
Server Port: 80
Document Path: /pn713/index.php
Document Length: 35277 bytes
Concurrency Level: 2
Time taken for tests: 437.928 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 35778000 bytes
HTML transferred: 35277000 bytes
Requests per second: 2.28
Transfer rate: 81.70 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 39
Processing: 659 875 1091
Total: 659 875 1130
Blocklayout:
[root@ns5 /root]# ab -n1000 -c2 site2
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: 8.hostnuke.com
Server Port: 80
Document Path: /html/index.php
Document Length: 9315 bytes
Concurrency Level: 2
Time taken for tests: 223.446 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 9832256 bytes
HTML transferred: 9321746 bytes
Requests per second: 4.48
Transfer rate: 44.00 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 2
Processing: 271 446 656
Total: 271 446 658
Traditional PostNuke:
[root@ns5 /root]# ab -n1000 -c2 site3
This is ApacheBench, Version 1.3c apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/
Server Software: Apache/1.3.19
Server Hostname: developer.hostnuke.com
Server Port: 80
Document Path: /index.php
Document Length: 12971 bytes
Concurrency Level: 2
Time taken for tests: 260.773 seconds
Complete requests: 1000
Failed requests: 259
(Connect: 0, Length: 259, Exceptions: 0)
Total transferred: 13475259 bytes
HTML transferred: 12971259 bytes
Requests per second: 3.83
Transfer rate: 51.67 kb/s received
Connnection Times (ms)
min avg max
Connect: 0 0 4
Processing: 359 521 758
Total: 359 521 762
Generated on May 28, 2002.
-
Spanish translation for Rogue .711
(News)
-
Ya está disponible en postnuke-espanol.org la versión de los ficheros en español para Postnuke Rogue .711.
Como siempre, hemos intentado crear una versión lo más neutra posible, de forma que pueda servir para todos los usuarios de España y LatinoAmérica, evitando todo tipo de localismos .
Esta versión es en español informal (de "tu")
Próximamente tendremos la versión formal (de "Usted")
Generated on April 4, 2002.
-
Rogue .711 Release
(News)
-
Changelog for PostNuke 0.71.1. I believe Jim McDonald should recieve credit for most of these fixes.
- AOL users and other users with dynamic proxies or IP addresses can now log in and use PostNuke sites as normal
- Sites can now display HTML entities in their text (e.g. {) by setting the appropriate option in the administration settings panel
- Voting on polls should now behave itself better
- Minor fix in weblinks block for some php.ini settings
- Various fixes to langauge files
- Can now delete stories without errors
- Fix for those with News permissions to be able to add stories
- HTML tags now show correctly in comments
- Editing permissions no longer resets the group in some situations
- Extralite theme now works correctly on all PHP setups
- Whitespace removed from mainfile.php
- Repeatedly previewing a story no longer gives an authorisation error
- Fix for error when viewing FAQ with story-related blocks on the left-hand menu
- HTML display of email addresses now works on all browsers
Enjoy!
Generated on March 24, 2002.
-
Content Management Ideas
(News)
-
management database schema would include 3 tables. Read over the setup here, and if you have any questions, please let me know.
This is of course the most obvious. Content at the base level is the same across the board. Whether the content is news, articles, section content, or whatever you want to call it (heck, even comments!), they are all the same.
Table Schema and Explanation
Table: content
Field: id
The id field is simply the unique id (or a sequence) of the content. This is common enough.
Field: type
Somewhat abstract, however, type is important in human terms. What 'kind' of content is this? Content can a front page news article, section content, heck, even comments or forum posts. This allows for a special abstraction and making this system a core system would allow other applications using PostNuke a common content setup to use. They could define their own 'type' of document, and simply use that table. This would make searching the content of the site really easy as well.
All news items could have the 'news' declaration put on them. Namespaces would have to be enforced, so you could enforce a 'modulename_type' of system, and use 'core_type' for anything the core system uses.
Field: status
Status is important in a CMS. Content Management is the key, and just because content is in the system doesn't mean anyone should be able to look at it. It is important to remember what a CMS is. Giving status several possible values, like "Published", "Under Review", "Editing Phase 1", "Editing Phase 2", "Rough Draft" and finally, "Queued for Deletion" would allow PostNuke to take on a better CMS status. Integrating this with your proposed new user system could also be a boon, allowing only certain levels of users to "Publish" content finally. You can also set certain types of content, like comments, to be set to "Published" automatically, or allow admins to create "content rules".
Field: promotion
Another abstract term, yet something used to help describe how the system should handle the data. Most obvious use is the Drupal style of promoting the content, whatever it is, to the front of the page. This means you can quickly and easily add new content, or a comment, as a front page news item and 'promote' it. Of course, setting up something so that all "news" items are set as being promoted to the front page would be a good case.
Field: title
Self explanatory, the title of the content.
Field: abstract
Self explanatory, the abstract of the content.
Field: content
Finally, the content itself.
Table: content_author
Basically a one-to-many setup here. Content can have more than one author, and setting up an author's table containing important authors info would be important. This can link to the users table if need be, but not all author's may be users.
Field: content_id_fk
Foreign key to the content id.
Field: author_id_fk
Foreign key to the author id.
Table: content_category
Again, like the content_author table, content may be contained under more than one category. An article on PHP and MySQL may fall under 2 categories, PHP and MySQL.
Field: content_id_fk
Foreign key to the content id.
Field: category_id_fk
Foreign key to the category id.
What we have here is a working content model. As you can see in the diagram, we have defined content in a relatively simple matter.
Overall, it is important that content be managed as a core system. However, defining the content should be left up to the modules
Generated on December 10, 2001.
-
Croatian language Post Nuke support
(News)
-
Translation can be downloaded following this link:
Cro Post Nuke lang.
See you arround
CroNukers Team
Note for PostNuke.com admin:
Please coul'd you add http://www.cronukers.com at postnuke.com as site for Croatian Support like you have for Espanol, Deutschland, Italy ..
Allso I woul'd be glad that you add Croatian translation from above listed url in Rogue version and on CVS.
Generated on November 24, 2001.
-
PostNuke-Espanol.org: Meeting point for spanish community
(News)
-
In the next weeks, we will be adding more modules and translating them.
Hasta la vista :)
P.S.: The files will be sent also to Posnuke.com, so they can be included in the official packages if aren't available yet.
Generated on October 13, 2001.