-
Custom User Fields Storing Problem
(News)
-
pnUserSetVar($name, $value, $uid = 0){ list($dbconn) = pnDBGetConn(); $pntable = pnDBGetTables(); if (empty($name)) return false;
if (empty($uid)) { $uid = pnSessionGetVar('uid'); if (empty($uid)) return false; }...
#2Making use of the previous change to the API code, the problem could be solved with altering newuser_user_finishnewuser function (modules/NS-NewUser/user.php).Right after the lines that update user table, insert the following:...$result = $dbconn->Execute("sql statement to insert new user...");$uid = $dbconn->PO_Insert_ID($pntable['users'], $column['uid']); if (!empty($dynadata) && is_array($dynadata)) {
while (list($key, $val) = each($dynadata)) {
pnUserSetVar($key, $val, $uid);
}
}...
I found that this change completely solved the problem with custom user data fields storing.
Miklos Kovac
Generated on February 24, 2004.
-
Interview: pnCommerce-Team
(News)
-
Who belongs to the pnCommerce team?
Patrick Cornelissen: First of all there is Mario G. (gzuki) from Priesendorf/Bavaria in Germany who just finished his military service. Next is Frank Schummertz (Landseer) from Stuttgart, Germany. He works as IT specialist in a consulting company. JimHadfield (JimHadfield) is from Big Lake, MN, USA and works there as web designer. I personally live in Bonn, Germany and study computer science and software development. And Sebastian Schürmann, who already introduced himself in another interview ;-) Then there is David, he was also with us at the developer meeting, but his is afk atm so that he also didn't participate in this interview.
Let's begin where it alle started: How did your Postnuke career start?
Patrick.c: I started with Postnuke ~2 years ago. PN was much easier to install and the administrative stuff was/is very comfortable. PN has a lot of 3rd party modules too, that was very impressive.
gzuki: And the good api!
Landseer: End of 2002 I was asked to take care of the homepage of a German dog breeder club. This is a static page with only a few regular updates and my intention was to create a portal site where everyone can contribute something. So I started searching for such kind of system, stumbled upon phpwebsite and phpNuke and finally came to PostNuke. Unfortunately they never agreed to use this system so the site is still not nuked :-(
But at the moment I am working on a nuked website of the company I am working for. It will consist of a external part with information using some static sites with Xexpress and internal sites for the employees with forums, download, employee pages, tim recording and so on.
JimHadfield: I looked at several sites and finally ended up using PN for a group (http://oldihc.org) in Dec. 2001. It's been a success since the very first day. I have PN installed on several sites with some custom modules on some of them.
When did you start working on your own module?
Patrick.c: We started the project ~February 2003
gzuki: joined the team March/April???
Landseer: The breeders club website should contain a webshop for some dog related stuff and so I began evaluating PostKart when Rex stopped development and Pat asked for volunteers to fork. I had plenty of time and so I started working on pncommerce. From January to March I worked 8 to 10 hours per day on pnc. Since two weeks I am also working on the timerecording module pnHora, which will be used on the internal webpage of the company I am working for. It is currently in pre-alpha state.
JimHadfield: From the very beginning ~February 2003
What is your development like? How do you work together?
Patrick.c: Development is a lot of work, but with a good team it's possible to handle it. We communicate by chat, ML, Forums and sometimes by telephone. We also had a developer meeing in august too. I hope that the impact on the community is big :-) because the need for a good shopping cart is evident, so we hope to get positive feedback from the users out there and maybe some more help.
Landseer: PN module development teams consists of people, who normally never meet each other in real life so I work on my own as the others do also. Important decisions have been discussed in our internal dev mailinglist or in our daily chat in our EuIRC channel #pn-commerce. This and email are the most important ways of communicationg with each other. Another big thing is the CVS at sourceforge. CVS is the best thing ever invented for people working at different places :-) Mid of August our first DevMeeting took place in Würzburg, where four of the team met for the first time (generally). Via webcam our documentation guru Jim was also connected. The main development has been done by a couple of developers who could easily agree when we had to make such decisions.
The impact of the community is big, even bigger, after we released the first alpha version. Now the people know what pnc can do and so they can give us suggestions where to go to and what to implement also. Sometimes it's hard to say "Not possible at the moment" :-).
JimHadfield: The response from the community has been fantastic. CVS is a lifesaver!
What is the biggest difficulty in your development?
Patrick.c: One problem, we had, is the bad documentation. The Module Developers Guide has a lot of unclear points and the api documentation documents functions that are not written yet. Dabase has restarted the API Documentation project, so I hope it will get better soon, but this was one of the major problems from my point of view. The unclear information flow from the PostNuke leaders should be more open. We module dev's need all informations about comming changes in API, workflow or whatever as soon as possible, to be able to consider this in our strategy. We don't have time to invent the wheel 4 or 5 times because the layout system has changed for example.
Landseer: Personally the biggest problem is that I had to learn PHP and the Postnuke API at the same time. I started programming in the late 80's with Basic, Oberon and C on an Amiga so the basics are there and the step to PHP was not so difficult.
JimHadfield: My biggest problem (?) was working with a bunch of guys that were great to work with! I don't usually get that lucky!
What features should the Postnuke .8 core have to simplify your work?
Patrick.c: The SSL support for the modurl function we gave the dev team. And Smarty :-)
Landseer: The templating engine that will be in .8 simplifies our work dramatically. We are already porting pnc to Smarty and see, how much code we are going to get rid of in pnuser/pnadmin without minimizing the shop's capabilities. Another needed thing would be generic SSL support in .8, we made a suggestion to the core devs (really easy thing), which did not make it into the .726 package, but maybe in the next one.
Which route will Postnuke/your module in your opinion go in the future?
Patrick.c: Finish Smartification, add custom properties and add the missing small tweaks. After that maybe a compatibility layer to make it possible to use the module on different Postnuke-descendants. Custom properties is one of the most demanded features. You can create for example a tshirt product with it and assign different sizes. The whole thing is very complicated because there are a lot of thigs that we have to keep in mind, so it may take a while until this is completely working.
Landseer: I don't see a clear future for Postnuke (which does not mean that I do not see any future for PostNuke!!). The information politic by the projects leaders is very poor and can be heavily improved. The open module developers mailing list is dead (at least I do not get anything from there), compared to the Xaraya dev list it is more than dead. We can be glad that the community is strong and giving support where it is needed.
JimHadfield: I have to agree with Frank.. Sometimes it is real hard to truly see where PN is going with all of their internal bickering. We will still produce a igh quality product/module that will work with it and others.
What should users of your module regard?
Patrick.c: we have some difficulties with our plugin system and windows servers, the rest works fine most of the time. 75% of all problems occur because people have not filled out the main settings, wrong permissions or missing files.
Landseer: The strongest point is that pncommerce is completely modular and that it can be easily extended. This makes it a very powerful shopping cart solution which will even get better with Smarty, there you can do things which are not possible right now. The 0.82 version still looks to much like PostKart, this is going to change in the next version. Maybe this is the weakest point. But "under the hood" there is nearly nothing from the old program left over, I guess that more than 98% of the code have been changed to meet our requirements. I think that there will be a time when you can see two completely different shops that both use pncommerce, but with their own templates and their own layout.
JimHadfield: The biggest problem?? People do not read the docs...
Anything else you always wanted to say about Postnuke/your module?
Patrick.c: We hope to provide a good module to the community and help Postnuke to cover more areas. In return I hope to get mor
Generated on October 9, 2003.
-
RFC: First PostNuke Electronic Questionnaire Survey
(News)
-
The results of the questionnaires are not for me, they are for the entire PostNuke community and the rest of the world.
The first one, the Webmaster part, is almost done. The questionaire is split into several pages where each page represents a topic and each topic is devided into
experiences,
ratings,
needs,
suggestions
Topics are:
Site Characteristics
Installation
Look, Feel & Usability
Administration
Customization
Software Quality
Scalability
Maintability
Features
Security
Performance
Extensibility
Marketing
PN Development Process
PN Problem Reporting and Tracking
PN User/customer relationship
PN Information Flow and Distribution
PN Development Speed
Total number of questions is around 50.
Now, my request to you, the community: What do you think about a PostNuke questionnaire survey? What would you like to see in a questionnaire? Have i missed something?
I will publish a first testable version at the end of the week on questionaires.theknowledgeworker.com
(not yet active) after considering all your comments and activate it on sunday.
Results will be published one week later. An extract of the table data will be provided, too. That's my current plan which may be subject to change depending on your reactions.
The qestionaires are made with a slightly modified version of phpESP. With the questionaire and result data set i will also release a first basic PostNuke integration of phpESP (called pnESP) next week, too!
So, now it's up to you. Let me know what you are thinking.
Andreas
Generated on February 18, 2003.
-
Two New Postnuke Websites
(News)
-
ticket system for Yofitech by simply changing the tags in the language files and using the topics module as an accounts module.
Instead of stories by topic, I have helpdesk tickets by account number. Here is how it works. Each time we add a new client they get a topic (account) assigned to them and they would publish their tickets (news) under their topic (account). This provides a great way to keep track of and document problems and resolutions both for the client and us. The system sends an email when a new ticket (story) is received notifying us that there is work to be done. The user/client can view their last ten ticket (story) submissions on their personal page which could be used as a personal knowledge base.
I created two seperate categories, Helpdesk and News, to differentiate between helpdesk tickets and news items. This allows me to post news on the site that is readable to the public and yet keep the helpdesk tickets private.
I created a topic (account) for Yofitech news.
I configured the permission system to block all stories by topics (accounts) and stories by categories as the default setting. This way everything is denied, which is a good place to start.
Then I added two new permissions, one for the News category and another for the Yofitech news topic (account), which allows everyone to read our news items.
Thank you Postnuke for making it so easy!!!
Questions and comments can be sent to charles@yofitech.com
Generated on January 16, 2003.
-
Updating PostNuke - a users report
(News)
-
until it went smoothly and then repeat the procedure on the production machine. The production site is not a heavy usage site (~200 user/day), but I wanted the update to not take longer than an hour. As an 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.
-
New Mail on User Registration Hack for Core file: NS-NewUser/User.php
(News)
-
It's actually a fairly non-invasive technique.
First off open up the following File:
$PostNukeRoot\modules\NS-NewUser\user.php
Then go ALL the way to the bottom of the file. At around line 270 you will find the following code:
if($dbconn->ErrorNo()0) {
echo $dbconn->ErrorNo(). "Create default group membership: ".$dbconn->ErrorMsg(). "";
error_log ($dbconn->ErrorNo(). "Create default group membership: ".$dbconn->ErrorMsg(). "");
}
}
Directly under that snippet, insert the following:
// NewUser Mail To Admin Hack
// Author: Cloudrunner of The Noble Pagan
// Website: www.noblepagan.com
$message1 = "A New User Has Registered At $sitename!\n\n They used this email: ($var[email]) to register the following NickName: $var[uname]";
$subject1 = "A New User Has Registered At $sitename!";
$to = "$adminmail";
// End Part 1 of NewUser Mail To Admin Hack
After you do this, jump down to some where around line 278 or so and you will find this snippet:
if ($system == 1) {
Directly below that insert the following:
//Part 2 of NewUser hack
pnMail($to, $subject1, $message1, "From: $from\nX-Mailer: PHP/" . phpversion());
// End Part 2
and Lastly find this code around line 281:
} else {
pnMail($var['email'], $subject, $message, "From: $from\nX-Mailer: PHP/" . phpversion());
and insert this line directly below that:
// Part 3 of NewUser Hack
pnMail($to, $subject1, $message1, "From: $from\nX-Mailer: PHP/" . phpversion());
// End Part 3
Save the file, and then upload to overwrite the file on your server.
Now whenever a new user registers, you will get a short notification email telling you someone has.
You can modify the message sent by modifying the variable: $message1 leave the following within the message quotes however: $sitename, $var[email], and $var[uname].
That's it. I hope that this helps some of you out. Feel free to email me with any questions (even though there shouldn't bee, it's fairly straightforward) at: noblepagan@noblepagan.com
May your dreams come to life.
)O( Cloudrunner )O(
The Noble Pagan
http://www.noblepagan.com
Generated on April 8, 2002.