PostNuke

Flexible Content Management System

News

news from developement: postnuke-developement on a new CVS-SERVER

Jan: "The reason for the move is that we now have a CVS server with very fine-grained access control up and running, enabling us to implement some ... things like a QA workflow before release. We expect the state of our repository to improve considerably after the move...." (end of citation).

The migration to the new CVS-SERVER is done; The SERVER is unlocked, the new CVS is accessible. Anonymous access is possible with user "anonymous", pass "anonymous".

<a href="http://developer.hostnuke.com/modules.php?op=modload&name=News&file=article&sid=2&mode=thread&order=0&thold=0"target="_blank">Jan und FRED_B have written a <a href="http://developer.hostnuke.com/modules.php?op=modload&name=News&file=article&sid=2&mode=thread&order=0&thold=0"target="_blank"> guide for your CVS-access. Sidenote: -Checkout uses ssh, no pserver!
More news follow;

Here some easy to use <a href="http://www.tortoiseCVS.org"target="_blank">CVS-Clients like TortoiseCVS or <a href="http://www.winCVS.org"target="_blank">WinCVS for your CVS-access. Enjoy it!

martin

Better Multi-lingual Functionality

First off I think there needs to be an admin section for activating or deactivating languages on the site. Currently the system goes out (I believe) and looks at the /languages dir to see what global files are there. This is where the 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.

Thanks for reading.

Jim Starkweather
www.armorama.com



PostNuke is Legacy Free!

With this week's inclusion of the BlockLayout theme templating engine in the core and with the new multi-lingual system nearly ready to be committed into CVS, the future of PostNuke is certainly bright.

The PostNuke CMS development community can be found at http://postnuke.com and welcomes participation at any level.


Templating system for PostNuke chosen

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 <$Revision: 1.44 $> 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 <$Revision: 1.44 $> 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 <$Revision: 1.44 $> 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

Simple Mailing Lists

Footnote: 1

New Sections Functionality?

As this involved numerous core changes to the database and other core files I am not really interested in porting it out as a plug-in Module. Too tricky I'm afraid. But none of what I did is PHP brain surgery, on the contrary it's pretty straightforward stuff. Most of it is purely dynamic, however I did opt for a non-dynamic listing of the sections themselves as I wanted more control over how they displayed and were grouped.

You can view the new look here:
New Sections Design.

Thanks. Comments and feedback welcome.
Footnote: 1

High Quality Nuke Hosting

All of our hosting accounts include:
· Linux based Web servers using Red Hat operating system
· Advanced H-Sphere control panel to administer your domain
· Easy to use Site Studio website creation tool
· FrontPage Extensions
· Scripting Support: CGI, PHP, SSI
· Unlimited Mailboxes with Auto-responders, Aliasing, Forwarding, Catch All Mailbox and Mailing Lists
· Access mail via Web Mail or POP3
· Unlimited domains and sub domains with domain aliasing support
· Unlimited MySQL databases and users
· FTP and SSH access
· SSL Support including Shared SSL Support
· osCommerce shopping cart
· Web Statistics (with Webalizer and Modlogan)
· Apache logs: Transfer log, Referrer log, Agent log, and Error Log
· Virtual and Anonymous FTP with sub FTP account support
· MIME Types Management
· Custom Error Pages
· Pre-installed CGI Scripts (guestbook, chat, forum and counter)
· Free Search engine submission
· And a lot more!

Footnote: 1
First Page Previous Page Page 89 / 277 (881 - 890 of 2763 Total) Next Page Last Page