PostNuke

Site search

Search results

Number of hits: 11

Url rewriting on Postnuke 0.8   (News)

Main principles of the mod rewrite


For information, the URL rewriting is a module that you can activated in your apache to rewrite the links of a site in order to simplify their reading.

The idea is that the Pn Team also thought that the mod rewrite was not necessarily available / activated on all types of servers (particularly on Windows servers). Indeed, the Postnuke team offers rewritings based on tips already heavily used in management systems like blogs.

Before you begin, here is the format of a link without rewriting.


without rewriting
index.php?module=Users&func=logout Index.php? Users & module = func = logout


URL rewriting without mod rewrite

This rewriting reproduced a "virtual" Folders system on your site, links look like this


URL rewriting without mod rewrite
index.php/Users/logout



In terms of mechanism, it is very simple, when your Web server receives a request for a link, it loads instinctively page "index.html". In this index.php, the parameters of the request are recovered via the header (you can look in "phpInfo" there is a field $ _SERVER [ 'REQUEST_URI'] which corresponds to this information).Then these parameters are interpreted , between the first two "/" is the name of the module, between the two others, the function name. Now Postnuke know the name of the module and function to launch.

You can pass parameters too, for instance, if you want to load a forum with id=2, the links will look like this

URL rewriting without mod rewrite
index.php/Forum/viewforum/forum:2




Note that the url rewriting uses ":" to represent the parameters in a url. So you can't pass variables like this "index.php?variable=filter:3". (be carefull if you are using Pagesetter and his filters system).



URL rewriting with mod rewrite

Optimizing the previous version

In the previous example, all links contained index.php ... but it's ugly, and functionally this file contains no
information useful to load the asked module.This trick is useful when you have no mod rewrite, but if one has an "mod rewrite enabled" server,you can use a "lighter" version of the previous rewriting without an "index.html"



Here is an example



URL rewriting with mod rewrite :Optimizing the previous version
/Users/logout




Be careful, if one of your pictures is written this way and you load the page /MyModule/main/. "/MyModule/main/test.png" which will be searched. Note that you can make a rewriting that redirect all links of the form "/*/*/*.(jpg | png | gif)" to "$ 3. (Jpg | png | gif)." (but it's ugly).


Mode file


This url rewriting is the classical version already used in previous versions of the cms, The rewrited links are lists of words (module name, the name of function) separated by dashes. Note that this version uses a large number of regular expressions rules to do the rewriting compared to the other one, which may increase the load of your server Web.



One example here ...
URL rewriting with mod rewrite : Mode file
module-Forum-viewtopic-topic-2903-start-0.html





Note that the "module" which one would have thought there's no point in it, is made for the support of the "old style" loading of modules.



URL rewriting customized


So here is the coolest feature, which allows you to customize the URL rewriting depending on the module you want to load. Just create a "encodeurl" function in your API module (pnuserapi) that takes as parameters, the information needed to create for output a fully customized rewrited link.

After, the loading of each page of the CMS, a "decodeurl" function in the API part of the module takes care to reformat the encoded url in a form understandable by the CMS.



You can find an example of the use of this method in the module "Pages" of values addons


Format of a encode and decode url
function pages_userapi_encodeurl($args)
function pages_userapi_decodeurl($args)



This feature is interesting because it allows us to have the hands on your url, not only before loading the page, but after loading this page, allowing you post-processing actions rather interessant.




This method allow you to

- put keywords in the url: (see Pages module)
- have a single version of your rewrited url : Indeed, through the post treatment you can recalculate the url and it does not conform to your requirements, you can redirect to the good link via a redirect 301 "Moved Permanently headers.






Use case of a url rewriting "no duplicate"



Notes: A small problem nevertheless for the use of this rewriting, which is limited to the type url "user". (more details here)

This article is a translation from this "how to" released on Postnuke-France

Generated on February 25, 2008.

How to add icons to the Profile (0.8)   (News)

In the standard version the Profile contains just one icon to edit your personal data and one icon to logout.
So, I investigated how this works - as I never used it in over 3 years.
All modules are classified as 'admin' modules or user modules. Every user module and that is the vast majority of modules can have an icon in the Profile folder. What it requires is a pnaccountapi.php file in the modules directory. That means, if you want to show the Pages icon in the Profile folder you need a file named ./modules/Pages/pnaccountapi.php.
This program does not contain much but the definition of the icon to show. Sample content is like this:
[code]function Pages_accountapi_getall($args)
{
if (!isset($args['uname'])) {
if (!pnUserloggedIn()) {
$uname = null;
} else {
$uname = pnUserGetVar('uname');
}
}
// Create an array of links to return
if ($uname != null) {
$uid = pnUserGetIDFromName($uname);
$items = array(array('url' => pnModURL('Pages', 'user'),
'module' => 'core',
'set' => 'icons/large',
'title' => _PAGES,
'icon' => 'pages.gif'));
} else {
$items = null;
}
// Return the items
return $items;
}[/code]

That's it. Pretty easy.

Generated on September 19, 2007.

Development Update, November 2006-05   (News)

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

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

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

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

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

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

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

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

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

Generated on November 20, 2006.

HOWTO: keeping Member List private   (News)

Here's the sql that you can use(remember to drop the table, re-create it, and then insert):
INSERT INTO nuke_group_perms VALUES (1,2,3,0,'.*','.*',800,0);
INSERT INTO nuke_group_perms VALUES (2,-1,4,0,'Menublock::','Main Menu:Administr
ation:',0,0);
INSERT INTO nuke_group_perms VALUES (3,1,9,0,'.*','.*',300,0);
INSERT INTO nuke_group_perms VALUES (4,0,12,0,'Menublock::','Main Menu:(Book Co-
Op|My Account|Logout|Members List|Submit News|Top List|Stats|News|Downloads|Topi
cs|Sections|Search):',0,0);
INSERT INTO nuke_group_perms VALUES (5,0,20,0,'.*','.*',0,0);
INSERT INTO nuke_group_perms VALUES (6,0,13,0,'Menublock::','Subscriber Menu::',
0,0);
INSERT INTO nuke_group_perms VALUES (20,0,19,0,'PostCalendar::','::',0,0);
INSERT INTO nuke_group_perms VALUES (8,0,10,0,'Menublock::','Main Menu:(Modules|
Sign Up|Home|Recommed Us|Web Links):',200,0);
INSERT INTO nuke_group_perms VALUES (11,0,17,0,'Modules::','::',0,0);
INSERT INTO nuke_group_perms VALUES (10,0,14,0,'Stories::','.*',0,0);
INSERT INTO nuke_group_perms VALUES (17,1,5,0,'Menublock::','Main Menu:(Sign Up|
Stats):',0,0);
INSERT INTO nuke_group_perms VALUES (16,0,15,0,'xuser::','(Register|Signup|Activ
ate|Login|ResetPass|SendPass|xuserloginblock)::',300,0);
INSERT INTO nuke_group_perms VALUES (14,2,2,0,'Menublock::','Main Menu:Sign Up:'
,0,0);
INSERT INTO nuke_group_perms VALUES (15,2,1,0,'xuser::','xuserloginblock::',0,0)
;
INSERT INTO nuke_group_perms VALUES (18,0,18,0,'Onlineblock::','::',0,0);
INSERT INTO nuke_group_perms VALUES (19,1,6,0,'Users::','',300,0);
INSERT INTO nuke_group_perms VALUES (21,1,7,0,'Xuserblock::','.*',0,0);
INSERT INTO nuke_group_perms VALUES (23,0,11,0,'Admin Messages:Messagesblock:','
::',200,0);
INSERT INTO nuke_group_perms VALUES (25,0,16,0,'xuser::','::',200,0);
INSERT INTO nuke_group_perms VALUES (26,1,8,0,'Web Links::','::',300,0);

Generated on August 7, 2002.

Permissions Help (needed)   (News)

Admins .* .* Admin Edit | Delete
Moderators Stories:: .* Admin Edit | Delete
Moderators PostCalendar:: .* Admin Edit | Delete
Moderators Menublock:: Main Menu:Administration Read Edit | Delete
Board of Directors Stories:: :Board of Directors: Read Edit | Delete
Board of Directors Stories:: :Members: Read Edit | Delete
Members Stories:: :Members: Read Edit | Delete
Members Categoryblock:: Categories Menu:: None Edit | Delete
Users Stories:: :Board of Directors: None Edit | Delete
Users Stories:: :Members: None Edit | Delete
Users .* .* Comment Edit | Delete
Unregistered Menublock:: Main Menu:(My Account|Logout|Submit News): Read Edit | Delete
Unregistered Loginblock:: .* Read Edit | Delete
Unregistered Stories:: :General: Read Edit | Delete
Unregistered Stories:: :Board of Directors: None Edit | Delete
Unregistered Stories:: :Members: None Edit | Delete
All groups Menublock:: Main Menu:Administration: None Edit | Delete
Unregistered Categoryblock:: Categories Menu:: None Edit | Delete
Unregistered .* .* Read

Generated on July 18, 2002.

Updating PostNuke - a users report   (News)

extra catch, I only have FTP access to the online site, no Telnet or shell access and no access to the database. So, it had to work!
I have a PHP script on the online server that will query the database and extract all the data into a set of files (.sql files and restore.php) that can be used to recreate the database when needed. I've never needed to do it, but its comforting to know that I can. I use this script to transfer the data from the production site to the development site.

NOTE: these notes apply to the above upgrade. Your setup may be different.

The first thing I did was to make an installation on the development machine, in a different directory from the old version. Untar the files etc.

Next, make sure that there was a backup of the old installation database, so that I could rollback if needed. I repeated the installation about six times, backing up to the 0.63 version in between, so a script was needed, something like this:
In /var/lib/mysql make a back up like so:
tar czf pn63.tgz postnuke
Have a script like so:

#!/bin/sh
rm -r postnuke
tar xzf pn63.tgz
chmod 700 postnuke
chown mysql:daemon postnuke

Run this script and afterwards run:
mysqladmin flush-tables

OK, so now we have a backup of our 0.63 version of the database, we have the 0.713 files installed (in a new directory), now we need to copy over the extra themes, modules and blocks that the 0.63 installation used. Put them in the same directories in the 0.713 directory.
IMPORTANT: you will need to keep the PostNuke theme in order to make a first login in the new site. After the site is setup and running, you can remove the PostNuke theme if you don't need it.

Check the naming of the images/avatar files. In the 0.63 install, they were 'graphics/avatar/ava001.gif', in the 0.713 install, they are 'images/avatar/001.gif'. The change in directory name doesn't matter but the change in the gif name does, as your current users will have the gif name stored in their profile. The solution I took was to rename them all to the old names, the other possibility would be to run an update on the database (see later for this).

Copy over the old config file from the 0.63 install and rename it to pn7config.php. Check that the config.php and config-old.php files have 666 mode.

We're ready to run the install.php script now, follow the instructions on screen.
Assuming it was successful, we're now ready to log in as an administrator and configure the site to our needs. If the installation was not successful for some reason, running it again will not work because the installation scripts will complain that the (new PN0.713) tables already exist and abort. We can either modify the scripts to delete the new tables (take a look in pn7.php for this) or simply rollback the database as per my instructions above. Thats why we made a backup!

Right, logged in as administrator? No? One problem could be that if you are installed on an intranet or local machine, then PostNuke will not let you log in unless you use a fully qualified domain name, so make sure you have a fully qualified domain name in the location bar. (i.e. using 'http://mybox/pn7/index.php' will not work, you need to use 'http://mybox.domain.com/pn7/index.php').

Administration tasks:
The first thing to do as administrator is to go to the settings page and configure the site as you need.
Nip over to the comments page to change the name of the anonymous user if you need to.
Then move to the permissions page to set up the permissions.
On the blocks page, disable the Reminder block and set up the other blocks as you need them.
My installation ended up with two admin blocks, the first one activated, the second not. I deactivated the first and activated the second. I then modified the block to show adminstration and logout links.
I also added some links to the menu block. The nice thing about PostNuke0.713 is the abillity to design the menu with the items in the order you want, with the labels that you want.
On the modules page, setup the modules that you need.

Some funny things that I noted:

The main menu had three blank items at the start, which I had to remove using the blocks admin page.
The two admin modules as noted above.
The permissions system is quite complex and powerful, I won't make any description of it here, the online docs do a good job of that, but I will note that if something doesn't work the way you expect, then this is the first place to check.
If you add a logout item to the menu, then you would expect it to read something like:
user.php?op=logout
But if you do this, then the logout will just hang. You need to use:
user.php?op=logout&module=NS-User
Double spaced lines, extra '\n\r' and so on, see the note at the end of this article.
addslashes, stripslashes and the magic_quotes_gpc debacle, see note at the end of this article

By now you should have things working the way you want. Once you have everything checked and OK we want to create some scripts. What we've been through above is far too long winded for a real production site, what we want to do now is to dump out the setup and configuration data and create some PHP scripts that will automatically update the database with the settings we need.
There are two approaches to this. The first is to go in to mysql and dump out the data by hand. The other is to write a script to do it for us. I actually used the first method, but if I was to do it again I would use the second method. In fact, the backup script that I mentioned at the start of the article will do this job for you.

Now the site is setup on our development server, its working the way that we want and we have an update script that will load the configuration data into the database. Good. So, now delete everything in the pn7 installation directory. Using the shell script that I mentioned above, restore the old postnuke database to the way it was in PN63 and check that your old PN63 web site is working the way that it used to.

The next step is to have a dress rehearsal of installing the new site. Follow the instructions above (untar the site, copy over the needed files etc) until you have finished the install script and logged in as administrator. Now run the update script that we made in order to setup the site configuration. This should theoretically take care of all that phatzing around and the site will be set up in minutes instead of an hour.

If some things are not working out, run through the whole dress rehearsal again, modifying the update script in between till all the data that you need is updated. The aim here is to make it so simple that the real production site can be updated in a matter of minutes not hours.

When the whole process is running smoothly, you can go ahead and do the real thing on the live production server. You may want to provide a small index.html informing users of why they can't find the site while the update is taking place. Delete the root files first and put up the index.html. Then delete all the old files, ftp up the new ones, do the install, run the update scripts and the world is a beautiful place.

Some More Notes:
Double spaced lines
On the first run through, all my news stories came out double spaced! For every '\n\r\n\r' in the text I now had ''. Not good, especially when you have hundreds of stories. The offending lines are in the install scipt 'pn7.php' around line 97 there are some nl2br(...) function calls. Comment them out. I haven't noticed any detrimental side effects from doing this.
There is also an informative article at http://abooks.com/lines.htm by Ralph Roberts

The magic_quotes_gpc problem
When you run the install script, on the second page, where it checks the permissions on the config files, it will also check the magic_quotes_gpc setting (in the php.ini file) and warn you if it is set to Off. If it is Off, then it will advise you to turn it on.

The magic_quotes_gpc setting is a PITA. In my opinion PostNuke should not require it to be on, its not necessary. On my Web host, the setting is off, and I have no access to the .htaccess files to override that setting. I can't turn it on. So, I have to find another way of dealing with the problem. I think (but I'm not 100% sure, any feedback appreciated) that a modification to the textsanitizer.php script is all thats needed. Near line 85, these two functions should be changed to look like this:

function oopsAddSlashes($text) { if (get_magic_quotes_gpc()) { $text = addslashes($text); } return $text; }
function oopsStripSlashes($text) { if (get_magic_quotes_gpc()) { $text = stripslashes($text); } return $text; }


Good luck and have fun.
jalal at gnomedia.com

Generated on April 22, 2002.

Permissions for absolute beginners   (News)

Modules and I named it "Main Menu". If you name it differently, you have to name it the same in the "instance", too (see below).

Next thing I did was:

- make some hyperlinks viewable to the admin only. The only thing I had to do was modify (Administration Menu - Permissions - Group - View Permissions) the "instance" of the second default group permission (All groups || Menublock:: || Main Menu:Administration: || None) from instance:
Main Menu:Administration:
to instance:
Main Menu:(Administration|Forum|Members List|Sections|Stats|Top):

This way only the Administrator saw the hyperlinks to Administration, Forum, Members List, Sections, Stats, and Top, the way I wanted it.

- secondly I wanted registered users to see some extra hyperlinks so I modified (Administration Menu - Permissions - Group - View Permissions) the "instance" of the fourth default group permission (Unregistered || Menublock:: || Main Menu:(My Account|Logout): || None) from instance:
Main Menu:(My Account|Logout):
to instance:
Main Menu:(My Account|Logout|Search|Submit News):

This way only the Administrator saw the hyperlinks to Administration, Forum, Members List, Sections, Stats, and Top, the way I wanted it.


So far, so good. However, making a hyperlink invisible doesn't mean it's inaccessible! For example: if you are not an admin, the Members List hyperlink will not be visible to you in the Main Menu(in the above example) but if you know the URL to the Members List (http://www.anysite.com/modules.php?op=modload&name=Members_List&file=index), you could see it even as an unregistered user!

So I went on to try to make the Members List inaccessible to everyone except to Admins(s). I didn't succeed yet. Maybe someone can help? I tried the following permission:

- All groups || Modules:Members List: || .* || None

and put it in third position (from top) but that didn't work. I also tried:

- All groups || Members List:: || .* || None

but that didn't work either... If someone could help me out here, I'd be happy to document it and make it available to the community.

Something that kept me wondering, too, is that when I log into my PN 0.7* site, I cannot vote in my poll. When I log in, I can vote. Obviously this has something to do with permissions but nowhere in the default installation is there any permission that has a "Poll::" component in it!? Why's that?


Furthermore I have some suggestions:

1. Is it just me or is permissions difficult? There's just not a whole lot of examples on Permissions either, is there? First place I looked is in the Online manual (included in PN :-) which is quite good and technical, on docs.postnuke.com and in Permissions for Newbies (thanks to mrherald) but I still couldn't find what I was looking for.

2. Could more groups be included in a default PN installation? Perhaps 5 (or so) levels could be created from Visitor (unregistered), to Junior Member (registered), to Senior Member to Admin? (Just an example.) The only thing absolute beginners would have to do is add users to the correct group, they would not have to worry about (1) creating permissions and (2) having them in the correct order. Titus proposed something similar like that here.

3. Could some of the developpers perhaps include more examples in the Online Manual?

4. Could you setup a forum dedicated to Permissions or a FAQ (Post - Nuke Permissions) or both? I would be happy to add some questions and replies to that FAQ once I get the hang of it!

Reginald

Generated on February 17, 2002.

User SESSION Management   (News)

Greetings all PostNukers!

I was told by many other postnukers that PostNuke 0.7x supports user authentication based on user sessions.

I am using PostNuke 0.73 and am interested to know and understand how can i enable user session on my portal.

The idea of user session is to logout users when they are not using the system or remain idle after a certain period of time.

Please advice me, PostNukers!
anwarsadat@bizcity.f2s.com

Thank you so much. :-)

Generated on February 8, 2002.

Hack for NewUser module permission   (News)

system.First I modify the user.php under NS-NewUser module with the following:if (!(authorised(0, 'NewUser::', '::', ACCESS_READ))) {
include 'header.php';
echo _REGISTERNOAUTH;
include 'footer.php';
return;
}Then I modify the global.php under the module lang eng directory by adding:define("_REGISTERNOAUTH","Sorry this site does not accept user registration at this moment. Please contact site administrator for requesting user account.");
By default, this is enable. If you want to disable the user registration, just simply add a group permission rule: All Realm,

Generated on December 17, 2001.

Session-based logins   (News)

users will work on machines throughout the day. The current system of cookies won't work for us as I know students will forget to logout.

Is it possible to automatically logout the user when they close their web browser? if not, any ideas if/when this feature will be implimented

Generated on December 15, 2001.

Page 1 / 2 (1 - 10 of 11 Total)